Single Sign-On Integrations for Identity Cloud

This book provides information on Single Sign-on (SSO) Integrations for the Identity Cloud. SSO integrations allow end-users to authenticate to the Identity Cloud through third-party identity providers or external services such as Google or Salesforce.


SAML2 Federation


ADFS SSO integration with Identity Cloud as SAML service provider

The purpose of this article is to provide information on configuring Identity Cloud to integrate with Active Directory Federation Services (ADFS) using SAML2 federation for Single Sign-On (SSO). It assumes Identity Cloud is acting as the service provider (SP) and ADFS as the identity provider (IdP).

Overview

This article describes the steps required to configure ForgeRock Identity Cloud to federate with an on-prem or cloud-hosted Microsoft® Windows® ADFS instance using the SAML 2.0 standard, and covers the following use cases and scenarios: 

  • The user credentials are stored in Active Directory®, and may be updated by the admin or the user (for example, through a portal, app or the login panel on a domain attached PC).
  • Identity Cloud uses ADFS federation as one authentication factor in an authentication journey.
Note

In some cases, it is possible to use the Active Directory password synchronization plugin to intercept password changes as an alternative to using SAML2 federation. See Password Synchronization Plugin Guide for further information.

Steps involved:

  1. Create a Circle of Trust (COT)
  2. Create the hosted SP in Identity Cloud
  3. Configure ADFS
  4. Create the remote IdP in Identity Cloud
  5. Create the end-user journey
  6. Test the end-user experience
  7. Troubleshooting

Prerequisites

  • You have a working Identity Cloud tenant.
  • You have a working ADFS instance (either installed on your Microsoft Windows server or cloud hosted).

Creating a Circle of Trust (COT)

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Circles of Trust and click Add Circle of Trust.
  2. Enter a name (no spaces) for your new COT, for example, ADFSCOT, and click Create.
  3. Add a description for the COT and click Save Changes.

Creating the hosted SP in Identity Cloud

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Entity Providers and click Add Entity Provider followed by Hosted.
  2. Complete the following details and click Create:
    • Entity ID: Enter an ID (no special characters or spaces) for your hosted service provider, for example, idCloudSP.
    • Entity Provider Base URL: Verify the default URL is correct. This URL is used for all SAML2 related endpoints, so ensure other entities in your SAML deployment are able to access the specified URL.
    • Identity Provider Meta Alias: Leave blank because we're only creating a Hosted SP.
    • Service Provider Meta Alias: Enter a URL-friendly value to identify the service provider, for example, idCloudSP.
    • Circles of Trust: Select the COT created above, for example, ADFSCOT.
  1. Select the Services tab and scroll to Assertion Consumer Service.
  2. Update the location for the following services as follows:
    • HTTP-Artifact: Change Consumer in the location to AuthConsumer. For example, it should now look like this:https://openam-<YourTenantName>.forgerock.io/am/AuthConsumer/metaAlias/alpha/idCloudSP
    • HTTP-POST: Change Consumer in the location to AuthConsumer. For example, it should now look like this:https://openam-<YourTenantName>.forgerock.io/am/AuthConsumer/metaAlias/alpha/idCloudSP
    • Do not update the location for the PAOS service because integrated mode does not support the PAOS binding.

The results will resemble the following in the UI:

  1. Click Save Changes.

Configuring ADFS

Note

The following steps download the metadata and then import data from that file (Import data about the relying party from a file option). If you want to avoid downloading the metadata locally (Import data about the relying party published online or on a local network​ option), you will need to reconfigure ADFS to use modern security protocols. Otherwise, the Identity Cloud will reject the request for metadata because ADFS defaults to an insecure protocol. See Managing SSL/TLS Protocols and Cipher Suites for AD FS for further information.

ForgeRock assumes no responsibility for errors or omissions in the third-party software or documentation.

Download the hosted SP metadata

  1. Open a PowerShell terminal.
  2. Run the following command to download the SAML metadata into the specified file (outfile); ensure the URL and entityID are correct for your Identity Cloud tenant and configuration:Invoke-WebRequest -outfile idcloud-sp.xml -uri "https://openam-<YourTenantName>.forgerock.io/am/saml2/jsp/exportmetadata.jsp?entityid=idCloudSP&realm=/alpha"

