Authentication Methods

ActivID AS authentication methods determine the verification process used to authenticate a user.

ActivID AS supports two-factor authentication based on something a user knows (such as a password, a PIN, or memorable data in the form of security question answers), and something a user has (a physical authenticator such as an OTP token).

  • Direct users can submit authentication requests directly to ActivID AS.
  • Indirect users (such as end users) can be authenticated for ActivID AS through a direct user.

Static Passwords

Authentication is with a username and static credential, such as a password or PIN (also referred to as Username Password or UP Authentication). ActivID AS can manage multiple concurrent password policies. Each policy is configured as a Login authentication policy.

User name and password combination:

  • Full − requires entry of the full password.
  • Partial − requires entry of partial characters of the full password.

See Managing Password Authentication.

One-Time Password (OTP) Devices

A physical or software authentication device, such as a token or a smart card, that generates a one-time password (OTP). An OTP is valid for one authentication session only. It cannot be used to gain access a second time, even if captured.

Supported OTP devices include HID Global's range of hardware devices, as well as the HID Approve™ mobile application.

Out of the box, ActivID AS supports various OTP algorithms and modes - ActivID SKI, OATH HOTP, and TOTP.

ActivID AS can manage multiple concurrent OTP policies. Each policy is configured as a Device authentication policy.

See Managing OTP Device Authentication.

PKI Devices with Certificates

To enable PKI authentication, you must first create and assign devices containing PKI credentials to one or more direct users or indirect users.

Typically, a PKI credential is stored on a physical device (such as a smart card) or in the user's browser.

You can use tools such as the ActivID® Credential Management System to issue and manage PKI credentials.

Out of the box, ActivID AS supports two PKI-based authentication methods:

This authentication method is typically used for direct user authentication. It requires ActivID AS to issue a challenge to the authenticating system. The authenticating system signs the challenge with its private key using RSA or ECC encryption and submits this as the response to the challenge. ActivID AS verifies the response, and the authenticating party is validated as being in possession of the private key associated with the certificate.

  1. The direct user issues an API call to ActivID AS to request a challenge.
  2. ActivID AS generates a challenge and sends it to the application server used by the direct user. The direct user signs the challenge using its private key (RSA or ECC).
  3. The direct user issues an API call that includes the required information and a signature (as a one-time password parameter) to ActivID AS, requesting to be directly authenticated.
  4. Access is granted or denied and an appropriate authentication response is sent to the direct user.

This authentication method is generally used for indirect users and assumes that the Web server hosting the business application has established a two-way SSL/TLS session with the user, thereby confirming that the user’s certificate is valid and that the user is in possession of the associated private key.

The plug-in simply checks that the certificate is associated with the user and that the device and credential status on ActivID AS are active. It also validates the start and end dates for the device and the credential (as stored on ActivID AS), and it checks that the associated authentication record is enabled, has valid dates, and is valid for the channel.

The following diagram illustrates the indirect user authentication process using PKI.

  1. Using a Web browser, the indirect user browses to the URL of the application server over TLS/SSL with mutual authentication.

    2. A TLS/SSL session is established between the Service Provider and the indirect user through the Web browser.

  2. The service provider extracts the indirect user’s certificate used in the SSL session and sends an authentication request to ActivID AS including the indirect user’s certificate.
  3. ActivID AS compares the provided certificate with that registered for the user in the ActivID AS database and, if enabled, the certificate revocation status.
  4. ActivID AS sends the authentication response to the Service Provider.
  5. If the authentication record is enabled, then the user is allowed to access this channel and the certificate used is assigned to him (access is granted or denied.)

This authentication method is generally used for indirect users and assumes that the Web server hosting the business application has established a two-way SSL/TLS session with the user, thereby confirming that the user’s certificate is valid and that the user is in possession of the associated private key.

This method does not require to register the user’s certificate in ActivID AS prior to authentication. Instead, ActivID AS verifies the certificate by checking the content of user’s certificate against a pre-configured set of rules (for example, that the ‘Subject’ attribute contains the user’s first and last name”, the ‘Issuer’ attribute equals the DN of a given certificate authority, ot the ‘Subject Alternative Names’ attributes contains the user’s email address).

These rules only need to be configured once and can be customized to meet many different use cases.

Note: For PKI certificate matching authentication, ActivID AS includes a default authentication policy (AT_PKI_MCH), device type (DT_PKIMCH) and credential type (CT_PKIMATCH).

