Skip to main content
This multi-step process combines onboarding, authentication, account association, and handles a user’s subscription purchases all in one seamless flow. The Onboard and Authenticate Process allows your organization to manage new and existing users that may have current subscriptions or are about to make a purchase. Digital Identity Management verifies their identity, provides multiple secure methods for login/sign-in, and can auto-discover active subscriptions associated with the user’s account. There are many paths a user can take that depends on their user status, security implementation, and type of UI flow such as onboarding or login. These enhanced processes allow integration with external B/OSS systems for subscription and account management. If no integration is required, the user processed as a regular ULM user. To accommodate all the different flows, two main processes execute to initiate and complete a user’s journey:
  • The first or initial Onboard and Authenticate Process handles user onboarding, authentication, and account association for existing users. All existing users with a verified AuthN ID start and finish with this flow that supports MFA, FIDO2, and One-Time Password (OTP).
  • New users (users that don’t exist yet) start with the initial Onboard and Authenticate flow and continue with the Onboard, Authenticate, and Activate Process (also known as the Finish Login and Enroll Process). This second process completes the creation, activation and verification of a User ID in the Digital Identity Management system. Optionally, the new user may be required to set their password or register factors for MFA. Once the password is updated in the Digital Identity Management Data store, the authentication identifier (authN ID) is processed, and the current user is verified in the Digital Identity Management environment.
  • Additionally, this second Onboard, Authenticate and Activate Process may be invoked when a user logs in with an authN ID and OTP/Magic Link.
This Process enhances and extends Digital Identity Management’s standard onboarding, authentication, or account/subscription Processes in one dynamic flow. Onboard and Authenticate is a very flexible multi-part process that supports all types of users, partner integration(s), and a variety of other configuration points including: Login options Many of these options are controlled through App Settings and enable users the ability to login with or without a password. Additionally, Digital Identity Management supports FIDO2, OTP, and magic links as valid sign-in/login options. Some of the relevant App Settings for login are: The Process supports reCAPTCHA Invisible Badge (v2, v3, enterprise) on the first prompt for user onboarding and authentication. Some of the relevant App Settings for this feature are: Multi-factor Authentication (MFA) The user is prompted to enter or register a second factor. Some of the relevant App Settings for this feature are: Subscription and Account Management Digital Identity Management supports integration with external B/OSS platforms and retrieves subscription data, payment methods, purchases, and associates accounts with a valid user. Some of the relevant App Settings for this feature are:

​
Onboard and Authenticate Process Flow

The Digital Identity Management Identity App supports several configurable flows out of the box and provides dynamic pages to guide the user through their journey. Your organization’s configuration uses App Settings and user inputs to determine which UI pages are rendered and what processes are called throughout the user journey. [product: dim]Onboard and authenticate process flow[/product: dim] This section describes the Authenticate Process from a high-level, “happy path” flow. Preconditions
  • The user has a password.
  • The User ID exists in Digital Identity Management.
Basic Flow
  1. Digital Identity Management queries the external billing support or operations system (B/OSS) to retrieve a product code (PLM Code). The PLM Code returns metadata that contains the Product Id, purchase URL, and terms of service. Note: The user is processed as a regular ULM user if no PLM code is returned.
  2. The user navigates to the application’s login/sign-in page and selects their identifier to use such as their email address or mobile number.
  3. reCAPTCHA (Conditional) If the client integrated a reCAPTCHA service, then Google checks the user’s input and if successful, returns a validation token to the client.
  4. Digital Identity Management consumes and submits the identifier using the PUT /process/step to retrieve the user’s account information.
  5. The Validate Account process returns the account and relevant information such as the payment method(s) and eligibility data for the specified user. Note: If the user logs in with no password or the User ID doesn’t exist, the current Process exits and invokes the secondary Onboard, Authenticate, and Activate Process. Digital Identity Management generates and sends the user a notification message that contains Access token as a short custom One-time Passcode (OTP) for the next step.
  6. The user enters their password for validation. Depending on your App Settings, the following may apply:
    • FIDO2 (Conditional) is configured, the user is redirected to another page (UI) to enter their credentials and the current process resumes.
    • MFA (Conditional) is configured, the user selects the MFA type from a supplied list of previously registered factors. If the user doesn’t have any registered factors, they’re directed to setup MFA before continuing. This option is controlled by the App Setting minMfaCount.
    • Password (Conditional) is expired, and the user is prompted to enter a new password. This option is controlled by the App Setting passwordLifeTimeSeconds. Note: If the user chooses to enter an OTP or Magic Link, the current Process exits and invokes the secondary Onboard, Authenticate, and Activate Process to complete authentication.
  7. Digital Identity Management updates the payment methods and invokes GET submgnt/v2/subscriptions API to retrieve the subscriptions to associate with the specified account and performs an entitlement check. Note: If no PLM code is available, the current Process prompts a regular ULM user for the account id to complete the account association using the Associate Account to User Process.
Post-conditions
  • The existing user is successfully logged in and has access to services according to their subscription and entitlements.
  • The user receives a purchase prompt on their UI (if required).
Possible or Common Errors
  • The product code (PLM) is invalid.
  • The provided mobile number or email is already registered to an existing Digital Identity Management User.
  • The mobile number or email doesn’t pass validation rules.
  • The provided password does not match the password complexity settings.
  • The user selects an unsupported MFA method.
  • The user enters an invalid OTP/TOTP that may be caused by incorrect digits, expired code, or wrong pkat.
  • The user doesn’t have any associated accounts or payment methods set up and therefore isn’t eligible to use the requested service.

​
Response Parameters

Depending on where the user is on their journey, the Onboard and Authenticate Process records events and returns these properties as required:

​
Onboard, Authenticate and Activate Process Flow

Digital Identity Management provides user onboarding, authentication and activation using the Onboard, Authenticate and Activate Process. A new user navigates to a login page to sign themselves up by providing an AuthN ID (mobile/email), password, and registration details. Once the user is activated and authenticated, they can log in to access the service(s), and/or make a subscription purchase. This process is also used for existing users that sign in with an OTP or Magic Link. The user already has a verified authN ID in Digital Identity Management. This second process is different from the Onboard and Authenticate Process because it starts with the GET session/token Process. The current user has an access token from the first Process to complete their onboarding and authentication journey. This section describes the Onboard, Authenticate and Activate Process from a high-level, “happy path” flow. [product: dim]Onboard, authenticate and activate user process flow[/product: dim] Preconditions
  • The User ID doesn’t exist in Digital Identity Management.
  • The user has no password.
  • The user has an access token.
Basic Flow
  1. The user navigates to your application’s sign-in page, and submits the OTP they received from the initial Onboard and Authenticate Process.
  2. Digital Identity Management updates the payment methods and invokes GET submgnt/v2/subscriptions API to retrieve the subscriptions to associate with the specified account and performs an entitlement check. Note: If no PLM code is available, the current Process completes the account association using the Associate Account to User Process.
  3. Digital Identity Management prompts the user for a password and additional information that includes: First Name, Last Name, Display Name, and Language. The process sets the password and other attributes using the PUT /process/step API.
  4. Digital Identity Management creates the User entity and activates the authentication identifier (AuthN ID).
  5. Note: If MFA is enabled and/or needs to be configured, Digital Identity Management sends a corresponding pkathttps://docs.saas.amdocs.com/bundle/b_processGuide/page/topics/c_actionTokens.html to your client application. The client application retains this information for onboarding flows where the user needs to enter their OTP.
  6. If no PLM code is available, the current Process prompts a regular ULM user for the account id to complete the account association using the Associate Account to User Process.
  7. The user receives a purchase prompt on their UI (if required).
Post-conditions
  • A new User entity exists in Digital Identity Management with a verified AuthN ID (mobile/email).
  • The new user’s password is created/updated.
  • The new user is successfully logged on.
Possible or Common Errors
  • The provided password does not match complexity settings.
  • The mobile/email does not pass validation rules.
  • The client submitted a request with a missing expected input parameter (e.g., no email or mobile provided).
  • The user selects an unsupported MFA method.
  • The user enters an invalid OTP/TOTP that may be caused by incorrect digits, expired code, or wrong pkat.
  • The user doesn’t have any associated accounts or payment methods set up and therefore isn’t eligible to use the requested service.
The Onboard, Authenticate and Activate Process supports additional configuration points within this flow such as:
  • Password Option – In the onboarding or authentication flows, this Process creates a new password for a new user or updates a password if the user doesn’t have one and is required to set one. Several password options are controlled through the App Settings.
  • Collect User Data – Your client application prompts for additional information such as the user’s First Name, Last Name, Display Name, and Preferred Language in the onboarding flow.
  • Subscription and Account Management – Digital Identity Management supports integration with external B/OSS platforms and retrieves subscription data, payment methods, purchases, and associates accounts with a valid user. If the user doesn’t have any active subscriptions, a purchase prompt can be enabled to guide the user through a subscription purchase.

​
Response Parameters

Depending on where the user is on their journey, the Onboard, Authenticate and Activate Process records events and returns these properties:

​
Application Settings

Certain aspects of the Process’ behavior are controlled by configurable App Settings. Debug mode allows UI developers and QA to get some extra information about the REST calls and the relevant response/data. For example we may return user otp that is sent to mobile and this value may be . The caller need to trigger debug mode for each call by passing request header x-process-debug: true

​
Use Cases

The following use cases are supported: