Software authenticator registration process

The software authenticator registration process is as follows:

Identify the client component

OneSpan Authentication Server identifies the application that initiated the request. A client component record must exist for the provisioning application and location from which it connects to the server:

• Component type. This is set as a parameter provided by the application.
• Location. The source IP address of the request.

A client component with an IP address range (IPv4 CIDR notation) as component location will be used to handle requests from any client within that IP address range. If two (or more) matching client components with overlapping IP address ranges are found, the client component with the smaller IP address range (more specific) takes precedence and will be used to serve the request.

Identify the policy

OneSpan Authentication Server identifies the policy to use in the registration from the client component record and verifies the validity of the policy.

The following policy settings will be ignored as they are not relevant for provisioning:

• DIGIPASS > DIGIPASS ASSIGNMENT settings
• CHALLENGE settings

Look up and verify the user account

OneSpan Authentication Server verifies the user account for the following:

• Ensure that the user ID and domain have been defined.
• Perform the Windows group check if necessary.
• Verify whether a user account exists.

• Verify whether the user account is disabled or locked if it already exists.

  If the user account is locked, OneSpan Authentication Server verifies whether a user auto-unlock attempt is possible (see User account auto-unlock).

Local authentication

A static password or one-time password must be entered. For more information about local authentication options and their effect on the user authentication process during software authenticator provisioning, see User authentication during provisioning

If back-end authentication is not enabled, the registration will fail in the following cases:

• The static password is not verified.
• The user account does not exist.
• The user account exists but has no static password stored.

If back-end authentication is enabled, then the back-end system will verify the static password. If the password is verified, but there is no user account in OneSpan Authentication Server, a new user account will be created. For this to succeed, Dynamic User Registration (DUR) must be enabled.

User authentication during software authenticator provisioning may vary depending on the local authentication policy settings and on whether the user already has an activated authenticator. For more information, see User authentication during provisioning.

Back-end authentication

Back-end authentication is an optional step in software authenticator registration. If enabled, the static password will be verified by the back-end system. If the back-end system cannot verify the credentials, registration will fail.

Assign the authenticator

The registration process performs the following steps:

• Search for an applicable authenticator according to the criteria specified in the policy associated with the user account involved in the activation request.
• If no authenticator is found, the first applicable and available authenticator record is assigned to the user account.

Generate the activation code

The reactivation restrictions are verified. If this is a reactivation request and reactivation is allowed, then the user account and the authenticator record already exist in OneSpan Authentication Server and will be used in the following steps.

The activation code is generated using the first capable application on the authenticator. The activation code may be encrypted with the user's password if the password was not verified by local and back-end authentication.

If defined in the effective policy, the authenticator start time is calculated and set based on the delayed activation period. If defined, notifications are scheduled to be sent to the respective user when (a) the delayed activation begins and (b) the authenticator start time has been reached and the authenticator becomes active.

Finalization

In the finalization step the created user accounts and authenticator assignment are stored in the data store. The audit data is updated to record the completed transactions and the results of those transactions. A response is sent to the user to confirm the registration or to show an error message if activation failed.

For information specific to the registration process using multi-device licensing and multi-device activation, see Scenario: multi-device activation (MDA)  .