OIDC authentication with Microsoft Azure

This content borrows heavily from the Microsoft Entra single sign-on (SSO) integration with HashiCorp Boundary documentation.

1. From the Microsoft Entra ID view, select Enterprise applications using the sidebar on the left side of the page.

   

2. From the Enterprise applications view, click the + New application button.

3. Type hashicorp boundary in the search bar, and click on the HashiCorp Boundary result.

   Confirm the name of your Boundary integration (this example uses HashiCorp Boundary) and click Create.

   

4. From the HashiCorp Boundary | Overview page, click Single sign-on.

   From the HashiCorp Boundary | OIDC-based Sign-on page, click Go to application.

   

5. Click Authentication under the Manage sidebar.

   Provide the redirect URI, which is http://localhost:9200/v1/auth-methods/oidc:authenticate:callback when Boundary is running in dev mode.

   Paste the following redirect URI in the Web field.

   http://localhost:9200/v1/auth-methods/oidc:authenticate:callback

   Scroll down and locate the Front-channel logout URL. The logout URL ensures session logouts are handled correctly.

   Construct the logout URL by appending :3000 to the end of your Boundary's https URL. In Dev mode, this is:

   https://localhost:3000

   Click Save.

   

6. Select Certificates & Secrets from the Manage sidebar on the left. Click New client secret and fill out the secret details. This tutorial describes the secret as Boundary OIDC test secret.

   Click Add.

   

   Copy the client Secret value and store it for use later. Ensure you grab the Value, not the Secret ID.

   

7. Lastly, navigate back to the App overview view using the menu on the left.

   From this view, copy the Directory (Tenant) ID and the Application (client) ID.

   

   You will also need to construct the application Issuer URL.

   An Entra ID OIDC identity provider issuer is usually formatted like https://login.windows-ppe.net/Tenant_ID/v2.0, but it may vary depending on your account.

   This is constructed from the OpenID Connect metadata document value, which is located in the application Endpoints view on the Overview page.

   Click on Endpoints. Copy the OpenID Connect metadata document value, up to the /v2.0. For example,

   https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0

   

   This value will be the Issuer used to configure the Boundary OIDC auth method.

   Note

   You may need to refer to Entra OIDC documentation for the latest OIDC endpoint schemas.

   Three important values are needed to configure OIDC with Boundary.

   • Issuer
   • Client ID
   • Client Secret

   The following format is used for these values:

   • issuer -> https://login.windows-ppe.net/Tenant_ID/v2.0 (copied from OpenID Connect metadata document)
   • client-id -> Application (client) ID)
   • client-secret -> Client Secret value

   For example, this tutorial uses the following values:

   • Issuer: https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0
   • Client ID: a4d21a76-e08c-4d8d-8c47-e1c423ee4d11
   • Client Secret: X9u~u58--~rWLR4Q9i1-PtdZOi_s04~9O-

   Keep these values in a safe place for use in the next steps.

This content borrows heavily from the Microsoft Entra register an application documentation.

1. From the Entra ID view, select App Registrations using the sidebar on the left side of the page.

2. From the Applications view, click the + New Registration button.

   

3. On the Register an application page, name your applciation and select its tenancy model. For this proof-of-concept tutorial, select Single-tenant. This tutorial names the application Boundary OIDC Test.

   Under Redirect URI select the Web field. In dev mode, Boundary's callback URI uses localhost:9200.

   Paste the following redirect URI in the Web field.

   http://localhost:9200/v1/auth-methods/oidc:authenticate:callback

   Click Register.

   

   Once registered, you will be taken to the Overview page for your new app registration.

4. Select Certificates & Secrets from the Entra ID menu on the left. Click New client secret and fill out the secret details. This tutorial describes the secret as Boundary OIDC test secret.

   Click Add.

   

   Copy the client Secret value and store it for use later. Ensure you grab the Value, not the Secret ID.

   

