Setting up self-service registration
PingFederate leverages the HTML Form Adapter to deliver include::partial$pf_rc_consumerregistrationauthenticationprofilemanagement.adoc[tags=pf_ph_consumerRegistrationAuthenticationProfileManagement].
About this task
A typical self-service registration setup involves five components:
To illustrate the configuration steps, consider the following example.
You need to support a consumer registration use case, where users 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
.
Steps
-
Install PingDirectory.
-
Create an authentication policy contract.
-
Go to Authentication → Policies → Policy Contracts.
-
In the Policy Contracts window, click Create New Contract.
-
On the Contract Attributes tab, in the Extend the Contract field, extend the authentication policy contract with three additional attributes, such as,
firstName
,lastName
, andmobileNumber
. -
After each entry add, click Add. Click Next.
-
On the Summary tab, review your changes. Click Save.
For more information, see Managing policy contracts.
-
-
Create a local identity profile using the Authentication → Policies → Local Identity Profiles configuration wizard.
-
In the Local Identity Profiles window, click Create New Profile.
-
On the Profile Info tab, enter a name in the Local Identity Profile Name field.
-
From the Authentication Policy Contract list, select the authentication policy (from step 2), and select the Enable Registration check box. Click Next.
-
On the Authentication Sources tab, click Next.
-
On the Fields tab, click Create New Field.
-
In the Field Configuration window, on the Field Configuration tab, define four local identity fields. Enter the information described in the following table.
Local Identity Profile fields and entries Type ID Label Parameters Email
lipEmail
Email address
Select the Required check box.
Text
lipFirstName
First name
Select the Required check box.
Text
lipLastName
Last name
Select the Required check box.
Phone
lipMobile
Mobile number
No parameters are required.
-
After each field entry, click Next. On the Summary tab, review your changes. Click Done.
-
Repeat steps e through g until the fields are entered.
As needed, select the Mask Log Values check box for any of the four local identity fields and the Mask all OGNL-expression generated log values check box. The latter applies to all local identity fields.
-
In the Local Identity Profile window, on the Fields tab, identify an ID field to be the unique ID for your configuration, and click the corresponding Unique ID. Click Next.
-
On the Email Verification tab, click Next.
-
On the Registration tab, click Next.
-
On the Data Store Configuration tab, click Configure Data Store.
-
In the Data Store Configuration window, on the Data Store tab, from the Data Store list, select the LDAP datastore that has been set up to connect to your PingDirectory. Click Next.
-
In the Data Store Configuration window, on the LDAP Configuration tab, specify the branch of your directory hierarchy where you want PingFederate to store customer identities in the Base DN field and the LDAP attributes to be associated with fields defined in this local identity profile under Attribute.
-
In the Data Store Configuration window, on the Identity Creation tab, define the RDN pattern in the Relative DN Pattern field, and select your object, such as class
aPerson
for this sample use case, from the Object Class list.The pattern is as follows.
attribute1=value1[, …, attributeN=valueN]
If you want to use the
${entryUUID}
variable variable to guarantee the uniqueness of the relative DNs for all users, you must use it with the{entryUUID}
LDAP attribute.entryUUID=${entryUUID}
-
In the Data Store Configuration window, on the Data Store Mapping tab, configure the mapping between the local identity profile fields and the datastore attributes. See the following table.
Mapping entries for local identity profile fields and datastore attributes Field Data Store Attribute lipEmail
mail
lipFirstName
givenName
lipLastName
sn
lipMobile
mobile
-
In the Data Store Configuration window, on the Summary tab, click Done.
-
On the Summary tab of the local identity profile, click Save.
For more information, see Configuring local identity profiles.
-
-
Configure an HTML Form Adapter instance for customer identities.
-
Go to the Authentication → Integration → IdP Adapters.
-
Create a new HTML Form Adapter instance or reuse an existing one by clicking its name.
-
On the IdP Adapter tab, in the Password Credential Validator Instance section add the LDAP Username Password Credential Validator instance that has been set up to validate credentials stored on your PingDirectory.
-
On the IdP Adapter tab, select the newly created local identity profile in the Local Identity Profile list.
-
Complete the rest of the configuration and save all changes.
(For more information, see Configuring the HTML Form Adapter for customer identities.)
-
-
Create an IdP authentication policy.
-
Go to Authentication → Policies → Policies.
-
Click Add Policy.
-
In the Policy window, in the Name field, enter a name.
-
Select the HTML Form Adapter instance (configured in step 4) under Policy.
-
For its Fail path, select Done.
-
For its Success path, select the local identity profile (created in step 3).
-
-
Click Local Identity Mapping underneath the selected local identity profile, which opens the Inbound Mapping & Contract Fulfillment configuration wizard.
-
On the Inbound Mapping & Contract Fulfillment Inbound Mapping window, configure the
pf.local.identity.unique.id
built-in local identity field for the registration process.At runtime, PingFederate fulfills the value of the
pf.local.identity.unique.id
built-in local identity field based on this configuration and passes the value to PingDirectory.PingDirectory uses this value to determine whether such identity has already been created. The
pf.local.identity.unique.id
field value should therefore be mapped from the subject identifier of the preceding authentication source, namely theusername
attribute from the HTML Form Adapter.For this sample use case, configure the Inbound Mapping window as shown in the following table.
Inbound Mapping Fulfillment Source Value pf.local.identity.unique.id
Adapter
username
-
On the Attribute Sources & User Lookup tab, click Next.
-
On the Contract Fulfillment tab, fulfill the authentication policy contract with values from this local identity profile as follows:
Outbound Contract Fulfillment Source Value subject
Local Identity
lipEmail
firstName
Local Identity
lipFirstName
lastName
Local Identity
lipLastName
mobileNumber
Local Identity
lipMobile
-
On the Issuance Criteria tab, click Next.
-
On the Summary tab, click Done.
-
On the Policy window, click Done.
-
On the Policies window, select the IdP Authentication Policies check box.
Other IdP authentication policies, if any, are enabled as well.
-
Click Save to keep your changes.
For more information, see Applying policy contracts or identity profiles to authentication policies.
-
-
Map the authentication policy contract to the applicable Browser SSO connections, OAuth grant-mapping configuration, or both. See Managing authentication source mappings and Managing authentication policy contract grant mapping.
Result
You have now successfully set up self-service registration. When users sign on through this HTML Form Adapter instance, they have the option to complete a self-service registration process to create their accounts using the Register now link, as illustrated in the following screen capture.
If a user chooses to register, the HTML Form Adapter redirects the user to the registration page. Based on the configuration of this sample use case, as illustrated in the following registration screen capture.