Configure Okta OIDC IdP for JIT

Get started with OAuth2 / Open ID Connect (OIDC) Identity Provider configuration to enable security integration with other systems or 3rd parties in your IT landscape

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 Key cloak.

  • 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.

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

Access Management 2.0 Attribute NameOkta OIDC Claim Name
User.UserIdpreferred_username
User.PrimaryOrgIdprimary_org_id
User.FirstNamegiven_name
User.LastNameAfamily_nam
User.LocaleIdLocaleId/locale
User.DateOfBirthbirthdate
User.UserOrgsuser_orgs
User.Locationslocations
User.Gendergender
User.Address1street_address
User.Address2street_address2
User.Citylocality
User.Stateregion
User.PostalCodepostal_code
User.Countrycountry
User.Phonephone_number
User.Email2email
User.UserTimeZonezoneinfo
User.AvailableUserLocalesavailable_user_locales

Last modified September 5, 2024: retrigger with original workflow cdn (9c51138)