Journeys in Identity Cloud


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 the ... menu and select 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 the ... menu and select 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. Select the social login journey.
  3. Click the ... menu and select 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

Facebook SSO integration with Identity Cloud for social authentication/registration

LinkedIn SSO integration with Identity Cloud for social authentication/registration

Yahoo SSO integration with Identity Cloud for social authentication/registration

Single Sign-On Integrations for Identity Cloud

FAQ: Journeys in Identity Cloud

ForgeRock Identity Cloud Docs

Authentication Nodes Configuration Reference

Configure Social Identity Providers


How do I make session properties from a journey available in the SAML2 assertion when Identity Cloud is the IdP?

The purpose of this article is to provide assistance with making session properties from a journey available in the SAML2 assertion when Identity Cloud is the IdP. For example, this allows you to retrieve specific information when a user logs in, store that in a session property and then use it in subsequent SAML2 flows in order to enrich the assertion.

Overview

The process outlined in this article uses a login journey to capture details when a user authenticates and then stores those details in a session property. The advantage of doing this at the login stage versus assertion minting time is that it reduces the number of API calls from once per assertion to once per session. You can then use the Authentication Context Mapper to map your login journey to an authentication context in order to use the stored session property in subsequent SAML2 flows. Finally, you can use the IdP and SP Attribute Mappers to extract the information from the stored session property and add it to the assertion.

Summary of steps involved:

  1. Create login journey
  2. Whitelist the session property
  3. Update the hosted IdP to use the login journey
  4. Update the hosted IdP to add the session property to the assertion
  5. Update the remote SP to add the same session property to the assertion
  6. Validate the SAML assertion contains the session property

These examples use a session property called mySessionProperty and a journey called myLoginJourney.

Prerequisites

  • You have a working Identity Cloud tenant.
  • You have an existing SAML2 integration set up, where Identity Cloud is the hosted IdP.

Creating a login journey

Creating a login journey can be quite straightforward or may need scripting knowledge depending on what you want to set in your session property:

  • If you just want to update a session property with static values, you can use the Set Session Properties node. See Set Session Properties Node for further information. In the following example journey, the Set Session Properties node would replace the two Scripted Decision nodes to simplify your journey.
  • If you want to retrieve a value using some logic and store that value as a session property, you will need to use Scripted Decision nodes and write suitable scripts to achieve it.
Note

Writing scripts for end-user journeys is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Deployment Support Services.

To create a login journey:

  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. Create a login journey, which authenticates the user, retrieves the required piece of information, and then updates a session property. For example, your journey may look similar to this, where the Retrieve Information and Update Session Property nodes are Scripted Decision nodes:
  1. Click Save.

See Setting Session Properties and Accessing Existing Session Properties for further information and examples on using Scripted Decision Node scripts to set and access session properties using the Action interface and the existingSession object respectively.

There are example scripts in GitHub that demonstrate retrieving a user's location from their IP address and setting that as a session property. You can refer to these scripts as a starting point for your own scripts (but they are not supported):

Whitelisting the session property

All session properties are considered sensitive and are invisible to everyone, including admins, by default. In order to make them accessible, you must whitelist them.

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Services > Session Property Whitelist Service.
  2. Add the name of your session property to both fields. For example, it would look similar to this after adding a property called mySessionProperty:
  1. Click Save Changes.

Updating the hosted IdP to use the login journey

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Entity Providers and click the name of the entity provider that is of type Hosted IdP.
  2. Select the Assertion Content tab and scroll to Authentication Context.
  3. Modify the default mapping of the PasswordProtectedTransport context as follows:
    • Key - select Service.
    • Value - enter the name of the login journey you created.

For example, it would look similar to this after specifying a login journey called myLoginJourney:

  1. Click Save Changes

Updating the hosted IdP to add the session property to the assertion

  1. Stay in the hosted IdP settings.
  2. Select the Assertion Processing tab and scroll to Attribute Mapper.
  3. Add a new attribute mapping to map the session property to a SAML attribute (which is the name shown in the assertion). For example, it would look similar to this after specifying your session property (mySessionProperty) and mapping it to a SAML attribute called sessionProperty:

