You can translate the document:

Introduction

In this document we will learn how to configure Azure Active Directory, a Microsoft cloud based entity and access management service, to use it as an Identity Provider for the Denodo Solution Manager to achieve single sign-on.

In Azure AD we will see how to:

  • Create an Application in the Azure Portal.
  • Create Users & Groups.
  • Assign Users to the Application.
  • Configure SAML, OAuth and OpenID.

In the Denodo Solution Manager we will see how to:

  • Enable single sign-on with SAML/OAuth/OpenID from the Solution Manager web tool.
  • Create a role with the same name as the group we have created in Azure AD.
  • Grant privileges to this new role.

Azure Active Directory Configuration

In Azure, we are going to create an Enterprise application which is an application identity provided within the Azure platform.

Create an Application

Log into your Azure Portal as Global Administrator - https://portal.azure.com/

Go to the Azure Active Directory Service, choose Enterprise applications and click on “+ New application”.

Click on Legacy App Gallery Experience > Non-gallery application. We will be using the Legacy Gallery to integrate Denodo with Azure.

Enter the name of the application and click on Add. We will use Denodo80 as our application  name

Now the application is ready for the next configuration steps. Note that we will be using the same application for configuring SAML, OAuth and OpenId

Creating Users and Groups

Users

You can create Users and Groups for the application for authentication with SSO. From the home page of Azure Active Directory, Click on Users.

From here, we can create a new user for this application or use the existing users. In this document, we will use the admin user for authentication.

Groups

We can create a basic group and add users to this group. Azure AD provides two different types of groups:

  • Security - This group type is used to manage a group of users and set permissions to all members at once.
  • Microsoft 365 - This group provides options by giving members access to mailbox, calendars,files, sharepoint, etc.

Follow the below steps to create the group:

On the Azure Active Directory page, select Groups and choose New group.

Create a new group by choosing Security as group type. Assign owners to groups from this window or assign this group to specific users from the User management section.

Assign Users to this group

From the Azure page choose Groups > Members > Add members and add the users to this group.

Assign Users to this Application

The next step is to assign the users to the created application.

  • Go to Enterprise Applications > Select your App > Users and groups.
  • Click on Add user/group.
  • Select the user and click on “Select”. Note: it is also possible to select AD roles, to add them to the application.
  • Finally, click on Assign.

Now we have successfully assigned the user to our application. Using this user account we will authenticate with SSO.

Single Sign-On with SAML

Click on Single sign-on under the Manage tab and choose SAML. The SAML-based Sign-on window will appear where we will register the Denodo Solution Manager as a SAML application.

In the SAML Signing Certificate section, select Certificate(Base 64) and click on the Download link.

Note that, if the Identity provider metadata URL is “https” and the SSL certificate of this service is not signed by a known Certificate Authority, we will have to add it to the TrustStore of the Denodo Server. The section Importing the Certificates of Data Sources (SSL/TLS Connections) of the Installation Guide explains how to do this. Otherwise, when the Denodo Server connects to this service, the connection will fail because the certificate is not trusted.

Azure AD allows uploading the metadata file from an XML file. For importing the metadata file, we are going to use the “Download XML metadata file” option available in the SAML Configuration of the Denodo Solution Manager. Using this metadata we can add the Solution Manager as a Service Provider on our IdP.

To download the XML metadata file from Solution Manager, provide a unique value for the SAML entity ID for example, https://<hostname>:19443/saml and Base URL as https://<hostname>:19443.

Click on “Download XML metadata File” option which will download the “samlmetadata.xml” file. We will use this file to import it in the Azure Application. From the Azure app, click on Upload Metadata File, choose the downloaded XML file and click on Add.

Once the metadata file is uploaded, the values are automatically filled based on the information retrieved from the Solution Manager.

Finally, provide the Reply URL (Assertion Consumer Service URL). The reply URL is where the application expects to receive the authentication token. This is also referred to as the “Assertion Consumer Service” (ACS) in SAML. The configured default reply URL will be the destination in the SAML response for IDP-initiated SSO.

Save the SAML configuration. Now the Azure application is successfully configured to use SSO.

Configure User Attributes & Claims

Azure AD allows adding group claims to tokens for SAML applications using SSO configuration. The supported group claims are listed here.

To configure Group Claims, click on your enterprise application in the list, select Single Sign On configuration, and then select User Attributes & Claims and click on “Add a group claim”.

Use the following options and select one of them for the application.

Check with the Azure Administrator to select the most appropriate group for the organization.

Note: Once a group claim configuration has been added to the User Attributes & Claims configuration, the option to add a group claim will be greyed out. To change the group claim configuration click on the group claim in the Additional claims list.

A group claim provides Object IDs which are unique values and only these IDs are passed in assertion for validation. By default, only the ID’s are returned in the “groups” claim and not the group name.

To use group claims in formats other than the group ObjectId, the groups must be synchronized from Active Directory using Azure AD Connect. If a group is synchronized to Azure AD using Azure AD Connect, then the group name can be displayed. For more information on group claim settings go to Configure group claims for applications with Azure Active Directory

Enabling Single Sign-On in the Solution Manager with SAML

The next step is to enable SSO from the Solution Manager Administration Tool. Navigate to https://<hostname>:19443/solution-manager-web-tool/Login and login with an administrator user.

  • From the Solution Manager home page, go to Menu > Configuration > Authentication.
  • Expand the panel Single Sign On Configuration, enable the the option and select SAML as Authentication method.
  • Configure the following information:
  • SAML entity ID: The entity ID uniquely identifies the Solution Manager installation to the IdP. It must match the Audience URI (Identifier Entity ID) configured in Azure. For example: https://denodo-test: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://denodo-test:19443
  • SAML signing request: if it is enabled, the Solution Manager will sign authorization requests to the IdP.
  • Identity provider metadata URL: this is the URL of the configuration file that the IdP provides for the application registered.
  • To obtain this URL, from the Azure Single sign-on page, choose the following:

  • Extract roles for SAML assertion: Enable this option. 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 is disabled, configure the global LDAP settings of the Solution Manager so the Solution Manager can obtain the roles of the user from the global LDAP configuration.
  • Assertion role field: Fill with the attribute name created for retrieving user groups. As including the display name is not supported in Azure AD, use the object ID of the group created in Azure.

Create Roles in the Solution Manager

After configuring Azure as IDP and enabling SAML in the Solution Manager, create roles that have the same name as the ones created in Azure. To do that, follow the below steps:

  • Log into the Solution Manager Administration Tool.
  • Navigate to Configuration > Role Management > New.
  • Create the Role by adding the Group Object ID as the role name. As explained before, if Group Names have to be used in the assertion then Azure AD connect needs to be enabled and groups must be synchronized.

Grant the role global_admin to the new role created. Any role can be assigned, the one shown in this document is just an example.

Now, the Single Sign-On setup is ready and it is time to test the same. Open a private window in a browser and go to https://<solution_manager_host>:19443/solution-manager-web-tool/Login.

Now, a Single Sign On option is available. Click on Single Sign On and log in to Azure AD using the new user account created in Azure. In this case, it will be and admin user.

Single Sign-On with OAuth

Register an application in Azure for OAuth

We will be using the same application we created in the previous steps i.e Denodo80 for OAuth as well.

  • Login into Azure as an Admin user.
  • From the Azure home page, under App Registrations, open the registration of the client application.

  • We will be using the highlighted fields: client ID, tenant ID Endpoints for configuring OAuth in the Solution Manager.
  • In the Client Credentials Grant type, we will need a client secret. To get it, open the Certificates & secrets page and click on  New client secret.

  • Copy the generated value to some place for registering in the Solution Manager .
  • Authorize the client application, to do that go to the Expose an API page.
  • When you authorize a client, you need to specify the scope to restrict client access. To define the scope, click Add a scope and configure as needed.

Add API Permissions

For the application to authorize requests to Azure with Azure AD follow these steps:

  • On the API permissions page for your registered application, select Add a permission.
  • Under the Microsoft APIs tab, select Azure Service Management.
  • On the Request API permissions pane, under What type of permissions does your application require? choose Delegated Permissions.
  • Under Permissions, select the checkbox next to user_impersonation, then select the Add permissions button.
  • Next, grant admin consent for these permissions by clicking on Grant admin consent for Default Directory.

Enabling Single Sign-On in the Solution Manager with OAuth

Follow these steps for configuration:

  • Log into the Solution Manager Web Administration Tool with an administrator user
  • Go to Configuration > Authentication.
  • Expand the panel Single Sign On Configuration, enable this feature and in the Authentication method, select OAuth.

Enter the following details to configure Oauth. The information to fill this page can be extracted from the default metadata URI of the application (https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration)

  1. Client ID: Client identifier generated during the client application registration process. It can be obtained from the App Registration in Azure .
  2. Client secret: Client secret generated during the application registration process. It can be obtained from App Registration > Choose your App
  3. User authorization URI: to request the authentication and consent. Used to obtain the authorization code.
  4. Access token URI: to exchange the authorization code for an access token.
  5. Issuer: unique identifier of the authorization server that issues the tokens.
  6. JWKS URL: URL to retrieve the public server JSON Web Key (JWK) used to verify the authenticity of access tokens.
  7. Default process URI: /sso-oauth/oauth-login
  1. This is the relative URI for the application's callback endpoint. The Identity Provider sends an authorization response to these URIs.

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

Note: In order to add the Redirect URI, from the Azure page, open the application, go to Authentication and add the Redirect URI.

  1. Scopes: Comma separated scope to send into the request to OAuth authorization server. Review the scopes allowed by the OAuth server.
  2. 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.
  3. Token role field: Name of the token claim used to extract roles. For example groups.

Open a private window in your browser and navigate to the Solution Manager Web Administration tool. Click on Single sign-on log into the Azure portal and the user will be successfully authenticated.

Single Sign-On with OpenID