5. Select Authentication from the Boundary OIDC test menu on the left.

   Click Configure.

   Under Redirect URIs, verify the callback URI you constructed earlier using the following format:

   http://localhost:9200/v1/auth-methods/oidc:authenticate:callback

   Update the callback URI if it is missing or incorrect.

   Under Front-channel logout URL, enter the following:

   https://localhost:3000

   This ensures session logouts are handled correctly with Boundary running in dev mode.

   Click Save when finished.

6. Now navigate back to the app's Overview page using the menu on the left.

   From this view, copy the Directory (Tenant) ID and the Application (client) ID.

   

   You will also need to construct the application Issuer URL.

   An Entra ID OIDC identity provider issuer will typically have format of https://login.microsoftonline.com/Tenant_ID/v2.0, but it may vary depending on your account.

   On the application Overview page, click on Endpoints. Copy the OpenID Connect metadata document value, up to the /v2.0. For example,

   https://login.microsoftonline.com/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0

   

   This value will be the Issuer used to configure the Boundary OIDC auth method.

   Note

   You may need to refer to Entra OIDC documentation for the latest OIDC endpoint schemas.

   Three important values are needed when configuring OIDC with Boundary.

   • Issuer
   • Client ID
   • Client Secret

   The following format is used for these values:

   • issuer -> https://login.microsoftonline.com/Tenant_ID/v2.0
   • client-id -> Application (client) ID)
   • client-secret -> Client Secret value

   For example, this tutorial uses the following values:

   • Issuer: https://login.microsoftonline.com/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0
   • Client ID: a4d21a76-e08c-4d8d-8c47-e1c423ee4d11
   • Client Secret: X9u~u58--~rWLR4Q9i1-PtdZOi_s04~9O-

   Keep these values in a safe place for use in the next steps.

The Boundary Admin Console provides a UI for creating and managing OIDC resources, including auth methods.

Open the Admin Console UI by entering the Dev Controller URL of http://localhost:9200 into a browser.

Enter the admin username admin and password password and click Authenticate.

For Entra ID, these settings map to the following:

• issuer -> https://login.windows-ppe.net/Tenant_ID/v2.0
• client-id -> Application (client) ID)
• client-secret -> Client Secret value

With these values you gathered from setting up an Entra ID application, a new OIDC auth method can be created.

Start by navigating to the Auth Methods settings view using the menu on the left side of the Admin Console. Select New and click OIDC.

Fill out the form details using the settings gathered from the Entra ID application settings.

These include:

• Name (Example: Azure)
• Description (Example: Azure OIDC test auth method)
• Issuer (Example: https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0)
• Client ID (Example: a4d21a76-e08c-4d8d-8c47-e1c423ee4d11)
• Client Secret (Example: X9u~u58--~rWLR4Q9i1-PtdZOi_s04~91-)
• Signing Algorithm
  • Set to RS256
  • Click Add

Additionally, set the API URL Prefix as follows:

• API URL Prefix: http://localhost:9200

Once the form is completed, click Save.

The new authentication method has now been created. Under the Attributes output, notice the state is set to inactive. Before it can be used the new auth method must be switched to an active state.

Next we will review the available authentication states and activate the new OIDC auth method.

Start by ensuring you are logged in to Boundary as the admin user.

For Entra ID, these settings map to the following:

• issuer -> https://login.windows-ppe.net/Tenant_ID/v2.0
• client-id -> Application (client) ID)
• client-secret -> Client Secret value

With these values you gathered from setting up an Entra ID application, a new OIDC auth method can be created.

Start by setting the Client ID, Client Secret, and Tenant ID as environment variables.

$ export CLIENT_ID="<COPIED-CLIENT-ID>"; \export CLIENT_SECRET="<COPIED-CLIENT-SECRET>"; \export TENANT_ID="<COPIED-TENANT-ID>"

Example:

$ export CLIENT_ID="a4d21a76-e08c-4d8d-8c47-e1c423ee4d11"; \export CLIENT_SECRET="X9u~u58--~rWLR4Q9i1-PtdZOi_s04~91-"; \export TENANT_ID="e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3"