The following diagram illustrates the indirect user authentication process using PKI certificate matching:

  1. Using a Web browser, the indirect user browses to the URL of the application server over TLS/SSL with mutual authentication.

    2. A TLS/SSL session is established between the Service Provider and the indirect user through the Web browser.

  2. The service provider extracts the indirect user’s certificate used in the SSL session and sends an authentication request to ActivID AS including the indirect user’s certificate.
  3. ActivID AS checks that all the certificate matching rules are met, the certificate and its path are valid and, if enabled, the certificate revocation status.
  4. ActivID AS sends the authentication response to the Service Provider.
  5. If the authentication record is enabled, then the user is allowed to access this channel and the certificate used is assigned to him (access is granted or denied.)

See Managing PKI Authentication.

Note:

PKI Authentication for direct and indirect users is also available through ActivID AS APIs. For further information and to see sample code, refer to the ActivID AS API documentation.

Security Questions

Responses to a number of security questions, such as mother’s maiden name or name of first school. ActivID AS can manage multiple concurrent Security Questions policies. Each policy has a unique set of questions and is configured as a Security Questions authentication policy.

Responses can be:

  • Full − requires entry of the full response to the security questions.
  • Partial − requires entry of partial characters of the full response to the security questions.

See Managing Security Questions Authentication.

Out-Of-Band Authentication with SMS or SMTP

Out-of-Band (OOB) authentication uses two independent networks to separate the authentication channel from the OTP delivery channels. This offers an additional layer of security, particularly against Man-In-The-Middle (MITM) attacks. For example, even if a fraudulent user gains all the security credentials to a user's account, a transaction cannot be completed without access to the second authentication network.

Using this form of authentication, an OTP is delivered “out-of-band” to the user via Over-the-Air SMS phone service or via SMTP email, and the user uses another network to send the OTP for authentication.

This authentication policy does not need a physical device or token. Instead it functions using OOB as a virtual device or credential. Even if a fraudulent user gains the security credentials to a user’s account, no transactions can be completed without valid access to the second authentication network.

Note: OOB is also commonly referred to as SMS OTP, since SMS is the most typical method for delivering an OOB OTP to the end user.

A user requests an OTP through an Internet website (using an IP-based network type), ActivID AS processes the request and sends an OOB OTP to the requester as a text message (using the Short Message Service or SMS) or an email via mobile telephone (telephony-based network type). The OTP is received out-of-band through an entirely different network type.

OOB SMS/Email one-time passwords can be used through a RADIUS channel or any other channel type. SMS OTPs can be triggered through a username/activation code or by the service provider.

The actual SMS/Email OTP is a random number generated by ActivID AS and sent to the end user by SMS or Email through a delivery gateway. Multiple SMS and/or Email Delivery Gateways can be configured. If the primary gateway fails, then a secondary gateway is used automatically.

Users authenticate using OTPs received via the out-of-band channel (SMS or Email). These OTPs can be used only once each. If entered incorrectly, the user can try multiple times before being required to request a new SMS.

ActivID AS − as delivered out-of-the-box − includes the following delivery gateways: standard SMPP, SMTP for SMS, and SMTP for email delivery. It is possible to build plug-ins to accommodate custom delivery gateways. For further information, contact HID Global Professional Services.

See Managing Out-of-Band Authentication.

Push Notification Authentication with HID Approve

Push-based authentication is an out-of-band validation feature that enables organizations to immediately notify users (via mobile push notifications) of pending operations such as logon or transaction requests.

Once the user receives the push notification, HID Approve will connect over a secure channel to the authentication server and securely retrieve the contents of the request that correlate to the push notification. The contents of the request will then be displayed to the user for approval and the user has the option to approve or decline the request. The user’s decision for each request is cryptographically signed with the user’s unique private key, then verified by the authentication server and securely recorded in the ActivID AS audit log.

See Managing Push Authentication.

LDAP Static Passwords

Users stored in an LDAP directory can authenticate to ActivID AS using their static LDAP passwords. For example, this method can be used before an OTP device is assigned to the user.

In order to be allowed to use LDAP authentication, LDAP users must be known to ActivID AS. In other words, the LDAP branch they belong to must be mapped to one or more ActivID AS administration groups.

ActivID AS offers two LDAP authentication policies:

  • Fallback − Fallback LDAP can be enabled at the channel level for all users authenticating over that channel. Once enabled, all users accessing that channel can authenticate using their LDAP passwords IF they do not have another authentication record assigned to them (for example, no device). An LDAP Fallback authentication record will be assigned automatically to each user upon first authentication. Once an OTP device is assigned, it will take precedence over the LDAP authentication record.
  • Passthrough − An operator can manually allow an individual user stored in LDAP and known to ActivID AS to authenticate using an LDAP password (that is, users who are stored in an LDAP directory that is mapped to an ActivID AS administration group).