PingOne Protect Initialization node
The PingOne Protect Initialization node instructs the client to initialize a PingOne Signals (Protect) SDK so that it can start gathering device signals and contextual information:
-
If the client is a device or browser running a Ping SDK, this node initializes a PingOne Signals (Protect) SDK in the device or browser. This requires a Ping SDK v4.4.0 or later. Learn more in Integrate with PingOne Protect for risk evaluations.
-
If the client is a browser running Advanced Identity Cloud hosted pages, this node initializes the PingOne Signals (Protect) SDK for Web in the browser.
You should place this node as early as possible in your journey so that it can gather sufficient contextual information to make risk evaluations.
This node can only initialize the PingOne Signals (Protect) SDK in the client once. If you include a second instance of the node in a journey, it won’t initialize the PingOne Signals (Protect) SDK again and won’t override the initial node configuration.
Learn more in Getting started with PingOne Protect.
Availability
Product | Available? |
---|---|
PingOne Advanced Identity Cloud |
Yes |
PingAM (self-managed) |
Yes |
Ping Identity Platform (self-managed) |
Yes |
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 make risk evaluations as part of the journey.
Find information on the configuration properties in the PingOne Worker service documentation for:
Only Ping SDKs v4.4.0 and later support this node.
Configuration
Property | Usage | ||
---|---|---|---|
PingOne Worker Service ID |
The ID of the PingOne worker service for connecting to PingOne. |
||
Enable SDK Logs |
When enabled, output SDK log messages in the developer console. Default: Disabled |
||
Device Attributes To Ignore |
A list of device attributes you want to exclude from the results when collecting device signals. These attributes will not be sent to PingOne to perform evaluations, which might limit its ability to create accurate results. Some examples of attributes the client might obtain from the device include:
|
||
Custom Host |
Deprecated. We recommend that you do not change this property. |
||
Lazy Metadata |
When enabled, calculate metadata on demand. When not enabled, metadata is calculated automatically after initialization. Default: Disabled |
||
Collect Behavioral Data |
When enabled, collect behavioral data. When not enabled, behavioral data is not collected. Default: Enabled |
||
Disable Hub |
When selected, the client stores device data in the browser’s When not selected, an iframe is used. Default: Not selected |
||
Device Key Rsync Intervals (days) |
Number of days that device attestation can rely upon the device fallback key. Default: |
||
Enable Trust |
Tie the device payload to a non-extractable crypto key stored in the browser for content authenticity verification |
||
Disable Tags |
When selected, the client does not collect tag data. Tags are used to record the pages the user visited, forming a browsing history. Default: Not selected |
Outputs
The node sends a PingOneProtectInitializeCallback
to the client application.
The client consumes this callback and initializes the PingOne Protect functionality so it can start gathering the data it needs to make risk evaluations.
Outcomes
True
The client application confirmed successful receipt of the configuration.
False
The client application did not confirm successful receipt of the configuration or returned a client error.
Example
The following example journey leverages PingOne Protect functionality to perform a risk evaluation.

-
1 The PingOne Protect Initialization node instructs the Ping SDK or Advanced Identity Cloud hosted pages to initialize a PingOne Signals (Protect) SDK with the configured properties.
Initialize a PingOne Signals (Protect) SDK as early in the journey as possible, before any user interaction.
This enables it to gather sufficient contextual data to make an informed risk evaluation.
In the subsequent nodes, the end user enters their credentials, which are verified against the identity store.
-
2 The PingOne Protect Evaluation node performs a risk evaluation against a risk policy in PingOne.
The example journey continues depending on the outcome:
High
-
The journey requests that the user respond to a push notification.
Medium
orLow
-
The risk is not significant, so no further authentication factors are required.
Exceeds Score Threshold
-
The score returned is higher than the configured threshold and is considered too risky to complete successfully.
Failure
-
The risk evaluation could not be completed, so the authentication attempt continues to the Failure node.
BOT_MITIGATION
-
The risk evaluation returned a recommended action to check for the presence of a human, so the journey continues to a CAPTCHA node.
AITM_MITIGATION
-
The risk evaluation returned a recommended action regarding the possible presence of an adversary-in-the-middle attack, so the journey continues to the Failure node.
ClientError
-
The client returned an error when attempting to capture the data to perform a risk evaluation, so the authentication attempt continues to the Failure node.
-
3 An instance of the PingOne Protect Result node returns the
Success
result to PingOne to help with analysis and risk policy tuning. -
4 A second instance of the PingOne Protect Result node returns the
Failed
result to PingOne to help with analysis and risk policy tuning.You can broadly observe the risk evaluation results in the PingOne threat protection dashboard. You can also use an audit to review specific risk evaluation results, including the JSON response from the risk evaluation.