Introduction

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 8.0, 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.

Summary of the Process

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.

Okta Configuration

Create an Okta developer account https://developer.okta.com/. If you already have your own, you can use it as well.

Create a User in Okta

1. Log in to Okta and then, click Admin (on the top-right corner)

2. Click Users > People. 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 documentation for 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 Directory > Groups.

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 Users > People.

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

Single Sign-On with SAML

Register the Solution Manager as a SAML Application

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

1. Go to the Classic UI (look for the Developer Console link)

2. Go to Applications menu and then, click Create new app.

3. In this dialog, select SAML 2.0:

Click on Next

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 Identifier of 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

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 in Authentication method, select SAML.

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 (use Classic UI), open the details of the application and look for Sign on Details (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 Manager so 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.

<Attribute Name="groups"    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">    <AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:type="xs:string">Everyone</AttributeValue>    <AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:type="xs:string">developer</AttributeValue> </Attribute>

Sample SAML assertion

Single Sign-On with OAuth

Register an OAuth Application in Okta

Using the default console:

If you are on Classic UI, change to Developer Console on the top menu:

Add Application. Select Web

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 the API > Authorization Servers we can navigate to the default Authorization server.

Click default and select the Claims tab.

Click the Add Claim button.

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 Token for OAuth or ID Token for OpenID Connect.

• Value type: Select Groups to retrieve the user group values.

• Filter: Select Matches regex with .* to not exclude groups.

• Include in: Check Any scope for always attaching the claim, independently of the scopes that has been requested.

Default Authorization Server Metadata

Under the 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 and to view 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:port and 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.

Create Roles in Solution Manager

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 to Configuration > Role management  and click .

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

4. Grant the role global_admin to 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.

References

Solution Manager Administration Guide: Authenticating with Single Sign-On

Denodo 8: Quick Start Guide with Automated Cloud Mode - section Enable Single Sign-On.