Set Up Okta Single Sign On (SSO)

This guides walks though the setup for Single Sign On (SSO) in Cloud Control Center using Okta Identity.

 

Three main components are required to successfully configure SSO using Okta Identity.

1. Create and Assign User Roles

2. Adding Elisity Cloud Control Center Application in Okta 

3. Configure Okta SSO within Cloud Control Center (Two Methods)

Cloud Control Center supports up to 10 SSO providers, so you can add Okta alongside other identity providers. For more information, see Configure Multiple SSO Identity Provider Connections.

Note: You can create custom mappings from groups within your SSO directory to user roles in Cloud Control Center. It is recommended to set up these role mapping configurations if you are planning on using Role-Based Access Control (RBAC) in Cloud Control Center, which enables powerful access control to various scopes such as Users, Devices, Policies, Virtual Edges, Settings, and more. 

Step 1 - Create User Groups in Okta

First we will create user groups in Okta - TenantAdmin and TenantUser in this example. These two user groups are the default roles in Cloud Control Center.

Remember, you can create custom mappings from existing user groups to user roles at any time.


Navigate to Directory -> Groups and select Add group

 

Give your user groups the appropriate names and descriptions. These user groups are used to authorize users in Cloud Control Center, so be sure that the Name syntax matches the images below exactly. 

 

 

Now that our groups are created, we will be able to quickly assign them to our Application defined in Okta that we are going to create in the next step.

 

Step 2 - Create App Integration in Okta

Go to the Applications dashboard in Okta and click Create App Integration.

Note that the screenshots are created in Developer Edition and may vary from customer portals.

 

 

Next, Select OIDC - OpenID Connect option, select Web Application as your application, and click Next.

 

 

Give the application a name such as 'Elisity SSO'. Under Grant Type, click the check box for the  Refresh Token option. Leave the redirect URLs as the default options for now; we will modify the sign-in redirect URI in a later step. 

 

 

Under Assignments, Select Limit access to selected groups and choose the two user groups we created previously - TenantAdmin and TenantUser.

Here is where you can also add any further user groups that you would like to map to user roles within Cloud Control Center. See how to map SSO groups to user roles.

 

Click the Save button after all options have been submitted.

 

After saving the application settings, open the application information and copy the Client ID and Client Secret into your notepad for later.

 

Step 3 - Create an API Role in Okta

Expand the Security drop-down in the left pane, then click API (the last item in the list).

Copy Issuer URI value for required (usually 'default') Authorization Server into the notepad where we saved the Client ID and Client Secret for later use.

For the default Okta authorization server, the Issuer URI is in the form https://<your-okta-domain>/oauth2/default — for example https://your-company.okta.com/oauth2/default. Note that default is the ID of the authorization server and is a required part of the URL. If your organization uses a different custom authorization server, replace default with that server’s ID (visible under Security > API next to each Authorization Server).

 

 

Edit the settings of the Default Authorization Server by clicking the name default on the left or by clicking the edit icon to the right. 

 

 

Enter the following options for the new claim:  

  • Enter 'UserRole' for Name

  • For Include in token type select ID token and Always

  • Select Groups for Value type 

  • For Filter select Matches regex and .* as regex

  • For Include in select The following scopes option, then type 'openid'

    Click Create

Step 4 - Configure Okta SSO within Cloud Control Center

Method 1: Using the Discovery Endpoint for Okta SSO

Before using this method, you need to ensure that your Elisity Application and User Roles are already created in Okta SSO. If they are not, navigate to the respective sections to fulfill these requirements first.

Step 1. Sign in to Cloud Control Center (CCC) with an admin account that has permissions to make SSO configuration changes. Navigate to Settings > Administration, select the SSO Configuration tab and click + Add SSO Provider.

Step 2. Leave Use Discovery Endpoint turned on. In Discovery Endpoint, enter the Okta issuer URL that you copied in Step 3 - Create an API Role in Okta with /.well-known/openid-configuration appended, and click Discover. The issuer URL takes the form https://<your-okta-domain>/oauth2/default, where default is the ID of the Okta authorization server and is a required part of the URL. For example, if the issuer URL is https://your-company.okta.com/oauth2/default, the Discovery Endpoint is https://your-company.okta.com/oauth2/default/.well-known/openid-configuration. When the message "Discovery endpoint is successful" appears, the Metadata fields are filled in. Expand Metadata to verify the values.

Step 3. In Name, enter the name users see on the login page, up to 60 characters (for example, your organization name or "Okta").

Step 4. Enter the Client ID and Client Secret that you copied from your Okta app in Step 2 - Create App Integration in Okta. Keep the default Scopes (openid, email, profile and offline_access). The UserRole claim that you created in Okta is included in the openid scope, so do not remove it.

Step 5. Click Add. The Connection created dialog displays the provider's Redirect URL. Click Copy, and then click Done.

Register the copied Redirect URL in Okta as described in Step 5 - Modify Sign-In Redirect URI in Okta. Users cannot sign in through this SSO provider until the Redirect URL is registered.

Method 2: Manually Entering Metadata

You can optionally choose to bypass the Discovery Endpoint method and manually enter all the required configurations in Cloud Control Center. On the Add SSO Provider page, turn off Use Discovery Endpoint and enter the following fields:

  • Name: The name users see on the login page, up to 60 characters.
  • Client ID: The unique identifier assigned to your application by the SSO provider. This value can be found by following the guide above.
  • Client Secret: A confidential secret used by your application to authenticate with the SSO provider. This value can be found by following the guide above.
  • Scopes: The OpenID Connect scopes requested from the SSO provider. Keep the defaults (openid, email, profile and offline_access).
  • Token Endpoint: The URL used by the application to exchange an authorization code for an access token.
  • Authorization Endpoint: The URL used to initiate the user authorization process.
  • JSON Web Key Set: The URL pointing to a set of public keys used to verify the signature of JSON Web Tokens.
  • User Information Endpoint: The URL from which the application can retrieve user profile information.
  • Issuer: The URL that uniquely identifies the authorization server that issued the token. This value can be found by following the guide above.

For the default Okta authorization server, these endpoints all follow a predictable pattern built from your issuer URL (https://<your-okta-domain>/oauth2/default). Using an example Okta domain of your-company.okta.com, the values would be:

Field Example value
Issuer https://your-company.okta.com/oauth2/default
Authorization Endpoint https://your-company.okta.com/oauth2/default/v1/authorize
Token Endpoint https://your-company.okta.com/oauth2/default/v1/token
JSON Web Key Set https://your-company.okta.com/oauth2/default/v1/keys
User Information Endpoint https://your-company.okta.com/oauth2/default/v1/userinfo

Replace your-company.okta.com with your own Okta domain and, if you are not using the default authorization server, replace default with your authorization server ID. The authoritative values for your tenant are always the ones returned by the Discovery Endpoint above (…/.well-known/openid-configuration); the table shows the standard Okta format so you know what to expect. The Client ID and Client Secret come from your Okta app, and Cloud Control Center assigns the Redirect URL after you click Add.

Refer to Okta Identity documentation on how to retrieve the values for manual configuration that are not covered in this document.

Click Add, and then copy the Redirect URL from the Connection created dialog as described in Method 1.

 

Step 5 - Modify Sign-In Redirect URI in Okta

After you add the SSO provider in Cloud Control Center, open the Elisity application that you created in Step 2 - Create App Integration in Okta and register its Redirect URL.

Scroll down to the application general settings, and click edit. Scroll down to the LOGIN section that contains the sign-in redirect URls.

Replace the existing Sign-in redirect URI with the Redirect URL that you copied from the Connection created dialog in Cloud Control Center. To copy it again, open the Actions menu for the SSO provider on the SSO Configuration tab and select View Redirect URL.

 

Click Save after appropriately modifying the URI.

 

Step 6 - Create SSO Role Configurations in Cloud Control Center

Before finalizing our SSO integration, we can quickly add our Key-Value to User Role configurations within Cloud Control Center. Recall the API role that we configured in Okta for our CCC Application registration. We use a Key-Value pair for these API calls where the key is "UserRole" and the value type is user groups filtered by a matching regex in Okta. Any groups in Okta that are assigned to the Application Integration for Cloud Control Center are eligible to be mapped to a role in Cloud Control Center. Role mappings apply only to the SSO provider they are configured on.

Step 1. On the SSO Configuration tab, open the Actions menu for your Okta SSO provider and select Role Configuration.

Step 2. For any and every user group that you would like to map to a role in Cloud Control Center, click Add Role and enter the Key, Value and User Role. If you copied the syntax for the Key-Value pairs in this guide, the default User Roles should look exactly like this:

KEY VALUE USER ROLE (pre-defined)
UserRole TenantAdmin Tenant Admin
UserRole TenantUser Tenant User

Any additional user groups you would like to map to custom roles can also be configured here. They should use the same key (Key = "UserRole") unless you configured your key-value differently. Key and Value are case sensitive, meaning if you used "UserRole" as your role key in Okta, it must match exactly in Cloud Control Center. The "Value" field should also match exactly the syntax of user groups assigned to your CCC Application within your IDP. You can then assign to any custom role you have created to effectively enable Role-Based Access Control for Cloud Control Center. An example might look like this:

In this example, SSO users who are members of the NetworkAdmins group are assigned the Virtual-Edges-Only custom role, which restricts their access to ONLY the Virtual Edge page.

Step 3. Click Save Changes. The message "Role mappers have been updated successfully." confirms the change.

Okta SSO Integration Completed

You can now log in to Cloud Control Center using Okta SSO for users who have the appropriate attributes applied. Click Log In With SSO and, when more than one SSO provider is configured, select this provider by name. Then enter your credentials from Okta.

Important: Each user's email address must exist in only one configured SSO provider. Signing in with the same email address through two providers, such as Okta and Entra ID, is not supported; see Configure Multiple SSO Identity Provider Connections for details.

 

Was this article helpful?
0 out of 0 found this helpful