Authentication Policies
An authentication policy is a template containing pre-defined parameters enforced during authentication such as password lengths or constraints, OTP synchronization protocols, Push Notification Signature details...
When an authentication policy is assigned to a user it is then represented as an authentication record (that is, the user’s record of usage for that particular policy).
Channels are assigned to authentication policies which enable the enforcement parameters specified by the authentication policy to be applied to the respective channels.
Authentication policies are defined by codes in the ActivID Management Console. When authenticating a user, the calling system is required to specify an authentication code. This can be an explicit code, such as AT_CUSTOTP, or a dynamic authentication code such as DYNMC_AUTH.
ActivID AS supports the following authentication policies:
-
What you know
-
Password-based policies
-
-
What you have
-
Device-based policies:
-
One-Time Password devices, virtual or physical
-
Out of Band (code through SMS or Email)
-
Push-based validation with the HID Approve App
-
-
PKI-based (digital certificate)
-
Combining authentication policies is the best way to achieve strong protection of resources. For example:
Code | Description | Type of factor | Level of protection |
---|---|---|---|
AT_STDPWD | Password (standard) | What you know | LOW |
AT_STDPWD + AT_OOB |
Password (standard) + Out of Band Email or SMS |
What you know + what you have |
STRONG |
AT_STDPWD + AT_OTP |
Password (standard) + One-Time Passwords, virtual or physical devices |
What you know + what you have |
OPTIMAL |
AT_STDPWD + AT_PASA |
Password (standard) + HID Approve Push notification |
What you know + what you have |
OPTIMAL |
-
Depending on the type of Authentication policy, you can set up password constraints and validity parameters.
-
Device-based Authentication policies are assigned a set of applicable credential types. For example, an OTP device authentication policy can have a combination of Out of Band, OATH, or SKI credentials.
Authentication Policies and User Types
Authentication Policies are enabled for User Types and specify which authentication methods are available for the users of a respective user type.
For example:
- A "Consumer Banking" User Type can have multiple policies enabled – OTP and security questions.
- A "Business Banking" User Type can have OTP, and PKI-based authentication policies enabled.
In these examples, the respective Authentication Policies would be enabled for the User Type ensuring that users a part of that User Type can use those policies while users outside of that User Type may not.
Authentication Policies and Channels
You can think of an authentication policy as a purpose for which a credential is used as the policy enables you to configure a risk-appropriate profile for access to a particular channel (for example, the complexity of a password, or tolerance for failed authentications, etc.).
Examples of authentication policies that are defined within the default data set are:
- System Login (for systems authenticating to the public API)
- Operator Login (for operators logging on to the ActivID Management Console)
- Customer OTP (for customers authenticating to a web site or other service channel)
A single user credential (for example, OTP) can be used for more than one purpose. For example, there can be multiple policies for OTP authentication with different parameters based on the risk-tolerance of the associated channel, and the user’s OTP token can be used with each policy and channel.
Setting up an authentication policy includes the definition of channel(s) over which that authentication policy will be valid. One or more channels can be permitted in an authentication policy and one or more authentication policies can be permitted per channel.
See also: