How To Configure PingFederate for SSO in the Denodo Solution Manager

You can translate the document:

Introduction

In this document you will learn the following:

In PingFederate:

  • Configuring  PingFederate as an OAuth authorization server (AS).
  • Configuring OpenID Connect policies in PingFederate.
  • Configuring  SAML 2.0 within PingFederate.
  • Register Denodo Solution Manager as an OAuth or  OpenID application or a SAML application.

In Denodo Solution Manager:

  • Enable single sign-on with OAuth or SAML or OpenID (you can only enable one of these options at a time).
  • Create a role  that matches the name of the group you have created in PingFederate.
  • Grant privileges to the newly created  role.

Once above steps are completed, single sign-on will be enabled on the Solution Manager and users will only have to login once with their required password, eliminating the need for multiple logins

An OAuth/OpenID access token or a SAML assertion usually includes information about the groups to which the associated user account belongs. When the Solution Manager receives the token/assertion, it searches its roles for those with  corresponding names. The privileges granted to these roles will be the privileges of this user. Note that not all the privileges defined in the token/assertion must exist in the Solution Manager.

Single Sign-On with OAuth

For OAuth authentication, we are going to do the following:

In PingFederate:

  • Configuring PingFederate as an OAuth authorization server (AS).
  • Configuring an OAuth client and register the Solution Manager as an OAuth application.

In Solution Manager:

  • Enabling Single Sign-On in Solution Manager with OAuth.

Configuring PingFederate as an OAuth authorization server (AS)

The Denodo Knowledge Base article PingFederate Integration with Denodo provides detailed instructions on  the necessary configurations to use PingFederate as an OAuth authorization server (AS). That is, including setting up the Data store, Password Validator,  Idp Adapter Mapping,  Access Token Management, Access Token Mapping, and Scopes. We will be implementing the same configurations outlined as part of the knowledge Base article.

Configuring an OAuth client and register the Solution Manager as an OAuth application

An OAuth client application interacts with an OAuth authorization server to obtain the required access tokens to call OAuth-protected services at the resource server. To configure the OAuth clients, go to Applications → OAuth → Clients. Click Add Client and complete the configuration in the Client window.

OAuth defines  various access grant types. Each grant type reflects different authorization mechanisms as mentioned in the Denodo Knowledge Base article PingFederate Integration with Denodo:

  • Authorization code (authorization_code)
  • Resource owner password credentials (password)
  • Implicit (implicit)
  • Client credentials (client_credentials)

In this example, we are going to configure a client with the grant type  “Authorization code (authorization_code)” by providing the required information such as Client ID, Name, Client Authentication, etc as outlined in the documentation: Configuring OAuth clients.

In the “Redirect URIs” configuration section, register the Solution Manager as an OAuth application.

For instance, if your Solution Manager Web Tool is accessible via https://server:port and the Default process URI for OAuth is /sso-oauth/oauth-login. Hence, you should register the following Redirect URI:

 https://server:port/sso/sso-oauth/oauth-login.

Also, as we are using the grant type “Authorization code (authorization_code)”, ensure  to select the checkbox “Authorization code” in the “Allowed Grant Types” and Click Save option.

Enabling Single Sign-On in Solution Manager with OAuth

Follow these steps:

Provide the following:

  • Client ID: Client identifier generated during the client application registration process. It can be obtained from the Configured OAuth Client details on PingFederate.
  • Client secret: Client secret generated during the application registration process. It can be obtained from the Configured OAuth Client details on PingFederate.

  • User authorization URI: to request their authentication and consent. Used to obtain the authorization code.

  • Access token URI: to exchange the authorization code for an access token.

  • Issuer: unique identifier of the authorization server that issues the tokens.

  • JWKS URL: URL to retrieve the public server JSON Web Key (JWK) used to verify the authenticity of access tokens.

  • Default process URI: Enter this:/sso-oauth/oauth-login

This is the relative URI for an application's callback endpoint. The Identity Provider sends an authorization response to these URIs. 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.

  • Scopes: Comma separated scope to send into the request to OAuth authorization server. Review the scopes allowed by your OAuth server. In this case, use readonly.

  • Extract roles from token: This option determines whether the token will attach roles in a claim. If not selected, the global LDAP section on Authentication with LDAP, must be configured  to retrieve user roles using a LDAP search.

  • Token role field: Name of the token claim used to extract roles. For example, groups.

Single Sign-On with OpenID

For OpenID authentication, we are going to do the following:

In PingFederate:

  • Configuring OpenID Connect policies in PingFederate.
  • Configuring an OpenID client and register the Solution Manager as an OpenID application.

In Solution Manager:

  • Enabling Single Sign-On in Solution Manager with OpenID.

Configuring OpenID Connect policies in PingFederate

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

To begin creating a new policy, navigate to Applications → OAuth → OpenID Connect Policy Management and create a new policy as outlined  in the documentation: Configuring policy and ID token settings. In this example, we are going to choose the same access token management instance that we have configured for OAuth in the  “Access Token Manager” list.

Configuring an OpenID client and register the Solution Manager as an OpenID application

We are going to configure the OAuth clients for OpenID. To create a client, go to Applications → OAuth → Clients. Click Add Client and complete the configuration in the Client window.

In the Redirect URI configuration section, register the Solution Manager URL with the end point as /sso-openid/openid-login. For example, if your Solution Manager Web Tool is accessible via https://server:port and the Default process URI is /sso-openid/openid-login, you should register the following Redirect URI:

https://server:port/sso/sso-openid/openid-login.

In the OpenID Connect section, Select the OpenID Connect policy which we have configured from the list  and Click Save option.

Enabling Single Sign-On in Solution Manager with OpenID

Follow these steps:

  • Log in to Solution Manager Web Tool with an administrator user:

https://solution-manager.acme.com:19443/solution-manager-web-tool/Login

  • Click the menu Configuration > Authentication.

  • Expand the panel Single Sign On Configuration, enable this feature and in the Authentication method, select OPENID.

Fill this section to configure a authentication against an external OpenID Provider:

  • Client ID: Client identifier generated during the client application registration process.

  • Client secret: Client secret generated during the application registration process.

            To obtain the information to fill this page you can extract it using default metadata.

      https://hostname:<server>/.well-known/openid-configuration

  • User authorization URI: To request their authentication and consent. Used to obtain the authorization code.

  • Access token URI: To exchange the authorization code for an access token.

  • Issuer: Unique identifier of the authorization server that issues the tokens.

  • JWKS URL: URL to retrieve the public server JSON Web Key (JWK) used to verify the authenticity of access tokens.

  • Default process URI: Relative URI for application’s callback endpoint. The Identity Provider sends an authorization response to these URIs. Default is: /sso-openid/openid-login

The complete URL must match the one registered on the Authorization Server (usually called Redirect URI). For example, if your Solution Manager Web Tool is accessible via https://server:port and the Default process URI is /sso-openid/openid-login, you should register the following Redirect URI:

 https://server:port/sso/sso-openid/openid-login.

  • Scopes: Comma separated scope to send into the request to the authorization server. For example: readonly, openid, email, profile, offline_access.

  • Extract roles from token: This option determines whether the token will attach roles in a claim. If not selected, the global LDAP section on Authentication with LDAP, must be configured to retrieve the user roles using a LDAP search.

  • Token role field: Name of the token claim used to extract roles.

Single Sign-On with SAML

For SAML authentication, we are going to do the following:

In PingFederate:

  • Configuring SP connection in PingFederate.

In Solution Manager:

  • Enabling Single Sign-On in Solution Manager with SAML.

Configuring SP connection in  PingFederate

As an identity provider (IdP), you manage connection settings to support the exchange of federation-protocol messages such as SAML, WS-Federation, or WS-Trust with a service provider (SP) or security token service (STS) client application at your site.

For SAML authentication, we are going to create a SP connection by navigating to: Applications → Integration → SP Connections and Click Create Connection.

PingFederate provides quick-configuration templates, available separately with SaaS Connectors, for specific Service Providers. For this example we are not going to use templates and hence we are continuing to the next screen for more options.

To configure a connection for secure browser-based SSO, select the Browser SSO Profiles check box and choose SAML 2.0 as a protocol from the drop-down list.

On the Connection Options tab, you can enable browser-based single sign-on (SSO), Attribute Query, or both for the current connection. We are going to select Browser SSO to create a connection for browser-based SSO.

When creating or modifying service provider (SP) connections, PingFederate allows you to import metadata from an XML file or a metadata URL.

We are going to import the metadata from an XML file. For this, we are going to use the “Download XML metadata file” option available in the SAML Configuration of the Solution Manager. Using this metadata you can add Solution Manager as a Service Provider on your IdP.

To download XML metadata file from Solution Manager, provide a unique value for SAML entity ID for example, https://<hostname>:19443/saml and Base URL as https://<hostname>:19443. Then, click on “Download XML metadata file” option which will download the “samlmetadata.xml” file. We are going to import this file into the “Import Metadata” tab of PingFederate.