These values will be passed to Boundary when creating the new OIDC auth method.

For Dev mode the api-url-prefix is set to the local controller's address of http://localhost:9200.

$ boundary auth-methods create oidc \  -issuer "https://login.windows-ppe.net/$TENANT_ID/v2.0" \  -client-id "$CLIENT_ID" \  -client-secret "$CLIENT_SECRET" \  -signing-algorithm RS256 \  -api-url-prefix "http://localhost:9200" \  -name "azure"

• The signing-algorithm is commonly set to RS256.

• The api-url-prefix is used by the OIDC provider in the authentication flow, and should match the Boundary controller's address, set to http://localhost:9200 in this example.

Example:

$ boundary auth-methods create oidc \  -issuer "https://login.windows-ppe.net/$TENANT_ID/v2.0" \  -client-id "$CLIENT_ID" \  -client-secret "$CLIENT_SECRET" \  -signing-algorithm RS256 \  -api-url-prefix "https://localhost:9200" \  -name "azure" Auth Method information:  Created Time:         Mon, 07 Jun 2021 14:28:45 MDT  ID:                   amoidc_rFqhKQlrvn  Name:                 azure  Type:                 oidc  Updated Time:         Mon, 07 Jun 2021 14:28:45 MDT  Version:              1   Scope:    ID:                 global    Name:               global    Type:               global   Authorized Actions:    no-op    read    update    delete    change-state    authenticate   Authorized Actions on Auth Method's Collections:    accounts:      create      list   Attributes:    api_url_prefix:     https://localhost:9200    callback_url:       https://localhost:9200/v1/auth-methods/oidc:authenticate:callback    client_id:          a4d21a76-e08c-4d8d-8c47-e1c423ee4d11    client_secret_hmac: SOhcIKhF0rBbe_Xc-2eHY0BNfIc3AO8GkQ0iohgLT_4    issuer:             https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/    signing_algorithms: [RS256]    state:              inactive

The new authentication method has now been created. Under the Attributes output, notice the state is set to inactive. Before it can be used the new auth method must be switched to an active state.

Next we will review the available authentication states and activate the new OIDC auth method.

Begin by creating a working directory to store the Terraform configuration file and changing into that directory. This tutorial will work out of the user's HOME directory.

$ mkdir learn-boundary-oidc && cd learn-boundary-oidc/

Next, create a Terraform configuration file called main.tf.

$ touch main.tf

Open the main.tf file in your code editor and add the base Boundary provider configuration below. The 1.0.2 version or above is required to support OIDC. An output value is included to print the oidc auth method id when Terraform applies the configuration.

The initial setup should set the boundary provider to match Boundary's authentication configuration so that Terraform can authenticate to Boundary. These settings are discussed in the Get Setup section.

Copy the following configuration, but replace the recovery_kms_hcl key with the value printed in the boundary dev terminal window.

terraform {  required_providers {    boundary = {      source  = "hashicorp/boundary"      version = "1.0.12"    }  }} output "auth-method-id" {  value = boundary_auth_method_oidc.provider.id} provider "boundary" {  addr             = "http://127.0.0.1:9200"  recovery_kms_hcl = <<EOTkms "aead" {  purpose = "recovery"  aead_type = "aes-gcm"  key = "1/niAcbdYlJGqwOJfRtx3AyewF+Ty2EnioOR/q7tWRo="  key_id = "global_recovery"}EOT}

Next, Boundary Terraform resources will be used to set up the provider of choice.

For Entra ID, these settings map to the following:

• issuer -> https://login.windows-ppe.net/Tenant_ID/v2.0
• client-id -> Application (client) ID)
• client-secret -> Client Secret value
• subject -> User object_id

With these values you gathered from the Entra ID application settings a new OIDC auth method can be created.

The Terraform Boundary provider enables OIDC using the boundary_auth_method_oidc and boundary_account_oidc resources.