Create the Relying Party Trust

  1. Launch your ADFS instance and start the Add Relying Party Trust wizard.
  2. Progress through the wizard using the following settings:
    • The Claims Aware option.
    • The Import data about the relying party from a file option - choose the metadata file you saved above (idcloud-sp.xml). You can ignore the resulting warning about content in the metadata XML being unsupported.
    • The ​Permit Everyone​ policy.
    • The ​Configure claims issuance policy for this application option.

Refer to Create a Replying Party Trust for further information.

Add a Claims rule

  1. Click Add Rule and choose the ​Send LDAP Attributes as Claims option as the Rule Type template.
  2. Progress through the wizard using the following settings:
    • Select ​Active Directory​ as the Attribute Store.
    • Map LDAP attributes to the outgoing claim types per your requirements, for example: LDAP Attribute                    Outgoing Claim Type --------------                      ------------------- SAM-Account-Name                    samAccountName E-Mail-Addresses                    mail Department                          department Given-Name                          givenName Surname                             snOne of the Outgoing Claims is used as the SAML NameId. We suggest you use ​samAccountName​ unless you have specific requirements.

Refer to Create a Rule to Send LDAP Attributes as Claims for further information.

Add a NameId rule

  1. Click Add Rule and choose the ​Send Claims Using a Custom Rule option as the Rule Type template.
  2. Create a custom rule using the following rule as a starting point:c: [Type == "​samAccountName​"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/form at"] = "​urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified​", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/name qualifier"] = "http://<ADFS deployment URL>/adfs/services/trust​", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spna mequalifier"] = "​idCloudSP");
  3. Update the following items in this custom rule to match your configuration:
    • samAccountName​: This is the outgoing claim specified in the first rule. This will be the value of the NameId element.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified​: The format being used - this indicates we'll be using the unspecified NameId format.
    • http://<ADFS deployment URL>/adfs/services/trust:​ The URL of the ADFS Federation Service Identifier.
    • idCloudSP: The Entity ID of the hosted SP in the Identity Cloud.

Refer to Create a Rule to Send Claims Using a Custom Rule for further information.

Creating the remote IdP in Identity Cloud

Download and fix the ADFS metadata

  1. Generate the ADFS metadata by navigating to the metadata link, ensuring you specify the correct ADFS deployment URL. For example: https://<ADFS deployment URL>/FederationMetadata/2007-06/FederationMetadata.xml
  2. Save the FederationMetadata.xml file locally.
  3. Edit the FederationMetadata.xml file and remove the following sections:
    • ds: Signature
    • RoleDescriptor
    • SPSSODescriptor

This will just leave the IDPSSODescriptor section. Be careful editing this file, as ADFS generates the XML all on one line.

Create the remote IdP

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Entity Providers and click Add Entity Provider followed by Remote.
  2. Import the FederationMetadata.xml file, select the ADFSCOT COT and click Create.
  1. Select the Assertion Content tab and scroll to NameId Format.
  2. Add the following NameId format to the list:urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
  3. Reorder the list so this new NameId format is first.

Creating the end-user journey

When Identity Cloud is acting as the SP, you can use the SAML2 authentication node to provide single sign on initiated by the SP.

The SAML2 node redirects the user to ADFS for authentication when it is invoked. This node can be placed at any point in the authentication journey, which allows for scenarios such as selection between multiple providers based on user selection, conditional invocation of SAML based on user choice, and so on.

The node returns either Account Exists or No Account Exists which corresponds to success or failure for any reason. If successful, the username session state variable is set to the name identifier defined in the SAML configuration.

In a simple deployment where all accounts have been pre-provisioned and linked, you only need to include the SAML2 node in the tree. For more complicated scenarios, you can use additional nodes to provision the corresponding account in Identity Cloud and link the two accounts.

Simple deployment example

  1. In the Identity Cloud Admin UI, navigate to Journeys and click New Journey.
  2. Enter a name for your journey, select which identities will authenticate using this journey, and click Save.
  3. Add the SAML2 Authentication node to the journey, and link the user to the node and the outcomes from the node, for example:
  1. Click the SAML2 Authentication node to display the configuration options and enter values for the following ones related to SP initiated SSO:
    • IdP Entity ID
    • SP MetaAlias

You can leave the other default settings as they are unless you have any specific requirements. For ADFS, you should use the default bindings: HTTP-Redirect request binding and HTTP-Artifact response binding. 

  1. Click Save.

Other journeys

Journeys are very customizable and can be used to cater to a variety of use cases. To give an example of a more complicated one, the following journey determines if a user has attempted to log in from the Partner1 domain, Partner2 domain, or from an internal domain, and then redirects the user to a selection of SAML2 providers accordingly:

Testing the end-user experience

To log in to Identity Cloud using ADFS as the SAML identity provider:

  1. Navigate to the Identity Cloud protected resource.
  2. You should then be redirected to ADFS where you can log in with your ADFS credentials.
  3. If successful, you should then be logged into the Identity Cloud protected resource automatically.

Troubleshooting

Debugging

Debug information can be found in the logs; specifically, the am-config and am-everything logs. See View Audit Logs for further information on accessing these debug logs.

Disable Encrypted Assertions

By default, ADFS is configured to encrypt the assertions it generates. It can be helpful to disable this encryption when troubleshooting.

You can disable this encryption as follows:

  1. Open an administrator level Powershell window and enter the following:set-ADFSRelyingPartyTrust -TargetName "<RelyingPartyTrust>" -EncryptClaims $FalseWhere the TargeName parameter should match the value of your Relying Party Trust Display Name defined in ADFS, for example:set-ADFSRelyingPartyTrust -TargetName "IDCloud" -EncryptClaims $False

See Also

Manage Journeys

Active Directory Federation Services


Salesforce SSO integration with Identity Cloud as SAML identity provider

The purpose of this article is to provide information on how to configure Identity Cloud to integrate with Salesforce® using SAML2 federation for Single Sign-On (SSO). It assumes Identity Cloud is acting as the identity provider (IdP) and Salesforce as the service provider (SP).

Overview

This article describes how to enable your users to sign in to Salesforce with Identity Cloud using SAML2 SSO in a service provider-initiated flow. It assumes Identity Cloud is acting as the SAML IdP and Salesforce as the SP. 

Once configured, Salesforce end-users will be presented with the ForgeRock Sign In screen to authenticate before being redirected back to Salesforce. Users who do not already exist in your Salesforce domain will be automatically provisioned when they first log in (providing you enable user provisioning in Salesforce).

Note

Salesforce as an SP is not available for all Salesforce editions. See the Salesforce documentation for further details.

Steps involved:

  1. Create a Circle of Trust (COT)
  2. Create the hosted IdP in Identity Cloud
  3. Configure Salesforce 
  4. Create the remote SP in Identity Cloud
  5. Create the end-user journey
  6. Test the end-user experience
  7. Troubleshooting

Prerequisites

  • You have a working Identity Cloud tenant.
  • You have a Salesforce developer edition account. See Salesforce Developers for further information.
  • You have registered a remote site in Salesforce. The remote site's URL must point to your Identity Cloud tenant, for example, https://<YourTenantName>.forgerock.io.
  • Identity Cloud users who already exist in Salesforce must have a Federation ID configured in Salesforce. This is usually their email address.

Creating a Circle of Trust (COT)

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Circles of Trust and click Add Circle of Trust.
  2. Enter a name (no spaces) for your new COT, for example, SalesforceCOT, and click Create.
  3. Add a description for the COT and click Save Changes.

Creating the hosted IdP in Identity Cloud

