Denodo supports the protocol OAuth 2.0 for authentication and authorization of users. OAuth is an open-standard protocol that allows client applications to access Denodo without sending the password of the user account. Denodo supports OAuth in:
The JDBC interface and the ODBC interface of Virtual DataPort. That is, the client applications that connect to Virtual DataPort with the Denodo JDBC driver or the Denodo ODBC driver can use OAuth authentication.
REST and SOAP web services published from Virtual DataPort. You can configure these web services so client application have to use OAuth authentication.
The Denodo JDBC driver supports the OAuth 2.0 protocol for authentication and authorization of users. OAuth is an open-standard protocol that allows client applications to access Denodo without sending the password of the user account.
An application that sends requests to an OAuth 2.0 service (in this case, Virtual DataPort) have to include an access token in the request. This access token has to be obtained by the application from the authorization server. The standard OAuth 2.0 does not define a protocol for the resource server (in this case, the Denodo server) to validate access tokens and to obtain meta-information from them. Several approaches have been developed by the community to bridge this gap. Denodo supports two of them:
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. In this approach, the access tokens sent by applications contain a signature that must be validated in order to grant access to execute the request. After validating the token, it obtains the “scopes” defined in the token.
OAuth 2.0 Token Introspection. With this method, the resource server (in this case, the Denodo server) sends the access token sent by the client application to an introspection endpoint. This endpoint returns a JSON document indicating if the access token is valid and meta information about it, including the “scopes” of the token. The Denodo server sends a request to this data source every time a client sends a request to a Denodo web service that is configured to use OAuth 2.0 authentication.
In both approaches, the goal is the same:
To validate if the access token is valid and did not expire.
Obtain the names of the “scopes” contained in the token. The scopes of a token are, according to the standard, A list of space-delimited, case-sensitive strings. The strings are defined by the authorization server.
In the case of Denodo, the scopes are names of roles. Once Denodo has the scopes of the token, it obtains the roles with the same names and executes the request with the privileges granted to these roles.
Denodo ignores the scopes for which there is no role with the same name.
If there is not any role with the same name as any of the scopes of the token, the request fails.
Session attribute mapping: you can define a mapping between OAuth token 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 token 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 OAuth token, the value from the token is taken.
For example, if the OAuth token has an attribute department, you can create a mapping to a user_department attribute which will be added to the user session on Virtual DataPort. The user_department attribute is accessible to functions such GETVAR and to the Global Security Policies as session attribute audience.
If you configure the OAuth 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 OAuth authentication.
Connecting to REST and SOAP Web Service with OAuth Authentication¶
After enabling OAuth authentication in Virtual DataPort, you can configure REST and SOAP web services of Virtual DataPort to require OAuth authentication. In that case, the client applications that connect to these services need to:
Obtain an access token from the Identity Provider.
Provide this token in the HTTP header “Bearer” of the request:
GET /server/customer360/invoice Host: https://denodo-server.acme.com Authorization: Bearer ey1QiOiJsIiJZnl0aESUzI1NiIKVng1dCI6Ikci5HVEZ2ZELCJhJ0eXAiObGstV1Q...
Connecting with JDBC and ODBC with OAuth Authentication¶
After enabling OAuth authentication in Virtual DataPort, client applications can connect to Virtual DataPort using the Denodo JDBC driver or the Denodo ODBC driver, with OAuth authentication.
Denodo provides two paths to connect to Denodo using OAuth. Depending on the one you choose you have to configure the connection differently.
Path #1: The Client Application Provides an OAuth Token
The client application obtains an OAuth access token and passes it to the driver. Then, the driver uses this token to connect to Virtual DataPort, instead of using user/password.
This path is meant to be used by client applications that have the ability to obtain access tokens to connect to Virtual DataPort. This client application can obtain this access token for itself or on behalf of the end user of the application.
Path #2: The Driver Obtains an OAuth Token on Behalf of the User
If the client application does not have the ability of obtaining OAuth tokens, the driver can obtain one on behalf of the application, if the Identity Provider of your organization supports the Resource Owner Password Credentials OAuth flow.
In this case, you configure the connection with information about the Identity Provider. That is, the URL to request tokens to the Identity Provider, client id and client secret of the application you registered on the Identity Provider, etc.
If you are connecting with JDBC, you provide this information in the driver properties.
If you are connecting with ODBC, you provide this information in the DSN or if it is a DSN-less connection, in the connection properties.
In this case, when the client application wants to open a connection, the driver requests an OAuth token to the Identity Provider and uses the token to establish the connection.
Client applications that connect to Virtual DataPort using the ODBC driver of PostgreSQL will not be able to use OAuth authentication because this feature is part of the Denodo ODBC driver, not the PostgreSQL ODBC driver.
To connect with OAuth with the JDBC driver, read the page Connecting to Virtual DataPort Using OAuth Authentication (Developer Guide). It explains the parameters you have to define to use both paths.
To connect with the ODBC driver, read this:
Configuration of the ODBC Driver on Windows (Developer Guide): to create an ODBC DSN and your client application is on Windows.
Configuration of the ODBC Driver in Linux and Other UNIX (Developer Guide): to create an ODBC DSN and your client application is on Linux.
Creating a DSN-Less Connection (Developer Guide): to create a DSN-less connection.
When you enable OAuth authentication, you do not disable the other authentication mechanisms. That is, if you also enable Kerberos authentication, some client applications may choose to connect using user and password, others with OAuth and others with Kerberos.
Creating the Roles of the Virtual DataPort Users¶
Before any user can connect to Virtual DataPort using OAuth authentication, you have to do this:
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.
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.
In Virtual DataPort, create the role “denodo_administrator_production” and in the production servers, grant the role “serveradmin” to this role.
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.
After doing this, go to the next section to learn how to configure the Denodo server.