Authentication

ISAM provides user authentication functions that allow for simple and complex authentication scenarios. Users accessing protected resources can be challenged to provide credentials to authenticate with the various authentication technologies supported by ISAM. The component responsible for this capability is called the Authentication Service. The Authentication Service consists of a framework used 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 created 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 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 determines 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:

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

The Authentication Service supports two flows of execution:

Authentication mechanisms

ISAM 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 ISAM 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.

Mechanism Description
One-time password authentication Users provide a one-use password 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 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. We must configure our 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. We 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 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 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 generated for an authentication event. The RSA mechanism works with an RSA SecurID Authentication Manager and passcode generator. We 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 ISAM, 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, we can achieve several types of authentication:

Each authentication policy has a unique identifier we 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.

    /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.

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.

See

  1. Authentication Service configuration overview
  2. Authentication configuration scenarios
  3. Configure an HOTP one-time password mechanism
  4. Configure a TOTP one-time password mechanism
  5. Configure a MAC one-time password mechanism
  6. Configure an RSA one-time password mechanism
  7. Configure one-time password delivery methods
  8. Configure username and password authentication
  9. Configure an HTTP redirect authentication mechanism
  10. Configure consent to device registration
  11. Configure an End-User License Agreement authentication mechanism
  12. Configure an Email Message mechanism
  13. Configure the reCAPTCHA Verification authentication mechanism
  14. Configure an Info Map authentication mechanism
  15. Configure a Knowledge Questions authentication mechanism
  16. Configure a FIDO Universal 2nd Factor authentication mechanism
  17. Configure a FIDO2/WebAuthn authentication mechanism
  18. Configure a QR Code authentication mechanism
  19. Enabling or disabling authentication policies
  20. Manage mapping rules
  21. One-time password and authentication template files
  22. Push notification registration
  23. Cloud Identity API Integration
  24. Configure the authentication and access module for cookieless operation
  25. Reverse Proxy Configuration with Authentication Services
  26. Branching Authentication Policy


Parent topic: Advanced Access Control configuration