Create a hosted IdP

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Entity Providers and click Add Entity Provider followed by Hosted.
  2. Complete the following configuration:
    • Entity ID: Enter an ID (no special characters or spaces) for your hosted service provider, for example, idp.
    • Entity Provider Base URL: Verify the default URL is correct. This URL is used for all SAML2 related endpoints, so ensure other entities in your SAML deployment are able to access the specified URL.
    • Identity Provider Meta Alias: Enter a URL-friendly value to identify the service provider, for example, idp.
    • Service Provider Meta Alias: Leave blank because we're only creating a hosted IdP.
    • Circles of Trust: Select the COT you created, for example, SalesforceCOT.
  1. Click Create.
  2. In the Assertion Content tab, configure the signing and encryption options as follows:
    1. Enable the following options for request/response signing:
      • Authentication Request
      • Artifact Resolve
    2. Scroll to Secret ID And Algorithms, and add the required algorithms. The suggested ones below have been tested by ForgeRock for Salesforce integrations:
      • Digest Algorithm: Select the required digest algorithm, for example, http://www3.org/2001/04/xmlenc#sha256
      • Encryption Algorithm: Select the required encryption algorithm, for example, http://www3.org/2009/xmlenc11#rsa-oaep
  1. Scroll to NameID Format and configure the mapping as follows:
    1. Enter urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified in the Key field.
    2. Enter mail in the Value field. This will use the email address from the identity in Identity Cloud.
    3. Click Add.

The NameID Value Map appears like this:

  1. Scroll down and click Save Changes.
  2. Select the Assertion Processing tab and configure the attribute mapping for your assertion. You need to specify the name of a SAML attribute to send to Salesforce that maps to the mail attribute (this will use the email address from the identity in Identity Cloud), and you also need to map Salesforce fields to Identity Cloud attributes so that Salesforce can create the user. For example:
SAML Attribute Local Attribute
SSOID (the name of the SAML attribute to send to Salesforce)  mail  
User.Email   mail  
User.ProfileID   "Standard User"  
User.LastName   sn  
User.Username   mail  
  1. Click Add.

The Attribute Map appears similar to this:

  1. Scroll down and click Save Changes.

Verify the hosted IdP metadata

You'll use the IdP metadata when you configure SAML SSO in Salesforce.

To access the IdP metadata, navigate to the metadata URL in your browser, in the following format:

https://openam-<YourTenantName>.forgerock.io/am/saml2/jsp/exportmetadata.jsp?entityid=[entityID]&realm=/realmname

See How do I export and import SAML2 metadata in Identity Cloud? for further information.

Configuring Salesforce

Disclaimer

ForgeRock assumes no responsibility for errors or omissions in the third-party software or documentation.

Configure SAML SSO

Refer to the Salesforce documentation for guidance on configuring Salesforce as the SP with SAML SSO

Use the following configuration for Identity Cloud:

  • Choose New from Metadata URL and enter the metadata URL you used to test your hosted IdP metadata in Identity Cloud, for example: https://openam-<YourTenantName>forgerock.io/am/saml2/jsp/exportmetadata.jsp?entityid=idp&realm=/alphaThe settings in this metadata are applied when you create the configuration.
  • Other settings:
    • SAML Identity Type: Select Assertion contains the Federation ID from the User object. Identity Cloud will pass a user identifier in the SAML assertion.
    • SAML Identity Location: Select Identity is in an Attribute element.
    • Attribute Name: Enter the attribute name you configured in the hosted IdP, for example, SSOID.
    • Service Provider Initiated Request Binding: Select HTTP POST.
    • Single Logout Request Binding: Select HTTP POST.
    • User Provisioning Enabled: Select to allow users to be just-in-time provisioned the first time they log in.

Once you've saved the configuration, download the metadata. This creates an XML file of your SAML configuration settings. You'll need this metadata later when you complete the remote SP configuration in Identity Cloud.

Enable the SAML login 

To enable Salesforce users to log in using SAML SSO you will need to add the Identity Cloud identity provider (for example, idp) to your Salesforce domain as an authentication service. 

Creating the remote SP in Identity Cloud

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Entity Providers and click Add Entity Provider followed by Remote.
  2. Import the metadata file that you exported from Salesforce, select the COT you created (for example, SalesforceCOT), and click Create.
  1. In the list of entity providers, click the name of the remote SP entity provider you just created.
  2. Select the Assertion Processing tab and configure the attribute mapping for your assertion. You should create attribute mappings to match the ones you created for the hosted IdP. For example:
SAML Attribute Local Attribute
SSOID (the name of the SAML attribute to send to Salesforce)  mail  
User.Email   mail  
User.ProfileID   "Standard User"  
User.LastName   sn  
User.Username   mail  
  1. Click Add.

The Attribute Map appears similar to this:

  1. Click Save Changes.

Testing the end-user experience

To log in to Salesforce using Identity Cloud as the SAML identity provider:

  1. Go to your Salesforce instance login screen and click the Identity Cloud SAML IdP, for example, idp.
  1. In the ForgeRock Sign In screen, enter your username and password, and click Next.

After successful authentication, you are logged into Salesforce.

Troubleshooting

If your users are unable to log in to Salesforce, review the SAML login history to determine why. You can use the SAML Assertion Validator to troubleshoot errors in the SAML assertion.

See Also

SAML2 Federation in Identity Cloud

Configuring IDPs, SPs, and CoTs


Social Authentication


Google SSO integration with Identity Cloud for social authentication/registration

The purpose of this article is to provide information on configuring Identity Cloud to integrate with Google® as a social provider using OpenID Connect (OIDC) for Single Sign-On (SSO).

Overview

This article describes how to configure Identity Cloud to use Google as a social provider for authentication and/or registration. Identity Cloud provides a standards-based solution for Google social authentication and registration based on OIDC standards. 

Steps involved:

  1. Configure Google 
  2. Configure the Social Identity Provider in Identity Cloud
  3. Create the end-user journey
  4. Test the end-user experience

Prerequisites

Configuring Google

Disclaimer

ForgeRock assumes no responsibility for errors or omissions in the third-party software or documentation.

Create an OAuth 2.0 client

You'll need to create an OAuth 2.0 client for your Identity Cloud Platform project. Identity Cloud uses the OAuth 2.0 client ID when requesting an OAuth 2.0 access token.

Refer to the Google Cloud Platform documentation for guidance on setting up OAuth 2.0. When creating the OAuth 2.0 client, make sure you select your Identity Cloud project. If this is your first time creating a client ID, you will also need to configure your consent screen as shown in the User Consent section in the Google documentation.

Use the following configuration for Identity Cloud:

  • Application Type: Select Web application.
  • Name: Enter a suitable name to identify the OAuth 2.0 client.
  • Authorized JavaScript origins: Click Add URI and add your origin URI for your Identity Cloud instance, for example, https://<YourTenantName>.forgerock.io.
  • Authorized redirect URIs: Add the Identity Cloud server URI. This is the page to go to once access has been granted, for example, https://<YourTenantName>.forgerock.io/login.

Once you have created the OAuth 2.0 client, you'll see a unique Client ID and Client Secret. You'll need this information when you configure the Google social identity provider in Identity Cloud. You can retrieve these details at any time from the Credentials page.

Configuring the Social Identity Provider in Identity Cloud

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Services > Social Identity Provider Service.
  2. Choose Secondary Configurations, click Add a Secondary Configuration, and select the Client configuration for Google option.
  3. Complete the following configuration:
    • Name: Enter a name for the social identity provider, for example, Google.
    • Client ID: Enter the client identifier for your Google Cloud Platform project.
    • Redirect URL: Enter your Identity Cloud tenant login URL. This must match the redirect URI you configured in your Google Cloud Platform project, for example, https://<YourTenantName>.forgerock.io/login.
    • Scope Delimiter: Enter the scope delimiter, which is usually an empty space.
  1. Click Create.

The full configuration for the new Google social identity provider is displayed.

  1. Enter the client secret for your Google Cloud Platform project in the Client Secret field.
  2. Check the rest of the default settings are correct. In particular, check the following fields:
    • Enabled: Ensure the configuration is enabled.
    • Issuer: Ensure that https://accounts.google.com is entered.
    • Transform Script: Ensure that Google Profile Normalization is entered. This script transforms Google credential data into a normalized form.
  1. Click Save Changes.

Creating the end-user journey

You can create custom end-user journeys for social registration and sign in. These journeys will include all your enabled social identity providers, so you won't need to create different journeys for different providers.

See How do I create end-user journeys for social registration and login in Identity Cloud? for information on how to create end-user journeys for SSO with social providers.

Testing the end-user experience

  1. In the Identity Cloud Admin UI, navigate to Journeys.
  2. Click the journey that you want to test.
  3. Copy the Preview URL.
  4. Paste the preview URL into a browser using Incognito or Browsing mode.
  5. Follow the sign in and/or registration steps to test your journey.

For example, if Google is configured as a social identity provider for social login, end-users are asked if they want to authenticate with Google, similar to the screenshot below.

See Also

How do I create end-user journeys for social registration and login in Identity Cloud?

Manage Journeys

Google Social Identity Provider

Social Authentication


Salesforce SSO integration with Identity Cloud for social authentication/registration

The purpose of this article is to provide information on configuring Identity Cloud to integrate with Salesforce® as a social provider using OpenID Connect (OIDC) for Single Sign-On (SSO).

Overview

This article describes how to configure Identity Cloud to use Salesforce as a social provider for authentication and/or registration. Identity Cloud provides a standards-based solution for Salesforce social authentication and registration based on OIDC standards. 

Steps involved:

  1. Configure Salesforce 
  2. Configure the Social Identity Provider in Identity Cloud
  3. Create the end-user journey
  4. Test the end-user experience

Prerequisites

  • You have a working Identity Cloud tenant.
  • You have a Salesforce developer edition account. See Salesforce Developers for further information

Configuring Salesforce

Disclaimer

ForgeRock assumes no responsibility for errors or omissions in the third-party software or documentation.

Create a connected app for Identity Cloud

Refer to the Salesforce documentation for guidance on how to create a connected app.

Use the following configuration for Identity Cloud:

  • Basic Information:
    • Connected App Name: Enter the app name, for example, ForgeRock.
    • API Name: The API Name defaults to the Connected App Name.
    • Contact Email: Enter a contact email.
  • API (Enable Auth Settings):
    • Enable OAuth Settings: Select the checkbox to enable OAuth settings.
    • Callback URL: Enter the URL that a user's browser is redirected to after successful authentication. This must match the Redirect URL that you will configure in Identity Cloud, for example, https://<YourTenantName>.forgerock.io/login.
    • Selected OAuth Scopes: Add the following scopes:
      • Access and Manage your data (API)
      • Access your basic information (id, profile, email, address, phone)
      • Perform requests on your behalf at any time (refresh_token, offline_access)
      • Provide access to your data via the Web (web)

Note that the connected app may take a few minutes to become available.

Once the connected app is available, make a note of the Consumer Key and Consumer Secret, which can be found under the API list. You'll use this information when you configure Salesforce as a social identity provider in Identity Cloud.

Configuring the Social Identity Provider in Identity Cloud

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Services > Social Identity Provider Service.
  2. Choose Secondary Configurations, click Add a Secondary Configuration, and select the Client configuration for Salesforce option.
  3. Complete the following configuration:
    • Name: Enter a name for the social identity provider, for example, Salesforce.
    • Client ID: Enter the Consumer Key from the connected app you configured in Salesforce.
    • Redirect URL: Enter your Identity Cloud tenant login URL. This must match the value that you entered for the Callback URL in Salesforce, for example, https://<YourTenantName>.forgerock.io/login.
    • Scope Delimiter: Enter the scope delimiter, which is usually an empty space.
  1. Click Create.

The full configuration for the new Salesforce social identity provider is displayed.

  1. In the Client Secret field, enter the Consumer Secret from the connected app you configured in Salesforce.
  2. Check the rest of the default settings are correct. In particular, check the following fields:
    • Enabled: Ensure the configuration is enabled.
    • Transform Script: Ensure that Salesforce Profile Normalization is entered. This script transforms Salesforce credential data into a normalized form.
  1. Click Save Changes.

Creating the end-user journey

You can create custom end-user journeys for social registration and login. These journeys will include all your enabled social identity providers, so you won't need to create different journeys for different providers.

See How do I create end-user journeys for social registration and login in Identity Cloud? for further information.

Testing the end-user experience

  1. In the Identity Cloud Admin UI, navigate to Journeys.
  2. Click the journey that you want to test.
  3. Copy the Preview URL.
  4. Paste the preview URL into a browser using Incognito or Browsing mode.
  5. Follow the sign in and/or registration steps to test your journey.

For example, if Salesforce is configured as a social identity provider for social sign in, users are asked if they want to authenticate with Salesforce, similar to the screenshot below.

See Also

How do I create end-user journeys for social registration and login in Identity Cloud?

Configure Social Identity Providers

Manage Journeys

Social Authentication


How do I create end-user journeys for social registration and login in Identity Cloud?

The purpose of this article is to provide information on creating end-user journeys for social registration and login in Identity Cloud. These journeys are required when you integrate Identity Cloud with a third-party social provider, such as Google®, using OpenID Connect (OIDC) or OAuth 2.0 for Single Sign-On (SSO).

Overview

This article describes how to create end-user journeys for social registration and login in Identity Cloud. These journeys will include all your enabled social identity providers, so you won't need to create different journeys for different providers.

Journeys in Identity Cloud are very customizable and can support many use cases. This article provides examples of simple journeys that you can create easily by modifying the journey templates provided with Identity Cloud. It includes the following examples:

Social registration journey (example)

With this example journey, users can choose to register to Identity Cloud either with a social identity provider or by entering their details locally. If the user chooses to register with a social identity provider, such as Google, Identity Cloud creates a user from the profile data returned by the social identity provider. If any of the attributes required by Identity Cloud are missing from this profile data, the user is prompted to add values for those attributes when completing the registration.

Creating the social registration journey

  1. In the Identity Cloud Admin UI, navigate to Journeys > Registration.
  2. Click Duplicate.
  3. Enter a unique name for your journey, select which identities will authenticate using this journey, (optionally) enter a journey description, and click Save.
  4. Add the Select Identity Provider node to the Page Node. This node prompts the user to select a social identity provider to register with, or (optionally) to register locally.
  5. Add the following nodes to your journey:
    • Social Provider Handler. This node authenticates the user with the selected social identity provider. Once authenticated, the node collects profile information from the social identity provider and transforms that profile information into the attributes required by Identity Cloud.
    • Required Attributes Present. This node checks the attributes required by the specified identity object in Identity Cloud and determines if all the required attributes exist within the shared state of the journey.
    • Attribute Collector. This node collects the values of attributes required to populate a new account if any of those attributes are missing from the profile information provided by the social identity provider. Add this node to a Page Node so that the user is prompted to complete the required information during registration.

The journey should look similar to this:

  1. Configure the nodes as follows:
    • Click the initial Page Node and configure the Page Header and Page Description as needed. For example, you may want the “Sign In” link to go to a Social Login Journey instead of the default Login Journey.
    • Click the Social Provider Handler node and select Normalized Profile to Managed User in the Transformation Script field. This script transforms the social identity provider's profile object into an appropriate object for Identity Cloud.
    • Click the Required Attributes Present node and check the Identity Resource is correct; this should match the identity object you selected in step 3. The default is managed/user but you may need to change this to managed/alpha_user, for example.
    • Click the Attribute Collector node that you added and add the attributes to collect. These should include all the required attributes for the identity object. You can check which attributes are required by navigating to Native Consoles > Identity Management > Configure > Managed Objects > [Managed Object Type] and reviewing the list of properties. See Attribute Collector Node for further information.
    • Click the Page Node that contains the Attribute Collector node and configure the Page Header and Page Description as needed. See Page Node for further information.
  2. Click Save to save the journey.

Testing the journey

Before testing the journey, ensure that your social identity providers are correctly configured and enabled. See Social Authentication for further information.

  1. In the Identity Cloud Admin UI, navigate to Journeys.
  2. Click the journey that you want to test.
  3. Copy the Preview URL.
  4. Paste the preview URL into a browser using Incognito or Browsing mode.

A registration screen is displayed, similar to this:

  1. Follow the registration steps to test your journey.

Social login journey (example)

With this example journey, existing users can choose to sign in to Identity Cloud using either a social identity provider or by entering credentials locally. 

Creating the social login journey

  1. In the Identity Cloud Admin UI, navigate to Journeys > Login.
  2. Click Duplicate.
  3. Enter a unique name for your journey, select which identities will authenticate using this journey, (optionally) enter a journey description, and click Save.
  4. Add the Select Identity Provider node to the Page Node. This node prompts the user to select a social identity provider to log in with, or (optionally) to log in using local credentials.
  5. Add the Social Provider Handler node. This node authenticates the user with the selected social identity provider.

The journey should look similar to this:

  1. Configure the nodes as follows:
    • Click the initial Page Node and configure the Page Header and Page Description as needed. For example, you may want the “Create an Account” link to go to a Social Registration Journey instead of the default Registration Journey.
    • Click the Social Provider Handler node and select Normalized Profile to Managed User in the Transformation Script field.
  2. Click Save to save the journey.

Testing the journey

Before testing the journey, ensure that your social identity providers are correctly configured and enabled. See Social Authentication for further information.

  1. In the Identity Cloud Admin UI, navigate to Journeys.
  2. Click the journey that you want to test.
  3. Copy the Preview URL.
  4. Paste the preview URL into a browser using Incognito or Browsing mode.

A login screen is displayed, similar to this: 

  1. Follow the registration steps to test your journey.

Social login and registration journey (example)

A more comprehensive social login user experience would allow new accounts to be registered during the social login journey. This can be achieved by combining a social login journey and social registration journey, or by adding an Inner Tree Evaluator node.

In this example journey, the user can log in to Identity Cloud using a social identity provider or local credentials and register using a social identity provider if they do not already have an account. 

Creating the social login and registration journey

Note

The following steps assume that you have already created the social login journey described in the previous section.

  1. In the Identity Cloud Admin UI, navigate to Journeys.
  2. Choose the social login journey.
  3. Click Duplicate.
  4. Enter a unique name for your journey, select which identities will authenticate using this journey, (optionally) enter a journey description, and click Save.
  5. Add the following nodes to your login journey; these are the nodes required to register new users:
    • Required Attributes Present. This node checks the attributes required by the specified identity object and determines if all the required attributes exist within the shared state of the journey.
    • Attribute Collector. This node collects the values of attributes required to populate a new account if any of those attributes are missing from the profile information provided by the social provider. Add this node to a Page Node so that the user is prompted to complete the required information during registration.
    • Create Object. This node creates a new object in Identity Cloud, based on information collected during user registration.
    • Increment Login Count. This node increments the successful login count property of a managed object after the object has been created.

The journey should look similar to this:

  1. Configure the nodes as follows:
    • Click the initial Page Node and configure the Page Header and Page Description as needed. For example, you may want to completely remove the Create an Account link.
    • Click the Required Attributes Present node and check the Identity Resource is correct; this should match the identity object you selected in step 4. The default is managed/user but you may need to change this to managed/alpha_user, for example.
    • Click the Create Object node and check the Identity Resource is correct; this should match the identity object you selected in step 4. The default is managed/user but you may need to change this to managed/alpha_user, for example.
    • Click the Attributes Collector node and add the attributes to collect. These should include all the required attributes for the identity object. You can check which attributes are required by navigating to Native Consoles > Identity Management > Configure > Managed Objects > [Managed Object Type] and reviewing the list of properties. See Attribute Collector Node for further information.
    • Click the Page Node that contains the Attribute collector node and configure the Page Header and Page Description as needed. See Page Node for further information.
  2. Click Save to save the journey.

Testing the journey

Before testing the journey, ensure that your social identity providers are correctly configured and enabled. See Social Authentication for further information.

  1. In the Identity Cloud Admin UI, navigate to Journeys.
  2. Click the journey that you want to test.
  3. Copy the Preview URL.
  4. Paste the preview URL into a browser using Incognito or Browsing mode.

A login screen is displayed, similar to this:  

  1. Follow the registration steps to test your journey.

See Also

Google SSO integration with Identity Cloud for social authentication/registration

Salesforce SSO integration with Identity Cloud for social authentication/registration

FAQ: Journeys in Identity Cloud

ForgeRock Identity Cloud Docs

Authentication Nodes Configuration Reference

Configure Social Identity Providers


Copyright and Trademarks Copyright © 2021 ForgeRock, all rights reserved.

This content has been optimized for printing.

Loading...