How To Configure Okta for Single Sign-On in Denodo Solution Manager (2024)

You can translate the document:

In this document you will learn how to:

• Configure your Okta account to be able to use it as an Identity Provider (IdP)for the Solution Manager:

• Create a user in Okta

• Create a group

• Register the Solution Manager as a SAML application

• Register the Solution Manager as an OAuth application

• Enable single sign-on (SSO) in the Denodo Solution Manager, using your Okta account.

This document explains how to register the Solution Manager as a SAML application and as an OAuth application. In a real scenario, you will only do one or the other (currently, OAuth seems to be more popular than SAML).

This information is also applicable to Virtual DataPort, to enable OAuth authentication in the REST web services you publish.

Some organizations are transitioning from Windows Active Directory and Kerberos to “cloud-friendly” Identity Providers (IdP). These IdPs usually provide support for authentication protocols OAuth and SAML, which are more suited for applications that run on the cloud, than Kerberos. Okta is a very popular IdP.

This is what this document describes:

• In Okta

• Create a user

• Create a group and assign it to the user

• Register the Solution Manager as a SAML application or an OAuth application

• In the Denodo Solution Manager:

• Enable single sign-on with OAuth or SAML (you cannot enable both).

• Create a role with the same name as the group you have created in Okta.

• Grant privileges to this new role.

Once this is completed, single sign-on will be enabled on the Solution Manager and users will only have to provide their password in Okta.

An OAuth access token and a SAML assertion usually include the groups to which this user account belongs; that is, the user account associated with this token/assertion. When the Solution Manager receives the token/assertion, it searches the roles defined in Solution Manager that have the same name. The privileges granted to these roles will be the privileges of this user. Note that not all the privileges defined in the token/assertion have to exist in the Solution Manager.

Create an Okta Developeraccount. If you already have your own, you can use it as well.

Create a User in Okta

1. Log in to Okta as the admin user.

2. Click on Directory > People. Then click on Add Personand in this form, enter the details of the new user. Let’s say: jsmith@acme.com.

3. From a private window or another browser, log in as this user to initialize this new account.

Okta Groups

Groups are used for authorization on third-party applications. There are different types of groups in Okta:

• Native

• Active Directory

• LDAP

• Application

See the official documentationfor more information.

In this document, we are going to create a Native group because it is the more basic configuration. In a “real-world” scenario, customers may have different types of groups defined, which they may have imported from Active Directory.

To create a native group, log in to your Okta Admin Console and click on Directory > Groups >Add Group.

For example, create the group ‘developer’.

Assign Groups to a User

To assign a group to a user, do the following:

1. On the Administration Console, go to Directory > People.

2. Click on the user and on the tab Groupsand then, type the name of the group (developer) to assign it to the user.

Register the Solution Manager as a SAML Application

In this section, we are going to use the Classic UIbecause it is easier to do this.

1. Login in Okta as the admin user.
2. Click onApplications> Applications.
3. Click onCreate App Integration.

4. Select SAML 2.0as Sign-in method.

5. Set the App nameand App visibilityas follows

6. Click on Next.

SAML Settings

Enter the following:

• Single sign on URL: base URL of the web container of the Solution Manager, followed by “/sso/sso-saml/SSO”. For example:

https://solution-manager.acme.com:19443/sso/sso-saml/SSO

• Audience URI (SP Entity ID): this will be the Service Provider Identifierof this application. You will use this value later, in the single sign-on configuration of the Solution Manager. It can be a URL or plain text. For example:

https://solution-manager.acme.com:19443/saml

Attribute Statements

Add attribute statements to expose user profile values on the SAML assertion.

Group Attribute Statements

Special attribute statements to expose the user groups. The groups may be filtered, use .*as regex to retrieve all the groups assigned to the logged user.

Assign users to Application

After registering the SAML app, go to the Assignmentstab.

Go to the Assign> Assign to Peoplemenu.

Assign the test user.

Click on Save and Go Back.

Enabling Single Sign-On in Solution Manager with SAML

Follow these steps:

1. Log in to Solution Manager Web Tool with an administrator user: https://solution-manager.acme.com:19443/solution-manager-web-tool/Login

2. Click the menu Configuration > Authentication.

3. Expand the panel Single Sign On Configuration, enable this feature and select SAMLas Authentication method.

4. Provide the following:

• SAML entity ID: The entity ID uniquely identifies your Solution Manager installation to the IdP. It must match the Audience URI (SP Entity ID)configured on OKTA. For example:

https://solution-manager.acme.com:19443/saml

• Base URL: The base URL of the web container of the Solution Manager. It will be used as a base URL for Assertion Consumer Service in SAML requests to the IdP. For example:

https://solution-manager.acme.com:19443

• SAML signing request: if it is enabled, the Solution Manager will sign authorization requests to the IdP.

• Identity provider metadata URL: this is a URL of the configuration file that the IdP (Okta) provides for the application you registered.

  To obtain this URL, go back to Okta, open the details of the application and look for

  Sign on Details > SAML Signing Certificates(see below)

• Extract roles for SAML assertion: Enable this.

  By enabling this option, the Solution Manager will extract the roles of the users that are trying to log in, from the SAML assertion. If this option was disabled, you would have to configure the

  global LDAP settings of the Solution Managerso the Solution Manager can obtain the roles of the user.

• Assertion role field: Fill with the attribute name created for retrieving user groups. For instance: groups.

Sample SAML assertion

Register an OAuth Application in Okta

1. Login in Okta as the admin user.
2. Click on Applications> Applications.
3. Click on Create App Integration.

4. Select OIDC - OpenID Connectas Sign-in method.
5. Select Web Applicationas Application type.

6. Click on Next.

Once the application was created you can view important information like client credentials:

Configure Authentication Token

An OAuth token contains claims. A claim is information about the subject (the user), such as name, role, or email address. Beyond the default set of claims that are contained in ID tokens and access tokens, you can define your own custom claims and the Groups claim. To configure the Groups claims do the following steps:

Under Security> API > Authorization Serverswe can navigate to the default Authorization server.

Click on defaultand go to theClaimstab.

Click the Add Claimbutton.

In this form, enter the following:

• Name: The name of the claim that will be attached to the token. Use groups

• Include in token type: Select Access Tokenfor OAuth or ID Tokenfor OpenID Connect.

• Value type: Select Groupsto retrieve the user group values.

• Filter:Select Matches regexwith .* to not exclude groups.

• Include in: Check Any scopeto always attach the claim, independently of the scopes that have been requested.

Default Authorization Server Metadata

Under Security> API > Authorization Servers, navigate to the default Authorization server and review the metadata uri with important information for configuring our clients.

Click default

Metadata URI with information about OAuth Authorization Server: https://dev-{ACCOUNT_NUMBER}.okta.com/oauth2/default/.well-known/oauth-authorization-server

Click on this URL to see the JSON metadata of the service. It contains the issuer, authorization_endpoint, token_endpoint, jwks_uri, scopes_supported, etc. You will need this information to configure the OAuth authentication in the Solution Manager.

Enabling Single Sign-On in Solution Manager with OAuth

Follow these steps:

1. Log in to Solution Manager Web Tool with an administrator user: https://solution-manager.acme.com:19443/solution-manager-web-tool/Login

2. Click the menu Configuration > Authentication.

3. Expand the panel Single Sign On Configuration, enable this feature and in Authentication method, select OAuth.

4. Provide the following:

• Client ID: Client identifier generated during the client application registration process. It can be obtained from the Application detail on OKTA.

• Client secret: Client secret generated during the application registration process. It can be obtained from the Application detail on OKTA.

• To obtain the information to fill this page you can extract it using default metadata.

https://dev-{ACCOUNT_NUMBER}.okta.com/oauth2/default/.well-known/oauth-authorization-server

• User authorization URI: to request their authentication and consent. Used to obtain the authorization code.

• Access token URI: to exchange the authorization code for an access token.

• Issuer: unique identifier of the authorization server that issues the tokens.

• JWKS URL: URL to retrieve the public server JSON Web Key (JWK) used to verify the authenticity of access tokens.

• Default process URI: Enter this:/sso-oauth/oauth-login
  
  This is the relative URI for application’s callback endpoint. The Identity Provider sends an authorization response to these URIs.

The complete URL must match the one registered on the OAuth Authorization Server (usually called Redirect URI). For example, if your Solution Manager Web Tool is accessible by https://server:portand the Default process URI is /sso-oauth/oauth-login, you should register the following Redirect URI https://server:port/sso/sso-oauth/oauth-login.

• Scopes: Comma separated scope to send into the request to OAuth authorization server. Review the scopes allowed by your OAuth server. Use openid.

• Extract roles from token: The token will attach roles in a claim. If it is not selected, then the global LDAP section on authentication with LDAP, must be configured for retrieving the user roles using a LDAP search.

• Token role field: Name of the token claim used to extract roles. For example groups.

After enabling SAML or OAuth authentication in Solution Manager, you have to create roles that have the same names as the ones you created in Okta.

As with LDAP authentication of Virtual DataPort, you do not need to create all the roles that a user of Okta may have; only create the ones you need to.

1. Log in to the Solution Manager with an administrator account.

2. Go toConfiguration > Role managementand click .

3. Create a role for the roles you have assigned. In this document: developer.

4. Grant the role global_adminto the new role (developer) (see Authorization details):

   You can grant any other role, this is just an example.

At this moment, the single sign-on configuration should be ready.

5. Open a private window in your browser and go to https://solution-manager.acme.com:19443/solution-manager-web-tool/Login.

   Click

   Single sign-on. Log in to Okta using the new user account you have created in Okta; not the credentials you used to create the developer account.

Authenticating with Single Sign-On

Disclaimer
The information provided in the Denodo Knowledge Base is intended to assist our users in advanced uses of Denodo. Please note that the results from the application of processes and configurations detailed in these documents may vary depending on your specific environment. Use them at your own discretion.
For an official guide of supported features, please refer to the User Manuals. For questions on critical systems or complex environments we recommend you to contact your Denodo Customer Success Manager.