The boundary_auth_method_oidc resource uses the following attributes to configure a new auth method:

resource "boundary_auth_method_oidc" "name" {  name                = (String)  description         = (String)  scope_id            = (String)  issuer              = (String)  client_id           = (String)  client_secret       = (String)  signing_algorithms  = (List of String)  api_url_prefix      = (String)}

• The scope_id is the global scope ID. For HCP this is gathered from the Boundary Admin Console UI, or is o_1234567890 if using Boundary's Dev mode.
• The issuer was gathered from the provider, and should be prefixed by https://
• The client_id was gathered from the provider
• The client_secret was gathered from the provider
• The signing_algorithms are defined by the provider's issued tokens, and will usually include RS256
• The api_url_prefix is used when generating callback urls and corresponds to an address where the controller is reachable by the provider. For HCP Boundary this is the Boundary Cluster URL found in the HCP portal (such as https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud). For dev mode this is http://localhost:9200

The boundary_account_oidc resource uses the following attributes to configure a new auth method:

resource "boundary_account_oidc" "name" {  name           = (String)  description    = (String)  auth_method_id = (String)  issuer         = (String)  subject        = (String)}

• The auth_method_id is defined by the boundary_auth_method_oidc resource, and can be accessed using the named scope id, like boundary_auth_meethod_oidc.name.id
• The issuer was gathered from the provider, and should be prefixed by https://
• The subject maps to the user Object ID, and was gathered from the provider when creating a user

Add these two resources into your main.tf file. The entire file contents are shown below.

Make sure the following values are updated:

• kms key (from boundary dev)
• issuer (from provider)
• client_id (from provider)
• client_secret (from provider)
• subject (from provider)

terraform {  required_providers {    boundary = {      source  = "hashicorp/boundary"      version = "1.0.12"    }  }} output "auth-method-id" {  value = boundary_auth_method_oidc.provider.id} provider "boundary" {  addr             = "http://127.0.0.1:9200"  recovery_kms_hcl = <<EOTkms "aead" {  purpose = "recovery"  aead_type = "aes-gcm"  key = "m4+NMLonZAcAbr0VhFRThgnt+QM/P6BelMCEdYCBAa0="  key_id = "global_recovery"}EOT} resource "boundary_auth_method_oidc" "provider" {  name                 = "Azure"  description          = "OIDC auth method for Azure"  scope_id             = "o_1234567890"  issuer               = "https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0"  client_id            = "a4d21a76-e08c-4d8d-8c47-e1c423ee4d11"  client_secret        = "X9u~u58--~rWLR4Q9i1-PtdZOi_s04~9O-"  signing_algorithms   = ["RS256"]  api_url_prefix       = "http://localhost:9200"} resource "boundary_account_oidc" "oidc_user" {  name           = "user1"  description    = "OIDC account for user1"  auth_method_id = boundary_auth_method_oidc.provider.id  issuer  = "https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0"  subject = "c3dc63d0-90e6-4855-b9c0-e87da14a9c5f"}

With these resources in place, first initialize Terraform.

$ terraform init Initializing the backend... Initializing provider plugins...- Finding hashicorp/boundary versions matching "1.0.12"...- Installing hashicorp/boundary v1.0.12...- Installed hashicorp/boundary v1.0.12 (signed by HashiCorp) Terraform has created a lock file .terraform.lock.hcl to record the providerselections it made above. Include this file in your version control repositoryso that Terraform can guarantee to make the same selections by default whenyou run "terraform init" in the future. Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to seeany changes that are required for your infrastructure. All Terraform commandsshould now work. If you ever set or change modules or backend configuration for Terraform,rerun this command to reinitialize your working directory. If you forget, othercommands will detect it and remind you to do so if necessary.

Next, apply the configuration. Enter yes when prompted for confirmation.

