Advanced Identity Cloud

Authentication node reference

Basic nodes

Data Store Decision node

The Data Store Decision node checks that the credentials provided during authentication match the ones stored in the configured data store for the realm.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node requires the realm, username, and password properties in the incoming node state.

You can implement the following nodes as inputs to the Data Store Decision node:

Dependencies

The Data Store Decision node is a basic node used in many authentication application types, such as basic, push, OAuth 2.0, and social provider authentication applications.

Configuration

This node has no configurable properties.

Outputs

This node copies shared and transient state into the outgoing node state.

Outcomes

Returns a boolean outcome:

True

The credentials match those found in the data store.

False

The credentials do not match those found in the data store.

Errors

The following Data Store Decision node warnings and errors can appear in the logs:

Warnings
  • "invalid password error"

  • "invalid username error"

Errors
  • "Exception in data store decision node"

Troubleshooting

Review any errors and warnings this node logged.

  • If this node logged a warning, fix the credentials and try again.

  • If this node logged an error, review the log messages for the transaction to find the reason for the exception.

Examples

Example 1: Simple username and password collector nodes with Data Store Decision node
data store decision login

This example illustrates a simple login process. The journey involves a Page node that contains two embedded nodes: Platform Username node and Platform Password node. To enhance user experience, the Page node lets users input their username and password on a single page, instead of splitting them across two different pages.

The Data Store Decision node has two outcomes: True or False. When the outcome is True, it triggers a Login Count Decision node. The Increment Login Count node then moves to an Inner Tree Evaluator node, which performs additional login processes. The False outcome connects directly to a failure node, indicating a failed state where the username and/or password provided by the user did not match the information stored in the data store.

Example 2: Grant the user several attempts to enter their credentials correctly
data store decision with retry

In the following example, when an authentication attempt fails at the Data Store Decision node, you can direct it to a Retry Limit Decision node. The Retry Limit Decision node determines the number of retries allowed and either retries the login attempt or rejects it. If the journey rejects the login attempt after reaching the configured limit, for example three attempts, the operation results in an account lockout.

Additional information

The following are alternate nodes that you can use in your journeys depending on your specific use cases:

  • The LDAP Decision node supports LDAP Behera Password Policies with separate outcomes for accounts that are locked and passwords that have expired.

  • In Advanced Identity Cloud applications, the Identity Store Decision node is an enhanced node with additional outcomes. Use this node if your authentication journey needs more functionality than a simple True or False outcome.

LDAP Decision node

The LDAP Decision node verifies that the provided username and password exist in the specified LDAP user data store. The node also checks whether the associated user account has expired or is locked out.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

The node reads the username and password fields from the node state.

The journey can provide these credentials in a number of ways, for example, with a combination of the Platform Username node and Platform Password node, or by using the Zero Page Login Collector node.

Prerequisites

None

Configuration

Property Usage

Primary LDAP Server (required)

Specify one or more primary directory servers. Specify each directory server in the following format: host:port.

For example, directory_services.example.com:389.

Secondary LDAP Server

Specify one or more secondary directory servers. Specify each directory server in the following format: host:port.

The journey uses the secondary servers when none of the primary servers are available.

For example, directory_services_backup.example.com:389.

DN to Start User Search (required)

Specify the DN from which to start the user search. More specific DNs, such as ou=sales,dc=example,dc=com, result in better search performance.

If multiple entries with the same attribute values exist in the directory server, make sure this property is specific enough to return only one entry.

Bind User DN, Bind User Password

The credentials used to connect to the LDAP user data store.

Attribute Used to Retrieve User Profile (required)

The attribute used to retrieve a user profile from the directory server.

The user search will have already happened, as specified by the Attributes Used to Search for a User to be Authenticated and User Search Filter properties.

Attributes Used to Search for a User to be Authenticated (required)

The attributes the node uses to match the credentials provided by the user to an entry in the directory server.

For example, a value of uid forms the search filter uid=user. If you specify multiple values, such as uid and cn, the node forms a complex search filter (|(uid=user)(cn=user)).

Multiple attribute values let the user authenticate with any one of the values. For example, if you set both uid and mail, then Barbara Jensen can authenticate with either bjensen or bjensen@example.com.

If you are using account lockout and you set multiple attribute values here, you must add those attributes to the Alias Search Attribute Name property in the User profile.

User Search Filter

A filter to append to user searches.

For example, if your search attribute is mail and you set User Search Filter to (objectClass=inetOrgPerson), the node uses (&(mail=address)(objectClass=inetOrgPerson)) as the resulting search filter. In this example, address is the mail address provided by the user.

Search Scope

The extent of the search for users in the directory server:

  • OBJECT: The search extends only to the entry specified by the DN to Start User Search.

  • ONELEVEL: The search extends to the entries that are direct children of the DN to Start User Search.

  • SUBTREE: The search extends to the DN to Start User Search and every entry under it.

Default: SUBTREE

LDAP Connection Mode

Specifies whether to use SSL or StartTLS to connect to the directory server. The node must be able to trust the certificates used.

Possible values: LDAP, LDAPS, and StartTLS

Default: LDAP

mTLS Enabled

Enables mTLS (mutual TLS) between AM and the directory server.

This setting applies to all configured LDAP servers; that is, AM uses mTLS to authenticate to all LDAP servers configured for this node.

When mTLS is enabled, AM ignores the values for Bind User DN and Bind User Password.

If you enable this property, you must:

  • Set the LDAP Connection Mode to LDAPS

  • Provide an mTLS Secret Label Identifier

Default: Disabled

mTLS Secret Label Identifier

Identifier used to create a secret label for mapping to the mTLS certificate in the secret store. AM uses this identifier to create a specific secret label for this node. The secret label takes the form am.authentication.nodes.ldap.decision.mtls.identifier.cert , where identifier is the value of mTLS Secret Label Identifier. The identifier can only contain alphanumeric characters (a-z, A-Z, 0-9) and periods (.). It can’t start or end with a period. All LDAP servers configured for this node share the same secret label.

For more security, you should rotate certificates periodically. When you rotate a certificate, update the corresponding mapping in the realm secret store configuration to reflect this label. When you rotate a certificate, AM closes any existing connections using the old certificate. A new connection is selected from the connection pool and no server restart is required.

Return User DN to DataStore

When enabled, the node returns the DN rather than the User ID. From the DN value, AM uses the RDN to search for the user profile. For example, if a returned DN value is uid=demo,ou=people,dc=openam,dc=example,dc=org, AM uses uid=demo to search the directory server.

Default: Enabled

User Creation Attributes

This list lets you map (external) attribute names from the LDAP directory server to (internal) attribute names used by AM.

Minimum Password Length

The minimum acceptable password length.

Default: 8

LDAP Behera Password Policy Support

When enabled, support interoperability with servers that implement the Internet-Draft, Password Policy for LDAP Directories.

Default: Enabled

Trust All Server Certificates

When enabled, the server blindly trusts server certificates, including self-signed test certificates.

Default: Disabled

LDAP Connection Heartbeat Interval

Specifies how often AM should send a heartbeat request to the directory server to ensure that the connection doesn’t remain idle.

Some network administrators configure firewalls and load balancers to drop connections that are idle for too long. Set the units for the interval in the LDAP Connection Heartbeat Time Unit property.

Setting this property to 0 does not disable the heartbeat (keepalive) or load balancer availability checks.

Default: 10

LDAP Connection Heartbeat Time Unit

The time unit for the LDAP Connection Heartbeat Interval.

Default: seconds

LDAP Operations Timeout

The timeout, in seconds, that AM should wait for a response from the directory server.

Default: 0 (means no timeout)

Use mixed case for password change messages

Specifies whether the server returns password change messages in mixed (sentence) case or transforms them to uppercase.

By default, the server transforms password reset and password change messages to uppercase. Enable this setting to return messages in sentence case.

Default: Disabled

LDAP Affinity Level

Level of affinity used to balance requests across LDAP servers.

Affinity-based load balancing means that each request for the same user entry goes to the same DS server. The DS server used for a specific operation is determined by the DN of the identity involved.

List the directory server instances that form part of the affinity deployment in the Primary LDAP Server and Secondary LDAP Server properties.

Options are:

  • NONE – no affinity

  • BIND – affinity for BIND requests only

  • ALL – affinity for all requests

Default: NONE

Outcomes

True

The provided credentials match those found in the LDAP user data store.

False

The provided credentials don’t match those found in the LDAP user data store.

Locked

The profile associated with the provided credentials is locked.

Cancelled

The user must change their password. When the journey prompts the user to change their password, the user cancels the password change.

Expired

The profile is found, but the password has expired.

Identity Store Decision node

The Identity Store Decision node attempts to match the provided username and password with the credentials stored in the identity store.

If the credentials exist, the node checks the following:

  • Is the profile locked?

  • Has the provided password expired?

  • Has the user cancelled a password reset?

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

No

Ping Identity Platform (self-managed)

No

Inputs

The node reads the username and password fields from the node state.

The journey can provide these credentials in a number of ways, for example, with a combination of the Platform Username node and Platform Password node, or by using the Zero Page Login Collector node.

Dependencies

None

Configuration

Property Usage

Minimum Password Length

For password change requests, the node rejects passwords that are shorter than this value. If you set this value to 0, the node doesn’t check the password length.

Default: 8

Username as Universal Identifier

If you enable this property, the username property is set to the value of the uuid. For example, "username": "c636b756-ba6b-481d-ab4a-ab8c064cb24b".

If this property is false, the value of the username property remains unchanged. For example, "username": "bjensen".

Default: false

Use mixed case for password change messages

Return password change messages in mixed (sentence) case.

By default password reset and password change messages are transformed to upper case. Enable this option to return messages in sentence case.

Default: Disabled

Outputs

This node copies shared and transient state into the outgoing node state.

Outcomes

True

The credentials match those found in the identity store.

False

The credentials don’t match those found in the identity store.

Locked

The profile associated with the provided credentials is locked.

Cancelled

The user cancelled a password change request. The example provides a detailed explanation of this outcome.

Expired

The credentials match those found in the identity store, but the password has expired.

Example

The Identity Store Decision node in context

This example illustrates a simple login process.

  • A Page node with the embedded nodes (Platform Username node and Platform Password node) prompts the user for their credentials.

  • The Identity Store Decision node assesses the credentials:

    • If it finds the credentials in the data store and the credentials are valid, the journey follows the True outcome. An Increment Login Count node increments the login count and the user is authenticated.

    • If the credentials don’t exist in the data store, the journey follows the False outcome and authentication fails.

    • If the credentials exist in the data store but the account is locked, the journey follows the Locked outcome. A Message node displays a custom lockout message and authentication fails.

    • If the credentials exist in the data store but the user must change their password, the node prompts the user to change their password. If the user cancels this change request, the journey follows the Cancelled outcome. A Message node displays a custom message and authentication fails.

    • If the credentials exist in the data store but the password has expired, the node follows the Expired outcome. The user is routed to an inner tree journey that contains the password reset logic and then routes the user to the start of the journey to authenticate again.

Alternative nodes

  • The Data Store Decision node is a simpler node with only two outcomes, True and False. Use this node if the flow only requires these outcomes.

Zero Page Login Collector node

The Zero Page Login Collector node verifies the presence of specific HTTP username and password headers in the incoming authentication request. If the headers exist, the node uses their corresponding values as the provided username and password.

The Zero Page Login Collector node is commonly used to:

The password collected by this node remains in the node state only until the journey reaches the next node that requires user interaction.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

  • HTTP username header

  • HTTP password header

  • An allowlist of referrers if Allow Without Referer property is disabled. When you set the Allow Without Referer property to false, the request must contain a referrer from the allowlist; otherwise, the journey ends in a failure.

Dependencies

None.

Configuration

Properties
Property Usage

Username Header name

Enter the name of the header that contains the username value.

Default: X-OpenAM-Username

Password Header name

Enter the name of the header that contains the password value.

Default: X-OpenAM-Password

Allow without referer

If enabled, the node accepts incoming requests that do not contain a Referer HTTP header. If a Referer HTTP header is present, the value is not checked.

If disabled, a Referer HTTP header must be present in the incoming request, and the value must appear in the Referer allowlist property.

Default: Enabled

Referer Whitelist

Specify a list of URLs allowed in the Referer HTTP header of incoming requests. An incoming request containing a Referer HTTP header value not specified in the allowlist causes evaluation to continue along the No Credentials outcome path.

You must disable the Allow Without Referer property for the referer allowlist property to take effect.

Outputs

The collected credentials from the headers.

Outcomes

  • Has Credentials

  • No Credentials

Evaluation continues along the Has Credentials outcome path if the specified headers are available in the request, or the No Credentials path if the specified headers are not present.

Errors

If more than one header value exists for username and/or password, the node returns the following error message

"Expecting only one header value for username and/or password but size is {}."

If the node can’t decode the header values, the node returns the following error message

"Could not decode username or password header."

Example

zero page login collector node

Multi-factor nodes

Get Authenticator App node

Displays information to obtain an authenticator application from the Apple App Store or the Google Play Store.

Use the following variables to customize the message:

  • {{appleLink}}

  • {{appleLabel}}

  • {{googleLink}}

  • {{googleLabel}}

You can also include HTML elements, for example:

Apple: <a target='_blank' href='{{appleLink}}'>{{appleLabel}}</a>

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Get App Authenticator Message

Localized title for the node. The key is the language, such as en or fr, and the value is the message to display.

Default: Get the app from the {{appleLink}} or on {{googleLink}}.

Continue Label

Localized text to use on the Continue button. The key is the language, such as en or fr, and the value is the message to display.

Apple App Store URL

Specifies the URL to download your authenticator application from the Apple App Store. The default value points to the ForgeRock Authenticator application for iOS.

Google Play URL

Specifies the URL to download your authenticator application from the Google Play Store. The default value points to the ForgeRock Authenticator application for Android.

HOTP Generator node

Creates a string of random digits of the specified length for use as a one-time passcode.

Passwords are stored in the oneTimePassword transient node state property.

Use this node with these nodes to add one-time passcode verification as an additional factor:

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

One-time password length

Specify the number of digits in the one-time passcode. The minimum number of digits is 6, in accordance with the HOTP specification.

Default: 8

Example

The following example uses an HOTP generator as part of multi-factor authentication:

HOTP generator as part of MFA

MFA Registration Options node

Lets the user register a multi-factor authentication device or skip the registration process.

The node requires the username of the identity to update and the type of MFA device. For example, you can use a Platform Username node and a Push Sender node earlier in the flow to obtain these.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Register

  • Get App (configurable)

  • Skip (configurable)

  • Opt-out (configurable)

Evaluation continues along the outcome the user selects.

Properties

Property Usage

Remove 'skip' option

If checked, users can no longer skip the node and must interact with it.

Display Get Authenticator App

If enabled, display the Get the App button.

Message

Localized text to use as the title of the screen.

The key is the language, such as en or fr, and the value is the message to display.

Register Device

Localized text to use on the Register Device button.

The key is the language, such as en or fr, and the value is the message to display.

Get Authenticator App

Localized text to use on the Get Authenticator App button.

The key is the language, such as en or fr, and the value is the message to display.

Skip this Step

Localized text to use on the Skip this Step button.

The button and the outcome only appear if the Remove 'skip' option is not enabled.

The key is the language, such as en or fr, and the value is the message to display.

Opt-out

Localized text to use on the Opt-Out button.

The button and the outcome only appear if the Remove 'skip' option is not enabled.

Note that this node does not change the user’s profile. Connect the Opt-out outcome to an Opt-out Multi-Factor Authentication node to persist the option in the user’s profile.

The key is the language, such as en or fr, and the value is the message to display.

Example

Refer to the Push authentication example journey for how to use the MFA Registration Options node in a journey handling push devices.

Default text of the MFA Registration Options node.

OATH Device Storage node

The OATH Device Storage node stores devices in the user profile after an OATH Registration node records them in the shared state.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Authenticators

The OATH-related nodes can integrate with the following authenticator apps:

  • The ForgeRock Authenticator app for Android and iOS.

  • Third-party authenticator apps that support the following open standards:

    • RFC 4226: HMAC-Based One-Time Password (HOTP)

    • RFC 6238: Time-Based One-Time Password (TOTP)

Inputs

This node reads the device profile as the value of the shared state attribute oathDeviceProfile.

Dependencies

Precede this node in the flow with an OATH Registration node with its Store device data in shared state setting enabled.

Configuration

This node has no configurable properties.

Outputs

This node doesn’t change the shared state.

Outcomes

Success

The node wrote the device profile to the user’s account.

Failure

Any other case.

Errors

This node logs a No device profile found on shared state error message if it can’t get the device profile from the oathDeviceProfile shared state attribute.

Example

The following journey includes both username-password and one-time passcode authentication:

OATH journey with device registration

OATH Registration node

The OATH Registration node lets the user register a device for OATH-based multi-factor authentication (MFA).

Based on the node settings, the user device displays a QR code that includes all the details required for registration. If registration is successful, the node stores the device data, and recovery codes (if enabled), and sets the skippable attribute to prevent repeat registration at next login.

You can use the Combined MFA Registration node to register a device for both push notifications and one-time passcode (OATH) verification in a single step.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Authenticators

The OATH-related nodes can integrate with the following authenticator apps:

  • The ForgeRock Authenticator app for Android and iOS.

  • Third-party authenticator apps that support the following open standards:

    • RFC 4226: HMAC-Based One-Time Password (HOTP)

    • RFC 6238: Time-Based One-Time Password (TOTP)

Inputs

This node reads the username attribute and optionally the oathDeviceProfile attribute from the shared state.

Dependencies

Confirm the user credentials before letting them register a device. For example, precede this node with the following nodes earlier in the authentication flow:

Properties

Property Usage

Issuer

Specify an identifier to appear on the user’s device, such as a company name, a website, or a realm.

The authenticator application displays the value.

Default: ForgeRock

Account Name

Select the profile attribute to display as the username in the authenticator application.

If not specified, or if the specified profile attribute is empty, their username is used.

Default: Username

Background Color

The background color in hex notation that displays behind the issuer’s logo within the authenticator application.

Default: 032b75

Logo Image URL

The location of an image to download and display as the issuer’s logo within the authenticator application.

The ForgeRock Authenticator supports logos in JPEG and PNG format only. The application resizes your logo automatically, but a maximum image size of one MByte (or 1024 X 1024 pixels) is recommended.

Default: none

Generate Recovery Codes

If enabled, recovery codes are generated and stored in the successful outcome’s transient state.

Use the Recovery Code Display node to display the codes to the user for safekeeping.

Default: true

QR code message

A custom, localized message with instructions to scan the QR code to register the device.

  1. Click Add.

  2. Enter the message locale in the Key field. For example, en-gb.

  3. Enter the message to display to the user in the Value field.

Default: none

One Time Password Length

The length of the generated OTP in digits.

This value must be at least 6. It must also be compatible with the hardware/software OTP generators you expect end users to use. For example, Google and ForgeRock authenticators support values of 6 and 8 respectively.

Default: 6

Minimum Secret Key Length

Number of hexadecimal characters allowed for the secret key.

Default: 32

OATH Algorithm

Specify the algorithm the device uses to generate the OTP:

HOTP

HOTP uses a counter; the counter increments every time a new OTP is generated. When you use this setting, also set the same value in the OATH Token Verifier node.

TOTP

TOTP generates a new OTP every few seconds as specified by the TOTP Time Step Interval setting.

Default: TOTP

TOTP Time Step Interval

The length of time that an OTP is valid in seconds.

For example, if the time step interval is 30 seconds, a new OTP is generated every 30 seconds and is valid for 30 seconds only.

Default: 30 seconds

TOTP Hash Algorithm

The HMAC hash algorithm used to generate the OTP codes. PingOne Advanced Identity Cloud supports SHA1, SHA256, and SHA512.

Default: SHA1

HOTP Checksum Digit

This adds a digit to the end of the OTP generated to be used as a checksum to verify the OTP was generated correctly. This is in addition to the actual password length.

Only set this if the user devices support it.

Default: false

HOTP Truncation Offset

This is an option used by the HOTP algorithm that not all devices support. Leave the default value unless you know user devices use an offset.

Default: -1

Store device data in shared state

If enabled, the device data isn’t stored in the user profile on successful completion of the node. Instead, the node adds the device data as a base64-encoded string to the oathDeviceProfile property in the shared node state. This string is decoded as an unescaped plain string representation of a JSON object. For example:

In the shared node state:

oathDeviceProfile="eyAidXVpZCI6ICJhNDhiMjUyMS0xYzliLTRiYTct...ja0RyaWZ0U2Vjb25kcyI6IDAgfQ"

Decoded value:

{
  "uuid": "a48b2521-1c9b-4ba7-a45c-8dd855c7397c",
  "recoveryCodes": [],
  "sharedSecret": "0CF9910A24CAF84E81CEBA71C2086DE4",
  "deviceName": "OATH Device",
  "lastLogin": 0,
  "counter": 0,
  "checksumDigit": false,
  "truncationOffset": -1,
  "clockDriftSeconds": 0
}

Use the OATH Device Storage node to store the device data in the user profile instead.

Default: false

Outputs

If the Store device data in shared state setting is enabled, this node records the device profile in the oathDeviceProfile shared state attribute.

If the Generate Recovery Codes setting is enabled, this node records the recovery codes in the oathEnableRecoveryCode shared state attribute.

Outcomes

Success

Device registration succeeded.

Failure

Any other case.

Errors

This node logs the following error messages:

No username found.

The node failed to read the username from the shared state.

No device profile found on shared state

The node failed to read the device profile from the shared state.

Example

The following journey includes both username-password and one-time passcode authentication:

OATH journey with device registration

OATH Token Verifier node

The OATH Token Verifier node requests and verifies a one-time passcode (OTP) generated by a device such as a mobile phone.

The default configuration is time-based OTP (TOTP), but the node also supports HMAC (HOTP).

The node requires prior authentication and a device registered with an OATH Registration node.

You can use the OATH nodes in conjunction with the ForgeRock Authenticator application to register your device, receive notifications, and generate one-time passwords.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Authenticators

The OATH-related nodes can integrate with the following authenticator apps:

  • The ForgeRock Authenticator app for Android and iOS.

  • Third-party authenticator apps that support the following open standards:

    • RFC 4226: HMAC-Based One-Time Password (HOTP)

    • RFC 6238: Time-Based One-Time Password (TOTP)

Inputs

This node reads the username attribute from the shared state.

Dependencies

Confirm the user credentials before letting them authenticate with a device. For example, precede this node with the following nodes earlier in the authentication flow:

Configuration

Property Usage

OATH Algorithm

Specify the algorithm the device uses to generate the OTP:

HOTP

HOTP uses a counter; the counter increments every time a new OTP is generated. When you use this setting, also set the same value in the OATH Registration node.

TOTP

TOTP generates a new OTP every few seconds as specified by the TOTP Time Step Interval setting.

Default: TOTP

HOTP Window Size

Specify how much the OTP device and the server counter can be out of sync.

For example, if the window size is 100 and the server’s last successful login was at counter value 2, the server accepts an OTP that is generated between counter 3 and 102.

Default: 100

TOTP Time Step Interval

The length of time an OTP is valid in seconds.

For example, if the time step interval is 30 seconds, a new OTP is generated every 30 seconds and is valid for 30 seconds only.

Default: 30 seconds

TOTP Time Steps

Specify how many time steps the OTP can be out of sync.

This applies to codes generated before or after the current code. For example, with a time step of 1, the server accepts the previous, current, and next codes.

Default: 2

TOTP Hash Algorithm

The HMAC hash algorithm used to generate the OTP codes. The ForgeRock Authenticator application supports SHA1, SHA256, and SHA512.

Default: SHA1

TOTP Maximum Allowed Clock Drift

Specify how many time steps the authenticator application can be out of sync with the server before manual resynchronization is required.

For example, with TOTP Time Steps of 3 and a TOTP Time Step Interval of 30 (seconds), the server treats codes up to 90 seconds from the current time as belonging to the current time step.

The drift for a user’s device is calculated each time they enter a new code. If the drift exceeds this value, the outcome is Failure.

Default: 5

Allow recovery codes

If enabled, lets users provide a recovery code to authenticate.

Default: false

Outputs

If the outcome is Not registered, this node sets "mfaMethod": "oath" in the shared state

Outcomes

Success

The user has a registered device and the token code was verified.

Failure

The user was not authenticated, or the collected token code can’t be verified.

Not registered

The user account has no registered device profiles.

Recovery Code

Allow recovery codes is enabled, and the user chose to provide a recovery code.

Errors

If this node cannot read the username from the shared state, it logs an error message: Expected username to be set.

If processing raises an exception, this node logs the detail as an error message.

Example

The following journey includes both username-password and one-time passcode authentication:

OATH journey with device registration

Opt-out Multi-Factor Authentication node

Sets the skippable attribute in the user’s profile, which lets them skip MFA.

The node requires the username of the identity to update, and the type of MFA device. For example, you can use a Platform Username node and a Push Sender node earlier in the flow to obtain these.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Evaluation continues along the single outcome path after setting the MFA device as skippable in the user’s profile.

Properties

This node has no configurable properties.

OTP Collector Decision node

Requests and verifies one-time passwords.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Evaluation continues along the True outcome path if the one-time passcode is valid; otherwise, evaluation continues along the False outcome path.

Properties

Property Usage

One Time Password Validity Length

Specify the length of time, in minutes, that a one-time passcode remains valid.

Default: 5

OTP Email Sender node

The OTP Email Sender node sends an email containing a generated one-time passcode (OTP) to the user.

Send mail requests time out after 10 seconds.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Prerequisites

  • The node requires a configured email provider.

Inputs

This node requires the following input from the shared state:

  • The authenticating user’s ID. The node queries the user’s entry for an email address.

    Implement an Attribute Collector node node before this node to obtain the user’s ID.

  • The OTP stored in the oneTimePassword transient state property.

    Implement the HOTP Generator node before this node in the journey to obtain the OTP.

Configuration

Property Usage

Mail Server Host Name (required)

The hostname of the SMTP email server.

Mail Server Host Port

The outgoing mail server port.

Common ports are 25, 465 for SSL/TLS, or 587 for StartTLS.

Mail Server Authentication Username

The username PingOne Advanced Identity Cloud uses to connect to the mail server.

Mail Server Authentication Password

The password PingOne Advanced Identity Cloud uses to connect to the mail server.

This property is deprecated. Use the Mail Server Secret Label Identifier instead.

If you set a Mail Server Secret Label Identifier, this password is ignored.

Mail Server Secret Label Identifier

An identifier used to create a secret label for mapping to a secret in a secret store.

PingOne Advanced Identity Cloud uses this identifier to create a specific secret label for this node. The secret label takes the form am.authentication.nodes.otp.mail.identifier.password where identifier is the value of Mail Server Secret Label Identifier. The identifier can only contain alphanumeric characters a-z, A-Z, 0-9, and periods (.). It can’t start or end with a period.

If you set a Mail Server Secret Label Identifier and PingOne Advanced Identity Cloud finds a matching secret in a secret store, the Mail Server Authentication Password is ignored.

Email From Address (required)

The email address from which the OTP will appear to have been sent.

Email Attribute Name

The attribute in the user profile that contains the email address to which the email with the OTP is sent.

Default: mail

The subject of the email

Click Add to add a new email subject. Enter the locale, such as en-uk, in the Key field and the subject in the Value field. Repeat these steps for each locale that you support.

The content of the email

Click Add to add the content of the email. Enter the locale, such as en-uk, in the Key field and the email content in the Value field. Repeat these steps for each locale that you support.

Mail Server Secure Connection

Set the connection method to the mail server.

If you set a secure method here, PingOne Advanced Identity Cloud must trust the server certificate of the mail server.

The possible values for this property are:

  • NON SSL/TLS

  • SSL/TLS

  • Start TLS

Default: SSL/TLS

Gateway Implementation Class

The class the node uses to send SMS and email messages.

Default: com.sun.identity.authentication.modules.hotp.DefaultSMSGatewayImpl

Outputs

This node copies shared and transient state into the outgoing node state.

Errors

The node throws an IdRepoException and an SSOException error if it’s unable to obtain the user’s email address.

Outcomes

Single outcome path.

Implement an OTP Collector Decision node after this node to continue the authentication journey.

Example

journey otp email sender

OTP SMS Sender node

The OTP SMS Sender node uses an email-to-SMS gateway provider to send an SMS message containing a generated one-time password (OTP) to the user.

The node sends an email to an address formed by joining the following values together:

  • The user’s telephone number, obtained by querying a specified profile attribute, for example, telephoneNumber.

  • The @ character.

  • The email-to-SMS gateway domain, obtained by querying the profile attribute specified by the Mobile Carrier Attribute Name property.

For example, if configured to use the TextMagic email-to-SMS service, the node might send an email through the specified SMTP server to the address: 18005550187@textmagic.com.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Prerequisites

  • The node requires a configured email-to-SMS gateway provider.

Inputs

This node requires the following input from the shared state:

  • The authenticating user’s ID. The node queries the user’s entry for a telephone number.

    Implement an Attribute Collector node node before this node to obtain the user’s ID.

  • The OTP stored in the oneTimePassword transient state property.

    Implement the HOTP Generator node before this node in the journey to obtain the OTP.

Configuration

Property Usage

Mail Server Host Name (required)

The hostname of the SMTP email server.

Mail Server Host Port

The outgoing mail server port.

Common ports are 25, 465 for SSL/TLS, or 587 for StartTLS.

Mail Server Authentication Username

The username PingOne Advanced Identity Cloud uses to connect to the mail server.

Mail Server Authentication Password

The password PingOne Advanced Identity Cloud uses to connect to the mail server.

This property is deprecated. Use the Mail Server Secret Label Identifier instead.

If you set a Mail Server Secret Label Identifier, this password is ignored.

Mail Server Secret Label Identifier

An identifier used to create a secret label for mapping to a secret in a secret store.

PingOne Advanced Identity Cloud uses this identifier to create a specific secret label for this node. The secret label takes the form am.authentication.nodes.otp.sms.identifier.password where identifier is the value of Mail Server Secret Label Identifier. The identifier can only contain alphanumeric characters a-z, A-Z, 0-9, and periods (.). It can’t start or end with a period.

If you set a Mail Server Secret Label Identifier and PingOne Advanced Identity Cloud finds a matching secret in a secret store, the Mail Server Authentication Password is ignored.

Email From Address (required)

The email address from which the OTP will appear to have been sent.

Mobile Phone Number Attribute Name

The attribute in the user profile that contains the mobile phone number to which the SMS with the OTP is sent.

Default: telephoneNumber

Mobile Carrier Attribute Name

The attribute in the user profile that contains the mobile carrier domain for sending SMS messages.

By default, an PingOne Advanced Identity Cloud user profile doesn’t have an attribute for the mobile carrier domain.

You can customize the user profile by adding a new attribute to it, then populate that attribute with users' SMS messaging domains.

All mobile carriers and bulk SMS messaging services have associated SMS messaging domains. For example, Verizon uses vtext.com, T-Mobile uses tmomail.net, and the TextMagic service uses textmagic.com. If you plan to send text messages internationally, determine whether the messaging service requires a country code.

If you leave the Mobile Carrier Attribute Name property empty, PingOne Advanced Identity Cloud defaults to sending SMS messages using txt.att.net for all users.

The subject of the message

Click Add to add a new message subject. Enter the locale, such as en-uk, in the Key field and the subject in the Value field. Repeat these steps for each locale that you support.

The content of the message

Click Add to add the content of the message. Enter the locale, such as en-uk, in the Key field and the email content in the Value field. Repeat these steps for each locale that you support.

Mail Server Secure Connection

Set the connection method to the mail server.

If you set a secure method here, PingOne Advanced Identity Cloud must trust the server certificate of the mail server.

The possible values for this property are:

  • NON SSL/TLS

  • SSL/TLS

  • Start TLS

Default: SSL/TLS

Gateway Implementation Class

The class the node uses to send SMS and email messages.

Default: com.sun.identity.authentication.modules.hotp.DefaultSMSGatewayImpl

Outputs

This node copies shared and transient state into the outgoing node state.

Errors

The node throws an IdRepoException and an SSOException error if it’s unable to obtain the user’s telephone number.

Outcomes

Single outcome path.

Implement an OTP Collector Decision node after this node to continue the authentication journey.

Example

journey otp sms sender

Push Registration node

Provides a way to register a device, such as a mobile phone for multi-factor authentication using push notifications.

The node requires the username of the identity to update. For example, by using a Platform Username node.

You can use the Combined MFA Registration node to register a device for use with both push notifications and one-time passcode (OATH) verification in a single step.

You must also configure the Push Notification Service.

For information on provisioning the credentials required by the Push Notification Service, refer to How To Configure Service Credentials (Push Auth, Docker) in Backstage in the ForgeRock Knowledge Base.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Authenticators

The push-related nodes integrate with the ForgeRock Authenticator app for Android and iOS.

Third-party authenticator apps are not compatible with ForgeRock’s push notification functionality.

Outcomes

  • Success

  • Failure

  • Time Out

If the user successfully registers their authenticator, evaluation continues along the Success outcome path.

If the node does not receive a response from the user’s device within the time specified in the node configuration, evaluation continues along the Time Out outcome path.

If AM encounters an issue when attempting to register using a device, evaluation continues along the Failure outcome path.

Properties

Property Usage

Issuer

Specify an identifier so that the user knows which service their account relates to.

The value is displayed by the authenticator application:

The icons represent supported authentication factors supported.

For example, Example Inc. or the name of your application.

Account Name

Specifies the profile attribute to display as the username in the authenticator application.

If not specified, or if the specified profile attribute is empty, their username is used.

Registration Response Timeout

Specify the number of seconds to wait for a response from the authenticator.

If the specified time is reached, evaluation continues along the Time Out outcome path.

Background Color

Specifies the background color, in hex notation, to display behind the issuer’s logo within the ForgeRock Authenticator application.

Logo Image URL

Specifies the location of an image to download and display as the issuer’s logo in the ForgeRock Authenticator application.

Generate Recovery Codes

Specify whether push-specific recovery codes should be generated. If enabled, recovery codes are generated and stored in transient state if registration was successful.

Use the Recovery Code Display node to display the codes to the user for safe keeping.

Generating recovery codes overwrites all existing push-specific recovery codes.

Only the most recent set of recovery codes can be used for authentication if a device has been lost or stolen.

QR code message

The message with instructions to scan the QR code to register the device.

Click Add. Enter the message locale in the Key field. For example, en-gb. Enter the message to display to the user in the Value field.

Example

Refer to the Push authentication example journey for how to use the Push Registration node in a journey handling push devices.

Push Result Verifier node

Works with the Push Sender node to validate the user’s response to a previously sent push notification message.

If the push message contained any additional information, for example, if it was a registration request, the values are stored in the nodeState object on the pushContent key.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Authenticators

The push-related nodes integrate with the ForgeRock Authenticator app for Android and iOS.

Third-party authenticator apps are not compatible with ForgeRock’s push notification functionality.

Outcomes

  • Success

  • Failure

  • Expired

  • Waiting

Evaluation continues along the Success outcome path if the push notification was approved by the user.

Evaluation continues along the Failure outcome path if the push notification was rejected by the user.

If no response to the push notification was received within the Message Timeout value specified in the Push Sender node, evaluation continues along the Expired outcome path.

If no response to the push notification has been received yet, evaluation continues along the Waiting outcome path.

Properties

This node has no configurable properties.

Push Sender node

Sends push notification messages to a device for multi-factor authentication.

Configure the AM Push Notification Service for the realm before using this node.

For information on provisioning the credentials used by the service, refer to How To Configure Service Credentials (Push Auth, Docker) in Backstage in the ForgeRock Knowledge Base.

To determine whether the user has a registered device, the flow must have included the username in the shared state, for example, by using a Platform Username node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Authenticators

The push-related nodes integrate with the ForgeRock Authenticator app for Android and iOS.

Third-party authenticator apps are not compatible with ForgeRock’s push notification functionality.

Outcomes

  • Sent

  • Not Registered

  • Skipped

  • Failure

Evaluation continues along the Sent outcome path if the push notification was successfully sent to the handling service.

If the user doesn’t have a registered device, evaluation continues along the Not Registered outcome path.

If the user chooses to skip push authentication, evaluation continues along the Skipped outcome path.

The node displays the Failure outcome only if you enable the Capture failure configuration option. In this case, evaluation proceeds along the Failure path if there’s an error during execution of the node.

Properties

Property Usage

Message Timeout

Specifies the number of milliseconds the push notification message will remain valid. The Push Result Verifier node rejects responses to push messages that have timed out.

User Message

Specifies the optional message to send to the user.

You can provide the message in multiple languages by specifying the locale in the KEY field. For example, en-US.

The locale selected for display is based on the user’s locale settings in their browser.

Messages provided in the node override the defaults provided by AM.

The following variables can be used in the VALUE field:

{{user}}

Replaced with the username value of the account registered in the ForgeRock Authenticator application, for example Demo.

{{issuer}}

Replaced with the issuer value of the account registered in the ForgeRock Authenticator application, for example, ForgeRock.

Example: Login attempt from {{user}} at {{issuer}}.

Remove 'skip' option

Enable this option in the node to make the push authentication mandatory.

When disabled, the user can skip the push authentication requested by the node, and evaluation continues along the Skipped outcome path.

Default: Disabled

Share Context info

If enabled, context data such as remoteIp, userAgent, and location are included in the notification payload.

For example:

{
  "location": {
    "latitude": 49.2208569,
    "longitude": -123.1174431
  },
  "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36",
  "remoteIp": "9.9.9.9"
}

The ForgeRock Authenticator displays this additional information to the user to help verify that the request is genuine and initiated by them.

Challenge code
Figure 1. Context information in the ForgeRock Authenticator

For the location attribute to be set, the flow must contain a Device Profile Collector node with Collect Device Location enabled.

Custom Payload Attributes

Specify shared state objects to be included in the message payload sent to the client. The size of the payload must not exceed 3 Kb or a NodeProcessException is thrown.

To add a custom attribute, enter the shared state object name in the text field and click Add. Repeat for each object you want to include in the payload.

Push Type

Select the type of the push authentication the user must perform on their device to continue the journey.

Possible values are:

Tap to Accept (default)

Requires the user to tap to accept.

Display Challenge Code

Requires the user to select one of three numbers displayed on their device. This selected number must match the code displayed in the browser for the request to be verified.

Use Biometrics to Accept

Requires the user’s biometric authentication to process the notification.

The actions the user performs vary depending on the selected option. Refer to Respond to push notifications.

Capture failure (optional)

If enabled, and the node fails to send the Push Notification, the journey skips the node. The journey stores the reason for the failure in the PushAuthFailureReason key in the shared state for use by subsequent nodes in the journey.

Possible failure reasons include MISSING_USERNAME, SENDER_ALREADY_USED, CTS_ERROR, and TRANSMISSION_FAILURE.

Example

The following example shows one possible implementation of multi-factor push authentication:

Multi-factor push authentication
Node connections
Table 1. List of node connections
Source node Outcome path Target node

Page Node containing:

Platform Username, Platform Password

Data Store Decision

Data Store Decision

True

Push Sender

False

Failure

Push Sender

Sent

Push Wait

Not Registered

MFA Registration Options

Push Wait

Done

Push Result Verifier

Exit

Recovery Code Collector Decision

Push Result Verifier

Success

Success

Failure

Failure

Expired

Push Sender

Waiting

Push Wait

MFA Registration Options

Register

Push Registration

Get App

Get Authenticator App

Skip

Success

Opt-out

Opt-out Multi-Factor Authentication

Recovery Code Collector Decision

True

Success

False

Retry Limit Decision

Push Registration

Success

Recovery Code Display Node

Failure

Failure

Time Out

MFA Registration Options

Get Authenticator App

MFA Registration Options

Opt-out Multi-Factor Authentication

Success

Retry Limit Decision

Retry

Recovery Code Collector Decision

Reject

Failure

Recovery Code Display Node

Push Sender

After verifying the user’s credentials, evaluation continues to the Push Sender node.

If the user has a registered device:

  1. AM sends a push to their registered device.

  2. The Push Wait node pauses authentication for 5 seconds, during which time the user can respond to the push notification on their device; for example, by using the ForgeRock Authenticator application.

    • If the user responds positively, they are authenticated successfully and logged in.

    • If the user responds negatively, they are not authenticated successfully and do not receive a session.

    • If the push notification expires, AM sends a new push notification.

      Use a Retry Limit Decision node to constrain the number of times a new code is sent.
    • If the user has not yet responded, the flow loops back a step and the Push Wait node pauses authentication for another 5 seconds.

    If the user exits the Push Wait node, they can enter a recovery code in order to authenticate.

    For this situation, configure the Exit Message property in the Push Wait node with a message, such as Lost phone? Use a recovery code.

A Retry Limit Decision node allows three attempts at entering a recovery code before failing the authentication.

If the user does not have a registered device:

  1. The MFA Registration Options node presents the user with the following options:

    Register Device

    The flow continues to the Push Registration node, which displays the QR code that should be scanned with a suitable authenticator application.

    Get the App

    The flow continues to the Get Authenticator App node, which displays the links needed to obtain a suitable application, such as the ForgeRock Authenticator.

    Skip this step

    Displayed only if the node configuration lets the user skip. In this example, skipping is linked to the Success outcome. Alternatively, an Inner Tree Evaluator node could have been used for authentication.

    Opt-out

    Displayed only if the node configuration allows the user to skip or opt out. Evaluation continues to the Opt-out Multi-Factor Authentication node, which updates the user’s profile to skip MFA with push in the future. In this example, after updating the profile the flow continues to the Success node.

  2. The user registers the device with the Push Registration node.

    After registration, the recovery codes are displayed to the user for safekeeping, and evaluation continues with the Push Sender node to start push notification.

To manage push devices, the user must log in using either the device or a recovery code.

Learn more in Manage devices for MFA.

Respond to push notifications

The default Push Type setting is Tap to Accept. This requires the user to tap to either Accept or Reject in the ForgeRock Authenticator.

Tap to Accept
Figure 2. Tap to Accept (Default)

Research shows that users might accept a push authentication without fully checking if it is legitimate. To reduce the chances of a user accepting a malicious push authentication attempt, you can configure two additional push types:

Display Challenge Code

Requires the user to select one of three numbers displayed on their device. This selected number must match the code displayed in the browser for the request to be verified.

Challenge code
Figure 3. Challenge code
Use Biometrics to Accept

Requires the user’s biometric authentication to process the notification, after tapping Accept or Reject.

Biometric authentication required
Figure 4. Biometric authentication required

Push Wait node

Pauses the authentication for the specified number of seconds during the processing of a push authentication request.

When push authentication involves a number selection challenge, where the push type of the Push Sender node is set to Display Challenge Code, the node displays the code challenge for the user to complete. Connect this node to a Push Result Verifier node to check the result of the code challenge.

Both nodes' waiting times and the messages are configurable.

The message displayed on the exit button can be configured using the Exit Message property.

To provide localized versions of the waiting, push challenge, and exit messages in multiple languages, configure the message properties to specify the locale in the KEY field (for example, en-US) and the message in the VALUE field. The locale selected for display is based on the user’s locale settings in their browser.

Messages provided in the node override the defaults provided by AM.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Authenticators

The push-related nodes integrate with the ForgeRock Authenticator app for Android and iOS.

Third-party authenticator apps are not compatible with ForgeRock’s push notification functionality.

Outcomes

  • Done

  • Exit

Evaluation continues along the Done outcome path after the wait time has passed. Evaluation continues along the Exit outcome path if the user clicks the exit button.

Properties

Property Usage

Seconds To Wait

Specify the number of seconds to pause authentication.

Default: 5

Waiting Message

Customize the message to display to the user. To include the remaining seconds in the message, use the {{time}} variable.

Click Add to enter a KEY and VALUE for a localized message and + to save. Repeat for each supported language.

Default: Waiting for response…​

Push Challenge Message

Customize the message containing the challenge code. To include the number challenge, use the {{challenge}} variable.

Click Add to enter a KEY and VALUE for a localized message and + to save. Repeat for each supported language.

Default: Tap the number [{{challenge}}] on the Push Notification to continue.

Exit Message

Customize the message to display to the user when they choose to exit the node before the wait period has elapsed. The message is displayed as a link.

Click Add to enter a KEY and VALUE for a localized message and + to save. Repeat for each supported language.

Default: Cancel

Example

Refer to the Push authentication example journey for how to use the Push Wait node in a journey handling push devices.

Recovery Code Collector Decision node

Lets users authenticate with a recovery code provided when registering a device for multi-factor authentication.

Use this node for a flow that includes push notifications or one-time passwords. When the user loses their registered device, they can use a recovery code as an alternative method for authentication. For more information on viewing the recovery codes when registering a device, refer to Register the ForgeRock Authenticator for multi-factor authentication.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Evaluation continues along the True outcome path if the provided recovery code matches one belonging to the user. To determine whether the provided code belongs to the user, the shared state must include the username. You can obtain this using a Platform Username node.

If the recovery code does not match, or a username has not been acquired, evaluation continues along the False outcome path.

Properties

Property Usage

Recovery Code Type

Specify the type of recovery code the user will submit for verification.

Default: OATH

Recovery Code Display node

Retrieves generated recovery codes from the transient state and presents them to the user, for safe-keeping. The codes can be used to authenticate if a registered device is lost or stolen.

Generated recovery codes are inserted into transient state when evaluation continues along the Success outcome path of the MFA nodes configured to generate recovery codes. Connect this node to the Success outcome path to display the codes.

If no recovery codes are available in transient state, evaluation continues along the only outcome path, and nothing is displayed to the user.

Generated recovery codes cannot be retrieved from the user’s profile—​they are one-way encrypted.

This node is the one and only opportunity to view and save the recovery codes.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

This node has no configurable properties.

WebAuthn Authentication node

The WebAuthn Authentication node lets users on supported clients authenticate using a registered FIDO device.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

  • This node requires a username in the incoming node state to assess whether the user has a registered device.

    Implement the Platform Username node as an input to the WebAuthn Authentication node.

  • Optionally, this node can read the contents of the webAuthnExtensions shared state property as input.

    You can populate the webAuthnExtensions property with any JSON object you choose using a script or in a node that occurs earlier in the journey. If this property is populated, its contents are placed in the extensions entry passed to the browser or authenticator. If this property is empty, an empty JSON object is passed to the browser or authenticator.

    You can find more information on WebAuthn extensions in WebAuthn Extensions.

Prerequisites

For successful authentication, this node depends on:

  • A client that supports web authentication

  • A registered FIDO device

Configuration

Property Usage

Relying party identifier

The domain used as the relying party identifier during web authentication. This is the domain against which to register the device. If you leave this field blank, it defaults to the domain name of your tenant, for example, openam-example.forgeblocks.com.

Origin domains

A list of fully qualified URLs to accept as the origin of the incoming request.

If this field is empty, the accepted origin is the incoming request origin.

User verification requirement

The required user verification level.

The available options are:

REQUIRED

The authenticator used must verify the user’s identity, for example, by using biometrics. Authenticators that don’t verify the user’s identity are filtered out and can’t be selected by the user.

PREFERRED

If multiple authenticators are presented, PingOne Advanced Identity Cloud prefers those that verify the user’s identity. If none are available, PingOne Advanced Identity Cloud accepts any authenticator.

DISCOURAGED

PingOne Advanced Identity Cloud doesn’t require an authenticator that verifies the user’s identity. Authenticators that don’t verify the user’s identity are preferred.

Allow recovery codes

If you select this option, PingOne Advanced Identity Cloud lets the user enter a recovery code instead of performing an authentication gesture.

Enabling this options adds a Recovery Code outcome path to the node. The outcome path should lead to a Recovery Code Collector Decision node to collect and verify the recovery code.

Timeout

The number of seconds to wait for a valid WebAuthn authenticator to be registered before failing.

If the specified timeout is reached, evaluation continues along the Client error outcome path. PingOne Advanced Identity Cloud stores a message in the WebAuthenticationDOMException property of the shared state.

Username from device

Specifies whether PingOne Advanced Identity Cloud should get the username from the device.

If you enable this option and the device is unable to store or provide usernames, the node fails and evaluation continues along the Failure path.

You can find information on using this property for usernameless authentication with ForgeRock Go in Configure usernameless authentication with ForgeRock Go.

Return challenge as JavaScript

If you enable this option, the node returns its challenge as a fully encapsulated client-side JavaScript that interacts directly with the WebAuthn API and submit the response back.

If this option is disabled, the node returns the challenge and associated data in a metadata callback. A custom UI, such as an application using the Ping SDKs, uses the information from the callback to interact with the WebAuthn API on PingOne Advanced Identity Cloud’s behalf.

Detect sign count mismatch

If you enable this option, the node compares the authenticator’s sign count (signature counter) with the sign count stored in the user’s profile. If the authenticator sign count is less than or equal to the stored value, evaluation continues to the Sign Count Mismatch outcome.

Outcomes

Unsupported

If the user’s client doesn’t support web authentication, evaluation continues along the Unsupported outcome path. For example, clients connected over the HTTP protocol rather than HTTPS don’t support WebAuthn; however, HTTPS may not be required when testing locally on http://localhost. Learn more in Is origin potentially trustworthy?.

No Device Registered

If the user doesn’t have a registered device, evaluation continues along the No Device Registered outcome path.

Success

If the user successfully authenticates with a device of the type determined by the User verification requirement property, evaluation continues along the Success outcome path.

Failure

If the node encounters an issue when attempting to authenticate the user with the device, evaluation continues along the Failure outcome path; for example, if the node can’t verify that the response from the authenticator was appropriate for the specific instance of the authentication journey.

Client Error

If the user’s client encounters an issue when attempting to authenticate using the device, for example, if the timeout was reached, evaluation continues along the Client Error outcome path.

The journey takes this path whenever the client throws a DOMException, as required by the Web Authentication: An API for accessing Public Key Credentials Level 1 specification.

Recovery Code

If Allow recovery code is enabled, the node gives the user an option to enter a recovery code rather than authenticate using a device. If the user enters a recovery code, evaluation continues along the Recovery Code outcome path.

This outcome path must lead to a Recovery Code Collector Decision node to let PingOne Advanced Identity Cloud accept and verify the recovery code.

Sign Count Mismatch

If Detect sign count mismatch is enabled and the authenticator sign count is less than or equal to the value stored in the user’s profile, evaluation continues to the Sign Count Mismatch outcome.

This outcome can help to detect cloned or malfunctioning authenticators. A sign count mismatch doesn’t necessarily indicate that the operation was performed by a cloned authenticator. Address this situation appropriately for your deployment, for example, by using a scripted decision node.

The node itself is considered to have succeeded even if evaluation leads to this outcome. Therefore, if it suits your deployment, you can design your journey to continue through this outcome.

Outputs

If a client error occurs, the node adds the error type and description to a property named WebAuthenticationDOMException in the shared state. Other nodes can read this property later in the journey, if required.

The contents of the transient state for this node aren’t public. Don’t rely on them in your scripts.

Example

This example shows one possible implementation of the flow for authenticating with WebAuthn devices:

Example WebAuthn authentication journey

After verifying the users credentials against the configured data store, evaluation continues to the WebAuthn Authentication node.

If the user’s client doesn’t support WebAuthn, authentication fails and the user doesn’t get a session. A more user-friendly approach would be to set a success URL to redirect the user to a page explaining the benefits of multi-factor authentication, and then proceeding to the Success node.

If there are no registered WebAuthn devices present in the user’s profile, the failure URL is set, pointing to a flow that lets the user register a device. This stage could also be an Inner Tree Evaluator node.

If the user’s client supports WebAuthn, and the connection is secured with TLS, the user is prompted to complete an authorization gesture, for example, scanning a fingerprint, or entering a PIN:

trees-node-webauthn-waiting

The user’s browser may present a consent pop-up to allow access to the authenticators available on the client. When consent has been granted, the browser activates the relevant authenticators, ready for authentication.

The relying party details configured in the node are often included in the consent message to help the user verify the entity requesting access.

The authenticators the client activates for authentication depend on the value of the properties in the node. For example, if the User verification requirement property is set to REQUIRED, the client SHOULD only activate authenticators that verify the identity of the user.

For extra protection, PingOne Advanced Identity Cloud WILL verify that the response from an authenticator matches the criteria configured for the node, and will reject an authentication attempt by an inappropriate authenticator type by routing it to the Failure outcome.

When the user completes an authorization gesture, for example, by scanning a fingerprint or entering a PIN, evaluation continues along the Success outcome path. In this example, their authentication level is increased by ten to signify the stronger authentication that has occurred, and the user is taken to their profile page.

If the user clicks the Use Recovery Code button, evaluation continues to the Recovery Code Collector Decision node, ready to accept the recovery code. If verified, the user is taken to their profile page.

Any problems encountered during authentication lead to the Failure outcome, including a timeout, or to the Client Error outcome, resulting in an authentication failure.

WebAuthn Device Storage node

Writes information about FIDO2 devices to a user’s profile. The user can subsequently authenticate using the device.

Use this node to store the device data the WebAuthn Registration node places into the transient node state when its Store device data in transient state property is enabled.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Success

  • Failure

  • Exceed Device Limit

If AM encounters an issue when attempting to save the device data to the user’s profile; for example, the user was not identified earlier, then evaluation continues along the Failure outcome path.

If the Maximum Saved Devices property is set to an integer greater than zero, and registering a new device would take the number of devices above the specified threshold, then evaluation continues down the Exceed Device Limit outcome path. In this case, you may need to instruct your users to log in with an existing device in order to remove one or more of their registered devices.

If the node successfully stores the device data to the user’s profile, evaluation continues along the Success outcome path.

Properties

Property Usage

Generate recovery codes

Specify whether WebAuthn device recovery codes should be generated.

If enabled, recovery codes are generated and stored in the transient node state, and stored alongside the device profile.

Use the Recovery Code Display node to display the codes to the user for safe keeping.

Generating recovery codes overwrites all existing WebAuthn device recovery codes for the device.

Only the most recent set of recovery codes can be used for authentication if a device has been lost or stolen.

Maximum Saved Devices

Specify the maximum number of WebAuthn devices to save in a user’s profile.

Set this property to 0 if you do not want to limit the number of devices.

When this property is greater than zero, the Exceed Device Limit outcome path becomes available.

WebAuthn Registration node

The WebAuthn Registration node lets users of supported clients register FIDO2 devices for use during authentication.

PingOne Advanced Identity Cloud interacts with FIDO2/WebAuthn capable browsers, such as Chrome, Firefox and Microsoft Edge.

These browsers interact with the following:

  • Client to Authenticator Protocol 2 (CTAP2) authenticators, including Universal 2nd Factor (U2F) and FIDO2 Security Keys

  • Platforms such as Windows Hello and Apple Touch ID

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

  • This node requires the username and password properties in the incoming node state.

    + Implement the Platform Username node and Platform Password node before this node in the journey.

  • Optionally, this node can read the contents of the webAuthnExtensions shared state property as input.

    You can populate the webAuthnExtensions property with any JSON object you choose using a script or in a node that occurs earlier in the journey. If this property is populated, its contents are placed in the extensions entry passed to the browser or authenticator. If this property is empty, an empty JSON object is passed to the browser or authenticator.

    You can find more information on WebAuthn extensions in WebAuthn Extensions.

Dependencies

You must configure the WebAuthn Profile Encryption service to use this node.

Configuration

Property Usage

Relying party

The name of the relying party entity that registers and authenticates users by using WebAuthn. This could be the name of the organization, realm, and so on.

For example, Example.com

Relying party identifier

