Configure Identity Providers

• 1: IDP Initiated Login with Okta and AccessManagement 2.0 via SAML 2.0
• 2: Configure Okta SAML 2.0 IdP for JIT
• 3: Configure Okta OIDC IdP for JIT
• 4: Configure Azure Identity Providers

1 - IDP Initiated Login with Okta and AccessManagement 2.0 via SAML 2.0

Introduction

In AccessManagement 2.0, an IDP-initiated login enables users to begin the authentication process directly from an Identity Provider (IDP), like Okta, instead of a Service Provider (SP) or application. In this flow, the IDP sends a SAML authentication response to AccessManagement 2.0, which verifies the response and grants the user access to the target application. Common in SAML-based single sign-on (SSO) configurations, this approach allows users to log in from a central IDP-managed portal, streamlining access across applications and improving user experience with a single, centralized login point. Here, we will detail how to set up an IDP-initiated login between Okta and AccessManagement 2.0 via SAML 2.0. The section is segregated into two parts: the first section is related to changes on AccessManagement 2.0’s side, and the second section is related to changes on Okta’s side. As a pre-requisite, please have the SAML 2.0 IDP created. To create an OKTA SAML2.0 IDP, please follow the steps mentioned here if needed.

Section 1: Changes on AccessManagement 2.0’s side

Step 1

AccessManagement 2.0 needs to understand how to handle SAML assertions from Okta, which is accomplished by exporting and importing the correct metadata and establishing a Client. Log in to the admin console. Go to your already created IDP and click on the SAML 2.0 Service Provider Metadata link. Copy and save the contents from the metadata link in a .xml file.

Figure: Sample content of SAML 2.0 service provider metadata

Step 2

Go to the Clients section of the maactive realm and click Import client. On the next page, click Browse and import the .xml file exported in Step 1. Then, scroll down and click Save.

Step 3

Go to the IDP-Initiated SSO URL name on the same page and give a name to your app.

Step 4

Go to IDP Initiated SSO Relay State and enter the stack URL.

Step 5

Ensure that Force POST binding is On. Scroll down and disable Front channel logout. Once done, click Save.

Step 6

Scroll to the top and click the Advanced section. Scroll down and add the stack URL in the Assertion Consumer Service POST Binding URL.

Step 7

Remove content from Assertion Consumer Service Redirect Binding URL

Step 8

Remove the content of the Logout Service POST Binding URL.

Step 9

Scroll down and select Browser Flow as MA first broker login from the dropdown. Click Save. This concludes all changes at AccessManagement 2.0’s end.

Section 2: Changes on IDP’s (Okta) end

Step 1

Log in to Okta, go to your application, and click on the General tab. Scroll down and click on Edit in the SAML settings section.

Step 2

Click Next in the General Settings of the Edit SAML Integration section.

Step 3

Compose the Single Sign On URL by entering the AssertionConsumerService (ACS) URL, followed by /clients/<name of your app>. The ACS URL can be obtained from the XML file imported in Step 2 of Section 1, and the app name is the name given in Step 3 of Section 1. This is the endpoint in AccessManagement 2.0 where the IDP sends the SAML assertion (authentication response) after a user has successfully authenticated.

Step 4

Ensure that the value of Audience URI (SP Entity ID) is the entityID. The entityID can be obtained from the XML file imported in Step 2 of Section 1. Also, enter the value of Default RelayState as the stack URL.

Step 5

On the same page, click the Show Advanced Settings section and scroll down. Look for Other Requestable SSO URLs and enter the AssertionConsumerService (ACS) URL. The ACS URL can be obtained from the XML file imported in Step 2 of Section 1. This step is necessary if the same IDP has to work for SP-initiated flow as well. This concludes all changes needed on IDP’s(Okta) end.

Authors :

• Mustaque Rashid, Technical Lead, R&D-Cloud platform.
• Kaveen Jagadeesan, Technical Director - Software Engineering, R&D-Cloud platform.
• Binit Datta, Technical Director - Software Engineering, R&D-Cloud platform.

2 - Configure Okta SAML 2.0 IdP for JIT

Objective

This page describes the Okta SAML 2.0 setup with JIT and Non JIT flows.

Integrating Access Management 2.0 with Okta SAML 2.0

This section shows how to integrate Access Management 2.0 (AM 2.0) with Okta, where Okta will serve as the Identity Provider (IdP). The protocol used for authentication is SAML 2.0. Steps involve exchanging the IdP Metadata (URL generating XML) and the Service Provider Metadata URL between the IdP and the AM 2.0 SP.

Step 1: Identity provider in AM 2.0.

• Login to AM 2.0 Admin Console. Select the maactive realm.
  

  Note: In case you have Restricted Admin Access on AM 2.0, then use the URL:

  https://<stack_name>-auth.<domain_name>/auth/admin/maactive/console/
  

  Click on the Identity Providers option from the left panel and select SAML v2.0 from the list of providers.

  

• Enter the Alias. This will be the default display name on the login page.
  Please note that the Alias forms a part of the redirect URL. In case it does not reflect, you can create the Redirect URI yourself and keep the URL handy.
  Eg. if Alias is set as - samlokta
  Redirect URI - https://localdocker:8443/auth/realms/sample/broker/samlokta/endpoint

  

• Optionally enter Display Name. This is the name that will be displayed, in case you need it to be different from the alias.

• Take note of the Service provider entity ID value from the same page.

Step 2: SAML 2.0 App Registration in Okta

• Next, we need to create an IDP in Okta. In the Okta admin page, go to Applications → Click Create App Integration.

  

• Select the SAML 2.0 radio button, and click Next.

  

• Provide the application name under the App name, and click Next.

  

• Copy Redirect URI from AM 2.0’s provider page, from Step 1. Configure this URL in the Single sign on URL field.

  

• Copy the Service Provider Entity ID from AM 2.0’s provider page, from Step 1 and configure this URL in the Audience URI field.

• Leave other fields to default values. Hit Next. Select the fields as indicated below and select Finish.

  

Step 3: Get the IdP Metadata URL From Okta

• Now in the same Okta application configuration page, click on the Sign On tab. You will find the metadata URL here. Please copy this URL and we will configure this in AM 2.0

  

Step 4: Configure AM 2.0 With IdP Metadata

• Paste the metadata link from Okta in the SAML entity descriptor field on AM 2.0’s provider page. If the URL is correct, you will see a green tick on the right.

  

• Click on Add. This will create a basic SP configuration on AM 2.0 for this Okta application.

Step 5: Configure other fields on AM 2.0

• Scroll down and set the Want AuthnRequests signed option to be On.

  

• Now scroll to the bottom of AM 2.0’s provider configuration page and select First Login Flow and Post Login Flow, if not already pre-selected.

  

• Click on Save.

Step 6: Configure Mapping for JIT (this step is mandatory only if you would like to enable SAML JIT)

• In case a customer requires SAML JIT need to be enabled, we need to add 4 mandatory mappers on both sides - AM 2.0 as well as Okta. In case SAML JIT is not required, please skip this step entirely.

• To add mappers in AM 2.0, click the Mappers tab on the same SP configuration page. Click on the Add mapper button.

  

• Configure User.UserId mapper by filling in the fields as shown in the image below.

  

  Click on Save.

• Similarly, configure User.LocaleId mapper by filling in the fields as shown in the image below.

  

  Click on Save.

• Similarly, configure User.PrimaryOrgId mapper by filling in the fields as shown in the image below.

  

  Click on Save.

• Similarly, configure User.Roles mapper by filling in the fields as shown in the image below.

  

  Click on Save.

• To add mappers on the Okta side to support SAML JIT, go to the General settings tab and click on the Edit button in SAML Settings.

  

  Navigate to the SAML Tab by clicking on the Configure SAML button. Go to the Configure SAML tab and add the 4 attributes as shown below.

  

  Note: the values shown in the above image in the Okta side mapper configuration are only for example. Please enter values as per your requirements.

  Click on Next and then click on Finish. You are now done with the SAML JIT configuration.

Step 7: Configure logout

To configure logout, a Signing certificate needs to be extracted from AM 2.0 and saved on the Okta side.

• To extract this Signing certificate from AM 2.0, go to Realm settings → Keys → Certificate.

  

  The certificate will look like below:

  

• Follow the template shown below to create a new certificate file.

  —–BEGIN CERTIFICATE—–
  <PASTE THE CERT HERE!>
  —–END CERTIFICATE—–
  

  Replace the text “<PASTE THE CERT HERE!>” with the copied certificate data from above. It should look like this after the replace:

  

• This file needs to be saved on the Okta side. Now on the Okta side, go to the General settings tab and click the Edit button in SAML Settings. Click on Show Advanced Settings.

  

  The certificate saved goes in the Signature Certificate field.

  

• Get the Single Logout URL from the AM 2.0 metadata URL of this realm. The metadata link can be found on the IDP configuration page, as shown below.

  

  The metadata will look like below:

  

  Extract this URL and save it in the Single Logout URL field.

• The SP issuer will be the same as the SP Entity ID, which we saw in Step 1.

• After saving all of these changes, go to the Sign On tab in Okta and get the metadata URL.

  

• Okta metadata will now have a SingleLogoutService field populated to reflect the Logout URL.

  

  Use this URL to configure the logout on the AM 2.0 side. Save the change.

Step 8: Additional attributes configuration

• In case additional attributes are needed, they can be configured as well. Below is a list of attributes can be configured. You will have to pass the attribute from the IDP side to receive on SP side.

3 - Configure Okta OIDC IdP for JIT

Objective

This page describes the Okta OIDC setup with JIT and Non JIT flows.

Integrating Access Management 2.0 with OKTA OIDC

This section shows how to integrate Access Management 2.0 with OKTA, where OKTA will behave as the Identity Provider (IdP). The protocol used for authentication is OIDC. Steps involve creating an OIDC client on both sides.

Step 1: Identity provider in Access Management 2.0.

• Login to the Access Management 2.0 admin console. Select the correct realm, here it’s maactive.

https://mpsos-auth.sce.manh.com/auth/

If you only have Restricted Admin Access, then use the URL:

https://<stack_short_name>-auth.<domain_name>/auth/admin/maactive/console/

• Verify the Realm.

• Click Identity Providers → Add providers and select OpenID Connect provider from the list of providers.

• Enter the Alias and the Display name.

Alias also forms part of Redirect URL. For example, if the Alias is scoeoidc, then the Redirect URI is:

https://mpsos-auth.sce.manh.com/auth/realms/maactive/broker/scoeoidc/endpoint

Copy this redirect URI to register the application In OKTA.

Step 2: App Registration in OKTA

The instructions described below can be used to integrate the Manhattan Active Cloud Platform with OKTA Login

• Login to your OKTA Account → Go to Applications → Click Create App Integration.

• Select OIDC - OpenID connect radio button and then Web/Native Application radio button on the Application Type Panel, and click Next.

Provide the name of the application and paste that Redirect URI from step1-C to Okta Sign-in redirect URIs

The below screen will be displayed after Save Operation on Okta.

• Follow the below steps to create a client_secret key.

Edit and select client secret → save. As soon as you hit Save, you see Client Secret. Copy this for further configuration. Unselect Proof Key for Code Exchange (PKCE)

• Copy the Client ID, Client Secret from the above screen, and Metadata Well known URI as below to register it in Access Management 2.0.

• There is a concept in OIDC Application called the Metadata Well Known URI.

The general format (in Okta) is https://host:<port>/oauth2/default/.well-known/openid-configuration. In our case:

https://dev-95801423.okta.com/oauth2/default/.well-known/openid-configuration

• Assign users to the application in OKTA.

Step 3: Integrating Access Management 2.0 with OKTA OIDC

• Go to Access Management 2.0 Admin and paste the OpenID connect metadata URI in the Discovery endpoint as shown below (click on show metadata to see the rest of the endpoints).

• Select Client Authentication as Client secret sent as basic auth, paste the client ID and client secret value, and then hit add.

• Next, click on advanced to add the default scopes as shown below.

• Next, choose the First Login Flow as MA first Broker login if not already configured. Once done, choose the MA post login flow as the Post Login Flow drop down. This is an important step, and it is needed for the IDP login to work fine.

  

• Manually add users to the application with appropriate roles. This completes the integration of Access Management 2.0 and OKTA using the OIDC protocol.

• Click on the application URL and use the icon in the UI to log in through OKTA-ODIC. In our case it is scoeoidc

  

Step 4: Enabling JWT-OIDC-JIT – OKTA

Creating/adding mappers in Access Management 2.0:

• To add mappers in Access Management 2.0, go to Access Management 2.0’s provider configuration page, Select the identity providers (Scoeoidc) and click on the Mappers tab.

  

• Click on Add mapper and create the below mappers by filling in the fields as shown in the below screenshots.

  • User.UserId:

  

  • User.FirstName:

  

  • User.LastName:

  

  • User.Primary_Org_Id:

  

  • User.Roles:

  

  • User.LocaleId :

  

Step 5: Adding Custom claims in OKTA:

Login to OKTA portal https://okta-devok12.okta.com/

• Login to your OKTA Account → Go to Directory → Click Profile Editor → select User (default).

  

• Next, click on Add Attribute to add the required customer user attributes.

  

  • primary_org_id:

  

  • preferred_roles:

  

  • LocaleId:

  

Save and Next:

Once the attributes are added to the profile-editor, custom attributes fields will be displayed for the user under the profile.

• → Go to Directory → Click People → select User(ltadimarri@manh.com) → profile → Edit.

Define the values for custom attributes.

• Next is Add claims, go to Security tab on the left-hand side, and select the API option.

  

• Under the Authorization Servers tab, select the default authorization server.

  

• Under the claims header, click on the Add Claim button.

  

• Create a new claim called “primary_org_id” as shown below. Click save.

  

• Create a new claim called “preferred_roles” as shown below. Click save.

  

• Create a new claim called “LocaleId” as shown below. Click save.

  

Follow the above steps to add attributes based on customer requirements.

• Next, assign users to this application in OKTA.

Step 6: Viewing Claims and Attributes in Okta’s Token Preview

Okta provides a way to view the custom claims or attributes passed under the token preview in the authorization server.

• In the Okta admin console, navigate to Security > API > Authorization Servers, select default authorization server, and then go to the Token Preview.

Select the properties for your token request to preview a token payload (ClientID, Grant type, user, and scopes).

• Once properties are selected, click on the token preview to view the attributes and claims.

  

Note: By default, the claims for preferred_username, first name (given_name), and last name (family_name) will be available in the Okta token.

Step 7: JWT-OIDC-JIT Required claims in OKTA.

Note: Please take special care to make sure values mapped to your Identity Provider do not have any unwanted spaces, commas, or other invalid characters before or after the values.

Attributes Shown Below can be configured on IDP as well as SP.

4 - Configure Azure Identity Providers

Objective

This page describes Azure Ad OIDC Setup with JIT and Non JIT Flows.

Integrating Access Management 2.0 with Azure OIDC

This section shows how to integrate Access Management 2.0 with Azure AD, where Azure will behave as an Identity Provider (IdP). The protocol used for authentication is OpenID Connect (OIDC). Steps involve creating an OIDC client on both sides.

Step 1: Identity provider in Access Management 2.0.

• Login to the Access Management 2.0 Admin console and select the correct realm, here it’s maactive.

https://mpsos-auth.sce.manh.com/auth/

If you only have Restricted Admin Access, then use the URL.

https://<stack_short_name>-auth.<domain_name>/auth/admin/maactive/console/

• Verify the Realm.

• Click Identity Providers → Add providers and select OpenID Connect provider from the list of providers.

• Enter the Alias and the Display name.

Alias also forms part of the Redirect URL. For example, if Alias is scoeoidcazure, then the redirect URI is:

https://mpsos-auth.sce.manh.com/auth/realms/maactive/broker/scoeoidcazure/endpoint

Copy this redirect URI to register the application In Azure.

Step 2: OIDC App Registration in Microsoft Azure AD

The instructions described below can be used to integrate Manhattan Active Cloud Platform with Microsoft Azure AD Login:

• Login to https://portal.azure.com/#home as an Administrator or Co-Administrator to create a new Application.
• Select App Registration from the homepage or search for the same from the search bar.

• Select New Registration to create an OIDC application.

• Set the application name, select web application from the drop-down, and paste the redirect URI that has been copied from Access Management 2.0:

https://mpsos-auth.sce.manh.com/auth/realms/maactive/broker/scoeoidcazure/endpoint

Once the redirect URI is pasted, register the application.

This creates the new application (client) in Azure Portal. Note down the client ID, which is also the application ID.

• Creation of client secret Key.
  • Select the application (scoeoidc) → select certificate and secrets to create a new secret key.
  • Select New client secret. Describe this secret. Hit Add.

Note: Write down the Client secret value, and make sure you register the key “Value”.

This will be the only chance to capture the key. Never send the secrets over emails.

• Enable permission for this application
  • Select API permissions.
  • Click on Grant admin consent. Confirm in yes.

• Copy Endpoints for this client to configure in Access Management 2.0. These endpoints can be captured by clicking on Endpoints, as shown below.

Copy the OpenID Connect metadata document (also known as the OIDC Well Known URL across the Security Industry, like SAML IdP Metadata) to configure it in Access Management 2.0.

https://login.microsoftonline.com/c38aa44d-4165-427e-94a7-62d15e922c35/v2.0/.well-known/openid-configuration

Configure the OpenID Connect application using OpenID Connect Application Endpoints in Access Management 2.0.

• Assign the users or groups to this application in Azure.

Step 3: Integrating Access Management 2.0 with Azure OIDC

• Go to Access Management 2.0 Admin Console and paste the OpenID connect metadata in the Discovery endpoint as shown below (click on show metadata to see the rest of the endpoints).

• Select Client Authentication as Client secret sent as basic auth, paste the client ID and Client secret value, then hit Add.

• Next, click on Advanced to add the default scopes as shown below.

• Next, choose the First login flow as MA first Broker login if not yet configured.

Also, choose Post login flow as MA post login flow if not configured already. This is an important step, and it is needed for the IDP login to work fine.

• Ensure users were added to the application with appropriate roles.

This completes the integration of Access Management 2.0 and Azure using the OIDC protocol.

• Click on the application URL and use the icon in the UI to log in through Azure-ODIC. A better-looking screen is expected soon. The number of IdP Login buttons/Options will depend on how many IdPs the user has configured within Access Management 2.0. In our case, it is scoeazure-oidc.

Step 4: Enabling JWT-OIDC-JIT - Azure

In case Just In Time (JIT) User Provisioning is not needed, please skip this step 4.

If JIT needs to be enabled, we need to add six mandatory mappers on each side in Access Management 2.0, as well as Azure.

• To add mappers in Access Management 2.0, go to the Access Management 2.0 provider configuration page, select the identity providers (Scoeazure-oidc), and click on the Mappers tab.

• Click on Add mapper and create the below mappers by filling in the fields as shown in the screenshots below.

  • User.UserId:

  

  • User.FirstName:

  

  • User.LastName:

  

  • User.Primary_Org_Id:

  

  • User.Roles:

  

  • User.LocaleId:

  

Step 5: Adding Custom claims in Azure AD

Login to Azure portal https://portal.azure.com/#home

We have multiple options in Azure AD to pass the required claims in the response token.

Steps for Enabling Optional claim for OIDC in Azure:

• In AZURE AD, go to Token Configuration → Add optional claim ID → select preferred_username and add available required claims as well.

• If we do not have options to pass the required attributes/claims in token configuration, we can pass it through managed claims.

• Go to Enterprise applications → Single Sign-on → Attributes and claims.

• Go to Enterprise applications and search for the application (in our case: scoeoidc)

• Select the application and click on the Single sign-on Tab.

• Edit the attributes & Claims. Click on Add new claim. Provide the Claim Name and the Source attribute value:

  • primary_org_id

  

Similarly, add other attributes as well.

• To make these changes work and send the attributes in the ID token, we need to update the acceptMappedClaims to true in the application manifest.

Go to App registrations → <application name(scoeoidc)> → manifest.

Next, assign users to this application.

Once the above steps are performed, the user will be created in the application.

• JWT Token response using Postman.

We can check the sent claims/attributes in the JWT token response using Postman. Use the token endpoint, client ID, and client secret key to get the token response ID of the user in Postman.

POST Request:

A successful request would get HTTP 200 OK responses having an ID token and access token, as shown below.

• Go to https://jwt.io/ and paste the ID token in the debugger to know what response is sent from the token.

Step 6: JWT-OIDC-JIT Required claims in Azure.

Note: Please take special care to make sure values mapped to your Identity Provider do not have any unwanted spaces, commas, or other invalid characters before or after the values.

The attributes in the table below can be configured on both IDP and SP by following the steps above.