Identity Cloud initially looks for a profile attribute that matches the name specified for the Local Attribute. If a matching profile attribute doesn't exist, it then looks for a session property with that name.

  1. Click Save Changes.

Updating the remote SP to add the same session property to the assertion

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > Federation > Entity Providers and click the name of the entity provider that is of type Remote SP.
  2. Select the Assertion Processing tab and scroll to Attribute Mapper.
  3. Add a new attribute mapping to map the session property to a SAML attribute so that it matches the mapping you added to the IdP.
  4. Click Save Changes.

Validating the SAML assertion contains the session property

You can capture a SAML trace to check that the assertion contains the session property. There are free third-party tools you can use, for example, in Firefox®, you can use SAML Tracer.

You should see something similar to the following in the trace for the POST to the login URL if your session property has been successfully added:<saml:AttributeStatement>      <saml:Attribute Name="sessionProperty">           <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"                                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"                                xsi:type="xs:string"                                >propertyValue</saml:AttributeValue>       </saml:Attribute>   </saml:AttributeStatement>

See Also

How do I export and import SAML2 metadata in Identity Cloud?

Scripted Decision Node API Functionality

Hosted Identity Provider Configuration Properties

Remote Service Provider Configuration Properties


How do I make session properties from a journey available in the OIDC ID token in Identity Cloud?

The purpose of this article is to provide assistance with making session properties from a journey available in the OpenID Connect (OIDC) ID token. This can be achieved by adding custom claims to the OIDC claims script in Identity Cloud. For example, this allows you to capture specific information when a user logs in, store that in a journey session property, retrieve it in the OIDC claims script and then add it to a custom claim within the JWT ID token for use elsewhere.

Overview

The process outlined in this article uses a login journey to capture details when a user authenticates and then stores those details in a journey session property. By adding a custom claim to the OIDC claims script, you can then retrieve the stored session property and add it to the ID token as a custom claim.

Summary of steps involved:

  1. Create login journey
  2. Whitelist the session property
  3. Create a custom OIDC Claims Script
  4. Configure the OAuth2 provider
  5. Update the OAuth 2.0/OIDC client
  6. Validate the JWT ID token contains the journey session properties

The examples in this article use a session property called mySessionProperty and an additional scope called myCustomScope (which adds the session property to the id_token). 

Note

Writing scripts for end user journeys and OIDC claims is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Deployment Support Services.

Integration with IG

If you use IG to consume the resulting ID token, you may find the session property is null. This can happen in the following scenario: the ID token is issued successfully with the custom claim containing your session property. Subsequently, IG makes a call to /userinfo, which causes the OIDC claims script to be invoked again, but this time there is no session, which leads to a null session property. 

If you experience this issue, you should modify the OIDC claims script to ensure it only adds claims when a session exists.

Prerequisites

  • You have a working Identity Cloud tenant.
  • You have an existing OAuth 2.0/OIDC client in Identity Cloud for use with the OIDC Provider. See Applications for further information.

Creating a login journey

Creating a login journey can be quite straightforward or may need scripting knowledge depending on what you want to set in your journey session property:

  • If you just want to update a session property with static values, you can use the Set Session Properties node. See Set Session Properties Node for further information. In the following example journey, the Set Session Properties node would replace the two Scripted Decision nodes to simplify your journey.
  • If you want to retrieve a value using some logic and store that value as a session property, you will need to use Scripted Decision nodes and write suitable scripts to achieve it.

To create a login journey:

  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. Create a login journey, which authenticates the user, retrieves the required piece of information, and then updates a session property. For example, your journey may look similar to this, where the Retrieve Information and Update Session Property nodes are Scripted Decision nodes:
 
  1. Click Save.

See Setting Session Properties and Accessing Existing Session Properties for further information and examples on using Scripted Decision Node scripts to set and access session properties using the Action interface and the existingSession object respectively.

There are example scripts in GitHub that demonstrate retrieving a user's location from their IP address and setting that as a session property. You can refer to these scripts as a starting point for your own scripts (but they are not supported):

Whitelisting the session property

All session properties are considered sensitive and are invisible to everyone, including admins, by default. In order to make them accessible, you must whitelist them.

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Services > Session Property Whitelist Service.
  2. Add the name of your session property to both fields. For example, it would look similar to this after adding a property called mySessionProperty:
 
  1. Click Save Changes.

Creating a custom OIDC Claims Script

  1. In the Identity Cloud Admin UI, navigate to Scripts > OIDC Claims Script.
  2. Click the … menu and select Duplicate.
  3. Enter a unique name for your script and optionally a description.
  4. Specify the script details:
    1. Add the session property claim to a new scope in the utils.setScopeClaimsMap section. For example, with a new myCustomScope scope: utils.setScopeClaimsMap({        profile: [             'name',             'family_name',             'given_name',             'zoneinfo',             'locale'         ],         email: ['email'],         address: ['address'],         phone: ['phone_number'],         myCustomScope: ['mySessionProperty']     });
    2. Add mapping details for the session property claim to the utils.setClaimResolvers section. For example, with added mapping details for the mySessionProperty claim: utils.setClaimResolvers({        /*         // An example of a simple claim resolver function that is defined for a claim         // directly in the configuration object:         custom-claim-name: function (requestedClaim) {             // In this case, initially, the claim value comes straight from a user profile attribute value:             var claimValue = identity.getAttribute('custom-attribute-name').toArray()[0]             // Optionally, provide additional logic for processing (filtering, formatting, etc.) the claim value.             // You can use:             // requestedClaim.getName()             // requestedClaim.getValues()             // requestedClaim.getLocale()             // requestedClaim.isEssential()             return claimValue         },         */         /**          * The use of utils.getUserProfileClaimResolver shows how          * an argument passed to a function that returns a claim resolver          * becomes available to the resolver function (via its lexical context).          */         name: utils.getUserProfileClaimResolver('cn'),         family_name: utils.getUserProfileClaimResolver('sn'),         given_name: utils.getUserProfileClaimResolver('givenname'),         zoneinfo: utils.getUserProfileClaimResolver('preferredtimezone'),         locale: utils.getUserProfileClaimResolver('preferredlocale'),         email: utils.getUserProfileClaimResolver('mail'),         address: utils.getAddressClaimResolver(             /**              * The passed in user profile claim resolver function              * can be used by the address claim resolver function              * to obtain the claim value to be formatted as per the OIDC specification:              * @see https://openid.net/specs/openid-connect-core-1_0.html#AddressClaim.              */             utils.getUserProfileClaimResolver('postaladdress')         ),         phone_number: utils.getUserProfileClaimResolver('telephonenumber'),         mySessionProperty: function () {             return session.getProperty('mySessionProperty');         } });
    3. Update any other script details as needed.
  5. Click Save.

Configuring the OAuth2 provider

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Services > OAuth2 Provider > Advanced OpenID Connect and enable Always Return Claims in ID Tokens.
  2. Click Save Changes.

Updating the OAuth 2.0/OIDC client

  1. In the Identity Cloud Admin UI, navigate to Native Consoles > Access Management > Applications > OAuth 2.0 > Clients and click the name of your OAuth 2.0/OIDC client.
  2. Select the OAuth2 Provider Overrides tab and select the custom OIDC claims script you created above in the OIDC Claims Script field.
  3. Click Save Changes.
  4. In the Identity Cloud Admin UI, navigate to Applications and click the name of your OAuth 2.0/OIDC client.
  5. Add the new scope you specified in the script above in the Scopes field.
  6. Click Save.

