How it Works

ActivID AS provides the following core sets of services:

ActivID AS supports several out of the box methods of authentication (with a few options/permutations):

  • Static password
  • One-time password (OTP)
  • PKI credentials
  • Security Questions
  • Out of Band (OOB)
  • Push authentication
  • LDAP passwords

ActivID AS is a perennial solution that can accommodate new authentication methods as they become available. It provides an extensible framework into which you can add additional authentication methods. This is achieved using adapters (or plug-ins).

An adapter is a functional module that can be created by an organization deploying ActivID AS in order to extend the authentication methods supported natively by ActivID AS. This enables new authentication algorithms to be implemented and plugged into the core framework.

The various ActivID AS authentication processes provide substantial value over the basic validation of a submitted credential, such as a password, OTP, or PKI certificate.

Individual credentials are associated with Authentication Policies. The policies determine aspects such as:

The service set contains functions for the administration of users, devices and authentication credentials.

Certain administration functions, such as enabling and disabling an authentication record, resetting the failure count, and blocking an authentication record over specific channels are common across all authentication classes.

Other administration functions are specific to an individual authentication class. Examples include:

  • Creating users and editing their attributes
  • Assigning one or multiple devices to a user
  • Setting, resetting, and changing a static password or Security Questions response
  • Synchronizing or unlocking an OTP device
  • Updating the status of a device or a credential

Authorization is defined as the management and application of policies that determine what a user, a group of users, and a role are permitted to do.

These policies are defined through permissions.

There are two types of permissions inActivID AS.

  • Predefined/Internal Permissions − permissions for internal ActivID AS management functions such Configuration, User, Device, and Credential administration functions.
  • External Permissions − permissions for external operations that define the transactions and assets that a user is permitted to perform or access on systems external to ActivID AS (for example, external permissions for a bank money transfer).

For transaction asset permissions, ActivID AS manages the authorization policy, but does not apply it. The application (or enforcement) of the policy must be done in a system capable of permitting or denying the transaction. An example is a payment transaction. Provided that a person authenticates using a specified credential, there can be an ActivID AS permission that authorizes the person to make a payment from a specific bank account.

When a user or system successfully authenticates, a session is created. That session is identified by a Session ID, referred to as an Authenticated Login Session Identifier (ALSI), which is returned as part of the authentication response.

Information, such as the user’s identity and method of authentication, is stored against the session and is referenced as part of the authorization process. This determines whether or not a user is permitted to execute a requested ActivID AS administration function or transaction on an external system. All entries to the audit log are recorded against a specific session, providing a view of all activities that occurred within the session.

Available through a Public API, all four services are backed by the tamper-evident audit logging.

ActivID AS has a tamper-evident audit log that is used to record all events performed with the aforementioned services.

Additionally, the ActivID AS audit service can be used by external applications to record audit log events in a centralized location with tamper-evident security.

The audit service can also be used by authorized users to search and audit events for reporting purposes.

Server Architecture

ActivID AS can run in a clustered application server environment. However, it is recommended that you use a hardware load-balancer for load distribution between instance nodes and failover in case of node failure.

Note: An application is a set of modules with some added glue that binds them together into a complete integrated application. The modules can be web applications, Enterprise JavaBeans (EJBs), or application clients. An application also contains meta-information about the application, as well as shared libraries.

ActivID AS can use either a Hardware Security Module (HSM) or a software Java Cryptography Extension (JCE) provider for encryption, decryption, and data row signing.

The system is resilient in the face of a failure of an application server – provided that the deployment includes multiple application servers. If there is a failure of a single host, there is a proportional loss of capacity for each unavailable application server.

Each ActivID AS has a number of properties files containing the system configuration parameter definitions.

Important: Physical access to ActivID AS must be restricted.

Server Database

ActivID AS uses an industry-standard Oracle database to store all operational data (such as user credentials and devices, authentication records, and authorization policies), configuration data, and audit information.

Applications and Portals

The ActivID AS solution can be installed in various scenarios involving all or only some of the following components:

  • ActivID Authentication Services – consists of the following applications:
    • ActivID Authentication Server – the core server that provides the authentication infrastructure to meet cross-channel requirements.
    • About the ActivID Authentication Portal – the portal that provides the logon interface for service provider authentication (including the ActivID Management Console and ActivID Self-Service Portal).
  • About the ActivID Management Console – the web-based interface to manage the authentication system.
  • About the ActivID Self-Service Portal – the web-based interface that offers end users activation and management services for soft and hardware authentication devices.
  • ActivID RADIUS Front End (RFE) – enables OTP and static password authentication using the RADIUS protocol.
Note:  
  • The ActivID AS user interfaces, the ActivID Management Console, ActivID Authentication Portal, and ActivID Self-Service Portal, are browser-based and do not require client installation.
  • The portals support accessibility and are Section 508-compliant according to the US government regulations.

Key Concepts

Credential Management

ActivID AS simplifies ongoing credential management through a single point of administration. It ensures segregation of data between different applications, making a variety of types of information extremely secure.

It also provides unified, tamper-evident auditing capabilities.

Security Domains

Multiple data instances can be created in a single deployment. Individual instances are referred to as security domains. Each security domain contains a full data schema comprised of operational data, configuration data, and audit.

The purpose of having security domains is to provide a complete segregation of data for different business units within a single deployment. Multiple domains are also ideal for managed services offerings. Each call to the ActivID AS Public API must specify the domain against which the requested transaction is to be applied.

Data stored within the ActivID AS database is protected using two mechanisms:

  • Sensitive data, such as passwords, PINs, Security Questions and Answer responses. These device credentials are encrypted.
  • All data records within the database are digitally signed. This prevents an unauthorized user from by-passing the ActivID AS access control model by making direct updates to the database.

Hardware Security Module

The Hardware Security Module (HSM) is used to create a secure FIPS 140-2, Level 3-compliant environment for the protection and processing of data. The HSM is responsible for encryption, decryption, key management, and digital signature creation and validation.

There are two HSM form factors:

  • A PCI card physically resident on the application server.
  • A shared network resource accessible by multiple application servers. Network-connected HSMs perform cryptographic functions on behalf of one or more remote servers over a network.

ActivID AS also offers an alternative deployment mode wherein the HSM is replaced with a software crypto library. It is recommended deploying production systems with a hardware HSM. Nevertheless, the soft cryptography deployment mode provides good levels of data protection and is suitable for proofs of concept.

Application Server Platform

ActivID AS relies on industry standard J2EE technologies, and is deployed within an Application Server.

Multiple application servers can be deployed for scalability and performance, independent of the number of Security Domains. Each application server provides a full set of services for authentication, credentials and device administration, authorization and audit. Each application server connects to all security domains.

Note: More application servers can be added post-deployment to provide additional scalability and resilience.

Application Integration

The ActivID AS API preserves backward compatibility with client integration to previous versions of the product.

  • Integration with the ActivID AS is achieved via lightweight API clients, which are available for a variety of platforms, including Microsoft Windows and Linux
  • API clients are available for Java, C++/#, and C environments
  • The API client handles all communication with the server, including protection of the message using SSL over HTTPS

Integration can be done directly at the Web Services level.

Additionally, integration adapters can be made available for leading Web access managers, such as IBM Tivoli® Access Manager, Oracle Access Manager, Sun™ Access Manager, CA® Siteminder™ and Novell Access Manager.

Authenticators

The Authenticator is a central concept in the ActivID AS as it is the basis for authentication. To create an authenticator for an end user, you need to indicate an authentication policy and a device (if it is a device-based authentication policy). It can be seen as an instantiation of an Authentication Policy for a given user.

The authenticator allows a User to be authenticated by the ActivID AS. Without an authenticator, a User cannot authenticate. It can be summarized with this sentence: "A user is allowed to authenticate with an authentication factor (policy) using (or not) a device".

When an authentication policy is attached to a user, an authenticator with the corresponding type is created for the user.

A user can have as many authenticators as there are authentication policies in the ActivID AS. However, a user can only have one authenticator per authentication policy.

All of the non-password authenticators (that is, the device-based authenticators) store the secrets and configuration for the authentication secrets in a credential.

A single authenticator can contain multiple credentials.

The authenticator also contains the statistics of authentication for the user, such as the number of succeeded/failed authentications.

For further information, go to User and Authentication Management

How the ActivID AS Elements Work Together

The following diagram illustrates how the various elements of the ActivID AS configuration work together to provide secure and scalable authentication services.