Web Services Authentication¶
You can protect the access to a REST or SOAP Web service by configuring its authentication method. The available authentication methods are the same for the REST and the SOAP Web services, but the SOAP ones also support the Web Services Security protocol (WS-Security).
In addition to select an authentication method for the service, consider enabling SSL/TLS on the Denodo web container to encrypt the data transferred by the web services. The section Enabling HTTPS in the Embedded Apache Tomcat of the Installation Guide explains how to do it.
Available in SOAP Web Services
Available in REST Web Services
Uses the Credentials of the Web Service
Uses the Credentials of the Web Service’s Clients
HTTP Basic with VDP
HTTP SPNEGO (Kerberos)
OAuth 2.0 and OpenID
WSS Basic with VDP
Regardless of the authentication method, REST web services support impersonation of users (see the section Impersonating a User below).
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 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 Internet Explorer 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.
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.
Before publishing a REST web service with SAML authentication, you have to set up the global SAML settings of the Server on the “Server configuration” dialog. The section SAML Authentication explains how to do it. Once you set up SAML globally, you can enable it on REST web services.
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 OAuth 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:
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.
The web service has to be deployed with a user account that has the role
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
LOGINhas to be a user with this role.
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 to provide the credentials of the user “denodo_svc_project_1” as usual. In addition, to impersonate another user, the application has to:
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.
And add the HTTP header
Impersonate-User. For example:
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 this request, it does this:
It opens a connection to Virtual DataPort with the user “denodo_svc_project_1” or it reuses one from the connection pool.
On this connection, it creates a session on behalf of the user “jsmith” and executes the query.
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 others 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”.
A user with the role “impersonator” should not publish a web service without authentication. Anyone that knew the existence of this web service could impersonate any user without knowing any credentials, just by adding this header and the user name to impersonate.
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.
To prevent granting this role accidentally to a user, this role can only be granted to users, not to roles. In addition, only administrators or users with the role “serveradmin” can grant this role to other users.
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 information only applies to REST web services, not SOAP web services nor the RESTful web service.