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.
|Authentication Method||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 LDAP (*)||X||X||X|
|HTTP Basic with VDP||X||X||X|
|HTTP SPNEGO (Kerberos)||X||X||X|
|WSS Basic with LDAP (*)||X||X|
|WSS Basic with VDP||X||X|
(*): The authentication methods marked with “*” are deprecated and may be removed in future releases of the Denodo Platform.
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 LDAP¶
HTTP Basic with LDAP is basic HTTP authentication using an LDAP server. To configure this authentication method, follow these instructions:
Select the LDAP data source representing the LDAP server used for authenticating users. See section LDAP Sources to learn how to create an LDAP data source.
Fill in the “User pattern” field. The “User pattern” is used to build the user’s Distinguished Name replacing the
@logintoken with the received user name.
For example, if the “User pattern” is
@logintoken will be replaced by the user name provided by the invoker of the Service.
Accepted user(s): only users whose user name is in this list will have access to the Service. To accept more than one user, separate their user names by commas.
If empty, every user authenticated by the LDAP Server will be granted access to the Service.
HTTP Basic with VDP¶
HTTP Basic with VDP is basic HTTP authentication using the credentials of the Virtual DataPort’s 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’s 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.
To use Kerberos authentication from the browser, you do not need to modify the Windows registry as you have to do when using single sign-on from the administration tool.
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 > SAML 2.0” to obtain its roles so it know what queries this user can execute.
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.