You can translate the document:


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 / Groups 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

NOTE: It is necessary to create an application under the Enterprise applications section and not under the App registrations sections since the SAML SSO option is available only when you create an application as “Azure AD Gallery or Third option (Non-gallery)”.

Follow the below steps to create an application:

  • Log into your Azure Portal as Global Administrator -
  • Go to the Azure Active Directory Service > Enterprise applications and click on “+ New application”.

  • Enter the name for the application. We will use Denodo_8 as our application name.
  • The Supported account types will be determined by your internal security policy, so it is recommended to check this with your administrators. Usually the Single tenant is the option to choose when the use is internal to your organization.
  • The Redirect URI can be configured here optionally. We will be configuring it later in the below sections.
  • Click on Register.

Now the application is ready for the next configuration steps. Note that in this document, we will be using the same application for configuring SAML, OAuth and OpenID. It can also be configured to use separate application registrations for each authentication.

Creating Users and Groups


You can create new 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.


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 Home page, select Groups and choose New group.

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

Later to add additional users to this group, go to  Groups > Members > Add members and select the users to this group.

Assign Users / Groups to this Application

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

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

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

Single Sign-On with SAML

Register an application in Azure for SAML

Click on Single sign-on under the Manage tab of the created enterprise application and choose SAML.

The SAML-based Sign-on window will appear where we will register the Denodo Solution Manager as a SAML application.

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 and Base URL. For example,

  • SAML entity ID - http://localhost:19090/saml 
  • Base URL - http://localhost:19090.

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.

Go back to the SAML configuration section, click on Upload Metadata File option, choose the downloaded XML file and click on Add.

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

Finally, validate 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. Click on Save.

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 grayed out. To change the group claim configuration click on the created group claim in the Additional claims list and edit accordingly.

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. As an alternative, app roles can be configured as mentioned in the Configure App Roles section below.

Additionally, 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

Nextly, 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) explains how to do this. Otherwise, when the Denodo Server connects to this service, the connection will fail because the certificate is not trusted.

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 http://<hostname>:19090/solution-manager-web-tool/Login and login with an administrator user.

  • From the Solution Manager home page, go to Menu > Configuration > Authentication section.
  • Expand the panel Single Sign On Configuration, enable 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: http://localhost:19090/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: http://localhost:19090.
  • 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: Add claim name created for retrieving user groups.

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 which will be retrieved in the token. 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 appropriate Group Object ID as the role name. As explained before, if Group Names have to be used in the assertion then configure either App Roles or 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 http://<solution_manager_host>:19090/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 the admin user and this can be checked in the User Logout name of the Solution Manager web tool.

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 Denodo_8 for OAuth as well.

  • From the Azure home page, under App Registrations, open the registration of the client application.

  • We will be using the highlighted fields: Application (client) ID and Directory (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 section and click on  New client secret.

  • Copy the generated value for registering it later in the Solution Manager.

Add API Scope

  • Nextly, authorize the client application and to do that go to the Expose an API page. The default App URI follows the format api://<client_id>
  • 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.

  • The new scope created follows the format api://<client_id>/<scope_name>
  • Save by clicking on Add scope.

Add Groups Claim

To configure Group Claims to the token, follow the below steps:

  • Go to Token Configuration > Add groups claim.
  • Select group type as Security groups.
  • Select the group claim by choosing Group ID for Access token types. (Choose the same for ID token type for OpenID authentication)
  • Click on Add.


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 section.
  • 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 (<tenant-id>/v2.0/.well-known/openid-configuration) or from the Endpoints section in the Overview page of the Azure AD Application.

  1. Client ID: Client identifier generated during the client application registration process. This is the “Application (client) ID” property from the “Overview” page of the Azure AD application.
  2. Client secret: Client secret generated during the application registration process. This will be available only once during the generation and should be saved safely for later use.
  3. User authorization URI: to request 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 http://<hostname>:<port> and the Default process URI is /sso-oauth/oauth-login, register the following Redirect URI http://<hostname>:<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.

For OAuth authentication, make sure the Access tokens checkbox is enabled for successfully requesting an Access token from the authorization endpoint during authentication and click Save.

  1. Scopes: Scope to send into the request to OAuth authorization server. Review the scopes allowed by the OAuth server. Here, we have configured the new API scope created.
  2. Extract roles from token: By enabling this, 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 with OAuth.

In case, while performing SSO for the first time with a normal user account, an admin consent can be required. So you would need to contact the Global Administrator to provide consent. Check the Configure the admin consent workflow for more details.

Single Sign-On with OpenID

For OpenID, follow the same steps as configured above for the Azure application and OAuth authentication in Solution Manager. Additionally, modify certain configurations as explained below.

Register an application in Azure for OpenID

From the Azure page, open the same application, go to Authentication and add the Redirect URI. In the Redirect URI, register the Solution Manager URL with the endpoint as /sso-openid/openid-login.

For example, if the Solution Manager Web Administration Tool is accessible on http://<hostname>:<port> and the Default process URI is /sso-openid/openid-login, register the following Redirect URI http://<hostname>:<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.

Fetch the OpenID Connect metadata document by using the default metadata URI of the application (<tenant-id>/v2.0/.well-known/openid-configuration) or from the Endpoints section in the Overview page of the Azure AD Application.

Fill in the details same as configured for the OAuth Configuration section. Changes to be applied are:

  1. Default process URI: /sso-openid/openid-login
  2. Scopes: openid

Try Single sign-on into the solution manager web tool and the user will be successfully authenticated with OpenID.

Additional Information

Configure App Roles

For all three authentication methods, either the SAML assertion or the tokens hold the group information for granting the user privileges in Denodo. By default, the “groups” claim comprises an array  with the IDs of the groups to which this user is a member. Managing these group IDs and permissions in Denodo can be a cumbersome task.

In order to manage the roles with a valid group name instead of IDs, App Roles can be configured. App roles are defined on an application registration representing a service, application or API. Azure AD then emits a “roles” claim for each role that the user or service principal has been granted.

To configure this, follow below steps:

Go to the App roles section of the Application and click on Create app role.

Configure the necessary values and click Apply:

  • Display name: Name to be displayed for the app role.
  • Allowed member types: Specifies whether this app role can be assigned to users, applications, or both.
  • Value: Specifies the value of the roles claim that the application should expect in the token.

NOTE: This is the name that should be created in the Configuration > Role Management section to grant the necessary privileges. Here, dev_sm.

Next is to assign users / groups to the created app roles.

  • Go to Enterprise Applications > Select your Application > Users and groups.
  • Click on Add user/group.
  • Click on Add user to open the Add Assignment pane. Select the designated user and click Select. (It is also possible to select a created group like the previously created one, Denodo_Developer.)
  • Click on Select a role in the Add assignment pane. Select the role that you've defined for the application and click Select.
  • click Assign.

The app roles are the default claims included in the assertion / tokens and hence the information will be automatically fetched during authentication.

In Solution Manager Web Tool, modify the Token role field value for each authentication:

  • SAML:

  • OAUTH / OPENID: roles        

Make sure to configure the created app role claim “dev_sm” under the Role Management section of the Solution Manager Web tool and grant necessary privileges.

Forced Logout from SSO

From the Denodo update 8.0u20230301, it is possible to configure a redirect URL to be disconnected from SSO during the logout of web tools. The “logout.redirect-url” property can be configured to be redirected from the web application you are logging out to a logout page of the identity provider system. Check the Denodo Security Token Configuration File section for detailed information.

For instance: The logout URI for signing out from the Azure AD after OAuth authentication is

Hence, the below property can be configured under the <SOLUTION_MANAGER_HOME>/conf/denodo-sso/ file and restart Solution Manager server for the changes to take effect.


NOTE:The redirection will be done in the current browser window. If the user is authenticated in more than one application with SSO, the logout will be performed only in the application where the logout was executed. The rest of the applications will keep their sessions active.


Credentials Expired Exception 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.0u20210715 update, it is possible to disable this validation of the assertion lifetime.

  • Add the following property to the <SOLUTION_MANAGER_HOME>/conf/denodo-sso/ file.


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

InvalidSignatureException [] - Error during authentication Could not obtain user details from token


Caused by: RSA Signature did not match content

This error recently occurs when configuring openid as scope only for the OAuth Authentication. To resolve this configure a different scope by following the steps as mentioned in the Add API Scope sub-section of this document.

InvalidTokenException [] - Error during authentication Could not obtain user details from token


Caused by: Invalid JOSE Header kid

This error occurs when the “kid” is included in the header and this inclusion does not match the corresponding public key to be identified from the list of public keys available in the JSON Web Key Set (JWKS) endpoint. The default JWKS endpoint<tenant-id>/discovery/v2.0/keys may return incompatible kid keys.

For those scenarios, the application specific JWKS URI<tenant-id>/discovery/v2.0/keys?appid=<app-id>” can be configured.

Could not obtain the username using the claim preferred_username

This error occurs when the default claim “preferred_username” is not presented as part of the token during OpenID authentication. Starting from the update 8.0u20230301, the configuration can be altered to a appropriate claim holding username by setting the below property in the  <SOLUTION_MANAGER_HOME>/conf/denodo-sso/ file and restarting.

openid.userNameClaim = <value>

Similarly for OAuth, this error can appear where “sub” is the default claim configured for fetching username. This can be modified using the below property.

oauth.userNameClaim = <value>

Check Denodo Security Token Configuration File for detailed information.

Insufficient privileges to connect to the database 'admin'

This situation could arise due to incorrect privileges assigned to the created role in Solution Manager or if the configured Assertion role field is inaccurately set or misconfigured. To troubleshoot, it's advisable to carefully review and assess this configuration to identify the root cause of the issue.

Required string parameter "ref" is not present

Single Sign-On (SSO) in Solution Manager exclusively supports the Service Provider (SP)-Initiated Flow. In the event that SSO is initiated by the Identity Provider (IDP), this error will arise. To prevent this issue, it's recommended to always initiate the SSO process from the Solution Manager web tool.

Additional 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="" level="trace" />

<Logger name="" level="trace" />

<Logger name="" level="trace" />


<Logger name="" level="trace" />

<Logger name="" level="debug" />

<Logger name="" level="debug" />

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

Checking the roles returned during the SSO

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

Using Browser,

After you login via the identity provider you will be redirected to the Solution manager web page.

  1. Open the Developers console in the web browser and navigate to the Network tab.
  2. Perform the Single Sign On.
  3. For SAML, look for the SSO endpoint. For OAuth / OpenID look for the token endpoint.
  4. Navigate to the Payload tab and you should see a header like SAML response or token in encoded format.
  5. Decode this assertion / token to get the complete details retrieved from the IDP.

The SAML Assertion can be decoded using the SAML decoder. The copied token is a JSON web token (JWT) that can be decoded using online tools like 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.

Using Logs,

It is also possible to obtain OAuth / OpenID token information from the logs for debugging purposes.

  1. Enable the above mentioned log levels
  2. Save the changes and restart the Solution Manager server for the changes to take effect.
  3. Perform Single Sign On and look for the Bearer parameter in the <SOLUTION_MANAGER_HOME>/logs/solution-manager/solution-manager.log.
  4. The encoded token can then be decoded to extract the useful information as mentioned above.


Authenticating with Single Sign-On

Denodo Security Token Configuration File

Understand SAML-based single sign-on

Add app roles to your application and receive them in the token


Ask a question

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