USER MANUALS

Denodo Security Token

The Denodo Security Token Server is a system that delegates the authentication to an external Identity Provider (e.g. Okta, PingFederate, Azure Active Directory, etc.) It takes the authorization object and generates a valid credential so the other applications can use it to gain access across all the components of the Denodo Platform.

In addition, it provides Single Sign-On authentication. With this, users log in to the Solution Manager with their browser and from there, they can open any component of the Denodo Platform installations (Data Catalog, Design Studio, etc.) without having to enter the password again.

Note

The Solution Manager installation contains a file <SOLUTION_MANAGER_HOME>/conf/SSOConfiguration.properties and the value of the property sso.token-enabled must be true. Please, do not manually change this value.

Architecture

The Denodo Security Token Server is an application that runs on the web container of the Solution Manager. It provides a centralized authentication server based on the following points:

  1. Delegate authentication to external identity providers:

    • SAML

    • OAuth

    • OpenID Connect

  2. Role extraction from the delegated authentication object. The original assertion or token can be processed to extract role information by a configured attribute name.

  3. Issue temporary credentials representing the user who has just been authenticated through the external Identity Provider. This credentials are verified and validated by Denodo environment and grants the access on it.

Denodo Security Token Architecture

Denodo Security Token Architecture

Configure the Denodo Platform Components to Reach the Security Token Server

In the following scenarios, the components of the Denodo Platform need to connect to the Denodo Security Token Server:

  1. To enable Single sign-on across the web components of the installation. That is, the users log in to Solution Manager and then, they can open Data Catalog, Design Studio and others without entering their credentials on each application.

    Single sign-on configuration can be made in the specific page authentication configuration.

  2. To perform the following administrative tasks from the Solution Manager over an installation of the Denodo Platform:

    • Diagnostic and Monitoring: to check the status of servers. That is, either loading historical data or in real-time. Used by the Diagnostic & Monitoring Tool distributed with the Solution Manager installation and by the embedded Denodo Monitor to monitor an environment, a cluster or a server.

    • Deployments: to deploy revisions into environments.

    • Manage Log levels: to manage the logging level of the Virtual DataPort servers.

When you create an environment using the Automated Cloud Mode, the Solution Manager automatically configures the new installations so they can reach the Security Token Server.

When you install the Denodo Platform manually, you have to configure this installation so it can reach the Denodo Security Token Server (see Configure the Connection to the Security Token Server from the Denodo Platform below).

Security Considerations

For production environments, we strongly recommend that all the communication with the Denodo Security Token server is performed over a secure channel (i.e. SSL/TLS). It is important because the generated token is a security credential that should be transmitted securely. For this reason, Denodo Solution Manager and all the Denodo Platform used in environments must be over a secure channel (i.e. SSL/TLS). The section enable SSL/TLS in the Denodo Platform explains how to enable this.

Note

If you use a self-signed certificate or an SSL certificate that is only recognized within your organization, you have to import this certificate to the TrustStore of all the installations of the Denodo Platform. Otherwise, the connection to the Security Token Server will fail.

External Identity Provider Considerations

Denodo Security Token acts as a central authentication system to manage the delegated authentication. For this reason you must add a relying party trust between your identity provider and Denodo Security Token. This trust registration has a common configuration that depends on the protocol used in the external provider.

  • For SAML Identity Providers you can use the Service Provider XML metadata exposed by the Denodo Security Token on this URL: https://solution-manager.acme.com:19443/sso/sso-saml/metadata.

  • For OAuth and OpenID Connect providers you should add a Redirect URI (Complete URI to which the provider may redirect after authorization is obtained). The default redirect URI on Denodo Security Token follow this format: https://solution-manager.acme.com:19443/sso/sso-oauth/oauth-login. Ending in /sso/sso-oauth/oauth-login for OAuth and in /sso/sso-openid/openid-login for OpenID Connect.

Note

Review specific details on your Identity Provider for each configuration.

Configure the Connection to the Security Token Server from the Denodo Platform

