Authentication

Security Verify Access provides user authentication functions that allow for simple and complex authentication scenarios.

The users who want to access your protected resources can be challenged to provide credentials to authenticate with the various authentication technologies that are supported by Security Verify Access. The component responsible for this capability is called the Authentication Service. The Authentication Service consists of a framework you can use to enforce the execution of various supported authentication mechanisms to authenticate users.

Authentication mechanisms are modules that authenticate the user with a specific challenge or authentication technology, such as user name and password and one-time password. The order on which the authentication mechanisms are run is controlled by an authentication policy. An authentication policy is an XML document that you create with the authentication policy editor. The authentication policy dictates the order of authentication mechanisms to execute.

During an authentication event, the Authentication Service manages the execution of the authentication policy that is required for the event. Each authentication mechanism is included on the authentication policy workflow. This workflow is started by the Authentication Service authentication policy. After the user successfully authenticates to all of the authentication mechanisms that are required by the authentication policy, the Authentication Service generates a user credential. This user credential creates an authenticated session for the user at the point of contact.

The administrator can determine what information is included in the credential by configuring the authentication policy. The authentication policy editor provides a credential editor that an administrator can use to specify the attributes to be included in the resulting credential.

The generated credential contains:

authenticationTypes and authenticationMechanismTypes attributes to indicate the authentication policies.
Authentication mechanisms that are completed during the authenticated session.

The administrator can use authenticationTypes and authenticationMechanismTypes attributes to author an access control policy to require:

The user to authenticate through an authentication policy or mechanism once per policy.
The user to authenticate every time they access the protected resource.

The Authentication Service supports two flows of execution:

Enforcement of an authentication event as a result of an access control evaluation.
Request the user to authenticate as a result of either:
- A point of contact access control list (ACL).
- A protected object policy (POP) evaluation.

Authentication mechanisms

Security Verify Access provides the following authentication mechanisms:

One-time password authentication mechanisms

A one-time password is a password that is generated for an authentication event and is valid for one use. The one-time password authentication capability in Security Verify Access provides the following features:

One-time password generation and validation with support for various implementations as provided.
One-time password delivery with email and short message service (SMS) implementation.
Time-based, counter-based, and RSA one-time password generation and validation that requires no delivery mechanism.

The one-time password authentication mechanisms are described in the following table.

Mechanism	Description
One-time password authentication	Users provide a one-use password that is generated for an authentication event and is typically communicated between the client and the server through a secure channel. The OTP mechanism groups all the supported one-time passwords methods in a single flow and ask the user to select which one-time password method to use to login. The user can select from the supported one-time password authentication methods: HOTP TOTP RSA OTP MAC OTP with SMS delivery MAC OTP with email delivery
MAC One-time password authentication	Users provide a one-use password that is generated for an authentication event and is typically communicated between the client and the server through a secure channel. The MAC mechanism generates one-time passwords by randomly drawing one character at a time from the configured character set until the configured number of characters are drawn. The MAC mechanism also stores the generated one-time passwords in the configured one-time password store plug-in. Each one-time password is salted and hashed before it is stored in the configured one-time password store plug-in. The user can select from the supported MAC one-time password authentication methods: MAC OTP with email delivery. The email delivery sends the email address of the user and the one-time password in a message, whose MIME type is text/plain, to the configured SMTP Server. The SMTP Server then sends the one-time password to the user by email. The product does not provide an SMTP Server. You must configure your own SMTP Server. MAC OTP with SMS delivery. The SMS Delivery first sends the phone number of the user and the one-time password in an HTTP POST request, whose content type is `application/x-www-form-urlencoded`, to the configured SMS Gateway. The SMS Gateway then sends the one-time password to the user through SMS. The product does not provide an SMS Gateway. You must configure your own SMS Gateway. This mechanism also supports the one-time password mapping rules.
HOTP One-time password authentication	Users provide a one-use password that is generated for an authentication event. The one-time password is generated by the HOTP method.
TOTP One-time password authentication	Users provide a one-use password that is generated for an authentication event. The TOTP mechanism generates one-time passwords by using a specified algorithm with a time-based one-time password application. Passwords are not communicated or stored, but are verified as a match between server and client as they are regenerated at regular intervals.
RSA One-time password authentication	Users provide a one-use password that is generated for an authentication event. The RSA mechanism works with an RSA SecurID Authentication Manager and passcode generator. You must own the RSA Authentication Manager product to use RSA as a mechanism. The RSA Authentication Manager and passcode generator generates a passcode every 30 - 60 seconds. The user name and passcode are supplied by the user and passed to the RSA Authentication Manager. The RSA Authentication Manager makes a decision and returns it to Security Verify Access, which relays the decision back to the user.

Username and Password mechanism

Users provide a user name and password.

HTTP Redirect mechanism

Use this mechanism to integrate a custom authentication mechanism into the workflow of an authentication policy. Users provide credentials that are required by the custom authentication mechanism.

Consent to device registration mechanism

Users provide consent to allow their device to be registered.

FIDO Universal 2nd Factor mechanism

Users authenticate through the use of registered FIDO Universal 2nd Factor tokens.

FIDO2/WebAuthn mechanism

Users authenticate through the use of registered FIDO2/WebAuthn authenticators.

Decision JavaScript mechanism

This mechanism is used to run JavaScript rules during branching policies.

Authentication policies

By grouping the provided authentication mechanisms into the workflow of an authentication policy, you can achieve several types of authentication:

Simple authentication
Users provide basic identifying information such as a user name and password.
Step-up authentication
Users provide a specific type of credential usually to access sensitive resources. The users might be challenged to authenticate and provide an extra set of credentials to prove that they are allowed to access sensitive resources.
Multi-factor authentication
Users provide more than one type of credential to access a protected resource.

Each authentication policy has a unique identifier that you can use with an access policy or to start the authentication service directly without any prior access policy invocation.

Web-based authentication

For web-based authentication (using HTML template files and responses)


/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:<Unique PolicyId>

/mga/sps/authsvc/policy/<Unique PolicyId>

For example, the TOTP can be started like this:


/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:totp

/mga/sps/authsvc/policy/totp

When the policy runs, it cycles based on a rolling StateId parameter, on either the policy URL or the query string of the authsvc URL, depending on how it is started.

For example, /mga/sps/authsvc/policy/totp?StateId=cf845efa-52d0-4296-a524-9028acba4108 or /mga/sps/authsvc?StateId=cf845efa-52d0-4296-a524-9028acba4108.

REST API-based authentication

For REST based authentication (Using JSON Template files and responses). This is suitable for use from Single Page Applications making ajax requests or other REST clients. For more information, see Authentication Service Framework for REST API clients.


/mga/sps/apiauthsvc?PolicyId=urn:ibm:security:authentication:asf:<Unique PolicyId>

/mga/sps/apiauthsvc/policy/<Unique PolicyId>

For example, the TOTP policy can be started like this:


/mga/sps/apiauthsvc?PolicyId=urn:ibm:security:authentication:asf:totp

/mga/sps/apiauthsvc/policy/totp

When the policy runs, it cycles based on a rolling StateId parameter, on either the policy URL or the query string of the authsvc URL, depending on how it is started.

For example, /mga/sps/apiauthsvc/policy/totp?StateId=cf845efa-52d0-4296-a524-9028acba4108 or /mga/sps/apiauthsvc?StateId=cf845efa-52d0-4296-a524-9028acba4108.

Note: Query string invocation can be disabled through the advanced configuration parameter: sps.authService.policyKickoffMethod.

This allows administrators to set or use ACLs or POPs and CBA policy to prevent access to certain Authentication policies where necessary.