The domain used as the relying party identifier during WebAuthn. If not specified, AM uses the domain name of the instance, such as am.example.com.

Specify an alternative domain if your AM instances are behind a load balancer.

Origin domains

A set of fully-qualified URLs of accepted origins, for example http://app.example.com:443. If empty, the accepted origin is the incoming request origin.

User verification requirement

The required level of user verification.

The available options are:

REQUIRED

The authenticator must verify the identity of the user, for example, by using biometrics. PingOne Advanced Identity Cloud filters out authenticators that don’t verify user identity and the user can’t select them.

PREFERRED

PingOne Advanced Identity Cloud prefers an authenticator that verifies user identity. If none are available, PingOne Advanced Identity Cloud accepts any authenticator.

DISCOURAGED

The authenticator doesn’t need to verify the identity of the user. Authenticators that don’t verify user identity are preferred.

Default: PREFERRED

Preferred mode of attestation

Indicates whether the authenticator must provide attestation statements.

The available options are:

NONE

PingOne Advanced Identity Cloud doesn’t require the authenticator to provide attestation statements. If the authenticator sends attestation statements, PingOne Advanced Identity Cloud doesn’t verify them and the process doesn’t fail.

INDIRECT

PingOne Advanced Identity Cloud doesn’t require the authenticator to provide attestation statements. However, if the authenticator sends attestation statements, PingOne Advanced Identity Cloud verifies them and the process fails if the verification fails.

DIRECT

PingOne Advanced Identity Cloud requires the authenticator to provide attestation statements and verifies them. The process fails if the attestation statements can’t be verified.

PingOne Advanced Identity Cloud supports the following attestation formats:

If your end users use an authenticator that provides attestation statements in a format other than these supported formats, you must set the Preferred mode of attestation property to NONE.

Specifically, PingOne Advanced Identity Cloud does not support the Android Key Attestation Statement Format.

Accepted signing algorithms

The algorithms authenticators can use to sign their assertions.

Authentication attachment

If specified, PingOne Advanced Identity Cloud filters out authenticators that don’t match the attachment type.

There are two attachment types:

  • A PLATFORM authenticator is part of the device, for example, a fingerprint scanner built-in to a phone or laptop.

  • A CROSS_PLATFORM authenticator can be removed from a device and used elsewhere, for example, a USB hardware security key.

Available options for this property are:

UNSPECIFIED

PingOne Advanced Identity Cloud accepts any attachment type.

PLATFORM

The authenticator must be a platform attachment type. The client shouldn’t activate other authenticator types for registration.

CROSS_PLATFORM

The authenticator must be a cross-platform attachment type. The client shouldn’t activate other authenticator types for registration.

Trust Store alias

The alias of the realm trust store holding the secrets necessary to validate a supplied attestation certificate. The alias can only contain the characters a-z and periods (.).

This value is appended to the string am.authentication.nodes.webauthn.truststore. to form the dynamic secret label used to map certificate chains.

Enforce revocation check

Whether to enforce the checking of revocation entries from certificates.

If you enable this setting, any attestation certificate’s trust chain must have a CRL or OCSP entry that PingOne Advanced Identity Cloud can verify.

If you disable this setting, PingOne Advanced Identity Cloud doesn’t check presented certificates for revocation.

Certificates downloaded from the FIDO Metadata Service might not have a CRL or OCSP entry. You must remove expired or revoked certificates manually.

Timeout

The number of seconds to wait for a response from an authenticator.

If the specified time is reached, evaluation continues along the Client error outcome path and a relevant message is stored in the WebAuthenticationDOMException property of the shared state.

Limit registrations

Indicates whether the same authenticator can be registered multiple times.

If you enable this property, the client won’t activate an authenticator that’s already registered for registration.

Generate recovery codes

Indicates whether PingOne Advanced Identity Cloud generates WebAuthn-specific recovery codes. If enabled, PingOne Advanced Identity Cloud generates recovery codes and stores them in the transient state if registration is successful.

Use the Recovery Code Display node to display the codes to the user for safe-keeping.

Don’t enable this property if you’ve enabled the Store device data in transient state property (and aren’t saving the device data to the user’s profile immediately). Enable the Generate recovery codes property in the WebAuthn Device Storage node instead.

Generating recovery codes overwrites all existing WebAuthn-specific recovery codes.

Only the most recent set of recovery codes can be used for authentication if a device has been lost or stolen.

Store data in transient state

If you enable this property, the node stores the following data in transient state:

  • Information provided by the device is stored in the webauthnData property for later analysis by subsequent nodes.

  • The attestation type achieved (BASIC, CA, or SELF) is stored in the webauthnAttestationType property.

The amount of data received from the device can be large. Only enable this option if you intend to analyze it.

Store device data in transient state

If you enable this property, information about the device required for WebAuthn is stored in transient state instead of saved immediately to the user’s profile.

Enable this option under the following conditions:

  • You’ve enabled the Store data in transient state property

  • You need to make decisions in scripts based on the outcome of the analysis of data in transient state

  • You don’t want to register the device to the user until the analysis is complete

Don’t change the data while it’s in transient state, nor when it’s saved to a user’s profile.

Changing the device data will likely cause the device to be unable to authenticate.

If you enable this option, use the WebAuthn Device Storage node to write the device data to the user’s profile.

If this option is disabled, device data is written automatically to the user’s profile when registration is successful.

Username to device

This option specifies that the device should store the user’s username.

If you enable this option, devices that don’t support storing and providing the username won’t be able to use this node. If the device can’t store or provide usernames, the node fails and the journey follows the Failure outcome.

You can find information on using this property for usernameless authentication with ForgeRock Go in Configure usernameless authentication with ForgeRock Go.

Shared state attribute for display name

The share state property that contains a display name for the user. For example, their full name, or email address.

When Username to device is enabled, PingOne Advanced Identity Cloud writes the value stored in this property to devices in addition to the username. This helps the user select between the accounts they may have on their devices.

If you don’t set this property, or if the variable isn’t found in shared state, the username is used.

You can find information on using this property for usernameless authentication with ForgeRock Go in Configure usernameless authentication with ForgeRock Go.

Return challenge as JavaScript

If enabled, the node returns its challenge as a fully encapsulated client-side JavaScript that interacts directly with the WebAuthn API and submits the response.

If disabled, the node returns the challenge and associated data in a metadata callback. A custom UI, for example, an application using the Ping SDKs uses the information from the callback to interact with the WebAuthn API on behalf of PingOne Advanced Identity Cloud.

Maximum Saved Devices

The maximum number of WebAuthn devices that can be stored in the user’s profile.

Set this property to 0 if you don’t want to limit the number of devices.

When this property is greater than zero, the Exceed Device Limit outcome path becomes available.

You can only limit the number of devices stored in the user’s profile.

If you enable Store device data in transient state, the node can’t limit the number of devices and the Exceed Device Limit outcome path isn’t displayed.

In this case, specify the maximum number of saved devices in the WebAuthn Device Storage node.

Validate FIDO-U2F attestation AAGUID

If enabled, the node validates the Authenticator Attestation Global Unique Identifier (AAGUID) for any FIDO-U2F attestation type. The AAGUID must be 16 bytes, initialized with all zeros.

Outputs

  • The node passes the contents of the webAuthnExtensions property to the browser or authenticator.

  • If a timeout is reached, or any other client error occurs, the error type and description are added to the WebAuthenticationDOMException shared state property.

  • If Shared state attribute for display name is set, the node writes the username or display name to shared state as a value of the specified property.

  • If Store data in transient state is set, the node writes the following data to transient state:

    • Information provided by the device is stored in the webauthnData property.

    • The attestation type achieved is stored in the webauthnAttestationType property.

Outcomes

Unsupported

If the user’s client doesn’t support WebAuthn, evaluation continues along the Unsupported outcome path. For example, clients connected over the HTTP protocol rather than HTTPS don’t support WebAuthn.

Success

If the user successfully registers an authenticator of the correct type as determined by the node’s properties, evaluation continues along the Success outcome path.

Failure

If PingOne Advanced Identity Cloud encounters an issue when attempting to register a user’s device, evaluation continues along the Failure outcome path. For example, if PingOne Advanced Identity Cloud can’t verify that the response from the authenticator was appropriate for the specific instance of the authentication ceremony.

Client Error

If the user’s client encounters an issue when attempting to register using a device, for example, if the timeout was reached, evaluation continues along the Client Error outcome path. The node follows this outcome whenever the client throws a DOMException, as required by the WebAuthn specification.

If a client error occurs, the error type and description are added to the WebAuthenticationDOMException shared state property. If required, this property can be read by nodes later in the journey.

Exceed Device Limit

If the Maximum Saved Devices property is an integer greater than zero, and registering a new device would take the number of devices above the specified threshold, evaluation continues down the Exceed Device Limit outcome path. In this case, you might need to instruct users to log in with an existing device to remove one or more of their registered devices.

Example

The following sample journey registers WebAuthn devices:

WebAuthn device registration

If the user’s client doesn’t support WebAuthn, the failure URL is altered, for example to redirect the user to a page explaining which clients and operating systems support WebAuthn.

If the user’s client does support WebAuthn, and the connection is secured with TLS, AM prompts the user to register an authenticator:

WebAuthn waiting

The user’s browser may present a consent pop-up to allow access to the authenticators available on the client. When consent has been granted, the browser activates the relevant authenticators, ready for registration.

The relying party details configured in the node are often included in the consent message to help the user verify the entity requesting access.

The authenticators the client activates for registration depend on the value of the properties in the node. For example, if the User verification requirement property is set to REQUIRED, the client would not activate a USB hardware security key for registration.

When the user completes an authorization gesture, for example, by scanning a fingerprint or entering a PIN, the evaluation continues along the Success outcome path, and in this example will be taken to their profile page.

The registered authenticator appears on the user’s dashboard page, with the label New Security Key. To rename the authenticator, click its vertical ellipsis context icon, , and click Rename.

Any problems encountered during the registration, including a timeout, results in the evaluation continuing to the Failure outcome.

Risk management nodes

Account Active Decision node

The Account Active Decision node determines whether the current account is both active and unlocked, and lets the journey make a decision, based on that check.

An account is considered locked under these conditions:

  • The status is inactive.

  • The status is active and a duration lockout is set on the account.

An account is considered unlocked under this condition:

  • The status is active and no duration lockout is set on the account.

The node determines whether the account has been locked through both persistent (physical) lockout and duration lockout. Learn more in Account lockout.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

The node reads the user’s identity from the shared state. Implement a Platform Username node before this node in the journey.

Dependencies

This node has no dependencies.

Configuration

This node has no configurable properties.

Outputs

This node doesn’t write anything to the shared state.

Outcomes

  • True

    The journey follows this outcome path if the account is assessed to be active and unlocked.

  • False

    The journey follows this outcome path if the account is assessed to be inactive or locked.

Errors

If the node cannot read the identity of the account, it throws the following exception:

Failed to get the identity object

Examples

In this simple login journey, authentication fails if the account is assessed to be inactive or locked.

Account active Decision node in a simple login journey

This example uses the following nodes:

  • The Page node prompts the user to input their username and password:

  • The Data Store Decision node uses the username and password to determine whether the account exists.

  • The Account Active Decision node determines whether the account is active and unlocked.

  • If the account is active and unlocked, the Increment Login Count node increments the login count and authentication succeeds.

  • If the account is inactive or locked, the authentication fails.

Account Lockout node

The Account Lockout node locks or unlocks the authenticating user’s account profile.

The node also determines whether the account has been locked through both persistent (physical) lockout and duration lockout. Learn more in Account lockout.

You can also use the Account Active Decision node to check whether the account is locked at any point in the journey.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node requires the username property in the incoming node state. It uses this information to access the account status in the user profile.

It also requires the realm property, which PingOne Advanced Identity Cloud sets by default.

Dependencies

This node depends on the underlying identity service that stores the user profile.

Configuration

Property Usage

Lock Action

Choose whether to LOCK or UNLOCK the authenticating user’s account profile.

Outputs

This node does not change the shared node state.

Outcomes

Single outcome path; the node updates the account status according to the configured Lock Action:

LOCK

The account is inactive and the user cannot authenticate.

UNLOCK

The account is active and the user can authenticate.

Errors

If this node fails to set the account status, it logs a failed to set the user status inactive warning.

This node can also throw exceptions with the following messages:

Message Notes

Could not get a valid username from the context

Failed to read the username from the shared node state

Could not get a valid realm from the context

Failed to read the realm from the shared node state

Could not find the identity based on the information available on context

Failed to find the account profile with this username in this realm

An error occurred when trying to lock out the user account

Failed to update the account status; applies when locking and unlocking the account

Example

The following simple example uses this node with the Retry Limit Decision node to lock an account after the set number of invalid attempts:

Lock an account after too many authentication failures

The Retry Limit Decision node Retry limit (default: 3) defines the number of failed attempts before lockout.

Before using a journey like this in deployment, adapt it to reset the retry count on successful authentication.

Auth Level Decision node

Compares the current authentication level value against a configured value.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Properties

Property Usage

Sufficient Authentication Level

Evaluation continues along the True path if the current authentication level is equal to or greater than this integer; otherwise, the evaluation continues along the False path.

CAPTCHA node

The CAPTCHA node adds CAPTCHA support by verifying the response token received from the CAPTCHA provider and creating a callback for the UI to interact with.

By default, the node is configured for Google’s reCAPTCHA v2.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

This node only supports reCAPTCHA v2 and v3, and hCaptcha.

For Google reCAPTCHA Enterprise support, use the reCAPTCHA Enterprise node.

Inputs

None. This node doesn’t read shared state data.

Dependencies

You need to sign up for access to the reCAPTCHA API to get the API key pair required for configuring the node.

Configuration

Property Usage

CAPTCHA Site Key (required)

The CAPTCHA site key supplied by the CAPTCHA provider when you sign up for access to the API.

CAPTCHA Secret Key

The CAPTCHA secret key supplied by the CAPTCHA provider when you sign up for access to the API.

This property is deprecated and will be removed in a future release. Use the CAPTCHA Secret Label Identifier instead.

If you set a CAPTCHA Secret Label Identifier and PingOne Advanced Identity Cloud finds a matching secret in a secret store, the CAPTCHA Secret Key is ignored.

CAPTCHA Secret Label Identifier

An identifier used to create a secret label for mapping to a secret in a secret store.

PingOne Advanced Identity Cloud uses this identifier to create a specific secret label for this node. The secret label takes the form am.authentication.nodes.captcha.identifier.secret where identifier is the value of CAPTCHA Secret Label Identifier.

The identifier can only contain alphanumeric characters a-z, A-Z, 0-9, and periods (.). It can’t start or end with a period.

If you set a CAPTCHA Secret Label Identifier and PingOne Advanced Identity Cloud finds a matching secret in a secret store, the CAPTCHA Secret Key is ignored.

CAPTCHA Verification URL

The URL used to verify the CAPTCHA submission.

Use https://www.google.com/recaptcha/api/siteverify.

CAPTCHA API URL (required)

The URL of the JavaScript that loads the CAPTCHA widget.

Use https://www.google.com/recaptcha/api.js.

Class of CAPTCHA HTML Element

The class of the HTML element required by the CAPTCHA widget.

Use g-recaptcha.

ReCaptcha V3 node

If you’re using Google reCAPTCHA, specify whether it’s v2 or v3. Turn on for v3.

Score Threshold

If you’re using Google reCAPTCHA v3, enter a score threshold.

The CAPTCHA provider returns a score for each user request, based on observed interaction with your site. CAPTCHA "learns" by observing real site traffic, so scores in a staging environment or in a production deployment that has just been implemented might not be very accurate.

A score of 1.0 is likely a good user interaction, while 0.0 is likely to be a bot.

The threshold you set here determines whether to allow or deny access, based on the score returned by the CAPTCHA provider.

Start with a threshold of 0.5.

Learn more about score thresholds in the Google documentation.

Disable submission until verified

If selected, form submission is disabled until CAPTCHA verification succeeds.

Default: Enabled

Outputs

None.

Outcomes

True

The CAPTCHA response was successfully verified.

False

The CAPTCHA response wasn’t verified or failed verification.

Errors

This node can throw exceptions with the following messages:

  • CAPTCHA response required for verification

  • Unable to verify CAPTCHA response

  • Unable to retrieve state from token response

  • No secret key found

Example

The following journey uses a Page node and a Data Store Decision node to collect and verify the credentials and a CAPTCHA response:

The CAPTCHA node in context

This example uses the following nodes:

reCAPTCHA Enterprise node

The reCAPTCHA Enterprise node adds Google reCAPTCHA Enterprise support to your journeys.

Google reCAPTCHA Enterprise offers improvements over previous versions, including more granular scores, reason codes for events deemed higher risk, Web Application Firewall (WAF) support, and native support for Android and iOS.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes 1

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

1 Currently available only in the rapid release channel.

This node only supports Google reCAPTCHA Enterprise.

For reCAPTCHA v2 and v3 support, and hCaptcha support, use the CAPTCHA node.

Inputs

This node reads an optional CaptchaEnterpriseNode.PAYLOAD variable from shared state.

Use this variable to customize the payload the node sends to the Google reCAPTCHA Enterprise server for assessment.

You can set the value by using a Set State node, or by using a Scripted Decision node, using a script similar to the following:

var username = nodeState.get("username");
var customPayload =
  JSON.parse(`{"userInfo": {"accountId": "${username}"}}`);
sharedState.put("CaptchaEnterpriseNode.PAYLOAD", customPayload);
outcome = "true";

To learn more about the payload, refer to Project Assessments - Event in the Google Developer documentation.

Dependencies

You need to sign up for access to the reCAPTCHA API to get the API key pair required to configure the node.

Configuration

Property Usage

Google Cloud project ID

The ID of the project that has Google reCAPTCHA enabled.

You can get the ID of your project in the Google Cloud console.

For example, my-project-65746-07969469388.

reCAPTCHA Site Key (required)

The ID of the reCAPTCHA key you created in the Google Cloud console.

The key can be for any platform type, Website, Android app, or iOS app.

Sometimes referred to as a key ID in the Google Cloud console and documentation.

reCAPTCHA API key secret identifier

An identifier used to create a secret label for mapping to your Google reCAPTCHA API key in a secret store.

Get or create your API key from the Google Cloud Console under APIs and Services > Credentials.

The secret label takes the form am.authentication.nodes.captchaEnterprise.identifier.secret where identifier is the value of reCAPTCHA API key secret identifier.

The identifier can only contain alphanumeric characters a-z, A-Z, 0-9, and periods (.). It can’t start or end with a period.

Score Threshold

The score threshold for determining if a user is likely to be a real person.

reCAPTCHA scores are between 0.0 and 1.0, with higher scores indicating higher confidence that the user is a real person.

If the returned score is equal to or greater than the threshold the journey continues along the true outcome path.

To learn more, refer to Interpret scores in the Google documentation.

Store reCAPTCHA assessment JSON

Stores the assessment response JSON for future reference within the journey.

The node stores the JSON response in the CaptchaEnterpriseNode.ASSESSMENT_RESULT variable.

Store reCAPTCHA error messages

Stores the error messages for future reference within the journey.

The node stores the error messages in the CaptchaEnterpriseNode.FAILURE variable.

The error consists of an error code and description of the error.

View the possible error codes
  • INVALID_TOKEN

  • INVALID_PROJECT_ID

  • CLIENT_ERROR

  • INVALID_SECRET_KEY

  • VALIDATION_ERROR

  • API_ERROR

  • IO_ERROR

  • UNKNOWN

reCAPTCHA CSS class

A CSS class to apply to the HTML elements reCAPTCHA adds to JavaScript apps.

The default is g-recaptcha.

reCAPTCHA Verification URL

The URL to send the reCAPTCHA to for verification.

Only change this if Google updates the URL used for reCAPTCHA verifications.

The default is https://recaptchaenterprise.googleapis.com/v1.

JavaScript reCAPTCHA API URL

The URL of the JavaScript file containing the reCAPTCHA API.

Only change this if Google releases a new version of the JavaScript reCAPTCHA API.

The default is https://www.google.com/recaptcha/enterprise.js.

Outputs

If you enable the Store reCAPTCHA assessment JSON property, the node outputs the reCAPTCHA assessment response JSON in a state variable named CaptchaEnterpriseNode.ASSESSMENT_RESULT.

If you enable the Store reCAPTCHA error messages property, the node outputs the error response JSON in a state variable named CaptchaEnterpriseNode.FAILURE.

Outcomes

True

The reCAPTCHA response was successfully verified.

False

The reCAPTCHA response wasn’t verified or failed verification.

Example

The following journey uses a Page node and a Data Store Decision node to collect and verify the credentials and a CAPTCHA response:

The reCAPTCHA Enterprise node in context

This example uses the following nodes:

Legacy CAPTCHA node

Verifies the response token received from the CAPTCHA verifier, and creates a CAPTCHA callback for the UI to interact with. Default values are for Google ReCAPTCHA.

This node has been superseded by the CAPTCHA node. Use that node instead.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True (success)

  • False (failure)

Properties

Property Usage

CAPTCHA Site Key (required)

The CAPTCHA site key supplied by the CAPTCHA provider when you sign up for access to the API.

CAPTCHA Secret Key (required)

The CAPTCHA secret key supplied by the CAPTCHA provider when you sign up for access to the API.

CAPTCHA Verification URL (required)

The URL used to verify the CAPTCHA submission.

Use https://www.google.com/recaptcha/api/siteverify.

CAPTCHA API URL (required)

The URL of the JavaScript that loads the CAPTCHA widget.

Use https://www.google.com/recaptcha/api.js.

Class of CAPTCHA HTML Element

The class of the HTML element required by the CAPTCHA widget.

Use g-recaptcha.

Modify Auth Level node

Increases or decreases the current authentication level value.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Value To Add

Enter a positive integer to increase the current authentication level, or a negative integer to decrease the current authentication level by the specified value.

Behavioral nodes

Increment Login Count node

The Increment Login Count node increments the successful login count property of a managed object.

Use the Login Count Decision node to change the flow of the journey based on the count.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node’s Identity Attribute specifies the property it requires in the incoming node state. It uses this property to access the managed object.

Dependencies

This node depends on the underlying identity service to store the managed object.

Configuration

Property Usage

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Default: userName

Outputs

This node does not change the shared node state.

Outcomes

Single outcome path; on success, this node increments the managed object’s loginCount.

Errors

If this node fails to access the managed object, it throws an exception with a No object to increment message.

If this node fails to increment the login count, it logs an Unable to increment login count warning message.

Example

The following journey uses the Increment Login Count node to update the login count on successful authentication:

Incrementing login count
Determining next steps based on login count

Login Count Decision node

The Login Count Decision node triggers an action when a user’s successful login count property reaches a specified number.

Use the Increment Login Count node to set the login count on successful authentication.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node’s Identity Attribute specifies the property it requires in the incoming node state. It uses this property to access the managed object.

Dependencies

This node depends on the underlying identity service to store the managed object.

Configuration

Property Usage

Interval

Trigger the True outcome depending on this setting, the Amount, and the login count:

AT

Proceed to True when the login count matches the Amount setting.

EVERY

Proceed to True every time the login count reaches a multiple of the Amount setting.

Default: AT

Amount

The login count to trigger a True outcome depending on the Interval.

Default: 25

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Default: userName

Outputs

This node does not change the shared node state.

Outcomes

True

The login count reached Amount, and the Interval setting triggered this outome.

False

All other cases.

Errors

This node can throw exceptions with the following messages:

Message Notes

<Identity Attribute> not present in state

Failed to read the specified Identity Attribute in the shared node state

Failed to retrieve existing object

Failed to find the managed object using the Identity Attribute value from the shared node state

Retrieve login not found

Failed to read the managed object’s login count

Example

The following journey uses the Increment Login Count node to update the login count on successful authentication:

Incrementing login count
Determining next steps based on login count

Contextual nodes

Checks that a named cookie is present in the incoming authentication request.

This node does not check the value of the named cookie, only that it exists.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Properties

Property Usage

Name of Cookie (required)

Evaluation continues along the True path if the named cookie is present in the incoming authentication request; otherwise, evaluation continues along the False path.

Device Geofencing node

Compares any collected device location metadata with the trusted locations configured in the authentication node.

Use this node with the Device Profile Collector node to determine if the authenticating user’s device is located within range of configured, trusted locations.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Inside

  • Outside

Evaluation continues along the Inside path if the collected location is within the specified range of a configured trusted location; otherwise, evaluation continues along the Outside path.

Properties

Property Usage

Trusted Locations (required)

Specify the latitude and longitude of at least one trusted location. Separate the values with a comma. For example, 37.7910855,-122.3951663.

Geofence Radius (km)

Specifies the maximum distance, in kilometers, that a device can be from a configured trusted location.

The distance is calculated point-to-point.

Device Location Match node

Compares any collected device location metadata with that stored in the user’s profile.

Use this node with the Device Profile Collector node to determine if the authenticating user’s device is located within range of somewhere they have authenticated from, and saved, previously.

You must establish the identity of the user before attempting to match locations.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

  • Unknown Device

Evaluation continues along the True path if the collected location is within the specified range of saved location data; otherwise, evaluation continues along the False path.

If the user has no saved device profiles or the identity of the user has not been established, evaluation continues along the Unknown Device path.

Properties

Property Usage

Maximum Radius (km)

Specifies the maximum distance, in kilometers, that a device can be from a previously saved location.

The distance is calculated point-to-point.

Device Match node

The Device Match node compares collected device metadata with that stored in the user’s profile.

Use this node with the Device Profile Collector node to check whether the user is authenticating with a previously saved, trusted device.

The Device Match node supports the following methods of comparison:

  • Built-in matching

    The node handles the comparison and matching. You configure the acceptable variance and the maximum age for device profiles.

  • Custom matching

    Create scripts to compare captured device data against trusted device profiles.

    PingOne Advanced Identity Cloud includes a customizable template script. In the Advanced Identity Cloud admin UI, go to Scripts > Auth Scripts, and click Device Profile Match Template - Decision Node Script.

    For a comprehensive sample script with instructions for its use and a development toolkit, go to the GitHub sample repository.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads the username from the shared state to look up saved device profiles in the user’s account. Implement a Platform Username node earlier in the journey to obtain the username.

This node also reads collected device metadata from the shared state. Implement a Device Profile Collector node earlier in the journey to collect metadata for the current device.

If Use Custom Matching Script is enabled, the inputs depend on the script.

Dependencies

If Use Custom Matching Script is enabled, the dependencies depend on the script.

Configuration

Property Usage

Acceptable Variance

The maximum number of acceptable device attribute differences for a match.

Default: 0 (all attributes must match)

Expiration

The maximum age in days a saved profile is valid for comparison.

The node ignores older device profiles saved to the user’s account when comparing device profiles with the collected metadata.

Default: 30 (days)

Use Custom Matching Script

Enable this option to use a custom script instead of built-in matching to compare the collected metadata with saved device profiles.

When enabled, the node ignores the Acceptable Variance and Expiration settings.

The script type must be Journey Decision Node.

Default: false

Custom Matching Script

Select the custom script to use when Use Custom Matching Script is enabled.

Only scripts of type Journey Decision Node appear in the list.

Default: Authentication Tree Decision Node Script

Outputs

This node does not change the shared state on its own.

If the node uses a Custom Matching Script, the output is determined by the script.

Outcomes

True

The collected device metadata matches a saved profile within the configured variance.

False

The collected device metadata doesn’t match a saved profile, or another error occurred.

Unknown Device

The journey follows this outcome path in the following situations:

  • The user has no saved trusted device profiles.

  • The user identity hasn’t yet been established.

  • The acceptable device variance matches, but the device ID no longer matches.

    The device ID is randomly generated and stored in the local browser cache. If the cache is cleared, the device ID can change.

Errors

This node logs the following warning messages:

script outcome error

The script failed to set the outcome field to a string.

error evaluating the script

The script failed to complete. Refer to the logs for details.

Example

The following journey authenticates the user and checks whether the current device is trusted. If the device isn’t trusted yet, the journey requires an additional authentication factor and lets the user opt to trust the device:

Checking whether the current device is trusted

Device Profile Collector node

Gathers metadata about the device used to authenticate.

The node sends a DeviceProfileCallback callback. Learn more in Interactive callbacks.

When used with the ForgeRock SDKs, the node can collect the following:

Device Metadata

Information such as the platform, versions, device name, hardware information, and the brand of the device being used.

The captured data is in JSON format, and stored in the authentication shared state in a variable named forgeRock.device.profile.

Device Location

Provides the last known latitude and longitude of the device’s location.

The captured data is in JSON format, and stored in the authentication shared state in a variable named forgeRock.device.location.

The collection of geographical information requires end-user approval. A browser function drives this process. A pop-up displays, prompting for access to share the geographical location. The browser connection must be secure.

It is up to you what information you collect from users and devices.

Always use data responsibly and provide your users with appropriate control over data they share with you.

You are responsible for complying with any regulations or data protection laws.

In addition to the collected metadata, an identifier string in the JSON uniquely identifies the device.

Use this node with the Device Profile Save node to create a trusted profile from the collected data. You can use the trusted device profile in subsequent authentication attempts; for example, with the Device Match node and Device Location Match node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Maximum Profile Size (KB)

Specifies the maximum accepted size, in kilobytes, of a device profile.

If the collected profile data exceeds this size, authentication fails.

Default: 3

Collect Device Metadata

Specifies whether device metadata is requested.

Collect Device Location

Specifies whether device location is requested.

Message

Specifies an optional message to display to the user while the node collects the requested data.

You can provide the message in multiple languages by specifying the locale in the KEY field. For example, en-US.

The locale selected for display is based on the user’s locale settings in their browser.

Messages provided in the node override the defaults provided by AM.

Device Profile Save node

Persists collected device data to a user’s profile in the identity store.

Use this node with the Device Profile Collector node to reuse the collected data in future authentications; for example, with the Device Match node and Device Location Match node.

You must establish the identity of the user before attempting to save to their profile.

A user profile can contain multiple device profiles. Use the Maximum Saved Profiles property to configure the maximum number of device profiles to persist per user. Saving a device profile with the same identifier as an existing entry overwrites the original record, and does not increment the device profile count.

The end user UI displays saved device profiles to end users.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Device Name Variable

Specifies the name of a variable in the shared node state that contains an alias label for the device profile.

Maximum Saved Profiles

Specify the maximum number of device profiles to save in a user’s profile.

When the maximum is reached, saving a new profile replaces the least-recently used profile.

Save Device Metadata

Specifies whether device metadata is saved to the user’s profile.

Save Device Location

Specifies whether device location metadata is saved to the user’s profile.

Device Tampering Verification node

Specifies a threshold for deciding if the device has been tampered with; for example, if it has been rooted or jailbroken.

The device scores between zero and one, based on the likelihood that is has been tampered with or may pose a security risk. For example, an emulator scores the maximum of 1.

Use this node with the Device Profile Collector node to retrieve the tampering score from the device.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Not Tampered

  • Tampered

Evaluation continues along the Not Tampered path if the device scores less than or equal to the configured threshold; otherwise, evaluation continues along the Tampered path.

Properties

Property Usage

Score Threshold

Specifies the score threshold for determining if a device has been tampered with. Enter a decimal fraction, between 0 and 1. For example, 0.75.

The higher the score returned from the device, the more likely the device is jailbroken, rooted, or is a potential security risk.

Emulators score the maximum; 1.

The Persistent Cookie Decision node checks for the existence of a specified persistent cookie (default: session-jwt).

If the cookie is present, the node verifies the signature of the JWT stored in the cookie with the configured signing key.

If the configured signing key isn’t valid, PingOne Advanced Identity Cloud checks the signature against all valid signing keys mapped to the configured secret label.

If the signature is valid, the node decrypts the payload of the JWT using the key pair defined in the active secret mapped to the am.authentication.nodes.persistentcookie.encryption secret label.

If there isn’t a valid secret label mapping in a secret store, PingOne Advanced Identity Cloud uses the key pair specified in Native Consoles > Access Management > Realms > Realm Name > Authentication > Settings > Security > Persistent Cookie Encryption Certificate Alias.

The decrypted JSON payload includes information, such as the UID of the identity and the client IP address. Enable Enforce Client IP to verify that the current IP address and the client IP address in the cookie are the same.

This node recreates the specified persistent cookie, updating the value for the idle time property and the JWT kid header with the stable ID used to sign the JWT.

Therefore, the node has cookie creation properties similar to the Set Persistent Cookie node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node requires the realm property, which PingOne Advanced Identity Cloud sets by default.

Dependencies

To authenticate successfully, the tree must have set a persistent cookie using a node such as the Set Persistent Cookie node.

Configuration

Property Usage

Idle Timeout

The maximum idle time allowed before the persistent cookie is invalidated, in hours. If no requests are received and the time is exceeded, the cookie is no longer valid.

Enforce Client IP

When enabled, ensures that the persistent cookie is only used from the same client IP to which the cookie was issued.

Use Secure Cookie

When enabled, adds the Secure flag to the persistent cookie.

If the Secure flag is included, the cookie can only be transferred over HTTPS. When a request is made over HTTP, the cookie is not made available to the application.

Use HTTP Only Cookie

When enabled, adds the HttpOnly flag to the persistent cookie.

When the HttpOnly flag is included, that cookie will not be accessible through JavaScript. According to RFC 6265, the HttpOnly flag, "instructs the user agent to omit the cookie when providing access to cookies via 'non-HTTP' APIs (for example, a web browser API that exposes cookies to scripts)."

HMAC Signing Key

The key to use for HMAC signing of the persistent cookie.

This property is deprecated. Use the HMAC Signing Key Secret Label Identifier instead.

If you set an HMAC Signing Key Secret Label Identifier, this signing key is ignored.

Values must be base64-encoded and at least 256 bits (32 bytes) long.

To generate an HMAC signing key, run one of the following commands:

$ openssl rand -base64 32

or

$ cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1|base64

HMAC Signing Key Secret Label Identifier

An identifier used to create a secret label for mapping to a secret in a secret store.

PingOne Advanced Identity Cloud uses this identifier to create a specific secret label for the signing key for this node. The secret label takes the form am.authentication.nodes.persistentcookie.identifier.signing where identifier is the value of HMAC Signing Key Secret Label Identifier. The identifier can only contain alphanumeric characters a-z, A-Z, 0-9, and periods (.). It can’t start or end with a period.

If you set an HMAC Signing Key Secret Label Identifier and PingOne Advanced Identity Cloud finds a matching secret in a secret store, the HMAC Signing Key is ignored.

If HMAC Signing Key is empty, PingOne Advanced Identity Cloud uses the value configured for am.default.authentication.nodes.persistentcookie.signing for the realm, or at the global level if undefined.

For greater security, you should rotate signing keys periodically by adding new secret versions to the ESV.

To read the persistent cookies generated by the Set Persistent Cookie node, ensure the nodes use the same HMAC signing key.

Persistent cookie name

The name of the persistent cookie to check.

Outputs

The node copies shared state into the outgoing node state. It records the user identity and stores the cookie name as a session property.

The node adds the UpdatePersistentCookieTreeHook, which runs when the tree completes.

Outcomes

  • True

  • False

Evaluation continues along the True outcome path if the persistent cookie is present and all the verification checks are satisfied; otherwise, evaluation continues along the False outcome path.

Errors

The node logs the following warning messages:

  • Attempt to verify JWT failed, attempting other valid keys

  • Failed to parse universal id username from claim openam.usr

The node logs the following error messages:

  • Claims context not found

  • Failed to find signing key with associated keyID

  • jwt reconstruction error

  • Authentication failed. Jwt claim Realm does not match

  • Authentication failed. Cannot read the user from null claims

  • Authentication failed. Cannot read the user from empty claims

  • Failed to parse universal Id from claim: openam.usr

  • Authentication failed. Client IP is different

The following example authenticates the user based on a persistent cookie, if possible:

The persistent cookie decision in context

The Set Custom Cookie node lets you store a custom cookie on the client in addition to the session cookie.

The node uses the specified properties to create a cookie with a custom name and value. It can also set attributes, such as the cookie path, domain, expiry, and security flags.

Use this node with the Configuration Provider node to extend custom capabilities. For example, create a Config Provider script to set custom static values or access values from the shared node state.

Include all the attributes in the configuration provider script’s config map. The following example sets the attributes of the custom cookie to static values:

config = {
    "name": "testname",
    "value": "testvalue",
    "maxAge": "60",
    "domain": "am.example.com",
    "path": "/",
    "useSecureCookie": false,
    "useHttpOnlyCookie": false,
    "sameSite": "LAX"
};

Reference the script when you create a Configuration Provider node, and set the Node Type to Set Custom Cookie:

Configuration Provider node referencing this node

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads the user data from the shared node state.

It requires a predecessor node that gathers the user data.

Configuration

Property Usage

Custom Cookie Name (required)

The name of the custom cookie.

