PingFederate - Integrations - Idura Verify Documentation
  1. Integrations
  2. PingFederate

This tutorial demonstrates how to integrate Idura Verify with PingFederate. The following steps are required to complete your first login:

  1. Create an application in Idura Verify that represents your PingFederate tenant
  2. Create an authentication source in your PingFederate tenant which connects to the Idura Verify application
  3. Complete the application configuration in Idura Verify
  4. Integrate your own application with PingFederate

In the following you will be configuring first Idura Verify, then PingFederate, and then back to finalizing the configuration in Idura Verify.

The final step in this excercise is needed because of a catch-22 between the requirements of the configuration steps on the two platforms, respectively:

  • Creating an application in Idura Verify requires you to specify a callback URL to PingFederate before you can save the application configuration and get your hands on the generated client secret.
  • Getting the callback URL to PingFederate requires that you create an authentication source, which in turn requires the client secret from Idura Verify, but you don't have the secret yet because you need the callback URL [deadlock detected]

which is a bit of a chicken-and-egg-problem, unfortunately. We suggest that you break the deadlock by configuring a temporary (bogus) callback URL in the first step in Idura Verify, and then replace it with the actual value available after the authentication source is created.

As the setup requires some switching back-and-forth between Idura and PingFederate's respective management dashboards, we recommend that you have them open simultaneously to make the process fairly smooth.

Once configured you may test that everything works from PingFederate's OAuth Playground.

Create Idura Verify application

First, you must register your PingFederate tenant as an application in Idura Verify.

Once you register your PingFederate tenant, you will also need some of the information for configuring PingFederate to communicate with Idura Verify. You get these details from the settings of the application in the dashboard.

Specifically you need the following information to integrate with PingFederate:

  • Client ID to identify your PingFederate tenant to Idura Verify. We'll use urn:idura:samples:pingfederate for this example.
  • Client secret which PingFederate needs to fetch actual user information from Idura Verify during login. The secret is generated when you configure the OAuth2 code flow for your application.
  • Domain on which you will be communicating with Idura Verify. We'll use acme-corp.idura.broker.
Create App

Configure the OAuth2 code flow

If you are registering a new application, please save the initial configuration first.

After saving, you can configure the OAuth2 Code Flow for this application by following the three steps:

  1. Go to the OpenID Connect section of your Application settings and Enable OAuth2 Code Flow. OAuth2 client secret
  2. Copy the generated client secret. Note that this is the only time you will be shown the actual value of the client secret. Idura only stores this as a hashed value, which means you cannot retrieve the value once it has been generated and stored. OAuth2 client secret
  3. Set the user info response strategy to plainJson to enable retrieval of plain JSON user information from the /oauth2/userinfo endpoint. OAuth2 code flow Note that some libraries do not support the final userinfo request. In those cases, you will need to fetch the user data directly from the token endpoint as opposed to the userinfo endpoint. You can do this by choosing fromTokenEndpoint as a User info response strategy. User info response strategy

Idura Verify supports four modes for retrieving user information:

  • Plain JSON object (plainJson): User information is returned from the userinfo endpoint as a standard JSON object.
  • Signed JWT (signedJwt): User information is returned from the userinfo endpoint as a digitally signed JSON Web Token.
  • Signed and encrypted JWT (signedAndEncryptedJwt): User information is returned from the userinfo endpoint as a signed and encrypted JSON Web Encryption(JWE) object.
  • Directly from the token endpoint, embedded in the id_token (fromTokenEndpoint). The fromTokenEndpoint flow is not standard, but can be useful if you are working with a product that does not call the userinfo endpoint.

Create PingFederate authentication source

On the dashboard of your PingFederate tenant, go to the Authentication tab and click on the IdP Connections tile

IdP Connections

Click the Create Connection button and choose BROWSER SSO PROFILES in Connection Type and then OpenID Connect in the PROTOCOL dropdown

Create Connection

Click the Next button, choose BROWSER SSO in Connection Options

Connection Options

Click the Next button, enter your specific Domain authority in the ISSUER field and click the Load Metadata button

Give the connection a recognizable name, copy-paste the Client ID and Client secret values from your Idura Verify application

General Info

Click the Next button and then click the Configure Browser SSO button

Browser SSO

Choose NO MAPPING for the Identity Mapping

Identity Mapping

Click the Next button and add the claim types that you want to consume in the Attribute Contract

Attribute Contract

You can find the available claim types here.

Click the Save button. You'll need to add the Redirect URI shown at this step to your Idura Verify application configuration.

Callback URL

Complete the application configuration in Idura Verify

Back on the Idura Dashboard, go to your PingFederate application settings and add the Redirect URI from PingFederate to the list of Redirect URLs.

If you plan on using single-signon, you must also register your PingFederate post_logout_redirect_url here so you can run single-logouts.

Integrate your own application with PingFederate

How to integrate your application with PingFederate depends on the technology you are working with. Refer to the PingFederate developer documentation for more details.

If you want to use pass-through of login_hint values sent from your own application to Idura Verify via PingFederate, you must enable it via a Policy in your IDP AUTHENTICATION POLICIES.

If you haven't already done so, create a Policy Contract with the attributes you wish to consume

Policy Contract
  • available claim types can be found here

Then create a Policy for your IdP Connection to Idura Verify and set the Options for Incoming User ID to be sourced from Context and use the Requested User value.

Policy

You can read more about which per-authorize-request parameters you can use to control the runtime behavior of Idura Verify here (prefilled fields) and here (acr_values).

Leveraging these features makes you authentication source setup in PingFederate as simple as possible - you just need to register Idura Verify once, and reuse it for all the eID methods you need to consume.