--- title: Enabling third-party identity providers without registration description: If you have already configured identity provider (IdP) connections or IdP adapters to connect with third-party identity providers, you can enhance the HTML Form Adapter sign-on page with the option to authenticate with these providers. component: pingfederate version: 13.1 page_id: pingfederate:administrators_reference_guide:pf_enabling_thirdparty_identity_providers_without_registration canonical_url: https://docs.pingidentity.com/pingfederate/13.1/administrators_reference_guide/pf_enabling_thirdparty_identity_providers_without_registration.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: July 8, 2024 section_ids: about-this-task: About this task steps: Steps result: Result: result-2: Result --- # Enabling third-party identity providers without registration If you have already configured identity provider (IdP) connections or IdP adapters to connect with third-party identity providers, you can enhance the HTML Form Adapter sign-on page with the option to authenticate with these providers. ## About this task You configure an IdP authentication policy to chain the HTML Form Adapter instance and an authentication policy contract. Then the policy contract can harness attribute values returned by the HTML Form Adapter instance for multiple browser-based single sign-on (SSO) use cases through service provider (SP) connections, OAuth authorization code flow, and OAuth implicit flow. The following procedure offers an example of how you could enhance the sign-on experience by giving users the option to authenticate with their local accounts or their existing accounts on a major social network to which you have already established an IdP connection. In this example, the social network is named "ACME". | | | | - | ------------------------------------------------------------------------------------------------------------------------------ | | | You can also deploy and configure Cloud Identity Connectors to support identities from Facebook, Google, LinkedIn, or Twitter. | ## Steps 1. Verify that the IdP connection to ACME returns the attributes required to complete the browser-based SSO use cases. 2. Note which authentication policy contract your policy uses. 3. Create a local identity profile: 1. Go to **Authentication > Policies > Local Identity Profiles**. Click **Create New Profile**. 2. On the **Profile Info** tab, in the **Local Identity Profile Name** field, enter a name. 3. From the **Authentication Policy Contract**, select the authentication policy contract from [step 2](#step_y4x_bgb_xcb). Click **Next**. 4. On the **Authentication Sources** tab, under **Authentication Source**, enter `ACME`, and then click **Add**. Click **Done**. | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | | To support additional third-party identity providers, enter a value for each. At runtime, the sign-on page displays them in the order defined on this page. | 4. Configure the HTML Form Adapter instance for customer identities: 1. Go to **Integration > IdP Adapters**. 2. On the **IdP Adapters** window, from the **Instance Name** list, click the **HTMLFormAdapter** instance. 5. Modify your existing IdP authentication policy: 1. Go to **Authentication > Policies > Policies**. 2. On the **Policies** tab, in the **Policy** section, click the existing IdP policy. 3. In the **Success** path of the HTML Form Adapter instance, click **Rules**. 4. In the **Rules** dialog, create a policy path for users who choose to authenticate with ACME. For this example, configure the fields as shown in the following table. | Attribute Name | Condition | Value | Result | | -------------- | --------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | policy.action | equal to | ACME The value here must match the value defined on the Authentication Sources tab. See step 3d. | ACME users The Result field controls the label shown for the policy path of this rule. The value does not need to match the value defined on the Authentication Sources window. | | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | If you have defined multiple third-party identity providers on the **Authentication Sources** tab, you must repeat these steps to add a `policy.action` rule to create a policy path for each. | In addition, ensure the **Default to Success** checkbox is selected. When selected, the **Success** path remains, which is important when users can also authenticate using their local accounts, like in this example. 5. Click **Done**. ### Result: This returns you to the **Authentication Policies** window. 6. For the **ACME users** path, under **Action**, select the IdP connection to ACME. | | | | - | -------------------------------------------------------------------------------------------------------------------------- | | | Generally, any IdP adapter instance or IdP connection that connects to the third-party identity provider can be used here. | 7. For the ACME **Fail** path, select **Done**. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | If you have defined multiple third-party identity providers and added rules to create a policy path for each, you can select **Restart**. The **Restart** policy action provides users the opportunity to do over. When triggered, the policy engine routes the requests back to the first checkpoint of the invoked authentication policy. By selecting **Restart** for the **Fail** path, you give users the opportunity to choose another third-party identity provider if they fail to authenticate through ACME. | 8. For the ACME **Success** path, select the local identity profile created in [step 3](#step_wl2_ymb_xcb), and then complete the **Local Identity Mapping** configuration. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Because this use case does not involve registration, the source of fulfillment is limited to the preceding IdP connection or IdP adapter instance, dynamic text, and attribute mapping expression, if enabled. | 9. Click **Save**. ## Result After you give users the option to authenticate with ACME without enabling registration, when users sign on through this HTML Form Adapter instance, the following sign-on page is presented. ![A screen capture of a sample sign-on page with an option to sign on with ACME](_images/xtb1564003474361.jpg) If you also added Facebook, Google, LinkedIn, and Twitter as authentication sources, the following sign-on page is presented. ![A screen capture of a sample sign-on page with an option to sign on with ACME and more](_images/nyf1564003475009.jpg)