Authentication Service

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, which consists of a framework that enforces the execution of supported authentication mechanisms. 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 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 using the authentication policy editor:

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:

  1. One-time password authentication mechanisms

    Password generated for an authentication event which is valid for one use. 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.

    One-time password mechanisms:

      Mechanism Description
      One-time password Group supported one-time password methods in a single flow. Asks the user to select which method to use.
      MAC One-time password Generate one-time passwords by randomly drawing one character at a time from the configured character set until the configured number of characters are drawn. Users provide a one-use password generated for an authentication event. Typically communicated between the client and the server through a secure channel. Each one-time password is salted and hashed and stored in the one-time password store plug-in. This mechanism also supports the one-time password mapping rules. 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 our own SMS Gateway.
      HOTP One-time password 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 Generate 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 Generate a passcode every 30 - 60 seconds. 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 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.

  2. Username and Password mechanism

  3. HTTP Redirect mechanism

    Integrate a custom authentication mechanism into the workflow of an authentication policy. Users provide credentials required by the custom authentication mechanism.

  4. Consent to device registration mechanism

    Users provide consent to allow their device to be registered.

  5. FIDO Universal 2nd Factor mechanism

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

  6. FIDO2/WebAuthn mechanism

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

  7. Decision JavaScript mechanism

    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.

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.


Parent topic: Advanced Access Control configuration