$ terraform apply An execution plan has been generated and is shown below.Resource actions are indicated with the following symbols:  + create Terraform will perform the following actions:   # boundary_account_oidc.oidc_user will be created  + resource "boundary_account_oidc" "oidc_user" {      + auth_method_id = (known after apply)      + description    = "OIDC account for user1"      + id             = (known after apply)      + issuer         = "https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0"      + name           = "user1"      + subject        = "c3dc63d0-90e6-4855-b9c0-e87da14a9c5f"    }   # boundary_auth_method_oidc.provider will be created  + resource "boundary_auth_method_oidc" "provider" {      + api_url_prefix     = "http://localhost:9200"      + callback_url       = (known after apply)      + client_id          = "a4d21a76-e08c-4d8d-8c47-e1c423ee4d11"      + client_secret      = "X9u~u58--~rWLR4Q9i1-PtdZOi_s04~9O-"      + client_secret_hmac = (known after apply)      + description        = "OIDC auth method for Azure"      + id                 = (known after apply)      + issuer             = "https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0"      + name               = "Azure"      + scope_id           = "o_1234567890"      + signing_algorithms = [          + "RS256",        ]      + state              = (known after apply)      + type               = "oidc"    } Plan: 2 to add, 0 to change, 0 to destroy. Do you want to perform these actions?  Terraform will perform the actions described above.  Only 'yes' will be accepted to approve.   Enter a value: yes boundary_auth_method_oidc.provider: Creating...boundary_auth_method_oidc.provider: Creation complete after 1s [id=amoidc_ZMettTQoi7]boundary_account_oidc.oidc_user: Creating...boundary_account_oidc.oidc_user: Creation complete after 0s [id=acctoidc_RioLnuyZMw] Apply complete! Resources: 2 added, 0 changed, 0 destroyed. Outputs: auth-method-id = amoidc_ZMettTQoi7

The new authentication method has been created! If Terraform encounters an error, ensure the issuer, client_id and client_secret have been copied correctly from the provider, and that the issuer is prefixed with https://.

Copy the auth-method-id from the output.

Before the new auth method will be allowed it must be set to an active state.

Under the settings for the new auth method, select Inactive from the menu in the upper-right side of the page and change its state by clicking Public.

The login type will now allow be allowed.

Set OIDC as primary login

Global and organization scopes may have auth methods in Boundary, and each scope has one primary auth-method ID. Boundary will automatically create a user upon first successful authentication using the scope’s primary auth method, which will be used by scopes with only one auth method available.

When migrating the database, Boundary will produce a log of any auth methods which resulted in no primary auth method being set for the scope.

Set the new OIDC auth method as the primary auth method for the global scope.

Under the settings for the new auth method, select Manage from the menu in the upper-right side of the page.

A confirmation window will be displayed to inform you that new users that sign in using OIDC will automatically be added to the new auth method. Select OK to continue.

Now try authenticating using the newly created OIDC auth method.

Select the admin user menu in the top-right corner of the page and select Deauthenticate.

Next, select the new auth method called Azure, and click Authenticate.

A browser tab should automatically open and prompt you to log in with your Azure user account credentials. Ensure you log in with the test user credentials created in the Entra ID application setup, not your primary Azure account.

After successful authentication you are automatically redirected to the Admin Console. Notice the restricted permissions for this new user, which can be updated and assigned using Roles and Groups.

If you were to log back into the Admin Console as the admin user, you would notice the new OIDC user has automatically been added under the Users view.

Next you will review the various methods that can be used to authenticate to Boundary using the new OIDC auth method.

Enable the auth method by updating its state to active-public.

$ boundary auth-methods change-state oidc -id amoidc_rFqhKQlrvn -state active-public Auth Method information:  Created Time:         Mon, 12 Sep 2022 13:40:38 MDT  ID:                   amoidc_rFqhKQlrvn  Name:                 azure  Type:                 oidc  Updated Time:         Mon, 12 Sep 2022 13:56:43 MDT  Version:              2   Scope:    ID:                 global    Name:               global    Type:               global   Authorized Actions:    no-op    read    update    delete    change-state    authenticate   Authorized Actions on Auth Method's Collections:    accounts:      create      list    managed-groups:      create      list   Attributes:    api_url_prefix:     https://e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3.boundary.hashicorp.cloud    callback_url:       https://e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3.boundary.hashicorp.cloud/v1/auth-methods/oidc:authenticate:callback    client_id:          09443893-b713-4dbf-a417-8882bff4168d    client_secret_hmac: SEOTy9cZgs7BTYRknG44rFxQQ64xY3qp2i1iEDpkvX0    issuer:             https://login.windows-ppe.net/0e3e2e88-8caf-41ca-b4da-e3b33b6c52ec/v2.0    signing_algorithms: [RS256]    state:              active-public

With the state set to active the login type will now be allowed.

Set OIDC as primary login

Global and organization scopes may have auth methods in Boundary, and each scope has one primary auth-method ID. Boundary will automatically create a user upon first successful authentication using the scope’s primary auth method, which will be used by scopes with only one auth method available.

When migrating the database, Boundary will produce a log of any auth methods which resulted in no primary auth method being set for the scope.

Set the new OIDC auth method as the primary auth method for the global scope.

$ boundary scopes update -primary-auth-method-id amoidc_rFqhKQlrvn -id global Scope information:  Created Time:             Thu, 18 Aug 2022 10:55:18 MDT  Description:              Global Scope  ID:                       global  Name:                     global  Primary Auth Method ID:   amoidc_rFqhKQlrvn  Updated Time:             Mon, 12 Sep 2022 13:58:47 MDT  Version:                  3   Scope (parent):    ID:                     global    Name:                   global    Type:                   global   Authorized Actions:    no-op    read    update    delete   Authorized Actions on Scope's Collections:    auth-methods:      create      list    auth-tokens:      list    groups:      create      list    roles:      create      list    scopes:      create      list    users:      create      list    workers:      create:worker-led      list

Now try authenticating using the newly created OIDC auth method.

$ boundary authenticate oidc -auth-method-id amoidc_rFqhKQlrvnOpening returned authentication URL in your browser...

A browser tab should automatically open and prompt you to log in with the user credentials created when setting up Entra ID.

After successful authentication, return to your terminal and notice the Authentication information that is printed.

$ boundary authenticate oidc -auth-method-id amoidc_rFqhKQlrvnOpening returned authentication URL in your browser... Authentication information:  Account ID:      acctoidc_oztPFBFesH  Auth Method ID:  amoidc_rFqhKQlrvn  Expiration Time: Thu, 13 May 2021 17:01:11 MDT  User ID:         u_JCRQP3ID7l The token was successfully stored in the chosen keyring and is not displayed here.

Auth methods must be updated to an active state before they can be used.

The state of the new auth method can be checked using the read operation. First, ensure you are logged in as the admin user.

$ boundary authenticate password -auth-method-id ampw_1234567890 -login-name adminPlease enter the password (it will be hidden): <password> Authentication information:  Account ID:      apw_DZRvFzmb0Y  Auth Method ID:  ampw_1234567890  Expiration Time: Thu, 20 May 2021 16:32:06 MDT  User ID:         u_1234567890 The token was successfully stored in the chosen keyring and is not displayed here.

Next read the auth method details. Use the auth-method-id you copied from the terraform apply output.

$ boundary auth-methods read -id amoidc_ZMettTQoi7 Auth Method information:  Created Time:         Wed, 09 Jun 2021 12:59:44 MDT  Description:          OIDC auth method for Azure  ID:                   amoidc_ZMettTQoi7  Name:                 Azure  Type:                 oidc  Updated Time:         Wed, 09 Jun 2021 12:59:45 MDT  Version:              2   Scope:    ID:                 o_1234567890    Name:               Generated org scope    Parent Scope ID:    global    Type:               org   Authorized Actions:    no-op    read    update    delete    change-state    authenticate   Authorized Actions on Auth Method's Collections:    accounts:      create      list   Attributes:    api_url_prefix:     http://localhost:9200    callback_url:       http://localhost:9200/v1/auth-methods/oidc:authenticate:callback    client_id:          a4d21a76-e08c-4d8d-8c47-e1c423ee4d11    client_secret_hmac: qbLhGSr0XZpZhdEjChZwjJMqG-dZzsX9gSRG4f44jWQ    issuer:             https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0    signing_algorithms: [RS256]    state:              active-public

