Activate User and User Attribute Process

Content

• Overview
• Multiple Process Orchestration
• ULM User Entity and AuthN ID Status
• Process Invocation
• Common Use Scenarios
• Process Flow
• App Settings
• User Journey Flow Diagram
• API Walkthroughs
• Error Codes
• Revision History

Overview

This Process defines how a user verifies and activates their ULM User ID (and/or one of its entity attributes). In other words, this Process activates a new user, or it activates a new authentication identifier (authN ID) that a user registers and adds to their ULM User ID.

Multiple Process Orchestration

Most user journeys are facilitated by a single Process. Conversely, there are some cases where ULM orchestrates and links two or more Processes to complete a given journey.

The Activate User (and User Attribute) Process completes a user journey initiated by a preceding process, typically in cases where the user opts to (or needs to) navigate away from the client UI, and then resume their interactions with ULM from a separate point of entry (e.g., a redirect URL in a verification email).

ULM User Entity and AuthN ID Status

ULM is built on top of a user-centric and entitlement-specific data model of ULM data entities. Each ULM entity is defined by a set of default and extensible attributes. Some of the extensible attributes are simple string values, and others are more complex arrays (i.e., list of objects that make up a single attribute).

Like all ULM entities, the User entity has a default or "top level" status attribute. All of a user's registered authN IDs are stored one level down inside the attributes array, and each authN ID has its own status.

When the GET /session/token API redeems an action token to invoke the Activate User Process, the token is contextually aware so that it knows what attribute(s) need to be updated.

Process Invocation

Unlike most ULM Processes, Activate User cannot be invoked with the Process Start API. Instead, the GET session/token API invokes this Process when it redeems an action token generated by a previous Process.

Possible API variations of calling the Process include the following:

GET session/token?token={token}

1. The user completes a Process.
2. The Process generates an action token and sends a clickable or tappable link in an email or SMS. The link includes a redirect URL back to the client application, and the action token value is appended to the URL string.
3. Once the user clicks/taps the link, they are redirected back to the client.
4. The client then takes the token value to call GET /session/token?token={token value} to trigger the Activate User Process.

GET session/token?customToken={OTP}&pkat={PKAT}

1. The user completes a Process.
2. The Process generates and sends a receives a short, custom One Time Passcode in an email or SMS. The Process also returns a pkat to the front-end client.
3. The front-end client prompts the user to enter their code to verify who they are.
4. Once the user enters their code, the client then takes the OTP and the PKAT to call GET /session/token?customToken={otp}&pkat{pkat} to trigger the Activate User Process.

Common Use Scenarios

The following use cases commonly involve the Activate User Process.

• A new, anonymous user onboards with their email or mobile. They then verify (activate) their email/mobile, and fully activate their User ID at the same time.
• A new, anonymous user onboards with their social account. However, they change the email/mobile sent back by the social provider. They then verify (activate) the new email/mobile, and fully activate their User ID at the same time.
• An existing, authenticated user registers a new email or mobile. They then verify (activate) the new email/mobile, and can now use it for authentication.
• An existing, authenticated user updates a current email or mobile with a new one. They then verify (activate) the new email/mobile. The old email/mobile is removed from the User ID.

Process Flow

These tables describe the Process at a high level.

App Settings

Out of the box, this Process includes the following application settings. These configurable settings modify and control the Process behaviour.

See the edge case under Alt Flow 1 above for context of where and how a password prompt may come into effect with this Process.

User Journey Flow Diagram

The Activate User Process concludes a variety of different user journeys. See the Journey Flow diagrams for the following Processes for an idea of how this Process fits into those journeys:

• Onboard User with Email & Mobile
• Onboard & Authenticate User with Social Account
• Add/Update Email, Mobile, or Alias
• Authenticate User (if the user attempts to sign in with an unverified or activating authN ID)

API Walkthroughs

The following section provides guided walkthroughs of the Activate User Process.

Activate User ID with OTP Scenario

A separate process sends an OTP to the user (and sends a PKAT to the client application UI). The client application prompts the user for that OTP.

Request

The Session Token API initiates the Process, and uses the OTP the PKAT as URL parameters:

<no body>

Response

If the token is valid, the Process starts, activates the User ID (and/or the user's authN ID), and returns a 200 HTTP status code.

{
  "processId": "0c931a26-61df-4ed4-8121-592e0cf8c3dc",
  "lastStep": true,
  "runtimeId": 5014,
  "userId": 6040,
  "UserAuthenticated": true 
}

The Process also authenticates the user (if they are not already authenticated).

Response Parameters

Activate AuthN ID with Link Scenario

A separate process sends a clickable verification link to the user (and sends a PKAT to the client application UI). The link includes a redirect URL back to the client, and the action value appended to the URL. The client application prompts the user to go to their email/mobile to verify it.

Request

The user clicks the verification link, which then redirects them back to the client. The Session Token API initiates the Process and uses the token value as a URL parameter:

<no body>

Response

If the token is valid, the Process starts, activates the authN ID, and returns a 200 HTTP status code:

{
    "processId": "0c931a26-61df-4ed4-8121-592e0cf8c3dc",
    "lastStep": true,
    "runtimeId": 5014,
    "userId": 6040,
    "userAuthenticated": true 
}

The Process also authenticates the user (if they are not already authenticated).

Response Parameters

Activate AuthN ID with Link, Password Required

A user onboards into ULM successfully with their social account. Therefore, they have a verified authN ID but no password. The user decides to add a another authN ID to their user profile, and that Process sends a clickable verification link to the user (and sends a PKAT to the client application UI). The link includes a redirect URL back to the client, and the action value appended to the URL. The client application prompts the user to go to their email/mobile to verify it.

However, in this scenario, the Process prompts for a required password before it completes its task. This is because a user must set a password before they are allowed to have more than one authN ID.

Initial Request

The user clicks the verification link, which then redirects them back to the client. The Session Token API initiates the Process and uses the token value as a URL parameter:

<no body>

Initial Response: Prompt for Password

If the token is valid, the Process starts and prompts the user to set a password:

{
    "processId": "c8f337af-5cf1-4958-bdc2-e83fb942c8fd",
    "processName": "onboard.ActivateUserAndAttribute.v1.0",
    "stepName": "CreateCredentialPrompt",
    "lastStep": false,
    "displayMessage": "Please set a password",
    "parameters": {
        "credential": "String"
    },
    "output": {
        "activatedAuthenticationIdentifier": {
            "type": "EMAIL",
            "value": "email@amdocs.com"
        },
        "userDisplayName": "Jane Smith",
        "newUser": false
    }
}

Response Parameters

Next Request: User Provides Password

The user enters their desired password, and the client passes that info to the Process with the Process Step API.

{
    "processId": "c8f337af-5cf1-4958-bdc2-e83fb942c8fd",
    "parameters": {
        "credential": "Test_test1!13"
    }
}

Request Parameters

Final Response: Success

If the password passes validation, the Process activates the authN ID, and returns a 200 HTTP status code:

{
    "processId": "0c931a26-61df-4ed4-8121-592e0cf8c3dc",
    "lastStep": true,
    "runtimeId": 5014,
    "userId": 6040,
    "userAuthenticated": true 
}

The Process also authenticates the user. Going forward, the user can now authenticate with this authN ID and password.

Response Parameters

Error Codes

Below is a comprehensive list of potential error codes that may be returned during the execution of this Process.

Common Error Code

Common Process Error Codes

Process-Specific Error Codes

Revision History