Authenticating with Single Sign-On¶
The Solution Manager supports several single sign-on authentication methods, either using an external Identity Provider or using Kerberos. This ability improves the user experience and reduce the complexity of managing passwords across different applications.
To achieve single sign-on using an Identity Provider, the Solution Manager includes a system called Denodo Security Token, which is capable of delegating the authentication of users to the Identity Provider. It can do so using these authentication protocols:
SAML
OAuth
OpenID Connect
The Solution Manager also supports Kerberos authentication.
To enable single sign-on authentication in the Solution Manager, click the menu Configuration > Authentication menu. Then, expand Single Sign On Configuration and toggle Enabled on. Then, select one of the authentication methods available (the sections below explain how to configure them):
SAML Configuration¶
Fill this section to configure a authentication against an external SAML Identity Provider (IdP):
SAML entity ID: The entity ID uniquely identifies your Solution Manager installation to the IdP.
Base URL: The base URL of the platform web container. It will be use as base URL for Assertion Consumer Service in SAML requests to the IdP.
SAML signing request: If is enabled, Solution Manager installation will sign authorization request to the IdP. The SAML request will be signed using the authentication credentials configured in Solution Manager.
Download XML metadata file: Specify the file location and use this file to exchange the metadata that contains relying party information and certificates between Solution Manager and the IdP. Using this metadata you can add Solution Manager as a Service Provider on your IdP.
Important
Once SAML configuration is saved, the XML metadata will be available in the URL https://solution-manager.acme.com:19443/sso/sso-saml/metadata. You can use it if the Identity Provider of your organization allows URL for XML metadata exchange. In this case, you need to allow incoming connections from the Identity Provider to the server where the Solution Manager runs. For instance, port 19443 should be open.
Identity provider metadata URL: Once Solution Manager was added as a Service Provider on your IdP, you can retrieve the IdP’s metadata. At runtime, the Server recovers the identity provider identifier and the signing certificate from this URL.
Note
If this URL is “https” and the SSL certificate of this service is not signed by a known Certificate Authority (CA) like Verisign, Comodo, etc., you have to add it to the TrustStore of the Server. The section Importing the Certificates of Data Sources (SSL/TLS Connections) of the Virtual DataPort Administration Guide explains how to do this. Otherwise, when the Server connect to this service, the connection will fail because the certificate is not trusted.
Extract roles from SAML assertion: Enabling this option, the roles will be extracted from the assertion. If this option is not selected, then the global LDAP section on authentication with LDAP, have to be configured for retrieve the user roles using a LDAP search.
Assertion role field: Name of the SAML assertion attribute used to extract roles. For example the following piece of code is a SAML attribute named Group that represents the controller role:
<Attribute Name="Group" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <AttributeValue>controller</AttributeValue> </Attribute>
Once the user’s identity has been verified, the external identity provider (IdP)
sends an authentication response that includes the assertion to the SAML
endpoint at https://server:port/sso/sso-saml/SSO
, over the
HTTP POST Binding for SAML 2.0 standard.
After this change, when the users go to the Solution Manager, they will be redirected to the external Identity Provider automatically.
OAuth Configuration¶
Fill this section to configure a authentication against an external OAuth Provider:
Client ID: Client identifier generated during the client application registration process.
Client secret: Client secret generated during the application registration process.
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: Relative URI for application’s callback endpoint. The Identity Provider sends an authorization response to these URIs. Default /sso-oauth/oauth-login
Important
The complete URL must be 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 URIhttps://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.
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 retrieve the user roles using a LDAP search.
Token role field: Name of the token claim used to extract roles.
After this change, when the users go to the Solution Manager, they will be redirected to the external Identity Provider automatically.
OpenID Configuration¶
Fill this section to configure a authentication against an external OpenID Provider:
Client ID: Client identifier generated during the client application registration process.
Client secret: Client secret generated during the application registration process.
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: Relative URI for application’s callback endpoint. The Identity Provider sends an authorization response to these URIs. Default /sso-openid/openid-login
Important
The complete URL must be match the one registered on the 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-openid/openid-login
, you should register the following Redirect URIhttps://server:port/sso/sso-openid/openid-login
.Scopes: Comma separated scope to send into the request to authorization server. For example: openid, email, profile, and offline_access.
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 retrieve the user roles using a LDAP search.
Token role field: Name of the token claim used to extract roles.
After this change, when the users go to the Solution Manager, they will be redirected to the external Identity Provider automatically.
Kerberos Configuration¶
To enable Kerberos authentication in the Solution Manager, follow these steps:
Perform the post-installation tasks described in the section Setting-up Kerberos Authentication of the Denodo Platform Installation Guide.
Indicate a Kerberos realm, if it is different from the one from your domain, as explained in the page Enabling Kerberos Authentication Without Joining a Kerberos Realm.
Enable Kerberos in the Solution Manager Web Tool. Login as an administrator and click the menu Configuration > Authentication.
Check Enabled.
In the box Server principal name enter the “Service Principal Name” (SPN) used to create the keytab file.
For example, if you created the SPN with the command
setspn -S HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM CONTOSO.COM\denodo_server
enter
HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM
.In the input Keytab file upload the keytab file generated.
Leave the Kerberos configuration file input empty unless your environment meets one of these conditions:
The host where Solution Manager runs does not belong to a Kerberos realm (e.g., a Windows Active Directory domain).
Or the host where Solution Manager runs is Linux/Unix.
Or you are in a cross-domain scenario. That is, the organization has several domains.
If the environment meets any of these conditions, upload the file
krb5.conf
orkrb5.ini
Usually, the administrators of the Active Directory can provide a krb5 file. It is better to use one of an application that already uses Kerberos authentication to make sure it is correct.
The first time you set up Kerberos, we recommend selecting the check box Debug mode in case you run into any issues. Once Kerberos has been set up, disable this to avoid filling the log files with Kerberos debug messages.
To activate this logs you must edit the file
<DENODO_HOME>/conf/vdp/log4j2.xml
and add the following line, right below the line<Loggers>
:<Logger name="com.denodo.util.logging.JavaConsoleLogging" level="debug" />
You will find the Kerberos debug messages in
<DENODO_HOME>/logs/vdp/vdp.log
.
After this change, when the users go to the Solution Manager, they will be logged in automatically - without entering their credentials - because the browser will send the Kerberos credentials of their system.
Important
To access the Solution Manager Administration Tool, remember to
use the Fully Qualified Domain Name of the Server Principal Name
you configured in the Solution Manager Virtual DataPort Server.
For example, if your Server Principal Name is
HTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM
, you should
access the Solution Manager Administration Tool through the URL
http://denodo-prod.subnet1.contoso.com:19090/solution-manager-web-tool
or
https://denodo-prod.subnet1.contoso.com:9443/solution-manager-web-tool
.