Notice at the bottom of the output that the login state is already set to active-public.

It's important to be aware that using Terraform to provision an auth method will set the state to active by default, unless otherwise defined. The state attribute can be used on the boundary_auth_method_oidc resource to set an auth method to active-private or inactive.

Now that the auth method state has been verified, the primary login type can be defined for the global scope.

Set OIDC as primary login

Global and organization scopes may have auth methods in Boundary, and each scope has one primary auth-method ID. Boundary will automatically create a user upon first successful authentication using the scope’s primary auth method, which will be used by scopes with only one auth method available.

When migrating the database, Boundary will produce a log of any auth methods which have more than one auth method which resulted in no primary auth method being set for the Scope.

Make three updates to the boundary_auth_method_oidc resource in the main.tf file:

• Set the auth method's state to active-public for clarity
• Set the new OIDC auth method as the primary auth method for the global scope by setting the is_primary_for_scope attribute

Below is an example. Update your main.tf file accordingly.

resource "boundary_auth_method_oidc" "provider" {  name                 = "Azure"  description          = "OIDC auth method for Azure"  scope_id             = "o_1234567890"  issuer               = "https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0"  client_id            = "a4d21a76-e08c-4d8d-8c47-e1c423ee4d11"  client_secret        = "X9u~u58--~rWLR4Q9i1-PtdZOi_s04~9O-"  signing_algorithms   = ["RS256"]  api_url_prefix       = "http://localhost:9200"  is_primary_for_scope = true  state                = "active-public"}

Apply the updated configuration. Enter yes when prompted.

$ terraform applyboundary_auth_method_oidc.provider: Refreshing state... [id=amoidc_ZMettTQoi7]boundary_account_oidc.oidc_user: Refreshing state... [id=acctoidc_RioLnuyZMw] An execution plan has been generated and is shown below.Resource actions are indicated with the following symbols:  ~ update in-place-/+ destroy and then create replacement Terraform will perform the following actions:   # boundary_account_oidc.oidc_user must be replaced-/+ resource "boundary_account_oidc" "oidc_user" {        auth_method_id = "amoidc_ZMettTQoi7"        description    = "OIDC account for user1"      ~ id             = "acctoidc_RioLnuyZMw" -> (known after apply)      + issuer         = "https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0" # forces replacement        name           = "user1"      + subject        = "c3dc63d0-90e6-4855-b9c0-e87da14a9c5f"    }   # boundary_auth_method_oidc.provider will be updated in-place  ~ resource "boundary_auth_method_oidc" "provider" {        api_url_prefix       = "http://localhost:9200"        callback_url         = "http://localhost:9200/v1/auth-methods/oidc:authenticate:callback"        client_id            = "a4d21a76-e08c-4d8d-8c47-e1c423ee4d11"        client_secret        = "X9u~u58--~rWLR4Q9i1-PtdZOi_s04~9O-"        client_secret_hmac   = "qbLhGSr0XZpZhdEjChZwjJMqG-dZzsX9gSRG4f44jWQ"        description          = "OIDC auth method for Azure"        id                   = "amoidc_ZMettTQoi7"      + is_primary_for_scope = true        issuer               = "https://login.windows-ppe.net/e29eae0c-29d7-4851-5e1fb68bfb3-5f8e3/v2.0"        name                 = "Azure"        scope_id             = "o_1234567890"        signing_algorithms   = [            "RS256",        ]        state                = "active-public"        type                 = "oidc"    } Plan: 1 to add, 1 to change, 1 to destroy. Do you want to perform these actions?  Terraform will perform the actions described above.  Only 'yes' will be accepted to approve.   Enter a value: yes boundary_account_oidc.oidc_user: Destroying... [id=acctoidc_RioLnuyZMw]boundary_auth_method_oidc.provider: Modifying... [id=amoidc_ZMettTQoi7]boundary_auth_method_oidc.provider: Modifications complete after 0s [id=amoidc_ZMettTQoi7]boundary_account_oidc.oidc_user: Destruction complete after 0sboundary_account_oidc.oidc_user: Creating...boundary_account_oidc.oidc_user: Creation complete after 0s [id=acctoidc_RioLnuyZMw] Apply complete! Resources: 1 added, 1 changed, 1 destroyed. Outputs: auth-method-id = amoidc_ZMettTQoi7

With the auth method set to active and defined as the primary login method, users can now authenticate using their preferred method of choice.

The Boundary Desktop app is currently available for MacOS and Windows users.

1. Launch the Boundary Desktop app and enter the Boundary Cluster URL.

   Launch the Boundary Desktop app and enter http://localhost:9200 as the Cluster URL, then click Submit.

   

2. Select Azure and click Authenticate.

3. A browser window should launch and prompt for your provider's user credentials. You may see an "Authentication Pending" message, and can click the "Retry" button to force a new authentication tab to open.

   

   Submit your OIDC provider user credentials.

   

4. You should receive a "Successful Authentication" message.

   

   Once authenticated, open the Boundary Desktop app again and verify the authenticated user in the upper-right corner of the application window.

   It is expected for this user to be unprivileged, and to be denied access to view targets and sessions. The OIDC user could be updated to include new privileges if an admin user assigns it to a role.

   

   You have now completed OIDC integration with the Boundary Desktop app.

1. Navigate to the Boundary Cluster URL in your web browser. This is your HCP Cluster URL, such as https://e58fe114-7624-431c-994d-b6670e90b03J.boundary.hashicorp.cloud, or http://localhost:9200 if using Dev mode.

   Select the name of the new auth method (such as Azure) and click Authenticate.

   

2. If your browser doesn't allow pop-ups, you may be presented with an "Authentication Pending" message, which you can bypass by clicking Retry. If you do not encounter this message proceed to the next step. Consider enabling pop-ups from your localhost for the rest of this tutorial.

   

3. Next, enter your Azure user credentials and click Continue.

   

4. You should receive a "Successful Authentication" message and automatically be redirected to the Admin Console. If you are not redirected, check to make sure your browser is not blocking pop-ups from http://localhost:9200, or allow pop-ups temporarily.

   

5. Once authenticated, navigate to the Auth Methods view on the left, and notice the OIDC Type and ID used when setting up the auth method. Explore the other views and notice what this user has access to view and not view. The OIDC user could be updated to include new privileges if an admin user assigns it to a role.

   You have now completed OIDC integration with the Admin Console.

The boundary authenticate oidc command will launch a browser session to enable authentication using the configured provider.

$ boundary authenticate oidc -auth-method-id amoidc_q7jAdI1QgAOpening returned authentication URL in your browser...

The provider's login page should open in a browser tab, prompting for the username and password for the account used to configure the Boundary OIDC Test application. Below is an example of an Azure login prompt.

After logging in your terminal should confirm the Account and User IDs.

$ boundary authenticate oidc -auth-method-id amoidc_q7jAdI1QgAOpening returned authentication URL in your browser... Authentication information:  Account ID:      acctoidc_f0wWsno9jQ  Auth Method ID:  amoidc_q7jAdI1QgA  Expiration Time: Wed, 21 Apr 2021 15:02:38 MDT  User ID:         u_zAfnbL9b7y The token was successfully stored in the chosen keyring and is not displayed here.

The user is now authenticated using OIDC. Listing various scope items would show this user is not able to access most resources by default. The OIDC user could be updated to include new privileges if an admin user assigns it to a role.

You have now completed OIDC integration using the CLI.