In Azure, based on the configuration of the existing application, configure OpenID. From the Azure Active Directory page go to App Registration and then to the application. Fetch the OpenID Connect metadata document by using the below URL

The URL https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration can be used to see the common configuration.

The URL  https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration can be used to see the application specific metadata information.

Register the Solution Manager as an OpenID Application

From the Azure page, open the application, go to Authentication and add the Redirect URI. In the Redirect URI, register the Solution Manager URL with the end point as /sso-openid/openid-login. For example, if the Solution Manager Web Administration Tool is accessible on https://server:port and the Default process URI is /sso-openid/openid-login, register the following Redirect URI https://server:port/sso/sso-openid/openid-login.

In order to successfully request an ID token from the /authorization endpoint, the app registration in the registration portal must have the implicit grant of id_tokens enabled in the Authentication tab.

Enabling Single Sign-On in the Solution Manager with OpenID

  • Log into the Solution Manager Web Administration Tool with an administrator user.
  • Go to Configuration > Authentication.
  • Expand the panel Single Sign On Configuration, enable this feature and in the Authentication method, select OPenID.

Fill in the following details:

  1. Authentication method: OPENID
  2. Client ID: Client ID of the application.
  3. Client secret: Client secret of the application.
  4. User authorization URI: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
  5. Access token URI: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
  6. Issuer: https://login.microsoftonline.com/{tenant}/v2.0
  7. JWKS UR: https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys
  8. Default process URI: /sso-openid/openid-login
  9. Scopes: openid,profile
  10. Token role field: Enter the details of the token to extract roles. By default it is groups.

Troubleshooting

Credentials Expired Exception

org.springframework.security.authentication.CredentialsExpiredException: Authentication statement is too old to be used with value

org.opensaml.common.SAMLException: Response doesn't have any valid assertion which would pass subject validation

When using SAML authentication if the assertion lifetime is greater than 7200 seconds it could happen that the validation of the SAML response fails.

Starting with the Denodo 8 20210715 update it is possible to disable this validation of the assertion lifetime.

  • Add the following property to the <DENODO_SOLUTION_MANAGER_HOME>/conf/denodo-sso/SSOTokenConfiguration.properties file.

saml.enableAuthenticationAgeValidation=false

  • Save the changes and execute the <DENODO_SOLUTION_MANAGER_HOME>/bin/regenerateFiles.bat (or.sh) script in order to propagate the changes in the start-up scripts.
  • Restart the Solution Manager server.

Insufficient privileges to connect to the database 'admin'

This would occur if correct privileges are not assigned to the created role in the Solution Manager or the configured Assertion role field is incorrect or misconfigured. Review this configuration to narrow down this issue.

Required string parameter "ref" is not present

When testing the application from the Identity Provider Initiator flow instead of directly  from the Solution Manager Web Administration Tool url this error will occur. This is because this option is not supported. To test the Single Sign-On configuration use the Solution Manager URL.

Troubleshooting Steps

To debug a Single Sign On issue the following log categories can be enabled.

  • Edit the log4j2.xml file located under <SOLUTION_MANAGER_HOME>/resources/apache-tomcat/webapps/sso/WEB-INF/classes directory. Change the logger level to "trace" for the following loggers:

<Logger name="com.denodo.webapp.security.sso" level="trace" />

<Logger name="com.denodo.webapp.security.sso.delegate.saml.SamlUserDetailsServiceImpl" level="trace" />

  • Restart the Solution Manager server and the logs will be send to <DENODO_HOME>/logs/denodo-sso/sso.log.

Checking the roles returned during the authentication process

To check that the id_token generated by Azure contains the desired claim as user roles, the OAuth 2.0 authorization code flow can be used.

From the Azure application go to Authentication.

  1.  Add a new redirect URI at the authentication section on the Azure AD application.
  1. https://<host>:19443/oauth/2.0/redirectURL.jsp. This URI is an utility to retrieve the code for the OAuth 2.0 authorization code flow

  1. Go to the following URL after replacing tenant, client_id and host with the actual values:

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?client_id={client_id}&response_type=code&redirect_uri=https://<host>:19443/oauth/2.0/redirectURL.jsp&response_mode=query&scope=openid%20profile

  1. Copy the code which will be later used for retrieving the access token.

  1. From a external client application like postman or using a curl command, send the below request

  1. URL : https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
  2. Method: POST
  3. Header: Content-Type / application/x-www-form-urlencoded

  1. Parameters:

  1. client_id={clientId}
  2. client_secret={clientSecret}
  3. grant_type=authorization_code
  4. redirect_uri=https://<host>:19443/oauth/2.0/redirectURL.jsp
  5. scope=openid%20profile
  6. code={code}

Copy the id_token returned. This is a JSON web token (JWT) that can be decoded using tools like https://jwt.io/. Check that decoded payload contains the group claim used as user roles. For detailed information on debugging the JWT code check Microsoft identity platform ID tokens.

References

Authenticating with Single Sign-On

Understand SAML-based single sign-on

Questions

Ask a question

You must sign in to ask a question. If you do not have an account, you can register here