As soon as we imported the samlmetadata.xmlfile, we could see the “General Info” updated with required information based on the information we provided in the Solution Manager.

Now the next step is to configure the “Browser SSO”. Browser-based single sign-on (SSO), also known as Browser SSO, relies on a user's web browser and HTTP requests to broker identity-federation messaging in XML or JSON web token (JWT) between an identity provider (IdP) and a service provider (SP). As we have chosen SAML 2.0 protocol, we need to provide required configuration as mentioned in the PingFederate Configure IdP Browser SSO  documentation.

Next is to configure the Protocol Settings. The Protocol Settings tab provides the launching point for configuring partner endpoints, message customizations, and other protocol-specific settings for browser-based single sign-on (SSO) connections.

In the Endpoint, ensure to provide the relative path (begin with a forward slash) as mentioned below:

 /sso/sso-saml/SSO

Once the user’s identity has been verified, the external identity provider (IdP) sends an authentication response that includes the assertion to the SAML endpoint at https://server:port/sso/sso-saml/SSO, over the HTTP POST Binding for SAML 2.0 standard.

Finally, the Credentials tab provides the launching point for configuring security requirements you might need, depending on the federation protocol you are using and the choices you make.

Note that if the Identity provider metadata URL is “https” and the SSL certificate of this service is not signed by a known Certificate Authority (CA) like Verisign, Comodo, etc., you have to add it to the TrustStore of the Server. The section Importing the Certificates of Data Sources (SSL/TLS Connections) of the Installation Guide explains how to do this. Otherwise, when the Server connects to this service, the connection will fail because the certificate is not trusted.

When you finish creating or modifying a service provider (SP) connection, you can review the connection settings and toggle the connection status. On the Activation & Summary tab, you can review, amend, discard, or save your changes.

Click on Save to save the SP connection and its configuration.

Enabling Single Sign-On in Solution Manager with SAML

Follow these steps:

  • Log in to Solution Manager Web Tool with an administrator user: https://<hostname>:19443/solution-manager-web-tool/Login
  • Click the menu Configuration > Authentication.
  • Expand the panel Single Sign On Configuration, enable this feature and in the Authentication method, select SAML.

Provide the following:

  • SAML entity ID: The entity ID uniquely identifies your Solution Manager installation to the IdP. It must match the Partner's Entity ID (Connection ID) configured on PingFederate. For example: https://<hostname>:19443/saml

  • Base URL: The base URL of the web container of the Solution Manager. It will be used as a base URL for Assertion Consumer Service in SAML requests to the IdP. For example:

      https://<hostname>:19443

  • SAML signing request: if it is enabled, the Solution Manager will sign authorization requests to the IdP.

  • Identity provider metadata URL: this is a URL of the configuration file that the IdP (PingFederate) provides for the application you registered.

    https://<hostname>:9031/pf/federation_metadata.ping?PartnerSpId=<entity_id>

  • Extract roles for SAML assertion: Enable this.

    By enabling this option, the Solution Manager will extract the roles of the users that are trying to log in, from the SAML assertion. If this option was disabled, you would have to configure the
    global LDAP settings of the Solution Manager so the Solution Manager can obtain the roles of the user.

  • Assertion role field: Fill with the attribute name created for retrieving user groups. For instance: groups.

Create Roles in Solution Manager

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 PingFederate.

As with LDAP authentication of Virtual DataPort, you do not need to create all the roles that a user of PingFederate may have; only create the ones you need to.

  • Log in to the Solution Manager with an administrator account.
  • Go to Configuration > Role management  and click New.

  • Create a role for the roles you have assigned. In this document: (IT) role.

  • Grant the role global_admin to the new role (IT) (for more details, refer to Authorization section in Solution Manager Administration guide). You can grant any other role, this is merely an example.

            At this moment, the single sign-on configuration should be ready.

  • Open a private window in your browser and navigate to https://<hostname>:19443/solution-manager-web-tool/Login. You will now see a  Single Sign-Onbutton displayed on the login page.

  • Click Single Sign On. Log in to PingFederate using the required user account who belongs to the created group in PingFederate.

References

Authenticating with Single Sign-On

Disclaimer

The information provided in the Denodo Knowledge Base is intended to assist our users in advanced uses of Denodo. Please note that the results from the application of processes and configurations detailed in these documents may vary depending on your specific environment. Use them at your own discretion.

For an official guide of supported features, please refer to the User Manuals. For questions on critical systems or complex environments we recommend you to contact your Denodo Customer Success Manager.
Recommendation

Questions

Ask a question

You must sign in to ask a question. If you do not have an account, you can register here