Auth node reference

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.

Availability

Product Available?

PingOne Advanced Identity Cloud

Yes

PingAM (self-managed)

Yes

Ping Identity Platform (self-managed)

Yes

Inputs

This node has no required predecessor nodes.

It does not read from the shared node state.

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:

  • BATTERY_LEVEL

  • CPU_ARCHITECTURE

  • DEVICE_MODEL

  • DEVICE_VENDOR

  • GPS_SUPPORTED

  • HAS_CHROME_APP

  • IS_ACCEPT_COOKIES

  • NAVIGATOR_USER_AGENT

  • OS_NAME

  • OS_VERSION

  • RESOLUTION

  • TOUCH_SUPPORT

The attributes collected vary depending on the OS of the client.

For example, an Android device might provide different attributes to a JavaScript app running on Windows.

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 localStorage only.

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: 14

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.

Example PingOne Protect journey
Figure 1. Example PingOne Protect journey
  • 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 or Low

    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.