In all your installations of the Denodo Platform, follow these steps so the components of these installations can reach the Denodo Security Token Server, which is part of the Solution Manager:

  1. Check that the clocks of the computers of the Denodo Platform servers and the computer of the Solution Manager are in sync. On Windows, check that the option Synchronize your clock is enabled. On Linux, check that the Network Time Protocol (NTP) service is enabled.

    The clocks of these computers need to be in sync as much as possible. That is, both computers must be set to the same time and date. Not having the clocks synchronized may cause the single sign-on process between Solution Manager and the Denodo Platform components to fail with the error “Expired JWT”.

  2. Set up the connection to the Security Token Server in all your installations of the Denodo Platform. You can do this graphically or from the command line:

    1. To do this graphically, open the Denodo Platform Control Center of this installation (open <DENODO_HOME>/bin/denodo_platform). Then, click Configure and enter this:

      • Host: hostname of the Solution Manager. For example solution-manager.acme.com. The Denodo Security Token runs on the Solution Manager.

      • Port: enter 19443 if you enabled HTTPS on the web container of the Solution Manager; enter 19090 if it is disabled. You have to enter the port number of the web container because the Denodo Security Token Server runs on the web container of the Solution Manager.

      • Uses SSL/TLS: select this if you enabled HTTPS on the web container of the Solution Manager.

      • Enable Denodo Single Sign On for web applications: to allow Single Sign-On authentication through Denodo Security Token.

    Denodo Security Token enabled by Denodo Platform Control Center

    Denodo Security Token enabled by Denodo Platform Control Center

    1. To do this from the command line, edit <DENODO_HOME>/conf/SSOConfiguration.properties and set these properties:

      • sso.url: URL of the Denodo Security Token in the following format {scheme}://{hostname}:{port}. Usually this will be the web container URL of the Solution Manager, where the Denodo Security Token Server is deployed by default.

        For example https://solution-manager.acme.com:19443.

      • sso.token-enabled: Denodo Security Token enabled for Virtual DataPort (if it is installed).

      • sso.enabled: Denodo Security Token Single Sign-On enabled for the web applications deployed in this installation.

      sso.url=https://solution-manager.acme.com:19443
      sso.token-enabled=true
      sso.enabled=true
      
  3. Restart the affected servers to apply these changes.

Note

This Denodo Platform must be able to reach the web container port of the Solution Manager (19443 if HTTPS is enabled, 19090 if disabled). To verify that, run the following command from the Denodo Platform machine: telnet <Solution Manager Host> <Web Container Port>

Configure HTTP Timeouts and Limits for the Request of Public Keys

When the public signing keys are requested by URL to do the token signature validation, the slow or saturated networks can be a problem. In this case, you can configure connection timeouts and limits for the request of public keys. Usually, you do not need to do anything if you do not find any problem (e.g. timeouts for slow connection). If these configuration properties are not present, the default values will be used.

The following configuration properties can be changed using the command SET to define behavior of the HTTP connections opened from the Virtual DataPort Server to get the public keys.

  • com.denodo.vdb.security.DndTokenAuthenticator.RemoteJWKSet.httpConnectionTimeout: The HTTP connection timeout, in milliseconds, zero for infinite. The default value is 4000.

  • com.denodo.vdb.security.DndTokenAuthenticator.RemoteJWKSet.httpReadTimeout: The HTTP read timeout, in milliseconds, zero for infinite. The default value is 4000.

  • com.denodo.vdb.security.DndTokenAuthenticator.RemoteJWKSet.httpSizeLimit: The HTTP entity size limit, in bytes, zero for infinite. The default value is 51200.

  • com.denodo.vdb.security.DndTokenAuthenticator.JWKSetCache.expirationTime: The lifespan of the cached JWK set before it expires, negative means no expiration. The default value is 300.

Also, you can manually edit <SOLUTION_MANAGER_HOME>/conf/SSOConfiguration.properties and <DENODO_HOME>/conf/SSOConfiguration.properties in order to define behavior of the HTTP connections opened from the components of the Solution Manager/Denodo Platform installations to get the public keys:

  • sso.jwt.jwk.httpConnectionTimeout: The HTTP connection timeout, in milliseconds, zero for infinite. The default value is 2000.

  • sso.jwt.jwk.httpReadTimeout: The HTTP read timeout, in milliseconds, zero for infinite. The default value is 2000.

  • sso.jwt.jwk.httpSizeLimit: The HTTP entity size limit, in bytes, zero for infinite. The default value is 51200.

  • sso.jwt.jwk.expirationTime: The lifespan of the cached JWK set before it expires, negative means no expiration. The default value is 300.

Load Balancer Considerations

In a network configuration where the Denodo security token service (part of the solution manager) is behind a load balancer, authentication delegation or SSO setup can fail for several reasons. These failures can often happen when the Denodo platform servers are also behind the load balancer and try to retrieve the public signing key (by using the URL defined in the sso.url property) but cannot reach the solution manager to access the security token service using this URL endpoint.

In these situations, you can configure an alternative URL endpoint (sso.jwt.jwk.sourceUrl) for the Denodo security token service that bypasses the load balancer. The Denodo platform servers will then access this alternative URL endpoint to retrieve the public signing keys without contacting the load balancer.

Furthermore, a second property (sso.jwt.jwk.httpTrustedHostnames) may also need to be defined depending on the alternative URL endpoint used.

Edit the following properties in the files <SOLUTION_MANAGER_HOME>/conf/SSOConfiguration.properties and <DENODO_HOME>/conf/SSOConfiguration.properties to address these kinds of network issues and define the use of an alternative, private URL endpoint for the retrieval of the public verification key.

  • sso.url: The default URL endpoint used to access the Denodo security token service. This would be the URL of the load balancer if it has been configured for the network. For example sso.url=https://load-balancer.com

  • sso.jwt.jwk.sourceUrl: The alternative URL endpoint (instead of what is defined in sso.url) used by the Denodo platform servers to retrieve the public signing keys. As mentioned above, this would typically be a localhost reference or a private hostname that bypasses the load balancer. For example sso.jwt.jwk.sourceUrl=https://localhost:19443/sso/jwks.json or sso.jwt.jwk.sourceUrl=https://internal-dns:19443/sso/jwks.json. Note that to ensure the successful retrieval of the public signing keys, the URL’s hostname defined in this property must be valid by matching with one of the hostnames specified in the Solution manager signing certificate.

  • sso.jwt.jwk.httpTrustedHostnames: In situations where the use of an invalid hostname in sso.jwt.jwk.sourceUrl cannot be avoided, then you need to override the standard validation process by adding the invalid hostname defined in sso.jwt.jwk.sourceUrl in the property sso.jwt.jwk.httpTrustedHostnames. For instance, if you have set sso.jwt.jwk.sourceUrl=https://localhost:19443/sso/jwks.json, and “localhost” is not present in the Solution manager certificate (typically the case), then you must set sso.jwt.jwk.httpTrustedHostnames=localhost in order for “localhost” to be accepted as an alternative URL endpoint host. Note that this property is not mandatory and is empty by default.

Note that if the Virtual DataPort server is behind a load balancer or unable to access the solution manager via the URL endpoint defined in the sso.url property, then, you need to define an additional parameter to avoid the network issues described above and allow the Virtual DataPort Server to retrieve the public validation key by bypassing the load balancer using an alternative URL endpoint specifically used by the Virtual DataPort Server.

Edit the below property in the files <SOLUTION_MANAGER_HOME>/conf/vdp/VDBConfiguration.properties and <DENODO_HOME>/conf/vdp/VDBConfiguration.properties to define an alternative URL endpoint for the Virtual DataPort Server.

  • com.denodo.vdb.security.DndTokenAuthenticator.jwkSourceUrl: The alternative URL endpoint (instead of what is defined in sso.url) used by the Virtual DataPort server to retrieve the public signing key.

See the section Configuring Access Through the Load Balancer to review another considerations in these scenarios.

Authentication Credentials

The Solution Manager uses signature credentials to secure the communications with other components of the Denodo Platform. You can configure the Solution Manager to use a custom RSA cryptography key or one autogenerated by the system.

To manage the Solution Manager Credentials, click the menu Configuration > Authentication. The authentication credentials are configured at the top of this tab.

Solution Manager credentials configuration

Solution Manager credentials configuration

If Autogenerated is selected (default option), the Solution Manager uses a private key that was auto-generated.

If you select Custom, you need to provide this:

  • KeyStore file: a keyStore file that meets these prerequisites:

    • Contains only one keypair.

    • The keypair uses the RSA algorithm.

  • KeyStore password: the password that protects the keyStore. If the keypair is also protected, then it must be using the same password.

    Note

    If you change the credentials, some automated tasks may be affected. In this case, restart the servers.

Regenerate Autogenerated Credentials

To regenerate the Autogenerated Credentials do the following actions:

  • If the Solution Manager is executing some Denodo Monitor, stop all the active Monitoring (this does not affect to Denodo Monitor executed outside the Solution Manager).

  • Stop all the Solution Manager servers.

  • Create a backup of the keystore renaming the <SOLUTION_MANAGER_HOME>/conf/denodo-sso/tokenJavaKeyStore.jks file. This file can be removed later.

  • Edit <SOLUTION_MANAGER_HOME>/conf/denodo-sso/SSOTokenConfiguration.properties file commenting all the properties starting from authorization.token.signing.

  • Restart all the Solution Manager servers.

Single Sign-On Sequence

At a high level, the initial authentication flow for a web application looks like this:

Denodo Security Token Single Sign-On sequence diagram to Solution Manager Web Tool

Denodo Security Token Single Sign-On sequence diagram to Solution Manager Web Tool

After that, the next access to another web application will not require the user to log in again with their credentials:

Denodo Security Token Single Sign-On sequence diagram to another web application

Denodo Security Token Single Sign-On sequence diagram to another web application

Add feedback