Applies to:
Denodo 8.0
Last modified on: 08 Feb 2022
Tags:
Administration
OAuth
Okta
SAML
Solution Manager
In this document you will learn how to:
This document explains how to register the Solution Manager as a SAML application and as an OAuth application. In a real scenario, you will only do one or the other (currently, OAuth seems to be more popular than SAML).
This information is also applicable to Virtual DataPort, to enable OAuth authentication in the REST web services you publish.
Some organizations are transitioning from Windows Active Directory and Kerberos to “cloud-friendly” Identity Providers (IdP). These IdPs usually provide support for authentication protocols OAuth and SAML, which are more suited for applications that run on the cloud, than Kerberos. Okta is a very popular IdP.
This is what this document describes:
Once this is completed, single sign-on will be enabled on the Solution Manager and users will only have to provide their password in Okta.
An OAuth access token and a SAML assertion usually include the groups to which this user account belongs; that is, the user account associated with this token/assertion. When the Solution Manager receives the token/assertion, it searches the roles defined in Solution Manager that have the same name. The privileges granted to these roles will be the privileges of this user. Note that not all the privileges defined in the token/assertion have to exist in the Solution Manager.
Create an Okta developer account https://developer.okta.com/. If you already have your own, you can use it as well.
Groups are used for authorization on third-party applications. There are different types of groups in Okta:
See the official documentation for more information.
In this document, we are going to create a Native group because it is the more basic configuration. In a “real-world” scenario, customers may have different types of groups defined, which they may have imported from Active Directory.
To create a native group, log in to your Okta Admin Console and click on Directory > Groups > Add Group.
For example, create the group ‘developer’.
To assign a group to a user, do the following:
In this section, we are going to use the Classic UI because it is easier to do this.
Enter the following:
https://solution-manager.acme.com:19443/sso/sso-saml/SSO
https://solution-manager.acme.com:19443/saml
Add attribute statements to expose user profile values on the SAML assertion.
Special attribute statements to expose the user groups. The groups may be filtered, use .* as regex to retrieve all the groups assigned to the logged user.
After registering the SAML app, go to the Assignments tab.
Go to the Assign > Assign to People menu.
Assign the test user.
Click on Save and Go Back.
Follow these steps:
https://solution-manager.acme.com:19443/saml
https://solution-manager.acme.com:19443
.
<Attribute Name="groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Everyone</AttributeValue> <AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">developer</AttributeValue> </Attribute> |
Sample SAML assertion
Once the application was created you can view important information like client credentials:
An OAuth token contains claims. A claim is information about the subject (the user), such as name, role, or email address. Beyond the default set of claims that are contained in ID tokens and access tokens, you can define your own custom claims and the Groups claim. To configure the Groups claims do the following steps:
Under Security > API > Authorization Servers we can navigate to the default Authorization server.
Click on default and go to the Claims tab.
Click the Add Claim button.
In this form, enter the following:
Under Security > API > Authorization Servers, navigate to the default Authorization server and review the metadata uri with important information for configuring our clients.
Click default
Metadata URI with information about OAuth Authorization Server: https://dev-{ACCOUNT_NUMBER}.okta.com/oauth2/default/.well-known/oauth-authorization-server
Click on this URL to see the JSON metadata of the service. It contains the issuer, authorization_endpoint, token_endpoint, jwks_uri, scopes_supported, etc. You will need this information to configure the OAuth authentication in the Solution Manager.
Follow these steps:
https://dev-{ACCOUNT_NUMBER}.okta.com/oauth2/default/.well-known/oauth-authorization-server
The complete URL must match the one registered on the OAuth Authorization Server (usually called Redirect URI). For example, if your Solution Manager Web Tool is accessible by https://server:port and the Default process URI is /sso-oauth/oauth-login, you should register the following Redirect URI https://server:port/sso/sso-oauth/oauth-login.
After enabling SAML or OAuth authentication in Solution Manager, you have to create roles that have the same names as the ones you created in Okta.
As with LDAP authentication of Virtual DataPort, you do not need to create all the roles that a user of Okta may have; only create the ones you need to.
At this moment, the single sign-on configuration should be ready.
Solution Manager Administration Guide: Authenticating with Single Sign-On
Denodo 8.0 Automated Cloud Mode for AWS Quick Start Guide - section Enable Single Sign-On.