The cookie name can contain any US-ASCII characters except for: space, tab, control, or a separator character (()<>@,;:"/[]?=\{}).

Custom Cookie Value (required)

The value of the custom cookie.

Max Age

The length of time the custom cookie remains valid, in seconds. If that time is exceeded, the cookie is no longer valid.

AM sets the Max-Age and Expires attributes in the cookie to increase compatibility with different browsers.

If omitted, the cookie expires at the end of the current session. The precise implementation of this is determined by the specific browser. Refer to RFC 6265 for details.

Custom Cookie Domain

The domain the custom cookie will be sent to. If you specify a value here, AM sets a domain cookie. For example, if you set this property to am.example.com, AM sets a cookie on .am.example.com. Note the leading . indicating a domain cookie rather than a host cookie.

If you don’t set a value here, AM sets a host level cookie on the FQDN on which the client accessed AM. For example, if the client accesses AM at https://am.example.com and this property is empty, AM sets a host cookie on am.example.com.

Custom Cookie Path

The path of the custom cookie.

Use Secure Cookie

When enabled, adds the Secure flag to the custom cookie.

If you include the Secure flag, the cookie can only be transferred over HTTPS. When a request is made over HTTP, the cookie isn’t made available to the application.

Use HTTP Only Cookie

When enabled, adds the HttpOnly flag to the custom cookie.

If you include the HttpOnly flag, the cookie isn’t accessible to scripts.

Custom Cookie SameSite attribute

Sets the SameSite attribute of the custom cookie.

The default value is LAX, to align with most modern browsers.

Outcomes

Single outcome path.

The cookie is created when AM next returns to the client.

Example

This example uses this node in a login flow. The node sets the custom cookie in the client browser after the user has successfully authenticated:

The Set Custom Cookie node in context

Creates the specified persistent cookie, the default being session-jwt.

The cookie contains a JWT with a JSON payload including information such as the UID of the identity, and the client IP address.

The node encrypts the payload of the JWT using the key pair defined in the active secret mapped to the am.authentication.nodes.persistentcookie.encryption secret label.

If there isn’t a valid secret label mapping in a secret store, PingOne Advanced Identity Cloud uses the key pair specified in Native Consoles > Access Management > Realms > Realm Name > Authentication > Settings > Security > Persistent Cookie Encryption Certificate Alias.

The node signs the cookie with the HMAC signing key defined in the node properties or the secret store with the mapped secret label. Configure nodes that read the persistent cookie such as the Persistent Cookie Decision node with the same HMAC signing key.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

When the authentication tree completes successfully, the CreatePersistentCookieTreeHook treehook for this node uses session properties to create the persistent cookie.

Dependencies

None

Configuration

Property Usage

Idle Timeout

The maximum amount of idle time allowed before the persistent cookie is invalidated, in hours. If no requests are received before the timeout, the cookie is no longer valid.

Max life

The length of time the persistent cookie remains valid, in hours. After this time has passed, the cookie is no longer valid.

Use Secure Cookie

When enabled, adds the Secure flag to the persistent cookie.

If the Secure flag is included, the cookie can only be transferred over HTTPS. When a request is made over HTTP, the cookie is not made available to the application.

Use HTTP Only Cookie

When enabled, adds the HttpOnly flag to the persistent cookie.

When the HttpOnly flag is included, that cookie will not be accessible through JavaScript. According to RFC 6265, the HttpOnly flag, "instructs the user agent to omit the cookie when providing access to cookies via 'non-HTTP' APIs (for example, a web browser API that exposes cookies to scripts)."

HMAC Signing Key

A key to use for HMAC signing of the persistent cookie.

This property is deprecated. Use the HMAC Signing Key Secret Label Identifier instead.

If you set an HMAC Signing Key Secret Label Identifier, this signing key is ignored.

Values must be base64-encoded and at least 256 bits (32 bytes) long.

To generate an HMAC signing key, run one of the following commands:

$ openssl rand -base64 32

or

$ cat /dev/urandom | LC_ALL=C tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1|base64

HMAC Signing Key Secret Label Identifier

An identifier used to create a secret label for mapping to a secret in a secret store.

PingOne Advanced Identity Cloud uses this identifier to create a specific secret label for the signing key for this node. The secret label takes the form am.authentication.nodes.persistentcookie.identifier.signing where identifier is the value of HMAC Signing Key Secret Label Identifier. The identifier can only contain alphanumeric characters a-z, A-Z, 0-9, and periods (.). It can’t start or end with a period.

If you set an HMAC Signing Key Secret Label Identifier and PingOne Advanced Identity Cloud finds a matching secret in a secret store, the HMAC Signing Key is ignored.

If HMAC Signing Key is empty, PingOne Advanced Identity Cloud uses the value configured for am.default.authentication.nodes.persistentcookie.signing for the realm, or at the global level if undefined.

For greater security, you should rotate signing keys periodically by adding new secret versions to the ESV.

To read the persistent cookies this node generates, ensure the nodes use the same HMAC signing key.

Persistent Cookie Name

The name used for the persistent cookie.

Outputs

The node stores the cookie name in the session properties.

The node adds the CreatePersistentCookieTreeHook treehook, which runs when the tree completes.

Outcomes

Single outcome path.

Errors

The node logs the following warning messages:

  • Unable to create signing key from provided configuration.

The node logs the following error messages:

  • Tree hook creation exception

  • No signing keys available to sign JWT

  • Error creating jwt string

Example

Refer to the Persistent Cookie Decision node example.

Federation nodes

SAML2 Authentication node

Integrates SAML v2.0 SSO into an AM authentication flow.

Use this node when deploying SAML v2.0 single sign-on in integrated mode (SP-initiated SSO only).

Regardless of the outcome, Account exists or No account exists, if this node completes without failure, it sets the successURL parameter in the shared node state to the value of the RelayState parameter in the request. If the request does not provide a value for this parameter, the node uses the default RelayState value configured in the service provider (SP).

You can dynamically provision an account on the SP if it does not exist, or you can link the remote account to a local account using the Write Federation Information node.

Before attempting to configure a SAML2 authentication node, ensure that:

  • You have configured a remote identity provider (IdP) and a hosted SP in a circle of trust in the same realm where the authentication node is configured.

  • The service provider is configured for integrated mode.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Account exists

  • No account exists

If a user account is found that matches the federated account, evaluation continues along the Account exists outcome; otherwise, evaluation continues along the No account exists outcome.

Properties

Property Usage

IdP Entity ID

Specifies the name of the remote IdP.

SP MetaAlias

Specifies the local alias for the SP, in the format /Realm Name/SP Name.

Allow IdP to Create NameID

Specifies whether the IdP should create a new identifier for the authenticating user if none exists.

For detailed information, refer to the section on the AllowCreate property in SAML Version 2.0 Errata 05.

Default: Enabled

Comparison Type

Specifies a comparison method to evaluate authentication context classes or statements.

The value specified in this property overrides the value set in the SP configuration in AM admin UI under Realms > Realm Name > Applications > Federation > Entity Providers > Service Provider Name > Assertion Content > Authentication Context > Comparison Type.

Valid comparison methods are exact, minimum, maximum, or better.

For more information about the comparison methods, refer to the section on the <RequestedAuthnContext> element in Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.

Default: minimum

Authentication Context Class Reference

(Optional) Specifies one or more URIs for authentication context classes to be included in the SAML request.

Authentication Context Classes are unique identifiers for an authentication mechanism. The SAML v2.0 protocol supports a standard set of authentication context classes, defined in Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0. In addition to the standard authentication context classes, you can specify customized authentication context classes.

Any authentication context class you specify in this field must be supported for the service provider. In the AM admin UI, go to Realms > Realm Name > Applications > Federation > Entity Providers > Service Provider Name > Assertion Content > Authentication Context.

Authentication Context Supported by the SP

When specifying multiple authentication context classes, use the | character to separate the classes. For example:

urn:oasis:names:tc:SAML:2.0:ac:classes:Password|urn:oasis:names:tc:SAML:2.0:ac:classes:TimesyncToken

Authentication Context Declaration Reference

(Optional) Specifies one or more URIs that identify authentication context declarations.

When specifying multiple URIs, use the | character to separate the URIs.

Learn more in the section on the <RequestedAuthnContext> element in Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.

Request Binding

Specifies the format the SP will use to send the authentication request to the IdP.

Valid values are HTTP-Redirect and HTTP-POST.

Default: HTTP-Redirect

Response Binding

Specifies the format the IdP will use to send the response to the SP.

Valid values are HTTP-POST and HTTP-Artifact.

Default: HTTP-Artifact

Force IdP Authentication

Specifies whether the IdP forces authentication or if it can reuse existing security contexts.

Default: Disabled

Passive Authentication

Specifies whether the IdP uses passive authentication or not.

Passive authentication requires the IDP to only use authentication methods that do not require user interaction; for example, authenticating using an X.509 certificate.

Default: Disabled

NameID Format

Specifies the SAML name ID format that will be requested in the SAML authentication request. For example:

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Default: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

For examples, refer to SSO in integrated mode.

Legacy Social Provider Handler node

This node takes a provider selection from the Select Identity Provider node and attempts to authenticate the user. The node collects relevant profile information from the provider, transforms the profile information into the appropriate attributes and returns the user to the journey.

This node is deprecated and therefore marked as legacy. A new Social Provider Handler node with additional outcomes will be available in an upcoming release.

Implement this node with the Select Identity Provider node to use the Social Identity Provider Service.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Account exists

Social authentication succeeded, and a matching ForgeRock account exists.

No account exists

Social authentication succeeded, but no matching ForgeRock account exists.

Properties

Property Usage

Transformation Script (required)

This script is used after the configured provider’s normalization script has mapped the social identity provider’s attributes to a profile format compatible with AM. The transformation script then transforms a normalized social profile to a managed object.

Select Normalized Profile to Managed User (default), or your own script that you have created to transform the profile to a managed object.

To view the scripts and bindings, refer to normalized-profile-to-managed-user.js.

Normalization scripts (<Identity provider>-profile-normalization.*) are not suitable for this purpose.

Username Attribute

The attribute in the underlying identity service that contains the username for this object.

Client Type

Specify the client type you are using to authenticate to the provider.

Use the default, BROWSER, with ForgeRock-provided user interfaces or the ForgeRock SDK for JavaScript. This causes the node to return the RedirectCallback.

Select NATIVE with the ForgeRock SDKs for Android or iOS. This causes the node to return the IdPCallback.

Social Provider Handler node

The Social Provider Handler node attempts to authenticate a user with an identity provider they select in the Select Identity Provider node. The Social Provider Handler node collects relevant profile information from the provider, transforms the profile information into the appropriate attributes, and returns the user to the journey.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads the user’s selected social identity provider from shared state.

Implement the Select Identity Provider node before this node to capture the social provider name.

Dependencies

  • The Social Identity Provider service must be configured with the details of at least one social identity provider.

  • The user must have selected a social identity provider in a previous node in the journey.

Configuration

Property Usage

Transformation Script (required)

The normalization script of each provider maps that provider’s attributes to a profile format PingOne Advanced Identity Cloud can use.

The transformation script then transforms the normalized social profile to a managed object.

Select Normalized Profile to Managed User (default) or a custom script to transform the profile to a managed object.

Review the sample script (normalized-profile-to-managed-user.js) for a list of bindings.

Don’t use normalization scripts (<Identity provider>-profile-normalization.*) for this purpose.

Username Attribute

The attribute in the underlying identity service that contains the username for this object.

Client Type

The client type you’re using to authenticate to the provider. Select one of the following:

  • BROWSER (default) Select this type for Ping Identity-provided user interfaces or the Ping SDKs for JavaScript.

    With this setting, the node returns the RedirectCallback.

  • NATIVE Select this type for the Ping SDKs for Android or iOS.

    With this setting, the node returns the IdPCallback.

Outputs

  • If no profile information is returned from the social provider, the journey follows the Social auth interrupted outcome.

  • If the node retrieves profile information from the social identity provider, it transforms a normalized version of the profile and stores it in objectAttributes in transient state.

  • To link existing users, the aliasList is updated and saved to objectAttributes in transient state.

  • The node stores the social identity subject as the username both directly in shared state and in its objectAttributes.

  • The node also updates socialOAuthData in transient state with all existing node state, social provider data, and associated tokens.

Make sure you copy required transient data to shared state because all transient data is removed if the node is followed by an interactive page later in the journey.

Outcomes

Account exists

Social authentication succeeded, and a matching Ping Identity account exists.

No account exists

Social authentication succeeded, but no matching Ping Identity account exists.

To ensure existing users are dynamically linked, connect the No account exists outcome to an Identify Existing User node followed by a Patch Object node to create the link as demonstrated in Example 2: Social Provider Handler node with dynamic linking.

Social auth interrupted

The user interrupted the social authentication journey after the node requested profile information from the social identity provider. This can happen in the following situations:

  • The user clicks the Back button in their browser from the social identity provider’s login page

  • The user clicks the Cancel button on the social identity provider’s login page

  • The user re-enters the journey URL in the same browser window

    In this case, the node routes the user back to the Select Identity Provider node to select a social identity provider again.

Examples

Example 1: Social Provider Handler node in a social authentication journey
journey social provider handler

a A Page node contains the Select Identity Provider node node that prompts the user to select a social identity provider or to authenticate with a username and password.

b If the user selects local authentication, the Data Store Decision node takes care of the authentication.

c If the user selects social authentication, the Social Provider Handler node does the following:

  • Routes the user to the selected social provider to authenticate there

  • Retrieves the user’s profile information, and transforms it into a format that PingOne Advanced Identity Cloud can use

  • Assesses whether the user has an existing identity in PingOne Advanced Identity Cloud

    • If the user has an existing identity, authenticates that identity

    • If the user doesn’t have an identity, routes the user to another page node

    • If the user interrupts the social authentication, routes the user back to the Select Identity Provider node

d The nodes on the page node request the information required to register a new identity.

e The Create Object node creates the new identity in PingOne Advanced Identity Cloud.

Example 2: Social Provider Handler node with dynamic linking

This example shows a social authentication journey with dynamic account linking.

journey social provider handler link

a A Page node contains the Select Identity Provider node node that prompts the user to select a social identity provider or to authenticate with a username and password.

b If the user selects local authentication, the Data Store Decision node takes care of the authentication.

c If the user selects social authentication, the Social Provider Handler node does the following:

  • Routes the user to the selected social provider to authenticate there

  • Retrieves the user’s profile information, and transforms it into a format that PingOne Advanced Identity Cloud can use

  • Assesses whether the user has an existing identity in PingOne Advanced Identity Cloud

d The Identify Existing User node checks if the user exists in PingOne Advanced Identity Cloud using the Identity Attribute specified and does the following:

  • If the user exists, routes the user to the Patch Object node

  • If the user doesn’t exist, routes the user to another page node

e The Patch Object node updates the existing user to create the link.

f The nodes on the page node request the information required to register a new identity.

g The Create Object node creates the new identity in PingOne Advanced Identity Cloud.

Write Federation Information node

Creates a persistent link between a remote IdP account and a local account in the SP, if none exists yet. If a transient link exists, it is persisted. Existing account links with different IdPs are not lost.

Use this node with the SAML2 Authentication node, and ensure that the NameID Format is persistent.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

This node has no configurable properties.

For examples, refer to SSO in integrated mode.

Identity management nodes

Accept Terms and Conditions node

The Accept Terms and Conditions node prompts the user to accept the currently active terms and conditions.

You set terms and conditions in the Ping Identity Platform admin UI. Learn more in Terms and conditions.

Use this node for registration, or combined with the Terms and Conditions Decision node for progressive profiling or log in.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

None.

Dependencies

This node depends on the underlying identity service for the active terms and conditions.

Configuration

This node has no configurable properties.

Outputs

The node writes a termsAccepted object to the shared node state. The object contains these fields:

  • acceptDate: A timestamp string indicating when the user accepted the terms.

  • termsVersion: A string indicating the version of the accepted terms.

Outcomes

Single outcome path; the user accepted the terms and conditions.

Errors

This node does not log error or warning messages of its own.

Example

For progressive profiling, include this node after a Terms and Conditions Decision node. If the user has not accepted the latest version of the terms and conditions, evaluation takes them to a page that requires them to accept the current terms and conditions.

The Patch Object node stores the acceptance response in the underlying identity service if the user accepts:

Storing acceptance of terms and conditions

Attribute Collector node

The Attribute Collector node collects the values of attributes for use later in the flow; for example, to populate a new account during registration.

This node supports three types of attributes:
string
boolean
number

To request a value, the attribute must be present in the identity schema of the current identity object.

The node lets you configure whether the attributes are required to continue and whether to use a policy filter of the underlying identity service to validate them.

Use the node alone or within a Page node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

For validation, this node reads the Identity Attribute (default: userName) from the shared node state. It uses the value to look up the identity object.

It prompts the user for the attributes to collect.

Dependencies

This node depends on the underlying identity service to store the user profile and perform validation.

Configuration

Property Usage

Attributes to Collect

A list of the attributes to collect based on those in the identity schema for the current identity object.

Default: none

All Attributes Required

When enabled, all attributes collected in this node are required in order to continue.

Default: false

Validate Input

When enabled, validate the content against any policies specified in the identity schema for each collected attribute.

If you enable this property, the collected identity attributes must be User Editable. To make an attribute user-editable in the IDM admin UI:

  1. Go to Configure > Managed Objects > object-name.

  2. Click the pencil () icon, then click Show advanced options.

  3. Select the User Editable toggle.

For details, refer to Property Configuration Properties.

Default: false

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Default: userName

Outputs

The node writes the attributes and their values to the shared node state.

Outcomes

Single outcome path; on success, downstream nodes can read the attributes from the shared node state.

Errors

This node does not log error or warning messages of its own.

Examples

Add date and datetime fields to a journey

The Attribute Collector node lets you add properties (attributes) that follow a date or datetime (date and time of day). The format of the date comes from the locale set in your browser.

The following table displays the differences between date and datetime:

Display format Managed object field format Notes

Date only

String format

For example, frIndexedString1.

The format of the date comes from the locale set in your browser.

For example, if the locale is English, then the format presented to the end user is MM-DD-YYYY. If the local is French, the format is DD-MM-YYYY.

Date and time

String format (date and time of day)

For example, frIndexedDate1.

The format of the date comes from the locale set in your browser.

For example, if the locale is English (United States), then the format presented to the end user is MM-DD-YYYY. If the local is French, the format is DD-MM-YYYY.

Use the date general purpose extension attributes for datetime only. Don’t attempt to use the indexed date properties with the date format.

While the rendering of the date to the end user changes depending on the locale set in the browser, Advanced Identity Cloud stores the date value in UTC format as YYYY-MM-DDHH:MM:SS. For example, 2023-09-13T08:01:00Z.

To render the date or datetime UI element to an end user with the Attribute Collector node, you must:

  1. Specify the property to use as date or datetime:

  2. Apply formatting and policies to the property in the IDM admin UI for Date or Datetime.

Apply formatting and policies
  1. In the Advanced Identity Cloud admin UI, go to Configure > Managed Objects > Select object, for example, Alpha_user.

  2. Select the property to use.

  3. To select the format of the attribute, on the Details tab, click the Format field, and select one of the following:

    • For date property — Date

    • For datetime property — Datetime

  4. Click Save.

  5. On the Validation tab, click + Add Policy.

  6. In the Policy Id field, enter one of the following:

    • For date property — valid-formatted-date

    • For datetime property — valid-datetime

      For more information on applying policies to properties, refer to Apply policies to managed objects.

  7. Click Add.

  8. In your journey, in the Attribute Collector node, add the property name to the Attributes to Collect field; in this case, the following properties are used:

    • For date property — frIndexedString1

    • For datetime property — frIndexedDate1

For an in-depth use case, add the date or datetime property to an Attribute Collector node in a registration flow. Learn more in User self-registration.

The following video shows an example of a journey collecting the datetime from an end user using the Attribute Collector node:

Attribute Present Decision node

The Attribute Present Decision node checks whether an attribute is present on an object, including private attributes. There is no need to specify the value of the attribute.

Use this node during an update password flow to check whether the local account has a password, for example.

This node is similar to the Attribute Value Decision node when that node is set to use the PRESENT operator, except it can’t return the value of the attribute, but can work with private attributes.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads the Identity Attribute from the shared node state. If it can’t read the Identity Attribute, it reads the userName from the shared node state.

It uses the value to look up the identity object.

Dependencies

This node depends on the underlying identity service to look up the user object.

Configuration

Property Usage

Present Attribute

The attribute whose presence you want to verify in the the underlying identity service object. This can be an otherwise private attribute, such as password.

This field is case-sensitive and must match the the underlying identity service object attribute. For example, givenName, not givenname.

Default: password

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Default: userName

Outputs

None.

Outcomes

True

The node found the attribute in the managed identity object.

False

Any other case.

Errors

This node does not log error or warning messages of its own.

Example

This journey to update a password uses the Attribute Present Decision node to check whether the account has a password:

Checking whether an account has a password

The user has already authenticated before beginning this journey:

Attribute Value Decision node

Verifies that the specified attribute satisfies a specific condition.

Use this node to check whether an attribute’s expected value is equal to a collected attribute value, or to validate that the specified attribute was collected.

Examples:

  • To validate that a user provided the country attribute during registration, set the comparison operation to PRESENT, and the comparison attribute to country.

  • To validate that the country attribute is set to the United States, set the comparison operation to EQUALS, the comparison attribute to country, and the comparison value to United States.

Use Attribute Present Decision node instead when you need to check for the presence of a private attribute, such as password.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Properties

Property Usage

Comparison Operation

The operation to perform on the object attribute:

PRESENT

Checks the existence of an attribute regardless of its value.

EQUALS

Checks if the object’s attribute value equals the configured comparison value.

Comparison Attribute

The object attribute to compare.

Comparison Value

When Comparison Operation is EQUALS, compare this value to the provided attribute value.

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Prompts the user for consent to share their profile data.

A consent notice is listed for each identity mapping that has consent enabled. If an identity mapping is not created, or the mappings do not have privacy and consent enabled, PingOne Advanced Identity Cloud does not show a consent message to the user.

This node is primarily used in progressive profile and registration flows.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Properties

Property Usage

All Mappings Required

If enabled, all mappings listed by this node require consent in order to move forward.

Privacy & Consent Message

Localized message providing the privacy and consent notice. The key is the language, such as en or fr, and the value is the message to display.

Create Object node

The Create Object node lets you create a new object in the underlying identity service based on information collected during authentication, such as user registration.

Any managed object attributes that are marked as required in the underlying identity service must be collected during authentication in order to create the new object.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node requires the managed object attributes marked as required

Configuration

Property Usage

Identity Resource

The type of managed identity resource object that this node creates. It must match the identity resource type for the current flow.

To check for the available managed identity resource types, go to the IDM admin UI, and open the Manage drop-down list in the upper right corner of the screen.

Identity managed object types are preceded by the icon.

Default: managed/user

Outputs

This node doesn’t change the shared state.

Outcomes

This node has the following outcomes:

  • Created

  • Failed

Errors

This node can log the following warning messages:

Message Notes

Failed to create object

The preceding nodes don’t provide all the fields required to create the object.

Failed to retrieve object’s schema

The node failed to get the list of required attributes from the Identity Resource schema.

Example

The following example uses this node with the Increment Login Count node to create a new user object.

Create object flow
  • The Page node includes various nodes that collect attributes and store them in the shared node state.

  • The Create Object node uses these attributes to create the new user.

  • The Increment Login Count node resets the retry count on successful authentication of the new user.

Display Username node

Fetches a username based on a different identifying attribute, such as an email address, then displays it.

To email the username to the user instead, use the Identify Existing User node combined with a Email Suspend node or Email Template node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Properties

Property Usage

User Name

The attribute used to identify the username in a managed identity object.

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

When this node serves to recover a username, the identity attribute should be some other attribute that is unique to a user object, such as the email address.

The node raises an exception when more than one value exists for this attribute. Make sure the value of whatever attribute you select is unique for each user.

Identify Existing User node

The Identify Existing User node verifies if a user exists based on an identifying attribute, such as an email address, then makes the value of a specified attribute available in the shared node state.

Use this node in a forgotten password flow to fetch a username to email to the user. To display the username on the screen, use the Display Username node instead.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads the Identity Attribute (default: mail) from the shared node state.

If the Identity Attribute is not available, it reads the userName from the shared node state.

Dependencies

This node depends on the underlying identity service to store the user profile.

Configuration

Property Usage

Identifier

The attribute to collect from a managed identity object.

Default: userName

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

When this node serves to recover a username, the identity attribute should be some other attribute that is unique to a user object, such as the email address.

Default: mail

Outputs

The node writes the Identifier and the user account _id to the shared node state.

If the Identifier differs from userName, this node also writes the userName to the shared node state.

Outcomes

True

The node successfully identified the user and updated the shared node state.

False

Any other case.

Errors

This node does not log error or warning messages of its own.

Example

The following example shows a flow to reset a forgotten password:

Use this node to help reset a forgotten password
  • The user enters their email in the Attribute Collector node of the Page node.

  • The Identify Existing User node uses the email address to look up the username of the user’s account. If it finds the user account, it adds the username to the shared node state.

  • The Email Suspend node emails the user and suspends authentication.

  • Once authentication resumes, the Inner Tree Evaluator node sends the user to a different flow to reset their password.

KBA Decision node

Checks whether the user account has the required minimum number of KBA questions.

To set the number of KBA questions, edit Configure > Security Questions > Questions > Number in the IDM admin UI.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Evaluation continues along the True path if the user profile holds at least the minimum number of KBA questions; otherwise, evaluation continues along the False path.

Properties

Property Usage

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

KBA Definition node

The KBA Definition node collects knowledge-based authentication (KBA) questions and answers.

Use this node when creating or updating a user with KBA enabled. Learn more in Security questions.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

None. This node doesn’t require any attributes from the shared node state.

Dependencies

This node depends on the underlying identity service for the KBA configuration.

Configuration

Property Usage

Purpose Message

A localized message describing the purpose of the data requested from the user.

Default: none

Allow User-Defined Questions

When enabled, users can create their own KBA questions. Disable this setting to restrict users to select from predefined questions only.

Default: Enabled

Questions

Create or modify custom localized questions that the user can choose from when defining security questions.

To add a localized security question:

  1. Click + to open the Add a Security Question form.

  2. Select from the list of existing locales or add a new locale, type a question into the text field, and click Done.

  3. Repeat to add further questions, and click Save when complete.

To edit an existing security question, click the edit icon , make your changes, and click Save.

Default: What’s your favorite color? (locale: en)

Outputs

The node writes the KBA questions and answers in the transient shared node state.

Outcomes

Single outcome path; on success, the transient state holds the questions and answers.

Errors

This node logs a Failed to retrieve kba configuration warning message when it can’t read the configuration.

Example

The following registration journey prompts for questions and answers when creating an account:

Collecting questions and answers during registration

KBA Verification node

Presents KBA questions to the user, collects answers to those questions, and verifies the input against the user’s stored answers.

Use this node for additional authentication when resetting a forgotten password or username.

To set the number of KBA questions, edit Configure > Security Questions > Questions > Number in the IDM admin UI.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Properties

Property Usage

KBA Attribute

The managed object attribute in which KBA questions and answers are stored.

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Pass-through Authentication node

Authenticates an identity through a connector to a third-party service.

This lets you migrate user profiles without forcing users to reset their passwords, or retain a third-party service indefinitely as the canonical store for authentication credentials.

Before you use the node:

  • Configure the connector to the third-party service.

    For details, refer to Sync identities.

  • If you plan to collect credentials in the identity repository for users, synchronize accounts from the third-party service.

    For details, refer to Sync identities.

Use this node after collecting the authentication credentials. For example, use the Platform Username node and the Platform Password node to collect the username and password.

Pass the credentials to this node to authenticate the identity against the service.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Connectors that support pass-through authentication

The following connectors support pass-through authentication using the AuthenticateOp interface by default:

All Scripted Groovy-based connectors are capable of pass-through authentication if the AuthenticateScript.groovy script is implemented, but the only default implementation is the ScriptedSQL connector. Learn more in Authenticate script and Authenticate operation.

Outcomes

  • Authenticated

  • Missing Input

  • Failed

Properties

Property Usage

System Endpoint

Required. Name of the connector to the third-party service that performs authentication.

Object Type

The ICF object type for the object being authenticated.

Default: account

Identity Attribute

The username attribute for authentication.

Default: userName

Password Attribute

The password attribute for authentication.

Default: password

Example

Before trying this example, synchronize accounts from the third-party service. The example shows a login flow that tries pass-through authentication when local authentication fails, and stores the user password when authentication with the third-party service succeeds.

In this example, the user enters their credentials with the Platform Username node and Platform Password node. The Data Store Decision node authenticates against the platform directory service. On failure, authentication passes through to the third-party service. If authentication with the third-party service is successful, the Identify Existing User node and Required Attributes Present node check for a valid user profile. The Patch Object node updates the user’s profile with the successful password:

Pass-through authentication that updates user credentials
Node connections
Table 2. List of node connections
Source node Outcome path Target node

Page Node containing:

  • Platform Username

  • Platform Password

Data Store Decision

Data Store Decision

True

Increment Login Count

False

Pass-through Authentication

Pass-through Authentication

Authenticated

Identify Existing User

Missing Input

Page Node

Failed

Failure

Identify Existing User

True

Required Attributes Present

False

Increment Login Count

Required Attributes Present

True

Patch Object

False

Increment Login Count

Patch Object

Patched

Increment Login Count

Failed

Increment Login Count

Increment Login Count

Inner Tree Evaluator

Inner Tree Evaluator

True

Success

False

Failure

Patch Object node

The Patch Object node updates the attributes of an existing managed identity object.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads the Identity Attribute and the managed object fields to patch from the shared node state. If it can’t read the Identity Attribute, it reads the userName from the shared node state.

Dependencies

This node depends on the underlying identity service to find and patch the managed object.

Configuration

Property Usage

Patch as Object

If enabled, update the object as its subject—​for example, update a managed user object as the user; otherwise, update the object as the client application.

Enable this property to patch fields of the current, authenticated user’s account the client application can’t update.

Default: false

Ignored Fields

Omit the specified shared state fields from the patch.

If no fields are specified, the node attempts to update all the shared state fields as part of the patch.

Default: none

Identity Resource

The type of managed identity resource object this node patches.

This must match the identity resource type for the current flow.

To check for the available managed identity resource types, go to the IDM admin UI, and open the Manage drop-down list in the upper right corner of the screen.

Identity managed object types are preceded by the icon.

Default: managed/user

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Default: userName

Outputs

None.

Outcomes

Patched

The node updated the managed object.

Failed

Any other case.

Errors

This node logs the following warning messages when an update fails:

  • Failed to create object

  • Failed to patch object

Review the logs for additional messages describing the problem.

Example

This journey uses the Patch Object node to update a user’s password:

Updating a password

The user has already authenticated before beginning this journey:

PingOne Create User node

The PingOne Create User node can create new users in the PingOne platform.

You can configure the node to create a user including their profile data or to create an anonymized user.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes 1

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

1 Currently available only in the rapid release channel.

Inputs

This node reads the username field from the shared node state to access the user’s identity profile.

Implement a Platform Username node before this node in the journey.

You should also verify the user’s identity by using an Identity Store Decision node.

Dependencies

This node requires a PingOne Worker Service configuration so that it can authenticate to your PingOne instance.

You can find information on the properties used by the service in PingOne Worker service.

Configuration

Property Usage

PingOne Worker Service ID

The ID of the PingOne worker service for connecting to PingOne.

Population ID

The ID of the population in PingOne to check for users or provision new ones.

If not specified, the node uses the environment’s default population ID.

Anonymized user

When enabled, the node creates a user in PingOne with only a unique identifier and a language attribute.

It does not add any other profile attributes, helping prevent any personally identifiable information (PII) from being shared.

AM Identity Attribute

The attribute from the user’s PingOne Advanced Identity Cloud profile that the node uses as the username for the account created in PingOne.

When creating anonymized users, choose a profile attribute that does not contain PII.

Default: uid

Capture failure

Capture the details in shared state if a failure occurs.

The node stores the details in a variable named pingOneCreateUserFailureReason.

Default: False

Example:

{
  "code": "MISSING_ATTRIBUTE_FROM_PROFILE",
  "message": "Could not get attribute from user profile.",
  "exception": "",
}

Outputs

The node is non-interactive and does not send a callback to the client.

If the node was able to create a new user in PingOne it stores the PingOne user identifier in a state variable named pingOneUserId. For example a648aaac-ch15-b357-457b-8d2e714180ff.

If you select Capture failure, the node stores any error response in a shared state variable named pingOneCreateUserFailureReason.

Outcomes

True

The node created an account in PingOne.

False

The node did not create an account in PingOne.

The journey also uses this outcome if any error occurs. Enable Capture Failure to store the details in node state.

Example

The following example journey leverages PingOne Verify to perform user identity verification.

Example PingOne Verify journey
Figure 5. Example PingOne Verify journey
  • The user enters their credentials, which the Data Store Decision node then verifies against the identity store.

  • 1 The PingOne Identity Match node checks PingOne for a matching user.

  • 2 If a user is found, the PingOne Verify Completion Decision node checks the user’s most recent verification transaction to determine the status:

    Success

    The user successfully completed the most recent PingOne Verify transaction, so continue directly to the Success node, completing the authentication journey.

    Not Completed

    The user has an existing PingOne Verify transaction in progress, so continue the journey to resume the existing verification transaction.

    The node adds the user’s existing transaction ID to the shared node state in a variable named pingOneVerifyTransactionId.

    Not Started / Failure / Expired

    The user either does not have an existing transaction (Not Started), or did not successfully complete the most recent PingOne Verify transaction, or it expired, so continue the journey to start a new verification transaction.

  • 3 If a user is not found, the PingOne Create User node creates a new user in PingOne.

  • 4 The PingOne Verify Evaluation node starts a new PingOne Verify evaluation, or continues an existing one if pingOneVerifyTransactionId is present in the shared node state, and either completes or fails the journey based on the result.

PingOne Delete User node

The PingOne Delete User node can delete users from the PingOne platform.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes 1

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

1 Currently available only in the rapid release channel.

Inputs

This node requires the pingOneUserId variable from node state. The variable must contain the identifier of the user to delete from PingOne. For example, a648aaac-ch15-b357-457b-8d2e714180ff.

Use either of the following nodes to populate the pingOneUserId variable in shared state:

Dependencies

This node requires a PingOne Worker Service configuration so that it can authenticate to your PingOne instance.

You can find information on the properties used by the service in PingOne Worker service.

Configuration

Property Usage

PingOne Worker Service ID

The ID of the PingOne worker service for connecting to PingOne.

Capture failure

Capture the details in shared state if a failure occurs.

The node stores the details in a variable named pingOneDeleteUserFailureReason.

Default: False

Example:

{
  "code": "MISSING_PINGONE_USER_ID",
  "message": "Expected PingOne User ID to be set in sharedState or user's profile.",
  "exception": "",
}

Outputs

The node is non-interactive and does not send a callback to the client.

If you select Capture failure, the node stores any error response in a shared state variable named pingOneDeleteUserFailureReason.

Outcomes

True

The node deleted the account from PingOne.

False

The node did not delete the account from PingOne.

The journey also uses this outcome if any error occurs. Enable Capture Failure to store the details in node state.

PingOne Identity Match node

The PingOne Identity Match node checks that users that exist in the ForgeRock platform also exist in the PingOne platform.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes 1

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

1 Currently available only in the rapid release channel.

Inputs

This node reads the username field from the shared node state to access the user’s identity profile.

Implement a Platform Username node before this node in the journey.

You should also verify the user’s identity by using an Identity Store Decision node.

Dependencies

This node requires a PingOne Worker Service configuration so that it can authenticate to your PingOne instance.

You can find information on the properties used by the service in PingOne Worker service.

Configuration

Property Usage

PingOne Worker Service ID

The ID of the PingOne worker service for connecting to PingOne.

Population ID

The ID of the population in PingOne to check for users or provision new ones.

If not specified, the node uses the environment’s default population ID.

AM Identity Attribute

The attribute from the user’s ForgeRock profile that the node uses to match their account in PingOne.

Default: uid

Ping Identity Attribute

The attribute from the user’s PingOne profile that the node uses to search for a matching account.

If there are multiple entries with the same attribute value in the PingOne directory server, ensure that this property is specific enough to retrieve only one entry.

Default: username

Capture failure

Capture the details in shared state if a failure occurs.

The node stores the details in a variable named pingOneIdentityMatchFailureReason.

Default: False

Example:

{
  "code": "ACCESS_TOKEN",
  "message": "Unable to get access token for PingOne Worker.",
  "exception": "",
}

Outputs

The node is non-interactive and does not send a callback to the client.

If the node was able to find a unique match in PingOne it stores the PingOne user identifier in a state variable named pingOneUserId. For example a648aaac-ch15-b357-457b-8d2e714180ff.

If you select Capture failure, the node stores any error response in a shared state variable named pingOneIdentityMatchFailureReason.

Outcomes

True

The node found a unique matching account in PingOne.

False

The node did not find a unique match in PingOne.

Example

The following example journey leverages PingOne Verify to perform user identity verification.

Example PingOne Verify journey
Figure 6. Example PingOne Verify journey
  • The user enters their credentials, which the Data Store Decision node then verifies against the identity store.

  • 1 The PingOne Identity Match node checks PingOne for a matching user.

  • 2 If a user is found, the PingOne Verify Completion Decision node checks the user’s most recent verification transaction to determine the status:

    Success

    The user successfully completed the most recent PingOne Verify transaction, so continue directly to the Success node, completing the authentication journey.

    Not Completed

    The user has an existing PingOne Verify transaction in progress, so continue the journey to resume the existing verification transaction.

    The node adds the user’s existing transaction ID to the shared node state in a variable named pingOneVerifyTransactionId.

    Not Started / Failure / Expired

    The user either does not have an existing transaction (Not Started), or did not successfully complete the most recent PingOne Verify transaction, or it expired, so continue the journey to start a new verification transaction.

  • 3 If a user is not found, the PingOne Create User node creates a new user in PingOne.

  • 4 The PingOne Verify Evaluation node starts a new PingOne Verify evaluation, or continues an existing one if pingOneVerifyTransactionId is present in the shared node state, and either completes or fails the journey based on the result.

PingOne Verify Completion Decision node

The PingOne Verify Evaluation node determines the completion status of the most recent identity verification transaction for a PingOne user.

The node checks the previous identity verification transaction for the user and returns an outcome based on the verification status.

You can use this node to prevent users from repeatedly having to verify their identity by checking their most recent verification transaction. You can also determine if a transaction is already in progress, to prevent multiple ongoing transactions.

For further customization of behavior, use a PingOne Verify Completion Decision script to evaluate the verification transactions started for the specified PingOne user, and the associated metadata. The script can then add additional context to the journey, or perform additional business logic, dependent on the verification metadata.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes 1

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

1 Currently available only in the rapid release channel.

Inputs

This node requires that the user has an account in the PingOne environment. It requires that the journey stores the PingOne user ID for the account in the shared state variable named pingOneUserId.

Use a PingOne Identity Match node to populate the shared state with the user’s PingOne ID.

Dependencies

This node requires a PingOne Worker Service configuration so that it can connect to your PingOne instance and send it the necessary data to perform PingOne Verify evaluations as part of the journey.

You can find information on the properties used by the service in PingOne Worker service.

Configuration

Property Usage

PingOne Worker Service ID

The ID of the PingOne worker service for connecting to PingOne.

Use a Script to process Verify Transactions

When enabled, use a PingOne Verify Completion Decision script to process verification transaction data relating to the user.

Example verification transaction data
{
    "_links": {
        "self": {
            "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions"
        }
    },
    "_embedded": {
        "verifyTransactions": [
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/029ea878-2618-4067-b7e3-922591e6b55f"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "029ea878-2618-4067-b7e3-922591e6b55f",
                "transactionStatus": {
                    "status": "APPROVED_NO_REQUEST"
                },
                "createdAt": "2022-02-17T20:32:22.052Z",
                "updatedAt": "2022-02-17T20:32:58.711Z",
                "expiresAt": "2022-02-17T21:02:58.711Z"
            },
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/cca479e7-d130-4e3c-b888-74ba1920f59a"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "cca479e7-d130-4e3c-b888-74ba1920f59a",
                "transactionStatus": {
                    "status": "REQUESTED"
                },
                "qrUrl": "https://api.pingone.com/v1/idValidations/shortcode/086645084110/qr",
                "verificationCode": "086645084110",
                "createdAt": "2022-02-17T20:23:58.662Z",
                "updatedAt": "2022-02-17T20:23:58.662Z",
                "expiresAt": "2022-02-17T20:53:58.662Z"
            },
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/52c9bf9a-0687-4e01-85d1-9caa9bb387ee"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "52c9bf9a-0687-4e01-85d1-9caa9bb387ee",
                "transactionStatus": {
                    "status": "REQUESTED"
                },
                "qrUrl": "https://api.pingone.com/v1/idValidations/shortcode/008299320746/qr",
                "verificationCode": "008299320746",
                "createdAt": "2022-02-17T20:23:08.887Z",
                "updatedAt": "2022-02-17T20:23:08.887Z",
                "expiresAt": "2022-02-17T20:53:08.887Z"
            },
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/dd5a6d4f-a999-4819-b107-85a0a10138c6"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "dd5a6d4f-a999-4819-b107-85a0a10138c6",
                "transactionStatus": {
                    "status": "REQUESTED"
                },
                "createdAt": "2021-12-09T13:45:34.882Z",
                "updatedAt": "2021-12-09T13:45:34.882Z",
                "expiresAt": "2022-12-09T14:15:34.882Z"
            },
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/bfc414cb-a1b4-46b8-b622-3d806a85002f"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "bfc414cb-a1b4-46b8-b622-3d806a85002f",
                "transactionStatus": {
                    "status": "REQUESTED"
                },
                "createdAt": "2021-12-08T21:34:52.424Z",
                "updatedAt": "2021-12-08T21:34:52.424Z",
                "expiresAt": "2022-12-08T22:04:52.424Z"
            },
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/b21db4c4-01c5-47b5-a2a9-3d8df21d189b"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "b21db4c4-01c5-47b5-a2a9-3d8df21d189b",
                "transactionStatus": {
                    "status": "APPROVED_NO_REQUEST"
                },
                "createdAt": "2021-12-07T21:33:22.088Z",
                "updatedAt": "2021-12-07T21:45:22.944Z",
                "expiresAt": "2022-12-07T22:15:22.944Z"
            },
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/e44ebfe2-6a76-4ffa-ac35-d71ee9365e57"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "e44ebfe2-6a76-4ffa-ac35-d71ee9365e57",
                "transactionStatus": {
                    "status": "APPROVED_NO_REQUEST"
                },
                "createdAt": "2021-12-07T19:55:16.630Z",
                "updatedAt": "2021-12-07T21:31:26.835Z",
                "expiresAt": "2022-12-07T22:01:26.835Z"
            },
            {
                "_links": {
                    "self": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/36ff33da-cba7-4d46-bedc-8b242889d461/verifyTransactions/fc695b11-93a4-48bb-9ec3-ff5738e3818c"
                    },
                    "environment": {
                        "href": "https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
                    },
                    "user": {
                        "href": "https://api.pingone.com/v1/users/36ff33da-cba7-4d46-bedc-8b242889d461"
                    }
                },
                "id": "fc695b11-93a4-48bb-9ec3-ff5738e3818c",
                "transactionStatus": {
                    "status": "REQUESTED"
                },
                "createdAt": "2021-12-07T18:36:48.156Z",
                "updatedAt": "2021-12-07T18:36:48.156Z",
                "expiresAt": "2021-12-07T19:06:48.153Z"
            }
        ]
    },
    "size": 8
}

For more information on verification transaction data, refer to Read All Verify Transactions.

Manage Verify Transactions Script

The name of the script to process the JSON containing verification transactions relating to the user.

The script must be of type PingOne Verify Completion Decision.

Refer to Example scripts.

Capture failure

Capture the details in shared state if a failure occurs.

The node stores the details in a variable named pingOneVerifyCompletionFailureReason.

Default: False

Example:

{
  "code": "VERIFY_COMPLETION_SCRIPT_ERROR",
  "message": "Error evaluating the verify completion decision script.",
  "exception": "",
}

Outputs

The node is non-interactive and does not send a callback to the client.

If the node discovers that the user’s most recent Verify transaction is not yet complete, it adds the ID of the transaction to the shared state, in a variable named pingOneVerifyTransactionId. The PingOne Verify Evaluation node can use this value to continue the existing Verify evaluation, rather than start a brand new one.

If you select Capture failure, the node stores any error response in a shared state variable named pingOneVerifyCompletionFailureReason.

If you enable the Use a Script to process Verify Transactions property, the script you specify can add values to the shared state, as required.

Outcomes

Success

The user successfully completed their most recent PingOne Verify evaluation.

Failure

The user did not successfully complete their most recent PingOne Verify evaluation, or an error occurred.

Expired

The user’s most recent PingOne Verify evaluation timed out. Usually this happens when a user starts a verification transaction, but does not complete it within the time limit.

Not Started

The user’s most recent PingOne Verify evaluation has not yet started.

Not Completed

The user’s most recent PingOne Verify evaluation has started, but not yet completed.

Examples

Example journey

The following example journey leverages PingOne Verify to perform user identity verification.

Example PingOne Verify journey
Figure 7. Example PingOne Verify journey
  • The user enters their credentials, which the Data Store Decision node then verifies against the identity store.

  • 1 The PingOne Identity Match node checks PingOne for a matching user.

  • 2 If a user is found, the PingOne Verify Completion Decision node checks the user’s most recent verification transaction to determine the status:

    Success

    The user successfully completed the most recent PingOne Verify transaction, so continue directly to the Success node, completing the authentication journey.

    Not Completed

    The user has an existing PingOne Verify transaction in progress, so continue the journey to resume the existing verification transaction.

    The node adds the user’s existing transaction ID to the shared node state in a variable named pingOneVerifyTransactionId.

    Not Started / Failure / Expired

    The user either does not have an existing transaction (Not Started), or did not successfully complete the most recent PingOne Verify transaction, or it expired, so continue the journey to start a new verification transaction.

  • 3 If a user is not found, the PingOne Create User node creates a new user in PingOne.

  • 4 The PingOne Verify Evaluation node starts a new PingOne Verify evaluation, or continues an existing one if pingOneVerifyTransactionId is present in the shared node state, and either completes or fails the journey based on the result.

Example scripts

