Applies to:
Denodo 8.0
,
Denodo 7.0
Last modified on: 09 Jun 2020
Tags:
Administration
OAuth
Security
Web Services
This document describes how OAuth 2.0 works when using it in the Denodo Platform and how it has been implemented for Single sign-on, web services published through Virtual DataPort and for connecting to data sources.
OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2.0 provides authorization flows for web, desktop applications, and mobile devices.
The main benefit of using OAuth 2.0 is that the user doesn’t need to share username and password with any application.
Denodo Security Token Server is a centralized system that delegates the authentication to an external Identity Provider. It takes the authorization object and generates a valid credential so the other applications can use it to gain access across Denodo.
From Denodo 8.0 OAuth 2.0 can be used to delegate the authentication into multiple web applications (such as the Design Studio or the Solution Manager Web Tool) while logging in once and without having to have a separate identity and password for each.
This scenario works as follows:
The standard OAuth 2.0 does not define a protocol for the resource server to validate Access Tokens and to obtain meta-information from them. Two different approaches to validate Access Tokens are available in Virtual DataPort.
In both approaches there is the same goal:
JSON Web Token (JWT) is a JSON-based security token encoding that enables identity and security information to be shared across security domains. In this approach, the JWT sent by client/applications contains 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.
A JWT is cryptographically signed, so there is a guarantee we can trust it when we receive it, as no middleman can intercept and modify it, or the data it holds, without invalidating it.
The resource 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.
When creating a data source of type XML, JSON or Delimited Text File (DF), you have to specify a path to the data files. OAuth 2.0 is available when selecting HTTP path type in order to retrieve the information through an HTTP request.
The authentication process is the same as the Northbound authentication, but in this case, the Virtual DataPort Server acts as a client who wants to access a protected resource. On the other hand, the Resource Server is the Data Source that contains the information that our client wants to retrieve.
In this case, the Resource Server is the one who needs to validate the provided Token.
The OAuth 2.0 Authorization Framework
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants