Configuring Single Sign-On (SSO) for Choreo with Okta

In today’s digital landscape, managing multiple usernames and passwords across various applications can be a real hassle. That’s where Single Sign-On (SSO) comes in as a game-changing solution that streamlines user authentication processes and enhances security. SSO allows users to access multiple applications using a single set of login credentials, boosting convenience and reducing the risk of password-related vulnerabilities.

In this blog post, we’ll dive in and explore how to leverage Okta as the Identity Provider (IdP) to enable seamless access to Choreo. I ‘ll guide you through a step-by-step journey, illustrating how to configure SSO between Choreo and Okta, and in the process, unlocking a smoother, more efficient user experience.

Prerequisites

• Okta account
• Choreo account
• PAY-AS-YOU-GO or ENTERPRISE subscription for Choreo [1]

Configuring Choreo with Okta

Step 1️⃣ — Enable Enterprise login

To initiate the setup of Single Sign-On (SSO), the first step involves enabling the enterprise login feature within Choreo. This process is described in detail in the documentation [2]. You need to connect with the Customer Support (CS) team to activate this feature. The CS team will guide you through thedomain ownership validation and the activation of enterprise login for your organization.

The configuration of identity settings for Choreo is handled through the Asgardeo console, accessible (https://console.asgardeo.io/). Asgardeo is the identity as a service (IDaaS) solution offered by WSO2. Once you create an organization in Choreo, the corresponding Asgardeo organization will be automatically created for you. Once you login to the Asgardeo console (https://console.asgardeo.io/) you will notice an Asgardeo organization with the same handle created for you.

Once the enterprise login is enabled you will be able to see an Application named WSO2_LOGIN_FOR_CHOREO_CONSOLE in the Asgardeo portal.

Step 2️⃣ — Setting Up Okta

Create an Okta account by following the steps outlined in [3]. For the purpose of this guide, I am using an Okta developer account since it provides the required functionality for my use case. Once your Okta account is created, proceed with the steps below.

1. Begin by creating an Application within your Okta account. Depending on your preference and requirements for integrating with Choreo, you can opt for either OIDC or SAML. In this example, I will be using OIDC. Select the Application type as “Web Application”.

2. On the next screen assign a meaningful name for the application and as the Sign-in redirect URIs, provide the URL in the following format.

https://api.asgardeo.io/t/<asgardeo_organization_name>/commonauth

Replace <asgardeo_organization_name> with the appropriate organization name obtained from the Asgardeo console.

Ex: https://api.asgardeo.io/t/wso2cs/commonauth

3. Scroll down to the “Assignments” section within the application creation window. Depending on your specific use case, configure user access. As an example, I have established a user group called “choreo_admin,” and I am selecting this group here. This effectively restricts application access to users within this designated group. Alternatively, you have the flexibility to select multiple groups or even opt for the “Allow everyone in your organization to access” option, based on your unique requirements.

You can create users and assign to groups from the Okta console (Directory → People, Directory → Groups).

4. Once the application is saved, you will be given a Client ID and a Client Secret. These will be used in registering the IDP in the Asgardeo console.

5. Configure the group scope for the default Authorisation Server.

The IDP should return the group attribute of the user in order to map the user to a role in Choreo. This will decide the permission assigned to the user to carry out operations in Choreo. To achieve this, refer to the forum discussion documented in [8].

To implement this configuration, access the Okta console and navigate to “Security” → “API.” Locate and edit the default authorization server. Within the “Scope” tab, add the “groups” scope with the following configurations, then proceed to save the changes.

Continuing to the “Claims” tab, click on “Add Claims” and proceed to configure the settings as outlined below. Upon completion, save the configured claims settings.

Step 3️⃣ — Register OpenID Connect identity provider in Asgardeo Console

Refer to the “Register the OIDC IdP” section of the documentation [4] for additional details on this step.

1. Proceed by accessing the Asgardeo Console, and then navigate to the Connections tab.
2. Click Create Connection and select Standard-Based IdP.
3. Provide a unique identity provider name, select OpenID Connect, and click Next.
4. Enter the following details of the Okta OIDC identity provider you have configured above and click Next.

You can get the okta domain when you log into the Okta portal. Your URL will look like the following. Extract the domain from this URL.

https://<yourOktaDomain>/admin/dashboard

Client ID and Client secret are the values obtained in the above step by creating the Application (Step 2️⃣ — Setting Up Okta).

• Authorization endpoint URL [5]

https://<yourOktaDomain>/oauth2/default/v1/authorize

• Token endpoint URL [6]

https://<yourOktaDomain>/oauth2/default/v1/token

5. Provide the mode of certificate configuration. You can provide the JWKS endpoint which will take the following format [7].

https://<yourOktaDomain>/oauth2/default/v1/keys

6. Click Finish to complete the registration.

7. In the connection settings tab make sure the configurations added are available.

8. Scroll down to the Scopes section and add groups, email and openid if not present.

9. Update the Connection.

Step 4️⃣ — Configure Asgardeo Application

In the Asgardeo console (https://console.asgardeo.io/) navigate to the WSO2_LOGIN_FOR_CHOREO_CONSOLE application that was created by the Choreo team when the Enterprise login was enabled in the initial steps.

1. Configure User attributes

Make sure Groups, Profile → First Name , Profile → Last Name are added as “Requested” attributes. The Email should be added as a “Mandatory” attribute.

2. Configure a sign-in method

Go to the “Sign-in Method” tab in the WSO2_LOGIN_FOR_CHOREO_CONSOLE application. Choose the “Default Login” option which will direct you to the following view. In this window you will have the Username and password as the authentication option. You can provide multiple login options to the user as well if needed.

You can remove the Username and password option and click on “Add Authentication” to choose the asgardeo connection that you have created in the above step 3.

3. Once all modifications are in place, finalize the configuration update by selecting the “Update” button.

4. Then navigate to Attribute Management → Scopes → Open ID and add the attributes email, groups, given_name, family_name.

Step 5️⃣ — Configure Choreo Platform

It is necessary to establish the mapping of permissions for users. In Okta, various user groups are categorized under “Groups.” We must align these user groups with the corresponding roles within Choreo. Different roles have different sets of permissions to operate in Choreo.

1. On the Choreo Console (https://console.choreo.dev/) navigate to the organization settings page.

2. Go to the Role Mapping tab and click on add mapping.

3. Here, you can map the Okta groups to the Roles in the Choreo console. The purpose of this is to provide different permissions to user groups.

Login to Choreo Console

You can now test the login flow that you have configured. In order to do so you can follow the steps below.

1. Log out of the Choreo console.
2. Choose “Sign in with Enterprise ID” as the login option
3. Provide the email address (the user should be in Okta IDP).
4. You will be directed to the Okta login page. Provide the appropriate username and password. Once completed you should be able to successfully login to the Choreo Console.

To summarize, Choreo provides a smooth login experience and simplifies user access within your organization. While our focus was on Okta, you can replicate the same setup procedures for any IDP that support OIDC or SAML.

I hope you liked the blog and found some useful takeaways.

[1] — https://wso2.com/choreo/pricing/

[2] — https://wso2.com/choreo/docs/administer/configure-enterprise-login/

[3] — https://developer.okta.com/signup/

[4] — https://wso2.com/asgardeo/docs/guides/authentication/enterprise-login/add-oidc-idp-login/#register-the-oidc-idp

[5] — https://developer.okta.com/docs/reference/api/oidc/#authorize

[6] — https://developer.okta.com/docs/reference/api/oidc/#token

[7] — https://developer.okta.com/docs/reference/api/oidc/#keys

[8] — https://devforum.okta.com/t/no-groups-scope-in-the-console-for-the-default-authorisation-server/5573