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.

Note

Take a look to Denodo Security Token Configuration File for advanced configurations.

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

• 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.

Note

Take a look to Denodo Security Token Configuration File for advanced configurations.

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 URI https://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.

Note

Take a look to Denodo Security Token Configuration File for advanced configurations.

Kerberos Configuration¶

To enable Kerberos authentication in the Solution Manager, follow these steps:

1. Perform the post-installation tasks described in the section Setting-up Kerberos Authentication of the Denodo Platform Installation Guide.

2. 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.

3. Enable Kerberos in the Solution Manager Web Tool. Login as an administrator and click the menu Configuration > Authentication.

   

   Kerberos configuration dialog¶

   1. Check Enabled.

   2. 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.

   3. In the input Keytab file upload the keytab file generated.

   4. 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 or krb5.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.

   5. 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.

4. Configure Kerberos on your browser.

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.

Authentication dialog with Single Sign-On¶