You can translate the document:

Introduction

In this document you will learn the following:

In PingFederate:

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

In the Denodo Solution Manager:

  • Enable single sign-on with OAuth or SAML or OpenID (you cannot enable all three options together).
  • Create a role with the same name as the group you have created in PingFederate.
  • Grant privileges to this new role.

Once this is completed, single sign-on will be enabled on the Solution Manager and users will only have to login with their required password.

An OAuth/OpenID access token or a SAML assertion usually includes 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.

Single Sign-On with OAuth

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

In PingFederate:

  • Configure to use 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

Configure to use PingFederate as an OAuth authorization server (AS)

The Denodo Knowledge Base article PingFederate Integration with Denodo explains in detail about configuration that are required to perform to use PingFederate as an OAuth authorization server (AS). You could configure the Data store, Password Validator,  Idp Adapter Mapping,  Access Token Management, Access Token Mapping, Scopes as mentioned in this knowledge Base article. We are going to use the same configuration that has been configured as part of the knowledge Base article PingFederate Integration with Denodo.

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 several different 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 a grant type as “Authorization code (authorization_code)” by providing the required information such as Client ID, Name, Client Authentication, etc as mentioned in the documentation.

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

For example, if your Solution Manager Web Tool is accessible by 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 as “Authorization code (authorization_code)”, so 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 detail on PingFederate.
  • Client secret: Client secret generated during the application registration process. It can be obtained from the Configured OAuth Client detail 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. Use openid.

  • Extract roles from token: The token will attach roles in a claim. If it is not selected, then the global LDAP section on authentication with LDAP, must be configured for retrieving the 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 the 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 the 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 mentioned in the documentation. In this example, we are going to choose the same access token management instance that we have configured for the 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, register the Solution Manager URL with the end point as /sso-openid/openid-login. For example, if your Solution Manager Web Tool is accessible by 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 /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 by 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: openid, email, profile, offline_access.

  • Extract roles from token: The token will attach roles in a claim. If it is not selected, then the global LDAP section on authentication with LDAP, must be configured for retrieving 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 the PingFederate

In Solution Manager:

  • Enabling Single Sign-On in Solution Manager with SAML

Configuring SP connection in the 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 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.xml” file, 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 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.

Sample SAML assertion

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.

  • Grant the role global_admin to the new role (IT) (see Authorization details). You can grant any other role, this is just an example.

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

  • 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

Questions

Ask a question

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