--- title: Setting up self-service registration description: PingFederate leverages the HTML Form Adapter to deliver a secure and easy-to-use customer authentication, registration, and profile management solution. component: pingfederate version: 13.1 page_id: pingfederate:administrators_reference_guide:pf_setting_up_self_service_registra canonical_url: https://docs.pingidentity.com/pingfederate/13.1/administrators_reference_guide/pf_setting_up_self_service_registra.html llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md revdate: August 25, 2023 section_ids: about-this-task: About this task steps: Steps result: Result --- # Setting up self-service registration PingFederate leverages the HTML Form Adapter to deliver a secure and easy-to-use customer authentication, registration, and profile management solution. ## About this task A typical self-service registration setup involves five components: * A PingDirectory installation ([step 1](#step_syj_cyw_vcb)) * An authentication policy contract ([step 2](#step_syj_cyw_vcb2)) * A local identity profile ([step 3](#step_bl1_2yw_vcb3)) * An HTML Form Adapter instance ([step 4](#step_rql_2yw_vcb)) * An IdP authentication policy ([step 5](#step_d5f_sbx_vcb5)) For this consumer registration use case, users complete a self-service registration process to create their accounts, then access resources protected by multiple service providers. During registration, a user provides an email address, first and last name, password, and, optionally, a mobile phone number. The email address is the user identifier. All attributes are sent to the service providers, which the partner agreements specify. 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 1. []()Install PingDirectory. Refer to [Installing the PingDirectory Suite of Products](https://docs.pingidentity.com/pingdirectory/latest/installing_the_pingdirectory_suite_of_products/pd_suite_install_guide.html) in the PingDirectory documentation. 2. []()Create an authentication policy contract. 1. Go to **Authentication > Policies > Policy Contracts**. 2. On the **Policy Contracts** page, click **Create New Contract**. 3. On the **Contract Info** tab, enter a name for the authentication policy. Click **Next**. 4. On the **Contract Attributes** tab, extend the authentication policy contract by entering the `firstName`, `lastName`, `mobileNumber`, and `SAML_SUBJECT` (email address) attributes in the **Extend the Contract** field. (Optional) You can add other attributes. 5. After each entry, click **Add**. When you are finished, click **Next**. 6. On the **Summary** tab, review your changes. 7. Click **Save**. Learn more in [Managing policy contracts](pf_managing_policy_contracts.html). 3. []()Create a local identity profile using the **Authentication > Policies > Local Identity Profiles** configuration wizard. 1. On the **Local Identity Profiles** page, click **Create New Profile**. 2. On the **Profile Info** tab, enter a name in the **Local Identity Profile Name** field. 3. In the **Authentication Policy Contract** list, select the authentication policy (from [step 2](#step_syj_cyw_vcb2)). Select the **Enable Registration** checkbox. Click **Next**. 4. On the **Authentication Sources** tab, click **Next**. 5. On the **Fields** tab, click **Create New Field**. 6. In the **Field Configuration** page, 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** checkbox. | | Text | lipFirstName | First name | Select the **Required** checkbox. | | Text | lipLastName | Last name | Select the **Required** checkbox. | | Phone | lipMobile | Mobile number | No parameters are required. | ![Screen capture of the local identity profile field configuration page. There are fields for ID, Label, and Type. There are also Read-Only, which is selected, Required, and Mask Log Values checkboxes in the Parameters section.](_images/ohr1640030865082.png) 7. After each field entry, click **Next**. On the **Summary** tab, review your changes. Click **Done**. 8. Repeat steps 3e - 3g until the fields are entered. As needed, select the **Mask Log Values** checkbox for any of the four local identity fields and **Mask all OGNL-expression generated log values** checkbox. The latter applies to all local identity fields. 9. On the **Fields** tab of the **Local Identity Profile** page, specify an ID field as the unique ID for your configuration and click the corresponding **Unique ID**. Click **Next**. 10. On the **Email Verification** tab, click **Next**. 11. On the **Registration** tab, click **Next**. 12. On the **Data Store Configuration** tab, click **Configure Data Store**. 13. On the **Data Store** tab of the **Data Store Configuration** page, select the LDAP datastore that been set up to connect to your PingDirectory in the **Data Store** list. Click **Next**. 14. 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**. 15. On the **Identity Creation** tab, define the RDN pattern in the **Relative DN Pattern** field and select your object, such as class 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}` 1. On the **Data Store Mapping** tab, configure the mapping between the local identity profile fields and datastore attributes. Refer to 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 | 2. On the **Summary** tab, click **Done**. Learn more in [Configuring local identity profiles](pf_configuring_local_identity_profiles.html). 4. []()Configure an HTML Form Adapter instance for customer identities. 1. Go to **Authentication > Integration > IdP Adapters**. 2. Create a new HTML Form Adapter instance or reuse an existing one by clicking its name. 3. 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. 4. On the **IdP Adapter** tab, select the newly created local identity profile in the **Local Identity Profile** list. 5. Complete the rest of the configuration and save all changes. Learn more in [Configuring the HTML Form Adapter for customer identities](pf_config_html_form_adapt_customer_identit.html). 5. []()Create an IdP authentication policy. 1. Go to **Authentication > Policies > Policies**. 2. Click **Add Policy**. 3. On the **Policy** page, enter a name in the **Name** field. 4. Select the HTML Form Adapter instance (configured in [step 4](#step_rql_2yw_vcb)) under **Policy**. 1. For its **Fail** path, select **Done**. 2. For its **Success** path, select the local identity profile (created in [step 3](#step_bl1_2yw_vcb3)). 5. Click **Local Identity Mapping** underneath the selected local identity profile, which opens the **Inbound Mapping & Contract Fulfillment** configuration wizard. 6. On the **Inbound Mapping & Contract Fulfillment** **Inbound Mapping** page, 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 the `username` attribute from the HTML Form Adapter. For this use case, configure the **Inbound Mapping** page as shown in the following table. | Inbound Mapping Fulfillment | Source | Value | | --------------------------- | ------- | -------- | | pf.local.identity.unique.id | Adapter | username | 7. On the **Attribute Sources & User Lookup** tab, click **Next**. 6. 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 | 1. On the **Issuance Criteria** tab, click **Next**. 2. On the **Summary** tab, click **Done**. 3. On the **Policy** page, click **Done**. 4. Select the **IdP Authentication Policies** checkbox. | | | | - | --------------------------------------------------------------- | | | Other IdP authentication policies, if any, are enabled as well. | 5. Click **Save** to retain your changes. Learn more in [Applying policy contracts or identity profiles to authentication policies](pf_apply_policy_contract_or_ident_profile_to_auth_policies.html). 7. Map the authentication policy contract to the applicable Browser SSO connections, OAuth grant-mapping configuration, or both. Refer to [Managing authentication source mappings](help_assertioncreationtasklet_idpadaptermappingstate.html) and [Managing authentication policy contract grant mapping](help_oauthsource2targetmappingtasklet_oauthapc2targetmappingsstate.html). ## Result You have now successfully set up self-service registration. When users sign on through this HTML Form Adapter instance, they can complete a self-service registration process to create their accounts by using the **Register now** link at the bottom of the **Sign On** page. ![Screen capture of a sample sign-on page](_images/vde1564003462409.jpg) 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. ![Screen capture of a sample registration page](_images/oij1564003463012.jpg)