For registration, you can optionally allow users to leverage their existing identities from third-party identity providers. Any IdP connection or IdP adapter (such as the LinkedIn Cloud Identity Connector) can be used as an authentication source to a third-party identity provider. This optional capability enables a mapping configuration between the attributes returned by the identity provider and the fields within the registration page, thus streamlining the registration process. This configuration involves the same five components to set up registration, plus the IdP connections or IdP adapter instances to connect with the third-party identity providers.
- IdP connections or IdP adapter instances
- A PingDirectory installation (step 1)
- An authentication policy contract (step 2)
- A local identity profile (step 3)
- An HTML Form Adapter instance (step 4)
- An IdP authentication policy (step 5)
To illustrate the configuration steps, consider the following example:
You are tasked to support a consumer registration use case, where users can complete a self-service registration process to create their accounts and then access resources protected by multiple service providers. For a registration to complete successfully, a user must provide an email address, a first name, a last name, an optional mobile phone number, and a password. The email address is the user identifier. All attributes are sent to the service providers as per the partner agreements. You have already created a specific object class in the directory to store the user information. The object class name is aPerson, and the LDAP attributes are mail, givenName, sn, and mobile.
Additionally, this use case must also allow users to take advantage of their existing accounts at ACME (a major social network) for registration and authentication. It happens that you have already established an IdP connection to this social network, from which you received the same set of attributes: SAML_SUBJECT (for the user's email address), ssoFirstName, ssoLastName, and ssoMobile.
Configuration steps:
If you are familiar with the steps to set up PingDirectory to connect with PingFederate and an authentication policy contract (as documented in Setting up self-service registration), you may skip to step 3 to create a local identity profile.
You have now successfully set up self-service registration with an option for users to register and subsequently authenticate via ACME. When users sign on through this HTML Form Adapter instance, they have two registration options:
- Click the Register now link, fill in the registration page, and register.
- Click the social sign on link, authenticate via ACME, review the registration page, and register.
Based on the configuration of this sample use case, the following sign-on page is presented:
If you have added Facebook, Google, LinkedIn, and Twitter as the authentication sources, the following sign-on page is presented:
Suppose a user chooses to register through ACME. Once authenticated and redirected back to PingFederate, PingFederate pre-populates the registration page with values it receives from ACME, as illustrated in this screen capture:
This registration option streamlines the self-service registration process.