The following example PingOne Verify Completion Decision scripts demonstrate some use cases for this node:

Example 1

Check the status of the user’s most recent Verify transaction and that the ID used was a driving license.

Show example script
/** ******************************************************************
 *
 * The following script checks the status of the user's most recent
 * identity check, and ensures the ID used was a driver's license.
 *
 * Global node variables accessible within this scope:
 * 1. `sharedState` provides access to auth tree state attributes
 * 2. `verifyTransactionsHelper` provides access to verify transactions
 * 3. `outcome` variable maps to auth tree node outcomes; values are
 *    'successOutcome', 'notStartedOutcome', 'notCompletedOutcome',
 *    'expiredOutcome', or 'failureOutcome'.
 * ******************************************************************/

// Retrieve the user's latest verified transaction.
var result = verifyTransactionsHelper.getLastVerifyTransaction();
if (result != null) {
    var lastTransaction = JSON.parse(result);
    if (lastTransaction.hasOwnProperty("transactionStatus")) {
        // Get the status of the transaction.
        var status = lastTransaction.transactionStatus.status;
        // Determine the document type and verify if it is a Driver's License.
        var verifiedDocuments = lastTransaction.verifiedDocuments;
        if (status == "SUCCESS" && verifiedDocuments.includes("driver_license")) {
            outcome = "successOutcome";
        } else {
            outcome = "failureOutcome";
        }
    } else {
        outcome = "notStartedOutcome";
    }
}
Example 2

Check the ID used in the user’s most recent Verify transaction and that their age is 18 or over.

This data is available for a short timeframe after the verification.

Usually 30 minutes after PingOne Verify reaches its verification decision.

Show example script
/** ******************************************************************
 *
 * The following script checks the ID used in the user's most recent
 * identity check, and that their age is 18 or over.
 *
 * Note:
 * This data is available for a short timeframe after the verification.
 * Usually 30 minutes after a verification decision is reached.
 *
 * Global node variables accessible within this scope:
 * 1. `sharedState` provides access to auth tree state attributes
 * 2. `verifyTransactionsHelper` provides access to verify transactions
 * 3. `outcome` variable maps to auth tree node outcomes; values are
 *    'successOutcome', 'notStartedOutcome', 'notCompletedOutcome',
 *    'expiredOutcome', or 'failureOutcome'.
 * ******************************************************************/

// Retrieve the user's latest verified transaction.
var result = verifyTransactionsHelper.getLastVerifyTransaction();
if (result != null) {
    var lastTransaction = JSON.parse(result);
    if (lastTransaction.hasOwnProperty("id")) {
        // Obtain the ID of the last transaction.
        var lastTransactionId = lastTransaction.id;
        // Get the verified data for the Government ID provided by the user.
        var verifiedDataResult = verifyTransactionsHelper.getVerifiedDataByType(lastTransactionId, "GOVERNMENT_ID");
        // Determine the age of the user.
        if (verifiedDataResult != null) {
            var verifiedData = JSON.parse(verifiedDataResult);
            var dateString = verifiedData._embedded.verifiedData[0].data.birthDate;
            if (dateString != null && dateString.trim() != "") {
                var birthDate = new Date(dateString + "T00:00:01");
                var currentDate = new Date().getTime();
                var difference = currentDate - birthDate;
                var currentAge = Math.floor(difference / (1000 * 60 * 60 * 24 * 365.25));
                if (currentAge >= 18) {
                    outcome = "successOutcome";
                } else {
                    outcome = "failureOutcome";
                }
            } else {
                outcome = "failureOutcome";
            }
        } else {
            outcome = "notCompletedOutcome";
        }
    } else {
        outcome = "notStartedOutcome";
    }
} else {
    outcome = "notStartedOutcome";
}
Example 3

Check the user’s most recent Verify transaction to obtain the expiration date for the Government ID provided.

The node stores this information in a variable named governmentIdExpireDate in the shared state, but you could also store it in a user attribute to determine when to perform the next identity verification.

This data is available for a short timeframe after the verification.

Usually 30 minutes after PingOne Verify reaches its verification decision.

Show example script
/** ******************************************************************
 *
 * The following script checks the user's most recent Verify transaction
 * to obtain the expiration date for the Government ID provided.
 *
 * This information is stored in a variable named `governmentIdExpireDate`
 * in the shared state, but could also be stored as a user attribute
 * to determine when to perform the next identity verification.
 *
 * Note:
 * This data is available for a short timeframe after the verification.
 * Usually 30 minutes after a verification decision is reached.
 *
 * Global node variables accessible within this scope:
 * 1. `sharedState` provides access to auth tree state attributes
 * 2. `verifyTransactionsHelper` provides access to verify transactions
 * 3. `outcome` variable maps to auth tree node outcomes; values are
 *    'successOutcome', 'notStartedOutcome', 'notCompletedOutcome',
 *    'expiredOutcome', or 'failureOutcome'.
 * ******************************************************************/

// Retrieve the user's latest verified transaction.
var result = verifyTransactionsHelper.getLastVerifyTransaction();
if (result != null) {
    var lastTransaction = JSON.parse(result);
    if (lastTransaction.hasOwnProperty("id")) {
        // Obtain the ID of the last transaction.
        var lastTransactionId = lastTransaction.id;
        // Get the verified data for the Government ID provided by the user.
        var verifiedDataResult = verifyTransactionsHelper.getVerifiedDataByType(lastTransactionId, "GOVERNMENT_ID");
        // Get the expire date and set on shared state.
        if (verifiedDataResult != null) {
            var verifiedData = JSON.parse(verifiedDataResult);
            var expireDate = verifiedData._embedded.verifiedData[0].data.expirationDate;
            if (expireDate != null && expireDate.trim() != "") {
                sharedState.put("governmentIdExpireDate", expireDate);
                outcome = "successOutcome";
            } else {
                outcome = "failureOutcome";
            }
        } else {
            outcome = "notCompletedOutcome";
        }
    } else {
        outcome = "notStartedOutcome";
    }
} else {
    outcome = "notStartedOutcome";
}
Example 4

Check that the user has at least one successful identity verification in the past 365 days.

Show example script
/** ******************************************************************
 *
 * The following script checks that the user has at least one successful
 * identity verification in the past 365 days.
 *
 * Global node variables accessible within this scope:
 * 1. `sharedState` provides access to auth tree state attributes
 * 2. `verifyTransactionsHelper` provides access to verify transactions
 * 3. `outcome` variable maps to auth tree node outcomes; values are
 *    'successOutcome', 'notStartedOutcome', 'notCompletedOutcome',
 *    'expiredOutcome', or 'failureOutcome'.
 * ******************************************************************/

// Retrieve all transactions for the user
var result = verifyTransactionsHelper.getAllVerifyTransactions();
if (result != null) {
    var allTransactions = JSON.parse(result);
    if (allTransactions != null && allTransactions.length > 0) {
        // Loop through the transactions to find a successful verification within the last 12 months.
        var verifyTransactions = allTransactions._embedded.verifyTransactions;
        var found = false;
        for (var i = 0; i < verifyTransactions.length; i++) {
            var transaction = verifyTransactions[i];
            // Get the status of the transaction.
            var status = transaction.transactionStatus.status;
            // If status is success, verify if it is still valid
            if (status == "SUCCESS") {
                // Calculate the number of days
                var dateString = transaction.createdAt;
                var createdDate = new Date(dateString);
                var currentDate = new Date().getTime();
                var difference = Math.abs(createdDate - currentDate);
                var numDaysBetween = difference / (1000 * 60 * 60 * 24);
                if (numDaysBetween <= 365) {
                    outcome = "successOutcome";
                    break;
                } else {
                    outcome = "expiredOutcome";
                }
                found = true;
            }
        }
        // No successful transaction found
        if (found == false) {
            outcome = "failureOutcome";
        }
    } else {
        outcome = "notStartedOutcome";
    }
} else {
    outcome = "notStartedOutcome";
}
Example 5

Check the user’s most recent Verify transaction to review the biographic match results.

The script uses the Failure outcome if the match confidence for any attribute is anything other than HIGH.

Show example script
/** ******************************************************************
 *
 * The following script checks the user's last identity verification to
 * review the "Biographic Match" results.
 *
 * The script uses the failure outcome if the match confidence for any
 * attribute is below `HIGH`.
 *
 * Global node variables accessible within this scope:
 * 1. `sharedState` provides access to auth tree state attributes
 * 2. `verifyTransactionsHelper` provides access to verify transactions
 * 3. `outcome` variable maps to auth tree node outcomes; values are
 *    'successOutcome', 'notStartedOutcome', 'notCompletedOutcome',
 *    'expiredOutcome', or 'failureOutcome'.
 * ******************************************************************/

// Retrieve the user's latest verified transaction.
var result = verifyTransactionsHelper.getLastVerifyTransaction();
if (result != null) {
    var lastTransaction = JSON.parse(result);
    if (lastTransaction.hasOwnProperty("id")) {
        // Obtain the ID of the last transaction.
        var lastTransactionId = lastTransaction.id;
        // Get all the metadata.
        var allMetadataResult = verifyTransactionsHelper.getAllMetadata(lastTransactionId);
        // Loop through the metadata to find the biographic match results.
        var biographicMatchResults;
        if (allMetadataResult != null) {
            var allMetadataJson = JSON.parse(allMetadataResult);
			var allMetadata = allMetadataJson._embedded.metaData;
            for (var i = 0; i < allMetadata.length; i++) {
                var metadata = allMetadata[i];
                var type = metadata.type;
                var status = metadata.status;
                if (type == "BIOGRAPHIC_MATCH" && status == "SUCCESS") {
                    biographicMatchResults = metadata.data.biographic_match_results;
                    break;
                }
            }
        } else {
            outcome = "failureOutcome";
        }
        // Validate the biographic match results
        if (biographicMatchResults != null && biographicMatchResults.length > 0) {
            var success = true;
            for (var j = 0; j < biographicMatchResults.length; j++) {
                var match = biographicMatchResults[j].match;
                if (match != "HIGH") {
					success = false;
					break;
                }
            }
            if (success) {
                outcome = "successOutcome";
            } else {
                outcome = "failureOutcome";
            }
        } else {
            outcome = "failureOutcome";
        }
    } else {
        outcome = "notStartedOutcome";
    }
} else {
    outcome = "notStartedOutcome";
}

PingOne Verify Evaluation node

The PingOne Verify Evaluation node leverages the PingOne Verify Service to initiate a new or continue an existing verification transaction.

It offers a range of delivery methods, such as a QR code, email, or SMS to start the identity verification process.

You can customize the verification types users can perform in the PingOne Verification Policy.

Learn more in Verify policies.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes 1

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

1 Currently available only in the rapid release channel.

Inputs

This node requires that the user has an account in the PingOne environment. It requires that the journey stored the PingOne user ID for the account in a shared state variable named pingOneUserId.

Use a PingOne Identity Match node to populate the shared state with the user’s PingOne ID.

If there’s a transaction ID in the shared state variable named pingOneVerifyTransactionId, this node continues that evaluation, rather than starting a new one.

Use a PingOne Verify Completion Decision node to determine the status of any previous transactions and populate the shared state with an in-progress transaction ID.

Dependencies

This node requires a PingOne Worker Service configuration so that it can connect to your PingOne instance and send it the necessary data to perform PingOne Verify evaluations as part of the journey.

You can find information on the properties used by the service in PingOne Worker service.

Configuration

Property Usage

PingOne Worker Service ID

The ID of the PingOne worker service for connecting to PingOne.

Verify Policy ID

The ID of the policy to use for the PingOne Verify evaluation.

If not specified, the node uses the environment’s default Verify policy.

Verify URL delivery method

How the user will receive the URL they need to start a PingOne Verify evaluation.

Choose from:

QR Code

Display the URL as a QR code.

Email

Send an email containing the URL to the email address in the user’s PingOne Advanced Identity Cloud identity profile.

SMS

Send an SMS containing the URL to the phone number in the user’s PingOne Advanced Identity Cloud identity profile.

Redirect

Redirect the user to the PingOne Verify web app for identity verification.

On completion, redirect the user back to PingOne Advanced Identity Cloud to continue the authentication journey.

Default: QR Code

Allow user to choose the URL delivery method

When enabled, the node prompts the user to choose the URL delivery method.

Delivery method message

Add the text per locale to display when prompting the user to choose their delivery method:

  1. Click Add.

  2. In the Key field, enter the locale.1

    If the incoming HTTP request does not include the header or the preferred locales do not match any configured locales, the node uses the first text in the list.

  3. In the Value field, enter the text to display to the user.

    If you leave this blank, the node displays a localized version of the following text: Select the delivery method to start the identity verification process.

To edit an entry, click its pencil icon ().

To remove an entry, click its delete icon ().

QR code message

Add the text per locale to display when you select QR code as the delivery method:

  1. Click Add.

  2. In the Key field, enter the locale.1

    If the incoming HTTP request does not include the header or the preferred locales do not match any configured locales, the node uses the first text in the list.

  3. In the Value field, enter the text to display to the user.

    If you leave this blank, the node displays a localized version of the following text: Scan the QR code to initiate the identity verification process.

To edit an entry, click its pencil icon ().

To remove an entry, click its delete icon ().

Redirect message

Add the text per locale to display when you select Redirect as the delivery method, and the node redirects the user back to PingOne Advanced Identity Cloud to continue the journey:

  1. Click Add.

  2. In the Key field, enter the locale.1

    If the incoming HTTP request does not include the header or the preferred locales do not match any configured locales, the node uses the first text in the list.

  3. In the Value field, enter the text to display to the user.

To edit an entry, click its pencil icon ().

To remove an entry, click its delete icon ().

Waiting message

Add the text per locale to display while waiting for the user to respond to the Verify transaction, when using the SMS or Email delivery methods:

  1. Click Add.

  2. In the Key field, enter the locale.1

    If the incoming HTTP request does not include the header or the preferred locales do not match any configured locales, the node uses the first text in the list.

  3. In the Value field, enter the text to display to the user.

    You can use the following variable in the Value field:

    {{verificationCode}}

    Replaced with a 6-digit code that the user can compare with the code displayed when they begin verification, to ensure it matches. For example, 981092.

    pingone verify verification code
    Figure 8. Compare the code displayed on screen with the code presented during verification.

    If you leave this blank, the node displays a localized version of the following text: Waiting for identity verification completion. Here is the code you will see on your device: {{verificationCode}}

To edit an entry, click its pencil icon ().

To remove an entry, click its delete icon ().

Biographic Matching

Require that the specified data obtained from the user’s identity documents match the paired attribute in the user’s profile.

To create a pairing:

  1. Click Add.

  2. In the Key field, enter the biographic matching requirement.

    One of:

    referenceSelfie

    The photo the user took of themselves, in base64 encoded data form.

    phone

    The phone number obtained from the user’s identification.

    email

    The email address obtained from the user’s identification.

    given_name

    The first, or given name obtained from the user’s identification. For example, Babs.

    family_name

    The last, surname, or family name obtained from the user’s identification. For example, Jensen.

    name

    The full name obtained from the user’s identification. For example, Babs Jensen.

    address

    The address obtained from the user’s identification, as a single string. For example, 123 Any Street, London, United Kingdom, CH15 1EE.

    birth_date

    The date of birth obtained from the user’s identification.

  3. In the Value field, enter the attribute in the user’s PingOne Advanced Identity Cloud profile that should match.

    For example, you could pair the family_name biographic key to the sn profile attribute.

To edit an entry, click its pencil icon ().

To remove an entry, click its delete icon ().

Store Verification Metadata

When enabled, store the verification metadata returned from PingOne Verify in shared state under a key named pingOneVerifyMetadata.

Example verification metadata
{
    "_links":{
        "self":{
            "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94/verifyTransactions/7668563d-0226-4ca5-8401-03f6dc5bcdc6/metaData"
        },
        "user":{
            "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94"
        },
        "environment":{
            "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
        },
        "verifyTransaction":{
            "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94/verifyTransactions/7668563d-0226-4ca5-8401-03f6dc5bcdc6"
        }
    },
    "_embedded":{
        "metaData":[
            {
                "_links":{
                    "self":{
                        "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94/verifyTransactions/7668563d-0226-4ca5-8401-03f6dc5bcdc6/metaData/4ebb9165-4e5c-4270-94e4-d50d7b17ecb4"
                    }
                },
                "id":"4ebb9165-4e5c-4270-94e4-d50d7b17ecb4",
                "provider":"IDRND",
                "type":"LIVENESS",
                "status":"SUCCESS",
                "data":{
                    "score":6.4909873,
                    "probability":0.99848527,
                    "quality":0.94462675
                },
                "retry":{
                    "attempt":2
                }
            },
            {
                "_links":{
                    "self":{
                        "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94/verifyTransactions/7668563d-0226-4ca5-8401-03f6dc5bcdc6/metaData/546d3a8e-f606-4078-92f1-96a5c2d003e9"
                    }
                },
                "id":"546d3a8e-f606-4078-92f1-96a5c2d003e9",
                "provider":"AMAZON",
                "type":"FACIAL_COMPARISON",
                "status":"SUCCESS",
                "data":{
                    "similarity":99.37002,
                    "confidence":99.99767,
                    "quality":{
                        "brightness":36.77353,
                        "sharpness":20.92731
                    }
                }
            },
            {
                "_links":{
                    "self":{
                        "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94/verifyTransactions/7668563d-0226-4ca5-8401-03f6dc5bcdc6/metaData/96315a69-fb46-4d28-9b0d-c79927e59df1"
                    }
                },
                "id":"96315a69-fb46-4d28-9b0d-c79927e59df1",
                "provider":"BIOGRAPHIC_MATCHER",
                "type":"BIOGRAPHIC_MATCH",
                "status":"SUCCESS",
                "data":{
                    "biographic_match_results":[
                        {
                            "identifier":"address",
                            "match":"NOT_APPLICABLE"
                        },
                        {
                            "identifier":"given_name",
                            "match":"NONE"
                        },
                        {
                            "identifier":"family_name",
                            "match":"HIGH"
                        },
                        {
                            "identifier":"birth_date",
                            "match":"HIGH"
                        }
                    ]
                }
            },
            {
                "_links":{
                    "self":{
                        "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94/verifyTransactions/7668563d-0226-4ca5-8401-03f6dc5bcdc6/metaData/fba13756-8c24-49ff-9b42-ff1a3661d0ae"
                    }
                },
                "id":"fba13756-8c24-49ff-9b42-ff1a3661d0ae",
                "provider":"MITEK",
                "type":"DOCUMENT_AUTHENTICATION",
                "status":"SUCCESS",
                "data":{
                    "mitekVerifications":[
                        {
                            "name":"Document Ensemble Authenticator",
                            "judgement":"Authentic",
                            "verificationType":202,
                            "probability":753,
                            "version":"3.47.0.7114",
                            "documentId":"048f28f1-a7fe-42a5-9722-f10977606719"
                        },
                        {
                            "name":"Black And White Copy",
                            "judgement":"Authentic",
                            "verificationType":102,
                            "probability":717,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"Image Classification",
                            "judgement":"Authentic",
                            "verificationType":105,
                            "probability":1000,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"Data Comparison",
                            "judgement":"Authentic",
                            "verificationType":700,
                            "probability":1000,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"Ensemble Authenticator",
                            "judgement":"Authentic",
                            "verificationType":201,
                            "probability":753,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"ID Document Blacklist",
                            "judgement":"Authentic",
                            "verificationType":101,
                            "probability":1000,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"Generic Font",
                            "judgement":"Authentic",
                            "verificationType":104,
                            "probability":926,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"MRZ Check Digit",
                            "judgement":"Authentic",
                            "verificationType":601,
                            "probability":1000,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"MRZ Font Type Authentication",
                            "judgement":"Authentic",
                            "verificationType":600,
                            "probability":1000,
                            "version":"3.47.0.7114",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"Image Processing",
                            "judgement":"Authentic",
                            "verificationType":710,
                            "probability":1000,
                            "version":"1.0",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        },
                        {
                            "name":"Document Liveness",
                            "judgement":"Authentic",
                            "verificationType":108,
                            "probability":999,
                            "version":"1.0",
                            "documentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856"
                        }
                    ],
                    "frontImageDocumentId":"e290d74d-bf9c-4116-9fe7-9b6fb909c856",
                    "documentEvidenceId":"048f28f1-a7fe-42a5-9722-f10977606719",
                    "retry":{
                        "attempt":1
                    }
                }
            }
        ]
    },
    "previousAttempts":[
        {
            "_links":{
                "self":{
                    "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/03df72b1-b80b-4449-8eef-ee8f85f48d94/verifyTransactions/7668563d-0226-4ca5-8401-03f6dc5bcdc6/metaData/06aebfbd-0053-4860-8b59-4f3cb7371dcb"
                }
            },
            "id":"06aebfbd-0053-4860-8b59-4f3cb7371dcb",
            "provider":"IDRND",
            "type":"LIVENESS",
            "status":"FAIL",
            "data":{
                "score":2.4509223,
                "probability":0.40062885,
                "quality":0.40874674
            },
            "retry":{
                "attempt":1
            }
        }
    ],
    "size":4
}
The key is empty if the node is unable to retrieve the verification metadata from PingOne.

Default: Disabled

Store Verified Data

When enabled, store a list of the verified data submitted by the user in shared state under a key named pingOneVerifyVerifiedData.

Example verified data
{
    "_links":{
        "self":{
            "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/a27dec16-1e80-4f10-a261-2cac46a12b78/verifyTransactions/0e2ed48f-6c3a-46c4-bcb5-3a6bd791348b/verifiedData/34613a50-672c-428f-8db9-c67fe09fc4cc"
        },
        "environment":{
            "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6"
        },
        "user":{
            "href":"https://api.pingone.com/v1/users/a27dec16-1e80-4f10-a261-2cac46a12b78"
        },
        "transaction":{
            "href":"https://api.pingone.com/v1/environments/abfba8f6-49eb-49f5-a5d9-80ad5c98f9f6/users/a27dec16-1e80-4f10-a261-2cac46a12b78/verifyTransactions/0e2ed48f-6c3a-46c4-bcb5-3a6bd791348b"
        }
    },
    "id":"84170421-62c6-49a5-b343-496bee93c206",
    "type":"GOVERNMENT_ID",
    "createdAt":"2022-02-23T15:51:01.603Z",
    "data":{
        "addressCity":"this city",
        "addressState":"this state",
        "addressZip":"11111",
        "birthDate":"1970-01-01",
        "country":"USA",
        "expirationDate":"1970-01-01",
        "firstName":"given",
        "gender":"",
        "idNumber":"11111",
        "issueDate":"1970-01-01",
        "issuingCountry":"",
        "lastName":"surname",
        "nationality":"",
        "weight":""
    },
    "retry":{
        "attempt":1
    }
}
The key is empty if the node is unable to retrieve the verified data from PingOne.

Default: Disabled

Capture failure

Capture the details in shared state if a failure occurs.

The node stores the details in a variable named pingOneVerifyEvaluationFailureReason.

Default: False

Example:

{
  "code": "IDENTITY_VERIFICATION_FAILED",
  "message": "Identity verification failed.",
  "exception": "",
}

1 Specify a locale that Java supports, such as en-gb. Otherwise, the node throws a configuration exception with an Invalid locale provided message.

Outputs

  • If Allow user to choose the URL delivery method is selected, the node sends the following callbacks:

    TextOutputCallback

    Contains the Delivery method message.

    ConfirmationCallback

    Contains the options available to the client application.

  • When using the QR Code URL delivery method, the node sends the following callbacks:

    TextOutputCallback

    Contains the QR Code message.

    ScriptTextOutputCallback

    Contains JavaScript script to run to display the QR code.

    HiddenValueCallback

    Contains the actual URL to start the verification. The client might display this to users on a mobile device that cannot scan a QR code, or to render their own QR code, for example.

    PollingWaitCallback

    Waits for the user to complete the verification, and the Waiting message.

  • When using the Email or SMS URL delivery method, the node sends the following callbacks:

    PollingWaitCallback

    Waits for the user to complete the verification, and contains the Waiting message.

  • When using the Redirect delivery method, the node sends the following callbacks:

    RedirectCallback

    Contains the URI to redirect the user to for identity verification, using the PingOne Verify web application.

  • If you select Store Verification Metadata, the node outputs the verification metadata JSON in a state variable named pingOneVerifyMetadata.

    To learn more about verification metadata, refer to Read All Verification Metadata.

  • If you select Store Verified Data, the node outputs the verified information gathered from the user’s ID in a state variable named pingOneVerifyVerifiedData.

    To learn more about verified data, refer to Read One User Verified Data.

  • If you select Capture failure, the node stores any error response in a shared state variable named pingOneVerifyEvaluationFailureReason.

Outcomes

Success

The user successfully completed the PingOne Verify evaluation.

Failure

The user did not successfully complete the PingOne Verify evaluation, or an error occurred.

Time Out

The node did not receive a response from the user performing the verification before the timeout specified in the Verify Transaction Timeout property.

Example

The following example journey leverages PingOne Verify to perform user identity verification.

Example PingOne Verify journey
Figure 9. Example PingOne Verify journey
  • The user enters their credentials, which the Data Store Decision node then verifies against the identity store.

  • 1 The PingOne Identity Match node checks PingOne for a matching user.

  • 2 If a user is found, the PingOne Verify Completion Decision node checks the user’s most recent verification transaction to determine the status:

    Success

    The user successfully completed the most recent PingOne Verify transaction, so continue directly to the Success node, completing the authentication journey.

    Not Completed

    The user has an existing PingOne Verify transaction in progress, so continue the journey to resume the existing verification transaction.

    The node adds the user’s existing transaction ID to the shared node state in a variable named pingOneVerifyTransactionId.

    Not Started / Failure / Expired

    The user either does not have an existing transaction (Not Started), or did not successfully complete the most recent PingOne Verify transaction, or it expired, so continue the journey to start a new verification transaction.

  • 3 If a user is not found, the PingOne Create User node creates a new user in PingOne.

  • 4 The PingOne Verify Evaluation node starts a new PingOne Verify evaluation, or continues an existing one if pingOneVerifyTransactionId is present in the shared node state, and either completes or fails the journey based on the result.

Platform Password node

The Platform Password node prompts the user to enter their password and stores it in a configurable property of the shared node state.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node uses the _id of the object for policy evaluation.

For existing users, the user’s _id must be in the shared state to evaluate user-specific policies, such as password history, cannot-contain-others, and so on. No _id is available for new users.

Dependencies

If this node’s Validate Password setting is enabled, the node relies on the underlying identity service for password policies.

Configuration

Property Usage

Validate Password

When enabled, this node uses the password policies in the underlying identity service to validate the user’s input. It returns any policy failures as errors.

For example, if you submitted an invalid password on registration, the response from this node would include a list of failed policies:

{
    "name": "failedPolicies",
    "value": [
        "{ \"params\": { \"minLength\": 8 }, \"policyRequirement\": \"MIN_LENGTH\" }",
        "{ \"params\": { \"numCaps\": 1 }, \"policyRequirement\": \"AT_LEAST_X_CAPITAL_LETTERS\" }",
        "{ \"params\": { \"numNums\": 1 }, \"policyRequirement\": \"AT_LEAST_X_NUMBERS\" }"
      ]
}

Default: disabled

Password Attribute

The attribute used to store a password in the managed identity object.

Default: password

Confirm Password

Enable this option to require the user to enter the password identically in a second field.

This property only displays when the node is placed within a Page node.

Default: disabled

Checkmark Policy Display

Enable this option to show a checkmark instead of faded bullet points on successful password validation.

This property only displays when the node is placed within a Page node.

Default: disabled

Outputs

On success, this node updates the Password Attribute property in the shared node state with the password.

The captured password is transient, persisting only until the authentication flow reaches the next node requiring user interaction. It may be persisted to the secure state if required later in the journey.

Outcomes

Single outcome path.

Errors

This node does not log error or warning messages of its own.

If it fails to get the result from the underlying identity service for a validation request, this node throws an exception with a Communication failure message.

Example

The following journey uses a Page node containing the Platform Username node and Platform Password node to collect the username and password and set their values in the shared node state:

Username and password authentication

Platform Username node

The Platform Username node prompts the user to enter their username and stores it in a configurable property of the shared node state.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

None.

Dependencies

If this node’s Validate Username setting is enabled, the node relies on the underlying identity service for username policies.

Configuration

Property Usage

Validate Username

When enabled, this node uses the username policies in the underlying identity service to validate the user’s input. It returns any policy failures as errors.

Only enable this field if you’re using this node as part of a registration journey. Don’t enable this field in an authentication journey because the validation includes verifying that the provided username doesn’t exist in the identity store.

Default: disabled

Username Attribute

The attribute used to store a username in the managed identity object.

Default: userName

Outputs

On success, this node updates the Username Attribute property in the shared node state with the username.

Outcomes

Single outcome path.

Errors

This node does not log error or warning messages of its own.

If it fails to get the result from the underlying identity service for a validation request, this node throws an exception with a Communication failure message.

Example

The following journey uses a Page node containing the Platform Username node and Platform Password node to collect the username and password and set their values in the shared node state:

Username and password authentication

Profile Completeness Decision node

Use progressive profile flows to check how much of a user’s profile has been completed, where the completeness of a profile is expressed as a percentage of user-viewable, and user-editable fields that are not null.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Properties

Property Usage

Profile Completeness Threshold

Percentage of user-viewable and user-editable fields in a profile that must be filled for the node to pass. Express this as a number between 0 and 100.

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Query Filter Decision node

The Query Filter Decision node checks if the contents of a user’s profile match the specified query filter.

Use this node to check whether an attribute of the user profile matches a specific pattern. For instance, use this in progressive profile flows to check if marketing preferences are set on a user’s profile.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads the Identity Attribute from the shared node state. If it can’t read the Identity Attribute, it reads the userName.

It uses the value to look up the identity object.

Dependencies

This node depends on the underlying identity service to look up the user object.

Configuration

Property Usage

Query Filter

A query filter used to check the contents of an object.

For details on constructing effective query filters, refer to Construct queries.

Default: none

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Default: userName

Outputs

None.

Outcomes

True

The node user profile matched the query.

False

Any other case.

Errors

This node doesn’t log error or warning messages of its own.

Example

Other journeys invoke the following progressive profile journey to capture missing profile attributes:

Testing whether an account has profile attributes

Required Attributes Present node

Checks the specified identity resource in the underlying identity service, and determines if all attributes required to create the specified object exist within the shared node state.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Properties

Property Usage

Identity Resource

The type of managed identity resource object this node creates. It must match the identity resource type for the current flow.

To check for the available managed identity resource types, go to the IDM admin UI, and open the Manage drop-down list in the upper right corner of the screen.

Identity managed object types are preceded by the icon.

Select Identity Provider node

Presents the user with a list of configured, enabled, social identity providers to use for authentication.

Use this node with the Social Provider Handler node to use the Social Identity Provider Service.

The node has two possible outputs: social authentication and local authentication. Local authentication can be turned off by disabling Include local authentication.

This node returns the SelectIdPCallback when more than one social identity provider is enabled, or a single provider is enabled as well as the Local Authentication option, It then requires a choice from the user. If no choice from the user is required, authentication proceeds to the next node in the flow.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Social Authentication

  • Local Authentication

To turn off local authentication, disable Include local authentication.

Properties

Property Usage

Include local authentication

Whether local authentication is included as a method for authenticating.

Offer only existing providers

Password attribute

Identity Attribute

Filter Enabled Providers

By default, the node displays all identity providers marked as Enabled in the Social Identity Provider Service as a selectable option. Specify the name of one of more providers to filter the list.

View the names of your configured social identity providers in AM admin UI under Realms > Realm name > Services > Social Identity Provider Service > Secondary Configurations.

If this field is not empty, providers must be in the list and must be enabled in the Social Identity Provider service to appear. If left blank, the node displays all enabled providers.

Terms and Conditions Decision node

Verifies the user has accepted the active set of terms and conditions.

You set up terms and conditions in the Ping Identity Platform admin UI. Learn more in Terms and conditions.

Use this node to verify the user has accepted terms and conditions before proceeding, for example, during login or progressive profile data collection.

You can use this node with the Accept Terms and Conditions node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Properties

Property Usage

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Time Since Decision node

Checks if a specified amount of time has passed since the user was registered.

For example, to prompt users to review your terms and conditions after the account is a week old, set the Elapsed Time property to 1 week. After that time has elapsed, the next time the user logs in, they are prompted to review your terms and conditions.

Use this node for progressive profile completion.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • True

  • False

Properties

Property Usage

Elapsed Time

The amount of time since the user was created, in minutes, that needs to elapse before this node is triggered.

This property also supports specifying basic time units. For example, when setting the property to 10080 minutes, writing 7 days or 1 week also works.

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Utility nodes

Agent Data Store Decision node

The Agent Data Store Decision node authenticates the agent using the data store for agent profiles and sets its authentication identifier if successful.

This node only authenticates agents, such as PingGateway and PingOne Advanced Identity Cloud Java and web agents.

Use the Data Store Decision node for other identities.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node requires the username and password properties in the incoming node state.

Obtain the agent credentials from the user or with a Zero Page Login Collector node.

Dependencies

This node depends on the underlying data store for agent profiles.

Configuration

This node has no configurable properties.

Outputs

This node copies the shared and transient states into the outgoing node state.

Outcomes

True

The credentials match those found in the data store for agent profiles.

False

The credentials do not match those found in the data store for agent profiles.

Errors

This node can log the following warnings:

Exception in data store decision node

The node couldn’t connect to the data store, or another error occurred.

invalid password error

The password doesn’t match.

invalid username error

The username doesn’t match any profiles found in the data store.

Example

The following example uses this node to authenticate an agent with the credentials provided:

Journey to authenticate an agent
  • The Zero Page Login Collector node collects the username and password from HTTP headers if provided.

  • The Page node collects the username and password interactively from the user.

  • The Agent Data Store Decision node verifies the agent credentials match those in the data store.

Anonymous Session Upgrade node

Upgrades an anonymous session to a non-anonymous session.

Use this as the first node in the flow.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

This node has no configurable properties.

Example

After using the Anonymous User Mapping node to access AM as an anonymous user, this node lets users upgrade their session to a non-anonymous one:

Lets anonymous users upgrade their session

Anonymous User Mapping node

Lets users log in to an application or website without providing credentials, by assuming the identity of a specified existing user account. The default user for this purpose is named anonymous.

Take care to limit access for such users. For example, grant anonymous users access to public downloads on your site.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Anonymous User Name

Specifies the username of an account that represents anonymous users. This user must already exist in the realm, and its user status must be active.

Example

The following example uses this node to grant access as an anonymous user to users who have performed social authentication access and do not have an existing profile:

Optionally authenticating as an anonymous user

Choice Collector node

Define two or more options to present to the user when authenticating.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Choice 1

    …​

  • Choice n

Properties

Property Usage

Choices

Enter two or more choice strings to display to the user.

To remove a choice, select its Delete icon .

To delete all choices, select the Clear all button in the Choices field.

Default Choice (required)

Enter the value of the choice to be selected by default.

If you do not specify a default choice, the first choice in the list becomes the default.

Prompt (required)

Enter the prompt string to display to the user when presenting the choices.

Field Display Type

Specifies the format of the options presented to the user.

This property only appears when the node is placed within a Page node.

Possible values are:

select

Lets the user select one or more options from a selection (default).

radio

Lets the user select a single option from a group of radio buttons.

Configuration Provider node

The Configuration Provider node is a scripted node that dynamically imitates another node and replaces it in the journey.

The script builds a map of configuration properties matching settings for the imitated node. The Configuration Provider node uses the settings to imitate the other node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

The specific shared state inputs depend on your script and the configuration it builds. The shared state data must include all required Script Inputs properties.

In other words, shared state data must include whatever the Script requires to prepare configuration data for the imitated node.

Dependencies

To prepare to use this node:

  1. Decide what type of node to imitate.

    The imitated node must have a defined set of outcomes. This can be a variable set of outcomes from a predefined list, such as the Polling Wait node, or a fixed set of outcomes, such as the Message node.

    You can’t use a node type whose outcomes are defined entirely by configuration, such as the Scripted Decision node.

  2. Create an appropriate Configuration Provider Node script.

    Base your script on the config-provider-node.js sample.

  3. Get the required configuration properties for the imitated node:

    1. Call the following API endpoint with the configProviderScript action to get a template script for the type of node you want to imitate:

      /realm-config/authentication/authenticationtrees/nodes/node-type?_action=configProviderScript

      For example, the following request returns a base64-encoded template script for a Polling Wait node:

      $ curl \
      --request POST \
      --header "session-cookie-name: tenant-admin-tokenId" \
      --header "Content-Type: application/json" \
      "https://tenant-env-fqdn/json/realm-config/authentication/authenticationtrees/nodes/PollingWaitNode?_action=configProviderScript"
      {
        "script":"LyoqCiAqIFRoZSBmb2xsb3dpbmcgc2.."
      }
    2. Decode the script and adjust the property values as required.

      Your script must have a config object; a map of configuration properties matching the settings of the imitated node. For example, a script for the Polling Wait node has the following structure:

      config = {
          "secondsToWait" : 8,
          "spamDetectionEnabled" : false,
          "spamDetectionTolerance" : 3,
          "waitingMessage" : { },
          "exitable" : false,
          "exitMessage" : { }
        };
  4. Copy the script to the node’s Script field.

    Refer to the example for a script that uses shared state data to set the node configuration.

Configuration

Property Usage

Script

Select the script you created for this node.

Node Type

Select the type of node to imitate. The list is restricted to node types with outcomes that are fixed or variable based on predefined values.

Script Inputs

Optionally, limit the shared state data properties in the shared state input to the selected Script.

Default: * (Any available shared state property)

Outputs

The outputs match those of the imitated node.

Outcomes

The Configuration Provider node inherits the outcomes of its configured Node Type. Connect these as you would the outcomes of the imitated node.

Nodes with a variable set of outcomes inherit all the possible outcomes even if runtime configuration makes them unreachable. Connect these outcomes to the Failure node.

This node also has a Configuration failure outcome. The Configuration failure outcome arises when:

  • The Configuration Provider node failed to build the configuration map.

  • The configuration map is missing required values.

  • The configuration map is invalid.

Errors

In addition to the messages from the imitated node, this node can log the following:

Warnings
  • Failed to collect inputs of contained node: node-type

    A required input property was missing.

  • Failed to get outcome provider for node type.

    The Node Type outcomes were missing.

Errors
  • Failed to configure node: node-type

    This corresponds to the Configuration failure outcome.

To troubleshoot HTTP errors this node causes, refer to the Errors section of the imitated node.

Examples

In the following example, the Configuration Provider node imitates a Message node.

The Configuration Provider settings are the following:

Script

A script to configure a Message node dynamically.

The script accesses the username from shared state data to set the message:

config = {
    "message": {"en-GB": `Hi ${nodeState.get("username")}. Please confirm you are over 18.`},
    "messageYes": {"en-GB": "Confirm"},
    "messageNo": {"en-GB": "Deny"},
    "stateField" : null
}
Node Type

Message Node

Script Inputs

username

The default, *, also works because username is one of the available shared state properties.

The Configuration Provider node is part of a journey where the user enters their username and password before getting the message screen, so their username is in the shared state data. Notice the outcomes of the node include those of the Message node (True, False):

Journey with a [.label]#Configuration Provider# node

When the journey reaches the Configuration Provider node, the script for the node retrieves the username and dynamically configures the node. The Configuration Provider node, imitating a Message node, prompts the user with the message:

A [.label]#Configuration Provider# node imitating a [.label]#Message# node
  • When the user clicks Confirm, the journey continues to the Increment Login Count node.

  • When the user clicks Deny, the journey continues to the Failure node.

  • If the configuration process fails, the node triggers the Configuration failure outcome and the journey continues to the Failure node. In this case, you can find the reason for the failure in the logs.

Email Suspend node

The Email Suspend node generates and sends an email, such as an address verification email based on an email template. This node relies on an email provider to send the email.

This node generates a unique link and passes it as the resumeURI property for the template.

Authentication pauses until the end user clicks the link in the email to resume the flow. If there’s no need to pause authentication and wait for a reply, use the Email Template node instead.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

The Email Suspend node either uses the identity profile in the shared state data or looks up the user profile. In either case, the node uses any applicable profile properties to populate the email template, omitting missing values from the populated template.

If Object Lookup is not enabled for the node (default), the shared state data must hold the Email Attribute with the recipient’s email address and any properties the email template uses.

If Object Lookup is enabled for the node, the shared state data must hold the profile value to match the configured Identity Attribute. The Email Suspend node uses the Identity Attribute to look up the profile, and its Email Attribute to get the recipient’s email address from the profile.

Dependencies

Before you use the Email Suspend node:

Configuration

Property Usage

Email Template Name

The name of the email template prepared as a dependency.

Default: registration

Email Attribute

The shared state data property or profile attribute for the recipient’s email address.

Default: mail

Email Suspend Message

The localized message to display when the node suspends authentication.

According to OWASP authentication recommendations, the message should be the same regardless of the validity of the recipient’s email address.

You can use plain text or HTML code in this message.

Default: An email has been sent to the address you entered. Click the link in that email to proceed.

Object Lookup

Whether to look up the managed identity profile.

Default: disabled

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

The node uses this when Object Lookup is enabled.

Default: userName

Outputs

This node doesn’t add to the shared state data.

Outcomes

The Email Suspend node has a single outcome path.

Evaluation continues when the end user clicks the link in the email to resume the flow.

Errors

This node doesn’t log any error or warning messages of its own.

Examples

The following default journeys use the Email Suspend node:

  • ForgottenUsername

  • ResetPassword

  • UpdatePassword

Forgotten username

In the default journey for recovering a forgotten username, the end user enters their email address to recover their username.

Before you start
  • Configure the email service.

    Use the built-in SMTP server.

  • Optionally use the email template editor to modify the forgottenUsername template.

The journey
Forgotten username journey with an [.label]#Email Suspend# node

a The Page node with an Attribute Collector node prompts for the end user’s email address.

b The Identify Existing User node attempts to look up the username by matching the email address to the email address in an identity profile.

The lookup fails if more than one user profile uses the same email address.

c The Email Suspend node reads the user profile, generates a unique resumeURI link to resume the journey, and populates the forgottenUsername email template. On success, the node makes a request to the email service to send the email. In any case, it displays the suspend message:

Message from an [.label]#Email Suspend# node

The node’s settings are:

Email Template Name

forgottenUsername

Email Attribute

mail (default)

Email Suspend Message

An email has been sent to the address you entered. Click the link in that email to proceed. (default)

Object Lookup

Enabled

Identity Attribute

mail

d When the end user clicks the link to resume the journey, the Inner Tree Evaluator node starts the Login journey.

Try the journey

Use the journey to recover the username for an account whose email you have access to. For example, if Babs Jensen’s account has your email address, the Email Suspend node sends you a message such as the following:

Email from the forgotten username journey

Follow the link to continue the journey and log in as Babs Jensen.

Registration

For an example registration journey showing how to use the Email Suspend node and the Email Template node, refer to the Email Template node examples.

Email Template node

The Email Template node generates and sends an email, such as a welcome email based on an email template. This node relies on an email provider to send the email.

This node doesn’t wait for a reply. If authentication should pause and wait for a reply to the email, use the Email Suspend node instead.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

The Email Template node uses the identity in the shared state data to get the profile, meaning the journey must have successfully authenticated or at least identified the recipient. When the journey reaches this node, the shared state must hold the profile value to match the configured Identity Attribute. The value can be in the username property or in a property having the same name as the Identity Attribute.

The Email Template node uses its Identity Attribute to look up the profile, and its Email Attribute to get the recipient’s email address from the profile. In other words, the node finds the recipient’s address and other properties in the profile, not the shared state data.

For example, if the node uses default configuration settings and Babs Jensen authenticated to the journey, the shared state includes "username": "bjensen". The node looks for a profile with "userName": "bjensen". It gets the recipient address from the profile’s mail attribute, such as "mail": "bjensen@example.com". The node uses any applicable profile attributes to populate the email template, omitting missing values from the populated template.

Dependencies

Before you use the Email Template node:

Configuration

Property Usage

Email Template Name

The name of the email template prepared as a dependency.

Default: welcome

Email Attribute

The profile attribute for the recipient’s email address.

Default: mail

Identity Attribute

The attribute used to identify the managed object in the underlying identity service.

Default: userName

Outputs

This node doesn’t add to the shared state data.

If the outcome is Email Sent, this node has sent the templated message to the recipient through the email service.

Outcomes

Email Sent

The node completed a request to send the message to the recipient.

If the message doesn’t reach its destination, the problem is with the delivery, not with the node.

Email Not Sent

The node failed to complete a request to send the message.

This outcome arises, for example, when one of the following happens:

  • The node can’t get the user profile.

  • The template doesn’t match the user profile.

  • The specified Email Attribute doesn’t contain an address.

According to OWASP authentication recommendations, any messages displayed in the journey should be the same in both cases.

Errors

This node doesn’t log any error or warning messages of its own.

Examples

Use the Email Template node to send an email message when the journey doesn’t depend on a reply. For example, send a welcome message when a user completes registration.

This example augments the default Registration journey and sends a welcome email.

Before setting up the journey:

  • Configure the email service.

    Use the built-in SMTP server.

  • Create an email template for the Email Template node.

    Use the platform email template editor to duplicate the Welcome template and customize your copy:

    A modified welcome email template in the editor

The journey is as follows:

Registration journey with an [.label]#Email Template# node
  1. The Page node prompts for the same information as the default Registration journey.

  2. The Email Suspend node sends a message to the registered email address with a link for the user to click.

    The journey proceeds when the user clicks the link, confirming their email address.

    It has default settings and uses the default Registration email template:

    The default registration email template
  3. The Create Object node stores the newly registered user’s profile.

  4. The Email Template node reads the user profile and populates the template from profile attribute values. It makes a request to the email service to send the message.

    Its settings are:

    Email Template Name

    The name of your welcome email template

    Email Attribute

    mail (default)

    Identity Attribute

    userName (default)

  5. The Increment Login Count node updates the count on successful authentication.

Use the journey to register an account for Babs Jensen with your email as the address. You receive two messages:

Emails from the registration journey

  • The Register new account message has a link to click to continue the journey, confirming you can access the registered email account.

  • The Your account has been created welcomes you on successful registration.

This demonstrates you have successfully used the Email Template node in a journey.

Failure URL node

Sets the redirect URL when authentication fails.

Specifying a failure URL overrides any gotoOnFail query string parameters.

For more information on how AM determines the redirection URL, and to configure the Validation Service to trust redirection URLs, refer to Success and failure redirection URLs.

The URL is also saved in the shared nodeState object on the failureUrl key.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Failure URL (required)

Specify the full URL to redirect to when authentication fails.

Get Session Data node

The Get Session Data node retrieves the value of a specified key from a user’s session data, and stores it in the specified key of the shared state (in scripts, the nodeState object).

Use this node only during session upgrade—​when the user has already successfully authenticated previously and is now upgrading their session for additional access. For more information on upgrading a session, refer to Session upgrade with MFA.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads values from the user’s session data.

Dependencies

This node can complete its function only when the user has an existing session. Precede this node in the flow with a Scripted Decision node using a script to determine whether an existing session is present:

if (typeof existingSession !== 'undefined') {
  outcome = "hasSession";
} else {
  outcome = "noSession";
}

Configuration

All the configuration properties are required:

Property Usage

Session Data Key

Specify the session data key whose value the node reads.

Default: none

Shared State Key

Specify the name of the shared node state field to hold the session data.

Default: none

Outputs

This node writes the Session Data Key value in the Shared State Key field of the shared node state.

It also writes the field and its value to the objectAttributes object in the shared node state.

Outcomes

Single outcome path; on success, the Shared State Key in the shared node state holds the session data.

Errors

If it cannot read the Session Data Key value, this node logs an Exception occurred trying to get data (<session-data-key>) from existing session error message.

Example

When the user has an active session, the following example gets the username from the session, collects the password, and confirms the username-password credentials:

Scripted node to check for a session at the start of the flow

The following table includes example keys from an existing session with their corresponding sample values:

Key Sample value

AMCtxId

e370cca2-02d6-41f9-a244-2b107206bd2a-122934

amlbcookie

01

authInstant

2023-04-04T09:19:05Z

AuthLevel

0

CharSet

UTF-8

clientType

genericHTML

FullLoginURL

/am/XUI/?realm=alpha#login/

Host

34.117.172.39

HostName

am.forgeblocks.com

Locale

en_US

Organization

dc=openam,dc=forgerock,dc=org

Principal

uid=amAdmin,ou=People,dc=openam,dc=forgerock,dc=org

Principals

amAdmin

Service

ldapService

successURL

/openam/console

sun.am.UniversalIdentifier

uid=amAdmin,ou=People,dc=openam,dc=forgerock,dc=org

UserId

amAdmin

UserProfile

Required

UserToken

amAdmin

webhooks

myWebHook

Inner Tree Evaluator node

The Inner Tree Evaluator node lets you nest authentication journeys as children within a parent. There is no limit to the depth of nesting.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

Any information collected or set by the parent journey, such as a username or the authentication level, is available in the child journeys.

For information about shared state data, refer to Access shared state data.

Dependencies

None.

Configuration

Property Usage

Tree Name

Select or enter the name of the authentication journey to evaluate.

You must set this value; there’s no default.

Outputs

Shared node state data collected by child journeys is available to the parent when evaluation of the child is complete, but data stored in transient and secure state is not. For instance, if a child journey collects and stores the user’s password in transient state, it cannot be retrieved by a node in the parent journey when evaluation continues.

For information about shared state data, refer to Access shared state data.

Outcomes

True

Successfully reached the Success node of the child.

False

Any other case.

Errors

If it cannot get the shared node state from the child, this node logs an Exception when gathering inner tree inputs message.

If the Tree Name doesn’t match an existing journey, this node throws an exception with a Configured tree does not exist: <tree-name> message.

Example

The following journey uses an Inner Tree Evaluator node for progressive profiling:

Login with progressive profiling
Progressive profiling journey

Message node

The Message node presents a custom, localized message to the user with customizable, localized positive and negative answer buttons the user must click to proceed.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads preferred locales from the incoming request context.

It doesn’t read from the shared node state.

This node has no required predecessor nodes.

Dependencies

None.

Configuration

Property Usage

Message

Add a custom, localized message per locale:

  1. Click Add.

  2. In the Key field, enter the locale.1

    The incoming HTTP request can include an Accept-Language header indicating the user’s preferred locales. If the incoming HTTP request doesn’t include the header or the preferred locales don’t match any configured locales, the node uses default settings. It uses the Realms > Realm Name > Authentication > Settings > General > Default Authentication Locale setting from the AM admin UI.

  3. In the Value field, enter the message to display to the user.

    If you leave this blank, the message node displays a localized version of Default message to the user.

To edit an entry, click the [.label]#Pencil# icon ().

To remove an entry, click the [.label]#Delete# icon ().

Positive answer

Add the text per locale for the positive answer button that triggers a True outcome:

  1. Click Add.

  2. In the Key field, enter the locale.1

    If the incoming HTTP request doesn’t include the header or the preferred locales don’t match any configured locales, the node uses the first text in the list.

  3. In the Value field, enter the text to display to the user.

    If you leave this blank, the button displays a localized version of Yes.

To edit an entry, click the [.label]#Pencil# icon ().

To remove an entry, click the [.label]#Delete# icon ().

Negative answer

Add the text per locale for the negative answer button that triggers a False outcome:

  1. Click Add.

  2. In the Key field, enter the locale.1

    If the incoming HTTP request doesn’t include the header or the preferred locales don’t match any configured locales, the node uses the first text in the list.

  3. In the Value field, enter the text to display to the user.

    If you leave this blank, the button displays a localized version of No.

To edit an entry, click the [.label]#Pencil# icon ().

To remove an entry, click the [.label]#Delete# icon ().

Shared State Property Name

The name of the node state property.

If set, the node adds the property to shared node state, setting its value to the numeric value of the outcome:

0

The user clicked the positive answer button.

1

The user clicked the negative answer button.

For example, if you set this to messageNodeOutcome and the user clicks the positive answer button, the node adds "messageNodeOutcome": 0 as a shared node state property.

Only Positive Answer

When enabled, the node displays only the positive answer button.

This property only displays when the node is placed within a Page node.

Show buttons as links

When enabled, the node shows the buttons as links instead.

This property only displays when the node is placed within a Page node.

1 Specify a locale that Java supports, such as en-gb; otherwise, the node throws a configuration exception with an Invalid locale provided message.

Outputs

When the Shared State Property Name setting has a value, the node adds the property to the shared node state. The property’s value is the numeric value of the outcome:

0

The user clicked the positive answer button.

1

The user clicked the negative answer button.

Outcomes

Returns a boolean outcome:

True

The user clicked the positive answer button.

False

The user clicked the negative answer button.

Errors

This node doesn’t cause authentication to fail unless you connect one of the outcomes to a Failure node.

If the message or answer button settings specify a locale Java doesn’t support, the node throws a configuration exception with an Invalid locale provided message. If this happens, fix the locale setting.

If this node encounters an internal configuration issue, it logs a warning message Error attempting to retrieve the realm/global default locale. If the warning persists, contact ForgeRock Support.

Examples

Use a Message node to:

  • Communicate an important message for the user to acknowledge.

  • Ask a question with a yes/no answer.

The following journey uses the Join VIPs Message Node to prompt the user to join the VIP program:

Inner journey prompting to join the VIP program
  • The Login Count Decision node triggers the Query Filter Decision node after every tenth authentication.

  • The Query Filter Decision node queries the user profile to determine whether they have signed up for the VIP program.

    If the user hasn’t signed up yet, the True outcome triggers the Join VIPs Message Node, which prompts the user to join the program:

    Presenting a true/false question to the user

    Node property settings:

    Message

    en-gb; Do you want to join our VIP program?

    Positive answer

    en-gb; Yes, please!

    Negative answer

    en-gb; No, thanks!

  • If the user clicks Yes, please! the Page node with an embedded Attribute Collector node collects opt-in choices to store in user profile attributes.

  • The Patch Object node updates the user profile with the attributes collected.

Call the journey using an Inner Tree Evaluator node from another authentication journey directly after an Increment Login Count node note:

Calling an inner journey for VIP signup

The VIP Signup Journey uses the login count from the Increment Login Count node in the Login Count Decision node to decide whether to prompt the user to join the VIP program.

Meter node

Increments a specified metric key each time evaluation passes through the node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Metric Key (required)

Specify the name of a metric to increment when evaluation passes through the node.

Page node

The Page node lets you combine multiple nodes that request input onto a single page for display to the user.

Drag and drop nodes onto the Page node to combine them. Only add nodes that use callbacks to request input. Don’t add other nodes, such as the Data Store Decision node and the Push Sender node to this node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

The inputs are determined by the collective inputs of the contained nodes.

Dependencies

None.

Configuration

Property Usage

Page Header

Optional. A localized title for the Page node and the nodes contained within it. Use this when components of an authentication journey need a title. For example, dividing a registration flow into labeled sections.

Page Description

Optional. A localized description for the Page node and the nodes contained within it. Use this when you need additional descriptive text in an authentication journey. You can use HTML code to format the description.

Stage

Optional. A stage name to pass to the client to aid in rendering. NOTE: You can’t configure a Stage for this node if you configure a Page Footer, Theme or Submit Button Text. These properties overwrite the value of the Stage property.

Submit Button Text

Optional. Use the Key and Value fields to set the text of the Submit button.

Page Footer

Optional. A localized footer for the page node and the nodes contained within it. Use this when you need additional descriptive text in an authentication journey. You can use HTML code to format the footer.

Theme

Optional. If using hosted pages, specify a theme to override this journey’s UI theme.

This node’s optional properties are passed in the response, but a self-hosted or custom UI must support these properties to make them visible to the end user.

Outputs

The outputs are determined by the collective outputs of the contained nodes.

Outcomes

The outcomes are determined by the last node in the Page node. Only the last node in the page can have more than one outcome path.

Errors

This node can log the following error messages:

Message Notes

Failed to collect inputs of contained node: <node-name>

The <node-name> could not retrieve required properties from the shared node state

Failed to collect outputs of contained node: <node-name>

The <node-name> could not retrieve required properties to include in the shared node state

Could not find the identity based on the information available on context

Failed to find the account profile with this username in this realm

An error occurred when trying to lock out the user account

Failed to update the account status; applies when locking and unlocking the account

This node can throw exceptions with the following messages during operation:

Message Notes

This page has no nodes in it, so cannot proceed

A Page node must contain at least one other node

No outcome and only metadata callbacks found

Failed to get to an outcome while processing the contained nodes

Node properties cannot be fetched

Failed to access the properties of a contained node

This node can throw exceptions with the following messages when saving the journey:

Message Notes

Illegal child node type: <node-type>

A Page node can’t contain a <node-type>

Node does not have any outcomes: <node-type>

The contained nodes must have at least a single outcome path

Only the last node in a page can have more than one outcome

Consider rearranging the contained nodes

Node does not exist: <node-id>

Use the journey editor to fix the problem

Could not load child node: <node>

Use the journey editor to fix the problem

Could not obtain outcomes for node: <node>

Use the journey editor to fix the problem

Example

The following example uses a Page node containing a Platform Username node, Platform Password node, and Choice Collector node:

Example journey showing Page node use

The flow prompts the user for all input on a single page:

User’s view of an example journey containing a Page node

Polling Wait node

Pauses authentication progress for a specified number of seconds, for example, to wait for a response to a one-time passcode email or push notification.

Requests made during the wait period are sent a PollingWaitCallback callback and an authentication ID. For example, the following callback indicates a wait time of 10 seconds:

{
    "authId": "eyJ0eXAiOiJK...u4WvZmiI",
    "callbacks": [
        {
            "type": "PollingWaitCallback",
            "output": [
                {
                    "name": "waitTime",
                    "value": "10000"
                },
                {
                    "name": "message",
                    "value": "Waiting for response..."
                }
            ]
        }
    ]
}

The client must wait 10 seconds before returning the callback data, including the authId:

$ curl \
--request POST \
--header "Accept-API-Version: resource=2.0, protocol=1.0" \
--header "Content-Type: application/json" \
--data '{
  "authId": "eyJ0eXAiOiJK…​u4WvZmiI",
  "callbacks": [
      {
          "type": "PollingWaitCallback",
          "output": [
              {
                  "name": "waitTime",
                  "value": "10000"
              },
              {
                  "name": "message",
                  "value": "Waiting for response…​"
              }
          ]
      }
  ]
}' \
'https://am.example.com:8443/am/json/realms/root/realms/alpha/authenticate?authIndexType=service&authIndexValue=Example'

The end user UI automatically waits for the required amount of time and resubmits the page to continue evaluation. The message displayed during the wait is configurable with the Waiting Message property.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

  • Done

  • Exited (configurable)

  • Spam (configurable)

Evaluation continues along the Done outcome path when the next request is received after the wait time has passed.

Enabling Spam detection adds a Spam outcome path to the node. Evaluation continues along the Spam outcome path if more than the specified number of requests are received during the wait time.

Enabling the user to exit without waiting adds an Exited outcome path to the node. Evaluation continues along the Exited outcome path if the user clicks the button that appears when the option is enabled. The message displayed on the exit button is configurable by using the Exit Message property.

Properties

Property Usage

Seconds To Wait

Specify the number of seconds to pause authentication.

Default: 8

Enable Spam Detection

Specify whether to track the number of responses received during the wait time, and continue evaluation along the Spam outcome path if the number specified in the Spam Tolerance property is exceeded.

Default: Disabled

Spam Tolerance

Specify the number of responses to allow during the wait time before continuing evaluation along the Spam outcome path. This property only applies if spam detection is enabled.

Default: 3

Waiting Message

Specifies the optional message to display to the user.

Provide the message in multiple languages by specifying the locale in the KEY field, for example, en-US. For information on valid locale strings, refer to JDK 11 Supported Locales. The locale selected for display is based on the user’s locale settings in their browser.

Messages provided in the node override the defaults provided by AM.

Exitable

Whether the user can exit the node during the wait period.

Enabling this option adds a button with a configurable message to the page. Clicking the button causes evaluation to continue along the Exited outcome path.

Default: Disabled

Exit Message

Specifies the optional message to display to the user on the button used to exit the node before the wait period has elapsed. For example, Cancel or Lost phone? Use Recovery Code. This property only applies if the Exitable property is enabled.

Provide the message in multiple languages by specifying the locale in the KEY field, for example, en-US. For information on valid locale strings, refer to JDK 11 Supported Locales. The locale selected for display is based on the user’s locale settings in their browser.

Messages provided in the node override the defaults provided by AM.

Register Logout Webhook node

Registers the specified webhook to trigger when a user’s session ends. The webhook triggers when a user explicitly logs out or the maximum idle time or expiry time of the session is reached.

The webhook is only registered if evaluation passes through this node. You can register multiple webhooks during the authentication process, but they must be unique.

For more information on webhooks, refer to Configure authentication webhooks.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Webhook name

Specify the name of the webhook to register.

Remove Session Properties node

Removes properties from the session. The session properties may have been set by a Set Session Properties node elsewhere in the flow.

If a specified key is not found in the list of session properties it is added to the session upon successful authentication, no error is thrown, and evaluation continues along the single outcome path.

If a specified key is found, the evaluation continues along the single outcome path after setting the value of the property to null.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Property Names (required)

Enter one or more key names of properties to remove from the session.

Retry Limit Decision node

Permits the specified number of passes through to the Retry outcome path before continuing evaluation along the Reject outcome path.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

The node takes the user ID from the shared state.

Outputs

If Save Retry Limit to User is enabled, the node increments the retry count and saves the number of failed attempts in the retryLimitNodeCounts property of the user profile. If the user can’t be identified as part of the journey context, the journey ends with an error.

If Save Retry Limit to User is disabled, the node increments the retry count and saves the number of failed attempts in a shared state property named nodeId.retryCount. The count is lost if the journey is restarted.

Prerequisites

None

Configuration

Property Usage

Retry limit

Specify the number of retries to allow.

Default: 3

Save Retry Limit to User

Specify whether the number of failed login attempts persists across multiple journeys until authentication is successful. Possible values are:

Enabled

The node saves the number of failed login attempts to the user’s profile. New flows using this node start with the stored value and continue to the retry limit.

AM resets the count after the user authenticates successfully with an authentication journey that contains this node.

If AM cannot find the user’s profile, authentication ends with an error.

Disabled

The node saves the number of failed login attempts in a shared state property named nodeId.retryCount and discards the value when the authentication journey ends.

For security reasons, you should enable this setting.

Default: Enabled.

Outcomes

  • Retry

  • Reject

Example

A RetryLimit authentication journey, showing Retry Limit Decision node use.

Scripted Decision node

The Scripted Decision node lets you run a server-side script in an authentication journey. It exists to let you connect the script to other nodes with the journey editor.

The script makes a decision to set the outcome for the node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

Scripted Decision node inputs depend entirely on the node’s server-side script.

The script has access to the authentication context including:

  • Headers from the request

  • Query string parameters from the request

  • Secrets configured for the realm

  • Shared state data

  • User profile data

The script can use callbacks to prompt the user for information.

For details about the inputs available to the script, refer to Scripted decision node API.

You can restrict available inputs using the Script Inputs field when configuring the node.

Dependencies

A Scripted Decision node depends on a Journey Decision Node script you create before you configure the node.

Configuration

Property Usage

Script

Select the script to run from the drop-down list.

Outcomes

Enter one string for each outcome the script can set.

The node shows only the outcomes you configure. If you omit an outcome string, you can’t connect it in the journey editor.

When the script sets an outcome you omitted in the configuration, it logs a warning. This can prevent the journey from completing successfully.

Script Inputs

Optionally, list the shared state data properties required by the script.

If you change the setting, you must declare each property or null for no properties.

Default: *. The script has access to all shared and transient state data.

Sensitive data in transient state upgrades to secure state if:

  • The node sends a callback to the user.

  • The node detects a downstream node requesting the transient state data as input.

Unless the downstream node explicitly requests the secure state data by name, the authentication journey removes it from the node state after processing the next callback.

For example, a node in a registration journey stores a user’s password in transient state. The node sends a callback to the user before an inner tree node, downstream in the journey, consumes that password. As part of the callback, the journey assesses what to add to the secure state. It does this by checking the state inputs that downstream nodes in the journey require. Nodes that only request * are ignored, as this would result in putting everything in transient state into secure state, and retaining sensitive information longer than necessary.

If a downstream node requires the password, it must explicitly request it as state input, even if it lists the * wildcard as input.

Script Outputs

Optionally, list the shared state data properties the node expects the script to set.

If you change the setting, you must declare each property or null for no properties.

Default: *. The node doesn’t validate the script outputs at all.

Outputs

Scripted Decision node outputs, such as updates to shared state data, depend entirely on the node’s server-side script.

You can restrict available outputs using the Script Outputs field when configuring the node.

Outcomes

The script defines the outcomes by setting its outcome variable to an outcome string before returning.

You include all possible outcome strings from the script in the Outcome field when configuring the node.

The authentication journey continues along the outcome path from the script.

Errors

The server-side script can log messages.

The node logs the following warning messages:

Warnings:

  • Found an action result from scripted node, but it was not an Action object: An action in a legacy script didn’t return an object with type Action.

  • Found an action result from scripted node, but it was not an ActionWrapper object: An action in a next generation script didn’t return an object with type ActionWrapper.

  • invalid script outcome <outcome>: The <outcome> is missing in the Outcome field of the node configuration.

  • invalid script outcome <action-outcome> in action: The <action-outcome> is missing in the Outcome field of the node configuration.

  • script outcome error: The script set an outcome not found in the Outcome field of the node configuration.

Examples

You use a Scripted Decision node when no other available node does what you need.

In this example, the node depends on the following JavaScript Journey Decision Node script. The script gets the user’s names from their profile and stores a message in a shared state property:

  • Next-generation

  • Legacy

// Get the username from shared state data:
var username = nodeState.get('username')

// Get the given name(s) and surname(s) from the user profile:
var profile = idRepository.getIdentity(username)
var givenname = profile.getAttributeValues('givenName')
var surname = profile.getAttributeValues('sn')
if (!(givenname && surname)) {
  var error = `Failed to get names for ${username}: ${givenname} ${surname}`
  action.goTo('Failure').withErrorMessage(error);
} else {
  // Record who authenticated in the shared state data:
  var firstGivenName = givenname[0]
  var firstSurname = surname[0]
  var now = new Date().toLocaleString()
  var message = `${firstGivenName} ${firstSurname} logged in at ${now}.`
  nodeState.putShared('message', message)
  action.goTo('Success');
}
var goTo = org.forgerock.openam.auth.node.api.Action.goTo

// Get the username from shared state data:
var username = nodeState.get('username').asString()

// Get the given name(s) and surname(s) from the user profile:
var profile = idRepository.getIdentity(username)
var givenname = profile.getAttributeValues('givenName')
var surname = profile.getAttributeValues('sn')
if (!(givenname && surname)) {
  var error = `Failed to get names for ${username}: ${givenname} ${surname}`
  action = goTo('Failure').withErrorMessage(error).build()
} else {
  // Record who authenticated in the shared state data:
  var firstGivenName = givenname[0]
  var firstSurname = surname[0]
  var now = new Date().toLocaleString()
  var message = `${firstGivenName} ${firstSurname} logged in at ${now}.`
  nodeState.putShared('message', message)
  action = goTo('Success').build()
}

Notice the script sets the outcomes using the Action.goTo(outcome) function.

The journey is as follows:

Journey with a [.label]#Scripted Decision# node
  1. The Page node prompts the user for their username and password.

  2. The Identity Store Decision node checks the username and password with those in the identity store.

    The node configuration enables the optional Username as Universal Identifier setting. As a result, the nodeState.get('username').asString() function in the script returns the user’s _id. The username in idRepository.getIdentity(username) must be the _id, not the userName, to get the attribute from the user’s profile.

  3. The Scripted Decision node runs the script and has the following settings:

    Script

    The name of the script

    Outcomes

    Success, Failure

    Script Inputs

    username

    Script Outputs

    *

    Notice the Outcomes setting lists all outcome strings from the script.

  4. The Increment Login Count node updates the count on successful authentication.

  5. The Inner Tree Evaluator node refers to another journey to perform more steps.

    This node is optional.

If you activate debug mode for the journey and select Enable Debug Popup, you find the message in the debug popup window when authenticating:

{
  "universalId": "id=<_id>,ou=user,o=alpha,ou=services,ou=am-config",
  "transactionId": "<transaction-id>",
  "password": "<password>",
  "pageNodeCallbacks": {
    "0": 0,
    "1": 1
  },
  "realm": "/alpha",
  "message": "Babs Jensen logged in at August 16, 2023 9:55:33 AM UTC.",
  "authLevel": 0,
  "objectAttributes": {
    "password": "<password>"
  },
  "username": "id=<_id>"
}

Set Session Properties node

The Set Session Properties node adds key:value properties to the user’s session on successful authentication.

You can access session properties using a variable in a webhook. Learn more in Configure authentication webhooks.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

None. This node does not read shared node state data.

Dependencies

Ensure the user can successfully authenticate and get a session.

If the user never gets a session, this node has no effect.

Configuration

Property Usage

Properties

The session properties to set.

  • To add a session property:

    1. Click , then Add in the Properties modal.

    2. Enter the session property name in the Key field and the value to set in the Value field.

    3. Click Done.

  • To edit a property:

    1. Click the Pencil icon ().

    2. Update the Key and Value as when adding properties.

  • To remove a property, click the Delete icon ().

When finished, click Save to keep your settings.

Outputs

This node sets session properties; it does not change the shared state data.

This node cannot override system session properties, such as the principal or the authentication level. Use a different journey to re-authenticate the user rather than trying to change such properties with this node.

Outcomes

Single outcome path: when the journey completes successfully, this node sets the configured session properties.

Errors

This node does not log messages of its own.

Examples

The following example uses the Set Session Properties node to update the successURL session property.

  • A first platform journey updates the session property on successful authentication:

    Setting a session property

    When the journey completes successfully, PingOne Advanced Identity Cloud updates the successURL in the user’s session data.

  • A second journey uses a script to display the session properties after the user authenticates:

    Showing session properties in the shared state data

    The Scripted Decision node calls the following script to inject the session properties into the shared state data so the journey can display them though a debug popup:

    if (typeof existingSession !== 'undefined') {
      nodeState.putShared('session', existingSession)
      action.goTo('hasSession')
    } else {
      nodeState.putShared('session', null)
      action.goTo('noSession')
    }

    The second journey has Debug mode and Enable Debug Popup selected.

Follow these steps to try the example:

  1. Create both journeys using the journey editor.

  2. Sign in through the first journey with a test user account.

    The browser shows the user profile page.

  3. In the same browser window, browse to the URL for the second journey.

    The debug popup window displays the shared state data including session properties:

    {
        "transactionId": "...",
        "session": {
            "successURL": "<your-success-url>",
            "...": "..."
        },
        "realm": "/alpha",
        "authLevel": 0,
        "username": "test"
    }

    The successURL property is set to <your-success-url>, the one you configured as the value in Properties of the Set Session Properties node.

  4. Sign out as the test user.

  5. Sign in through the default journey as the test user.

    The default journey doesn’t use the Set Session Properties node with your configuration, so it uses the default value for the successURL session property.

  6. In the same browser window, browse to the URL for the second journey again.

    The debug popup window displays the shared state data, including session properties with the default successURL value.

State Metadata node

The State Metadata node returns selected attributes from the shared node state as metadata.

This node sends a MetadataCallback to retrieve shared state values, which it adds to the JSON response from the /authenticate endpoint. This example shows how a shared state attribute, mail, is returned:

{
    "callbacks": [
        {
            "type": "MetadataCallback",
            "output": [
                {
                    "name": "data",
                    "value": {
                        "mail": "bjensen@example.com"
                    }
                }
            ]
        }
    ]
}

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node reads its configured Attributes from the shared node state.

Dependencies

None.

Configuration

Property Usage

Attributes

Specify one or more shared state attribute names for return.

Default: none

Outputs

This node only sends the callback. It does not modify the shared node state.

Outcomes

Single outcome path.

Evaluation continues after the callback.

Errors

This node does not log error or warning messages of its own.

Example

Use this node to display custom information that includes user attributes without having to alter the existing flow.

For example, for OTP authentication with a choice of email or SMS, use this node to return the user’s email address or phone number. You can use the attributes with an OTP Collector Decision node, and optionally, a Scripted Decision node, to customize the data for display later.

An example of OTP authentication with a State Metadata node.

Success URL node

Sets the redirect URL when authentication succeeds.

Specifying a success URL overrides any goto query string parameters.

For more information on how AM determines the redirection URL, and to configure the Validation Service to trust redirection URLs, refer to Success and failure redirection URLs.

The URL is also saved in the nodeState object on the successUrl key.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Properties

Property Usage

Success URL (required)

Specify the full URL to redirect to when the authentication succeeds.

Timer Start node

Starts a named timer metric, which you can stop with a Timer Stop node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Start Time Property

Specify a property name into which to store the current time.

Specify the same value in any instances of the Timer Stop node that measure the time elapsed since evaluation passed through this node.

Timer Stop node

Records the time elapsed since evaluation passed through the Timer Start node in the specified metric name.

Note that this node does not reset the time stored in the specified Start Time Property property. Other Timer Stop nodes can also calculate the time elapsed since evaluation passed through the same Timer Start node.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Outcomes

Single outcome path.

Properties

Property Usage

Start Time Property

Specify the property name containing the time from which to calculate the elapsed time.

Metric Key (required)

Enter the name for a new metric that stores the calculated elapsed time.

Metrics collate data from multiple invocations of a journey. To record the time it takes for a particular journey to complete, use a Scripted Decision node to store the start time in shared state. Use a script at the end of the journey to capture the end time and output the calculated journey time to the authentication audit logs.

Learn more in Audit information.

Uncategorized nodes

Identity Assertion node

The Identity Assertion node provides a secure communication channel for authentication journeys to communicate directly with PingGateway.

The node extends PingOne Advanced Identity Cloud by adding PingGateway’s routing capabilities and supporting identity assertion with third-party authentication services. Authentication services include Windows Desktop SSO and Kerberos.

The following image shows the flow of an authentication request:

cdsso

PingOne Advanced Identity Cloud and PingGateway share a symmetric key for encryption and decryption at both ends of the flow.

Compatibility

Product Compatible?

Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

All shared node state properties listed in Mapping to server claims are valid optional inputs to this node.

To allow the node to validate that an Identity Assertion JWT is the result of an identity request, the nonce must be present in the shared node state as identityAssertionNonce. This isn’t required for the initiating authentication request.

Dependencies

The Identity Assertion node relies on the following prerequisites:

  • An Identity Assertion service must be configured in the same realm, with at least one server configuration that can be selected for use with the Identity Assertion node.

  • The Identity Assertion service server must have a valid shared secret encryption key configured as an ESV in the secret store.

  • The Identity Assertion server must be deployed, running, and accessible to the Identity Assertion node.

    It must also be configured with the shared secret encryption key.

    PingGateway can fulfil the role of the Identity Assertion server.

To use the Identity Assertion node in your PingOne Advanced Identity Cloud environment, you must complete the following steps, as described in detail in the worked Example :

Configuration

The configurable properties for this node are:

Property Usage

Node name

The name given to this node in the Journey.

Default: Identity Assertion.

Identity Assertion server ID

The ID of the Identity Assertion server that handles assertion requests. The ID is composed of the server’s ID and realm (if realm-scoped).

Mapping to server claims (optional)

Mapping of:

  • Key: Shared node state key

  • Value: Identity request JWT claim

Required only if the server requires additional data.

When a shared node state attribute has a value for a mapped key, the value is added to the identity request JWT claims according to the corresponding claim.

Mapping from server result (optional)

Mapping of:

  • Key: Identity Assertion JWT claim

  • Value: Shared node state key

Required only if the server requires additional data.

Default: the JWT principal claim is mapped to the shared node state username attribute.

When an Identity Assertion JWT claim has a value for a mapped claim, the value is added to the shared node state according to the corresponding shared node state key.

Outputs

Any data mapped from the claims returned by the Identity Assertion server stored in the shared node state of the journey.

Successful Identity Assertion

The configuration Mapping from server result (optional) determines the shared node state property to set for the mandatory claim principal. The value of the shared node state property is set with the value of the principal claim.

For example, if principal is mapped to usernameReceived, the attribute usernameReceived is set in the shared node state. By default, principal is mapped to username.

Other values mapped in Mapping from server result (optional) are set in the shared node state only if the claim exists in the resulting Identity Assertion JWT.

Failed Identity Assertion

The shared node state property error is set with the value of the error claim in the resulting Identity Assertion JWT.

Outcomes

Success

The Identity Assertion server indicates that authentication was successful. It provides the authenticated principal.

Error

The Identity Assertion server indicates that authentication failed. It provides information about the error.

Troubleshooting

If the node logs an error, review the log to find the reason for the error.

Example

The following worked example describes how to use the Identity Assertion node to authenticate internal access.

Create and import a secret encryption key

Identity Assertion in PingOne Advanced Identity Cloud and PingGateway uses a single secret for all encryption and decryption:

  • PingOne Advanced Identity Cloud uses the key to encrypt the identity request JWT; PingGateway uses it to decrypt the identity request JWT.

  • PingGateway uses the key to encrypt the resulting Identity Assertion JWT; PingOne Advanced Identity Cloud uses it to decrypt the Identity Assertion JWT.

Provide the encryption key as a PEM-encoded AES secret key or base64aes-encoded secret key ESV.

The example route in Configure PingGateway as an Identity Assertion Server uses PEM for PingGateway and imports the secret key value as an ESV into PingOne Advanced Identity Cloud.

Configure a key for that route as described in this section, and learn more from Map ESV secrets to secret labels

Create a PEM key and import it into the tenant ESV
  1. Generate a random 32-byte AES secret-key:

    $ head -c32 /dev/urandom | base64
    Rf8...Ig=
  2. Put the key string into a .pem file called idassert.pem, for use on the PingGateway side.

    -----BEGIN AES SECRET KEY-----
    Rf8...Ig=
    -----END AES SECRET KEY-----

    In the following steps, you import the raw key as an ESV and configure it in an ESV secret store.

  3. Using information in Authenticate to Identity Cloud REST API with access token, get an access token for your tenant.

  4. Using the access token, import the new ESV into your tenant. The following example imports an ESV named esv-idassert:

    $ export VALUE=$(echo -n Rf8…​Ig= | base64)
    
    $ curl -X PUT "<tenant-env-fqdn>/environment/secrets/esv-idassert" \
      -H "Authorization: Bearer <TOKEN>" \
      -H "Content-Type: application/json" \
      -H "Accept-API-Version: protocol=1.0;resource=1.0" \
      --data-raw "{\"encoding\":\"base64aes\",\"useInPlaceholders\":false,\"valueBase64\":\"$VALUE\"}"

    Consider the following points for ESVs:

    • Prefix the name with esv-.

    • Don’t suffix the name with a number.

    • Use base64aes encoding. PEM encoding is also available.

  5. Using information in Tenant settings, check that the ESV is displayed in the Environment Secrets and Variables panel.

Configure the Identity Assertion service
Enable the service
  1. In the Advanced Identity Cloud admin UI, go to Native Consoles > Access Management > Realms > Realm name > Services, click +Add a Service and select Identity Assertion Service to create.

  2. In the Identity Assertion Service page, ensure Enable is selected.

Configure a server
  1. In the Secondary Configurations tab, click +Add a Secondary Configuration and enter the following information:

    • Name: A unique name for the Identity Assertion server. For example, use IG01.

    • Identity Assertion server URL: The Identity Assertion server URL. For example, enter https://ig.ext.com:8443.

    • Shared Encryption Secret: PingOne Advanced Identity Cloud uses this identifier to create a secret label for encrypting the identity request JWT and resulting Identity Assertion JWT.

      The secret label takes the form am.services.identityassertion.service.identifier.shared.secret where identifier is the value of Shared Encryption Secret. For example, use identifier idassert to create a label called am.services.identityassertion.service.idassert.shared.secret.

  2. Click Create.

  3. Keep the default values for JWT TTL (seconds) and Skew Allowance (seconds) and save your changes.

Learn more about the service configuration in Identity Assertion service .

Map the secret label to the encryption key

The example route in Configure PingGateway as an Identity Assertion Server uses PEM for PingGateway and imports the secret key value as an ESV into PingOne Advanced Identity Cloud.

  1. Log in to your Advanced Identity Cloud admin UI, and go to Native Consoles > Access Management.

  2. In the Realm Overview page, click Secret Stores.

  3. Map the secret label used by the Identity Assertion service to the ESV secret store.

    In the Mappings tab, enter the following information:

    • Secret Label: Enter the value for the Shared Encryption Secret you created in the Identity Assertion Service. For example, enter idassert.

      You can configure the secret only after you have named it in the Identity Assertion service secondary configuration.

      The full-length secret label is automatically constructed from the value. In this example, the full-length secret label is am.services.identityassertion.service.idassert.shared.secret.

    • Aliases: Enter the alias to the secret you created earlier. For example, enter esv-idassert.

Configure PingGateway as an Identity Assertion Server

Configure PingGateway to:

  • Validate the identity request JWT.

  • Create an encrypted Identity Assertion JWT to send back to PingOne Advanced Identity Cloud.

The PingGateway configuration includes two routes:

Authentication filter route

Directs unauthenticated requests to an authentication journey in PingOne Advanced Identity Cloud.

For testing purposes, configure PingOne Advanced Identity Cloud and PingGateway as described in Cross-domain single sign-on. The setup configures a demo user and validation service that are required for the example.

In cdsso-idc.json , the CrossDomainSingleSignOnFilter uses PingOne Advanced Identity Cloud’s default authentication service. Add the property authenticationService to the CrossDomainSingleSignOnFilter to direct requests to the journey.

The following example redirects unauthenticated requests to a journey called IgCallout.

{
  "name": "CrossDomainSingleSignOnFilter-1",
  "type": "CrossDomainSingleSignOnFilter",
  "config": {
    ...
    "authenticationService" : "IgCallout",
    ...
  }
Identity Assertion service route

Directs unauthenticated requests to a local authentication service such as Kerberos or Windows Desktop SSO.

Consider the example in PingGateway’s Example Identity Assertion service route for Identity Assertion node. The route contains an IdentityAssertionHandler that calls a ScriptableIdentityAssertionPlugin to manage local authentication.

The route requires the following:

  • The key and PingOne Advanced Identity Cloud setup described in this worked example.

  • That the IdentityAssertionHandler's peerIdentifier property refers to the host part of the tenant URL.

  • That the IdentityAssertionHandler's condition refers to the same path as the Route configured in the node. In this example, it refers to /idassert.

Configure the example authentication journey
identity assertion node

Add a Failure URL node to manage the journey flow if assertion fails. Configure the node with a URL to use for failed requests. For example, the following URL returns PingGateway to the CDSSO redirect endpoint:

https://ig.ext.com:8443/home/cdsso/callback?error=Login%20failed&error_description=Identity%20Assertion%20Failure

Configure the Identity Assertion node as follows: