PingOne Advanced Identity Cloud

Nodes and journeys

Journeys provide fine-grained authentication by allowing multiple paths and decision points throughout the authentication flow. Use them to build complex authorization scenarios, while offering a streamlined login experience to users.

Journeys are made up of nodes, which define actions taken during authentication. Each node performs a single task during authentication; for example, collecting a username or making a simple decision based on a cookie.

Nodes can have multiple outcomes rather than just success or failure. These outcomes let you create complex yet user-friendly authentication experiences by linking nodes together, creating loops and sections for different authentication scenarios, and nesting nodes within a journey.

Create multiple paths for authentication by linking nodes within journeys.
Figure 1. Example authentication journey

For greater control of the authentication process, you can assign authentication levels to sections of a journey, with higher levels typically allowing access to more restricted resources.

Learn more about creating an authentication journey using the Advanced Identity Cloud admin console in Journeys.

Authentication levels

When a user authenticates successfully, Advanced Identity Cloud creates a session which allows Advanced Identity Cloud to manage the user’s access to resources. The session is assigned an authentication level. The authentication level is often used as a measure of the strength of the authentication performed. For example, a simple username and password might be assigned a low authentication level, while multi-factor authentication with push and WebAuthn might be assigned a high level.

Authorization policies might require a particular authentication level to access protected resources. When an authenticated user tries to access a protected resource without satisfying the authentication level requirement, Advanced Identity Cloud denies access to the resource and returns an advice indicating that the user must reauthenticate at the required level to access the resource.

The policy enforcement point, such as an agent, sends the user back to Advanced Identity Cloud for a session upgrade.

Advanced Identity Cloud provides the following nodes to manage authentication levels:

Position these nodes to alter the authentication level, depending on the route taken through the authentication flow.

Account lockout

Use account lockout to limit the number of times an end-user can attempt to authenticate with invalid credentials before rendering their account inactive. Limiting the number of attempts helps to prevent password-guessing and brute-force attacks.

Authentication journeys have built-in support for account lockout. They also provide nodes for checking and changing the status of a user.

For more information refer to Account lockout.

Configure authentication webhooks

Webhooks are used to send HTTP POST calls to a server with contextual information about an authenticated session when a predefined event occurs, for example, logging out.

Webhooks are used from within authentication journeys, by the Register Logout Webhook node.

  1. Under Native Consoles > Access Management, go to Realms > Realm Name > Authentication > Webhooks.

  2. Select Create Webhook, specify a Webhook Name, and select Create.

    The webhook configuration screen is displayed:

    Creating a new authentication webhook.

  3. Complete the fields as required:

    Url

    The URL to which the HTTP POST is sent when the event occurs.

    Body

    The body of the HTTP POST. To send different data formats, set the correct Content-Type header in the Header property, for example:

    • Form Data. Enter the body value in the format parameter=value&parameter2=value2, and set a Content-Type header of application/x-www-form-urlencoded.

    • JSON Data. Enter the body value in the format {"parameter":"value","parameter2":"value2"}, and set a Content-Type header of application/json.

    Headers

    Any HTTP headers to add to the POST.

    To add a header, enter the name of the header in the Key field, and the value, and then click Add (➕).

    To remove a header, click Delete (✖).

    The fields in a webhook support variables for retrieving values from the user’s session after successfully authenticating. Specify a variable in the following format: ${variable_name}.

    To access the type of webhook event, use the WebhookEventType parameter key to return one of the following possible values:

    • LOGOUT

    • UPGRADE

    • DESTROY

    • MAX_TIMEOUT

    • IDLE_TIMEOUT

    For example, to retrieve the event type as a query parameter: &event=${WebhookEventType}

    You can use a variable to access custom properties added to the session with the Set Session Properties node as well as the following default session properties:

    Default session properties
    Property Example value Description

    AMCtxId

    22e73c81-708e-4849-b064-db29b68ef943-105372

    The audit ID for the session. This is logged as the trackingIds field in Advanced Identity Cloud access audit logs.

    authInstant

    2022-02-28T14:06:31Z

    The exact time that authentication completed.

    AuthLevel

    5

    The authentication level of the session, determined by the login mechanism used to create the session. For example, a journey can have an authentication level of 10.

    Step-up authentication is triggered if an authentication level specified by an agent or policy that is designed to protect a resource, is greater than or equal to the value of the AuthLevel session property.

    For more information, refer to Session upgrade with MFA.

    CharSet

    UTF-8

    The character set for the session, set to UTF-8.

    clientType

    genericHTML

    The type of client, set to genericHTML.

    FullLoginURL

    https://example.forgeblocks.com/platform/?realm=alpha

    The full login URL, including query parameters.

    Host

    192.0.2.1

    The originating IP address of the authentication request.

    HostName

    192.0.2.1

    The host name that was used when the session was authenticated.

    IndexType

    service

    Based on the value of the authIndexValue query parameter during authentication. Typically, this is set to service.

    Locale

    en_US

    The session locale.

    loginURL

    /am/XUI

    The base login URL. A subset of FullLoginURL.

    OidcSid

    g0wmSpoAIwH6HAwCnurvRcfYqh4

    Unique session ID used by Advanced Identity Cloud to determine whether OIDC ID tokens granted for the same client relate to the same session. This appears when Enable Session Management (storeOpsToken) is set to true in the OAuth 2.0 provider settings.

    Organization

    o=alpha,ou=services,dc=am,dc=example,dc=com

    The DN of the realm where authentication took place.

    Principal

    id=bjensen,ou=user,o=alpha,ou=services,dc=am,dc=example,dc=com

    The value of sun.am.UniversalIdentifier.

    Principals

    bjensen

    The username for the session.

    Service

    Example

    The name of the journey that was used to authenticate this session.

    successURL

    /am/console

    The URL that was redirected to, upon a successful login request.

    sun.am.UniversalIdentifier

    id=bjensen,ou=user,o=alpha,ou=services,dc=am,dc=example,dc=com

    The DN of the user (username is lowercase).

    UserId

    bjensen

    The id value from the Principal property.

    UserProfile

    Required

    Can be one of: Required, Create, Ignore, or CreateWithAlias. Based on the value of the dynamicProfileCreation authentication configuration. Values other than Ignore indicates that user profile attributes were mapped based on the User Attribute Mapping to Session Attribute setting. Refer to authentication configuration for details.

    Default: Required.

    UserToken

    bjensen

    The username, as defined in the Principal property.

    The following figure shows an example webhook, using variable substitutions:

    Example authentication webhook.

    Specifying a variable that isn’t present in the user’s session places the literal variable text in the HTTP POST, for example user=${UserId}, rather than user=bjensen.