Healthcare - Progressive Verification during Authentication - Main Flow
The Healthcare - Progressive Verification during Authentication - Main Flow lets users sign on. It can be launched through the widget or through PingOne.
Purpose
The Healthcare - Progressive Verification during Authentication - Main Flow is one of the initial flows in the Healthcare flow pack solution. It enables existing users to sign on using a password and uses the Healthcare - Progressive Verification during Authentication - Device Authentication - Subflow flow to let existing users sign on using a known device.
Structure
This flow is divided into sections using teleport nodes:
- Flow Configuration
-
Uses multiple function nodes to save the variable and parameter values so that the correct values are available in the flow and in subflows. The flow then progresses to the Check Session, Call To Protect Analysis & MFA Step-Up section.
- Check Session, Call To Protect Analysis & MFA Step-Up
-
Uses a PingOne node to determine whether the user has an existing session:
-
If the user has a session, a hidden HTML node captures risk information, and a PingOne node fetches additional user information, then the flow progresses to the Threat Detection and Mitigation section. When this section completes, a function node checks if the user’s account is enabled, and if the user’s account is enabled, the flow progresses to the Return Success section.
-
If the user doesn’t have a session, the flow checks for any existing session tokens and uses a PingOne node to delete the prior session before invoking the Healthcare - Progressive Verification during Authentication - SignOn - Subflow subflow.
When the subflow completes, a function node updates the risk level, and a PingOne Authentication node creates a user session. A loading page displays, and a PingOne node retrieves user information.
Function nodes then evaluate the number of times the user has logged in. If the count is 2, 4, or 6 logins, the flow progresses to the Progressive profiling during authentication section. If the login count is less than 10, a PingOne node updates the login count. The flow then progresses to the Return Success section.
-
- Threat Detection and Mitigation
-
Uses a function node to check if PingOne Protect analysis is required:
-
If PingOne Protect analysis is not required, the flow returns to the previous section.
-
If PingOne Protect analysis is required, the flow invokes the Healthcare - Progressive Verification during Authentication - Threat Detection - Subflow.
If the Healthcare - Progressive Verification during Authentication - Threat Detection - Subflow completes successfully, a function node stores the risk evaluation as a variable, then a second function node branches the flow based on the risk level:
-
If the risk level is low, the flow returns to the previous section.
-
If the risk level is medium, the flow progresses to the MFA Authentication section. When this section completes, the flow returns to the previous section.
-
If the risk level is high, a function node checks if the high risk was the result of a new device. If not, a PingOne node notifies the user. A PingOne node deletes the existing session, and a loading page displays. The flow then progresses to the Check Session, Call To Protect Analysis & MFA Step-Up section.
If the Healthcare - Progressive Verification during Authentication - Threat Detection - Subflow completes unsuccessfully, a function node stores the risk evaluation as a variable and the flow progresses to the Return Error section.
-
-
- MFA Authentication
-
Uses a PingOne node to look up the user’s existing devices. An HTML node then checks the user’s current device for WebAuthn support, and comparison nodes filter for unusable devices and check if at least one device is configured.
If the user has no active devices or the user’s device information could not be found, the flow progresses to the Step up to register Email MFA device if no MFA devices found during authentication section.
If the user has active devices, the flow invokes the Healthcare - Progressive Verification during Authentication - Device Authentication - Subflow.
If the subflow completes successfully, a function node saves the user’s authentication method as a variable, and the flow returns to the previous section.
- Step up to register Email MFA device if no MFA devices found during authentication
-
A comparison node checks whether email verification is required.
If email verification isn’t required, the flow invokes the Healthcare - Progressive Verification during Authentication - Device Registration - Subflow. The section then branches based on the device registration result:
-
If the result is Complete, the user’s authentication method is stored as a variable and the flow returns to the previous section.
-
If the result is Skip, the flow returns to the previous section.
-
If the result is Cancel, the flow returns to the Return Error section if an existing session was found, and to the Offer Sign On Page section if no session was found.
If email verification is required, the flow invokes the Healthcare - Progressive Verification during Authentication - Verify Email - Subflow, then uses PingOne nodes to enroll email as an MFA device and enable MFA for the user. The user’s authentication method is stored as a variable, and the flow then returns to the previous section.
-
- Progressive profiling during authentication
-
Uses a function node to branch the flow based on the number of successful logins:
-
If the user has had two successful logins, an HTML node gathers emergency details.
-
If the user has had four successful logins, an HTML node gathers insurance details.
-
If the user has had six successful logins, an HTML node gathers information about medical conditions.
-
If the user has any other number of successful logins, the flow progresses to the Return Success section.
-
The flow then branches based on the user’s selection:
-
If the user clicked Save, a PingOne node saves the provided information and a success message displays. The flow then progresses to the Return Success section.
-
If the user clicked Cancel, the flow progresses to the Return Success section.
- Return Success
-
Sends a JSON Success Response, indicating that the flow completed successfully. Simultaneously, the flow uses function nodes to check for a PingOne Protect risk evaluation ID and verify that the user did not cancel. If a PingOne Protect risk evaluation ID is found and the user did not cancel, the flow uses a PingOne node to update the evaluation status with a success.
- Return Error
-
Uses a function node to enrich the error details, then displays an error message. The flow checks the flow invocation method, then sends an error JSON response with the appropriate parameters indicating tha the flow completed unsuccessfully.
The flow also simultaneously uses a function node to check for a PingOne Protect risk evaluation ID, and if a PingOne Protect risk evaluation ID is found, uses a PingOne node to update the evaluation status with a failure.
Input schema
This flow has the following inputs:
| Input name | Required | Description |
|---|---|---|
|
No |
An object containing parameters passed in if the flow was launched with the widget. |
Output schema
This flow has the following outputs:
| Output name | Description |
|---|---|
|
The user’s PingOne user ID. |
|
The user’s PingOne username. |
|
The authentication method that was configured by the flow. |
|
The success message to display. |
|
The error message to display. |
Variables and parameters
This flow uses the following variable or parameter values:
| Variable name | Description |
|---|---|
|
A Boolean indicating whether email should be the only permitted MFA device. |
|
The number of times the user has resent the OTP. |
|
The device ID for the device being registered. |