HTTP Basic¶

HTTP Basic is basic HTTP authentication [HTTP-AUTH] with the credentials passed as plain text.

All the users will use the values of the fields “Login” and “Password” as credentials for accessing this service.

HTTP Basic with VDP¶

HTTP Basic with VDP is basic HTTP authentication using the credentials of the Virtual DataPort users. That is, the Web service will connect to Virtual DataPort with the credentials used by the client of the Web service.

Only users whose user name is in the “Accepted user(s)” list will have access to the Service (separate user names with commas). If this list is empty, the Web Service will accept all Virtual DataPort users.

Unlike with the other authentication methods, with this one, you have to grant the user privileges to access the published views.

HTTP Digest¶

HTTP Digest access authentication. HTTP Authentication Basic and Digest Access Authentication.

HTTP SPNEGO (Kerberos)¶

In order for the Kerberos-SPNEGO authentication to work, the clients that send requests to the service have to be logged in the same domain as the Virtual DataPort server.

This authentication method can only be used when the Kerberos authentication is enabled on the Virtual DataPort Server. The section Kerberos Authentication explains how to enable this.

The section “Client Configuration” of this article explains how to configure Chrome and Mozilla Firefox to use the Kerberos-SPNEGO authentication. No special configuration is needed for Google Chrome.

When you connect from a browser to a service with this authentication, instead of having to enter your credentials, the browser will obtain a Kerberos ticket from the system and send it with the request. If the browser requests your credentials, it means that the browser is not correctly configured to use Kerberos authentication or that there was an authentication error.

OAuth 2.0 and OpenID¶

To use these authentication methods on a web service, first you need to enable OAuth authentication on the Virtual DataPort server. The section OAuth Authentication explains how to do this. Once you set up OAuth 2.0 globally, you can enable it on REST web services.

OpenID is an extension of OAuth 2.0. Denodo supports OpenID when it is configured to accept a JSON Web Tokens (JWT). That is, in the OAuth 2.0 configuration of the Server, the option Use JWT is selected.

In REST web services with OAuth authentication, do not publish views whose data comes from data sources with pass-through authentication. The requests to these views will fail. That is because, when an application sends a request with OAuth authentication, it does not send a user/password. Instead, it sends an OAuth access token, from which is not possible to obtain a user and password to pass to the data source.

SAML 2.0¶

The REST web services published by Virtual DataPort support SAML 2.0 authentication (Security Assertion Markup Language); specifically, the “Web Browser SSO Profile” identity provider initiated with “HTTP POST Binding”.

The client applications need to obtain a new assertion for each request because the Denodo web services are stateless so they do not support sessions.

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 the dialog “Server configuration > Server authentication > SAML” to obtain the roles of the user. These roles determine if the user is allowed to perform the query.

When selecting the authentication method SAML 2.0, enter a value for Service provider ID. This is a string that identifies this web service as a service provider with the identity provider (IdP).

The section Invoking Web Services with SAML Authentication explains how to invoke a web service with SAML authentication from a browser and programmatically, from a client application.

In REST web services with SAML authentication, do not publish views whose data comes from data sources with pass-through authentication. The requests to these views will fail. That is because, when an application sends a request with SAML authentication, it does not send a user/password. Instead, it sends a SAML assertion, from which is not possible to obtain a user and password to pass to the data source.

Impersonating a User¶

The REST web services support impersonation of users regardless of the authentication method selected. That is, a client application can connect to a REST web service with its regular credentials and perform requests on behalf of another user.

To impersonate a user, the following conditions have to be fulfilled:

1. The requests to the web service have to include the HTTP header Impersonate-User. The value of this header is the user account to impersonate.

2. The web service has to be deployed with a user account that has the role impersonator.

   If you deploy the web service from the administration tool, you need to have this role, or in the dialog Deploy Web Service (the dialog displayed when you click Deploy), select a user that has this role.

   If you deploy the web service programmatically (i.e. with the statement DEPLOY WEBSERVICE), the value of the parameter LOGIN has to be a user with this role.

Example

Let us say that:

• You create a service account in Virtual DataPort called “denodo_svc_project_1”, which has the role “impersonator”.

• You create a REST web service with “HTTP Basic with VDP” authentication.

• In the dialog to deploy the service, you select the account “denodo_svc_project_1” and enter its password.

The client applications that connect to this web service have do this:

1. Provide the credentials of the user “denodo_svc_project_1”. The service validates the credentials the same way regardless of whether the request is impersonating another user or not.

2. Optionally, if the client application wants to impersonate another user, it has to add the HTTP header Impersonate-User: <user to impersonate> to the request. For example:

   Impersonate-User: jsmith
   

   If the request does not have this header, the service will behave as usual so the requests will be executed with the privileges granted to “denodo_svc_project_1”.

When the service receives a request with this header, it does this:

1. It opens a connection to Virtual DataPort with the user “denodo_svc_project_1” or it reuses one from the connection pool of the web service.

2. On this connection, it creates a session on behalf of the user “jsmith” and executes the query.

3. It closes the session (the connection remains opened).

The implications of impersonating a user are:

• The user “denodo_svc_project_1” needs to have the privilege CONNECT over the database to which the web service belongs, but it does not need other privileges.

• The user “jsmith” needs the adequate privileges to execute this request. That is, the execution engine will apply the privileges, row restrictions, etc. that are granted to the user “jsmith”.

• In the Denodo Monitoring Tool and other monitoring data, there will be a connection opened by the user “denodo_svc_project_1” and the queries are executed by the user “jsmith”.

Notes

• When impersonating a user from a REST web service, the queries to data sources with pass-through session credentials will fail because neither the web service nor the execution engine knows the password of the user.

• With the default configuration, REST web services create a pool of connections to Virtual DataPort to avoid having to open a connection for each request. When impersonating a user, this pool is still in use because the service creates the sessions over existing connections.

• This feature of impersonating users is available in REST web services, not in SOAP web services nor the RESTful web service.