USER MANUALS

SAML Authentication

The REST web services published by Virtual DataPort support SAML authentication (Security Assertion Markup Language).

At runtime, when a client sends a request to a REST web service with SAML authentication, the Server use the SAML protocol to authenticate the user. Then, it uses the LDAP settings of this dialog to obtain its roles so it validates what queries this user can execute.

Before enabling SAML authentication on any REST web service, you have to set up LDAP settings in the same way you do it if you want to enable Kerberos authentication or enable LDAP authentication for a database.

If you have not done this for Kerberos authentication or for a database with LDAP authentication, you need to create an LDAP data source that points to Active Directory or the LDAP server used in your organization to authenticate users.

To do this, click the menu Administration > Server configuration > Server authentication. Then, click SAML.

Global configuration of SAML authentication

Global configuration of SAML authentication

In this wizard, provide the following details:

  • Identity provider metadata URL: URL of the Identity provider’s metadata. At runtime, the Server recovers the identity provider identifier and the signing certificate from this URL.

    Important

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

  • Service provider URL base: URL of the Denodo web container. E.g. https://acme:9443/ (9443 is the default port of the Denodo web container when you enable HTTPS, otherwise, it is 9090)

    If Denodo is running on a cluster behind a load balancer, enter the URL of the load balancer.

  • Role configuration: the user roles can be retrieved from Active Directory (or another LDAP server) or from an attribute of the SAML assertions sent by the client applications. For the first option, there are two possibilities, Global LDAP configuration or Custom LDAP configuration; for the second, SAML assertion.

    • Global LDAP configuration: use the LDAP configuration defined in the tab LDAP of Administration > Server configuration > Server authentication.

    • Custom LDAP configuration:

      • Database: select the database of Virtual DataPort where you have stored the LDAP data source.

      • LDAP data source: select the data source.

      • User base: node of the Active Directory that is used as scope to search nodes that represent users. You can enter more than one “User base” by clicking the button image0 beside the “User base” box. When there is more than one “User base”, the Server searches the user’s node in the first “User base” scope. If the Server does not find the node that represents the user, it searches it in the second “User base” scope. If it also fails, in the third, etc. If the Server does not find the node that represents the user, it denies access to the user.

      • Attribute with user name: name of the attribute that contains the user name of users, in the nodes that represent users.

      • User search pattern: pattern used to generate the LDAP queries that will be executed to obtain the nodes that represent the users that try to connect to the Server.

      • Role base: node of the LDAP server that is used as the scope to search the nodes that represent roles that users of this database can have. You can enter more than one “Role base” by clicking the button image0 beside the “Role base” box. The LDAP query formed with the “Role search” pattern will be executed in every “Role base” scope.

      • Attribute with role name: name of the attribute that contains the name of the role, in the nodes that represent roles.

      • Role search pattern: pattern used to generate the LDAP queries that will be executed to obtain the nodes that represent the roles of a user. This pattern has to contain the token @{USERDN} or @{USERLOGIN} (it cannot contain both):

        • @{USERDN} will be replaced with the Distinguished Name of the user that tries to connect to this database. For example, “CN=john,CN=Users,DC=acme,DC=loc”.

        • @{USERLOGIN} will be replaced with the login name of the user that tries to connect to this database. For example, “john”.

      • Select Assign ‘allusers’ role for every connected user to grant the privileges of the role “allusers” to all the users that log in successfully even if this role has not been assigned to the user in the LDAP server.

        For example, if you want all users to have read access over a particular database, select this option and grant this privilege to the role “allusers”.

        This option does not modify the roles granted to the user in the LDAP server. This means that if you later clear this check box, the users that log in will not have the privileges granted by the role “allusers”.

    • SAML assertion: with this option, the roles are extracted from the assertion, instead of obtaining them from Active Directory.

      • Assertion role field: field name in the SAML assertion that will contain the roles of the user sending the assertion.

    Configuration of SAML authentication using role extraction by assertion

    Configuration of SAML authentication using role extraction by assertion

    Sample SAML attribute statement with role information

    Sample SAML attribute statement with role information

    • Session attribute mapping: you can define a mapping between SAML attributes from the authenticated user and attributes which will be added to the user session. The name on Virtual DataPort is represented by Session Attribute column, and the name at the assertion is the one specified on Authentication Attribute.

      In case of retrieving roles from LDAP:

      • Global LDAP: the user session will contain also the attribute mappings defined at Enabling Global LDAP Authentication for the Virtual DataPort Server configuration.

      • Custom LDAP: Virtual DataPort will also search on the custom LDAP for the attributes used by the mappings defined in this section.

      • In both cases, when the same mapping comes from the LDAP and the attributes from the assertion, the value from the assertion is taken.

      For example, if the SAML tenantid is received on the attribute http://schemas.microsoft.com/identity/claims/tenantid, you can create a mapping to a saml_tenantid attribute which will be added to the user session on Virtual DataPort. The saml_tenantid attribute is accessible to functions such GETVAR and to the Global Security Policies as session attribute audience.

You do not need to restart to apply these changes.

If you configure the SAML authentication to obtain the roles of the users from the LDAP server (e.g. Active Directory), the feature LDAP roles cache affects the users that log in with SAML authentication.

Creating the Roles of the Virtual DataPort Users

Before any user can connect to Virtual DataPort using SAML authentication, you have to do this:

  1. Create roles in Virtual DataPort and grant them the appropriate privileges.

    Create a role for each type of user you want to have. For example: administrators of Denodo, administrators of project X, administrators of project Y, developers, etc. Then, grant the role “serveradmin” to the role for the administrators of Denodo, grant the privilege ADMIN over the database of the project X to the role for the administrators of this project, etc.

  2. In the Identity Provider of your organization, create groups with the same name as the roles you have created and add the users to the appropriate groups.

For example:

  1. In Virtual DataPort, create the role “denodo_administrator_production” and in the production servers, grant the role “serveradmin” to this role.

  2. In the Identity Provider, create the group “denodo_administrator_production” and add the appropriate users to this group.

To grant users the role “serveradmin”, “assignprivileges” or any of the default roles, you cannot create groups in the Identity Provider with these names and add users to these groups.

For example, if in the Identity Provider you create a group called “serveradmin” and add users to this group, when these users log in to Virtual DataPort, they will not have this role. That is because when a user logs in, Virtual DataPort ignores the groups assigned in the Identity Provider that have the same name as the “default roles”.

The goal of this behavior is to ensure that only the administrators of Denodo grant administrative privileges to users. Otherwise, the administrators of the Identity Provider could grant special privileges to users without going through the approval of the administrators of Denodo.

Validation of the Response Signature

By default, the REST web services of Virtual DataPort do not require SAML assertions to be signed. If an assertion is signed, the service will validate its signature but it is not mandatory that they are signed.

If you want REST services to only accept SAML assertions that are signed, follow these steps:

  1. From the VQL Shell, execute this command:

    SET 'com.denodo.vdb.security.SAMLAuthenticator.requireResponseSigned' = 'true';

  2. Restart the Virtual DataPort server to apply the change. You do not need to redeploy the web services.

Add feedback