Validating the JWT ID token contains the journey session properties

  1. Authenticate using the login journey you created and obtain an authorization code using the resulting journey session token:
    1. Navigate to a URL such as the following in a browser using Incognito or Browsing mode; ensure you include the scope you specified in the script above (myCustomScope in this example):https://<tenant-name>.forgeblocks.com/am/oauth2/realms/root/realms/alpha/authorize?client_id=<client_id>&response_type=code&scope=openid%20myCustomScope&redirect_uri=https://httpbin.org/anything&service=<login_journey_name>
    2. Authenticate as an end user.
    3. Allow access to your account when prompted for consent.
    4. Copy the authorization code returned in the browser, for example:{  "args": {     "client_id": "<client_id>",      "code": "8xjrUVHHR5i5t_Fkpp3UUr6NBJ8.spkaJhs1d63p7qILFOVrHGaAlp8",  ...
  2. Exchange the authorization code for the id_token:$ curl --location --request POST 'https://<tenant-name>.forgeblocks.com/am/oauth2/realms/root/realms/alpha/access_token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=authorization_code' \ --data-urlencode 'code=<authorization-code>' \ --data-urlencode 'client_id=<client_id>' \ --data-urlencode 'client_secret=<client_secret>' \ --data-urlencode 'redirect_uri=https://httpbin.org/anything'

See Identity Cloud Postman Collection for further information.

  1. Copy the id_token returned (do not copy the entire response as that also includes the access_token).
  2. Decode the id_token to verify that the JWT includes the session property. For example, you can use jq on the command line (you can install jq as outlined in Download jq):$ jq -R 'split(".") | .[1] | @base64d | fromjson' <<< <id_token>Example response showing the session property (mySessionProperty in this example):{  "at_hash": "PtgPFhutEQ4eHK1_nEVmPQ",   "sub": "bddb135d-f6b7-4933-bb9e-525d436d48bb",   "auditTrackingId": "6a8d9c63-3154-4094-8713-63e19368d518-27339",   "subname": "bddb135d-f6b7-4933-bb9e-525d436d48bb",   "iss": "https://<tenant-name>.forgeblocks.com/am/oauth2/realms/root/realms/alpha",   "tokenName": "id_token",   "sid": "s+g7AVR2lNE6C9t3jx+Tn9VBPO7yVn2xMLHrpH2NAjA=",   "aud": "<client_name>",   "c_hash": "t8R_lQDDmeQRQe3Pbfn6rg",   "acr": "0",   "org.forgerock.openidconnect.ops": "5-kDQ_4m8XueDlHI0x6mYuKG9To",   "azp": "<client_name>",   "auth_time": 1637582507,   "mySessionProperty": "customValue",   "realm": "/alpha",   "exp": 1637586136,   "tokenType": "JWTToken",   "iat": 1637582536 }

See Also

Scripted Decision Node API Functionality

About Claims


FAQ: Journeys in Identity Cloud

The purpose of this FAQ is to provide answers to commonly asked questions regarding end-user journeys in Identity Cloud.

Frequently asked questions 

Q. How can I collect multiple attributes in the same node where some are required and some are optional?

A. If you include multiple attributes in a single Attribute Collector Node, they must all be required or all optional.

If you want attributes to have different validation options, you can use multiple Attribute Collector nodes to specify whether individual attributes are required or optional. You can then include these Attribute Collector nodes in a single Page Node to present them on the same page in the end-user journey.

Q. How do I know what policy will be used to validate a user's input?

A. When you use the Attribute Collector Node for user input, you can choose whether the input value for an attribute is validated or not by selecting the Validate Input option.

To find out what validation policies are defined for an attribute, you can navigate to: Native Consoles > Identity Management > Configure > Managed Objects > [Managed Object Type] and click the name of the attribute (property) you are interested in. On the Validation tab, you will see a list of policies that have been added to the attribute. See Default Policy Reference for further details about these policies.

Q. When is an attribute validation policy evaluated?

A. If an attribute has a validation policy attached to it, the policy will always be evaluated when there is user input, even if the attribute has been marked as optional in the Attribute Collector node. If a non-required field has data within it, the policy will be evaluated. 

Note

If you have a Scripted Decision Node that removes an attribute’s value (that is, by setting the value to null), then all policies attached to all attributes for the managed object (for example, alpha_user) will be re-evaluated when the object is updated/patched with the null value.

Q. How do I ensure a user input attribute is mandatory when I use policy validation?

A. If you are using policy validation with an Attribute Collector Node, you can add the not-empty validation policy to the attribute to ensure the field cannot be left blank. 

To make an attribute mandatory:

  1. Add a new policy by navigating to: Native Consoles > Identity Management > Configure > Managed Objects > [Managed Object Type] and clicking the name of the attribute (property) you want to make mandatory.
  2. Select the Validation tab, click Add Policy, enter not-empty in the Policy Id field and click Add.
  1. Return to the Attribute Collector node in your journey and make the following changes to ensure policies are used which give user feedback:
    • Deselect the All Attributes Required option.
    • Select the Validate Input option.

Q. How do I return a custom error message using the Scripted Decision node?

A. You can include the following in your script to define a custom error message:sharedState.put("errorMessage", "custom error message") outcome = "false" For example, if you would like to see a custom authentication failure response such as:{"code":401,"reason":"Unauthorized","message":"Token registration not possible"}Instead of the standard:{"code":401,"reason":"Unauthorized","message":"Login failure"} Your script would look similar to the following example:if (sharedState.get('transaction_mfa_option') != 'MFA') { logger.warning('Register Token not allowed for MFA option:' + sharedState.get('transaction_mfa_option')) sharedState.put("errorMessage", "Token registration not possible") outcome = "false" }else{ outcome = "true" }

Q. How can I reference environment-specific secret or non-secret values in a Scripted Decision node?

A. You can include environment secrets and variables (ESVs) in your scripts as detailed in Use ESVs in Scripts.

Q. How do I debug an end-user journey?

A. You can include a Scripted Decision node in your journey for debugging. See GitHub: Scripted Decision Debugger for some examples to get you started. 

You can insert a Scripted Decision node such as this at each stage of the journey that you want to debug. This node will then send script debug statements to the browser with the caught error, sharedState content or even just a simple message such as passed.

Caution

Please be aware that script debug statements will be visible to ForgeRock support, so you should ensure you do not log any personally identifiable information (PII) or any sensitive information. 

Writing scripts for end-user journeys is outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Deployment Support Services.  

See Also

Journeys


Known Issues


iOS Google Authenticator fails to register a device with an Invalid barcode error when using OATH nodes in Identity Cloud and AM 7.1

The purpose of this article is to provide assistance if you encounter an "Invalid barcode" error when attempting to register a device with the iOS® Google® Authenticator app. This issue occurs when using a journey or tree that contains the OATH Registration node in Identity Cloud or AM.

Symptoms

You will see the following error on your device when scanning a QR code with the iOS Google Authenticator app in order to register the device:

Invalid barcode The barcode [URL] is not a valid authentication token barcode

The same QR code will work with other authenticators such as the ForgeRock Authenticator or the Android™ version of the Google Authenticator app.

Recent Changes

N/A

Causes

The barcode includes = padding characters in the base32 encoded secret, which the iOS Google Authenticator rejects but other authenticator apps just ignore. This is a known limitation with the iOS Google Authenticator.

Solution

This issue can be resolved by increasing the minimum secret key length to avoid padding as follows:

Identity Cloud Admin UI

  1. Navigate to Journeys and click the journey that includes the OATH Registration node.
  2. Click the OATH Registration node.
  3. Enter a new value in the Minimum Secret Key Length field that avoids padding; choosing a value of 40 should typically work.
  4. Click Save.

AM Console

  1. Navigate to Realms > [Realm Name] > Authentication > Trees and select the tree that includes the OATH Registration node.
  2. Click the OATH Registration node.
  3. Enter a new value in the Minimum Secret Key Length field that avoids padding; choosing a value of 40 should typically work.
  4. Click Save.

See Also

FAQ: Journeys in Identity Cloud

Journeys


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

This content has been optimized for printing.