Solution Architecture

The conceptual architecture of DigitalPersona AD consists of four layers.

  • Management – Provides an Active Directory-based solution for the enterprise; enabling the IT Administrator to configure, deploy and administer security policies throughout the organization.

  • Security Applications – Provides pluggable applications and features that are managed through the HID DigitalPersona management infrastructure.

  • Clients - Workstation software installed on notebooks, desktops and shared-user kiosks.

  • Credentials – Provides support for multiple authentication credentials that may be used in specified combinations for verifying the identity of users accessing managed computers and security applications

DigitalPersona's composite authentication solution goes beyond traditional 2FA and MFA offerings to deliver the optimal mix of factors which enable risk-based policies that adapt to today's dynamic threat environment. This approach to authentication secures all systems and applications in an increasingly complex IT environment marked by proliferating endpoints, applications and new service delivery models.

Composite authentication represents what is next for secure authentication; it closes the gaps left by traditional authentication solutions, while covering on premise, legacy and cloud applications with an easy to deploy and use solution for any user, anywhere and at any moment.

  • Closes gaps left by traditional authentication approaches

  • Offers rapid adaptability

  • Delivers complete coverage

  • Is human-proofed

Together, these capabilities are transformative—freeing the organization's security posture from its dependence on people, ensuring usability for both users and IT, and providing long-term protection of an organization's applications, systems and networks.

DigitalPersona System Architecture

The illustration below provides an overview of the DigitalPersona System Architecture. The product contains various components, some of which run on Client Machines and others that run on Servers.

DigitalPersona Client Application

The DigitalPersona Client Application is an application running on a client machine and powered with the DigitalPersona Authentication API, which uses the rich variety of authentication methods and policies pro- vided by the DigitalPersona application.

The following diagram illustrates the architecture of the DigitalPersona Client Application.

Application code implements application-specific business logic and uses the APIs only when user authentication is required.

The API allows any application to authenticate the user through the composite authentication provided by the DigitalPersona framework, and to receive application-specific secrets when required. An application secret can be a user password, an encryption key or any other user-specific security-sensitive data.

Although the primary purpose of the DigitalPersona Client APIs is user authentication and the retrieval of application-specific secrets, it also provides auxiliary functions such as querying users, retrieving user public data, setting authentication policies and saving application secrets.

The framework provides two APIs for accessing DigitalPersona features.

  • DigitalPersona Fingerprint (DPFP) API UI

  • DigitalPersona Fingerprint (DPFP) API

An application can choose to use either one or both APIs.

DPFP API

This is a low-level GUI-less API for user authentication. It does not perform the actual authentication, but is a proxy which redirects all requests to the DigitalPersona Client Service using Local RPC (LRPC).

DigitalPersona Client Service

The DigitalPersona Client Service provides authentication capabilities and enforces authentication policies for the Client Application via the Authentication API. The figure below illustrates the DigitalPersona Client Service Architecture.

The components of the DigitalPersona Client Service are described below.

DPFP API Stub

This component is responsible for receiving requests from the Client Application.

It is implemented as an RPC Service listening on the Local RPC (LRPC) protocol. The RPC service is configured to use privacy and integrity on the communication channel to ensure that transmitted data cannot be altered or exposed to man-in-the-middle attacks.

After DPFP API Stub receives an authentication request from the Client Application, it redirects the requests to the Authentication Enforcement Engine.

Authentication Enforcement Engine

The goal of the Authentication Enforcement Engine (AEE) is to perform user authentication, ensure user authentication satisfies the authentication policy and then release application-specific secrets when required.

The AEE does not perform user authentication itself, instead it redirects any authentication request to the Authentication Token Manager (see description below).

The AEE uses the Policies Manager to retrieve user authentication policies.

Policies Manager

The goal of the Policies Manager component is to collect authentication policies from various sources, create the authentication Resultant Set of Policy report (RSoP) and provide it to the requesting party.

Note: The only available source for authentication policies in the current version of DigitalPersona is the Group Policy Object (GPO).

Authentication Token Manager

A core feature of DigitalPersona is a pluggable architecture for Authentication Token Providers (see description below). The goal of the Authentication Token Manager is to enumerate the Authentication Token Providers available on the system and load them into the Client Service.

When the Authentication Token Manager receives an authentication request from the Authentication Enforcement Engine, the request is redirected to the corresponding Authentication Token Provider.

Authentication Token Providers

Every authentication method (also called a credential), whether fingerprint, Smart Card, PIN, OTP, etc., implements its own Authentication Token Provider.

The purpose of an Authentication Token Provider is to perform the enrollment of, and authentication by, a specific credential.

The Authentication Token Manager described above will discover all installed Authentication Token Providers and load them into the Client Service.

The maximum number of authentication methods/credentials (that is, Authentication Token Providers is 64, the number of bits in the policy item). The pluggable architecture allows DigitalPersona, and third-party developers, to add new authentication methods/credentials to the framework.

The Authentication Token Provider does not necessarily perform authentication itself, but may direct the authentication call to the Server Service for authentication on the server.

The usual workflow is that the Authentication Token Provider directs an authentication request to the Server Service, and if the server is not reachable, it accesses the necessary information from the Client Database using the Database Connector (see description below) and attempts to perform authentication locally.

Database Connector

The Database Connector is an auxiliary component which is used by all other DigitalPersona Client Service components to access (read/write) data stored in the Client Database.

Client Database

The Client Database is a database based on the Windows registry which is used by the DigitalPersona Client Service to store information about users, such as their user credentials, relevant policies and public information.

As mentioned above, the Client Database is mostly used for caching purposes, and cannot be accessed by the DigitalPersona Server Service.

The user data in the Client Database is encrypted for security purposes using a DigitalPersona Client Service 2,048-bit RSA encryption key. The only access allowed to the Client Database is by the DigitalPersona Client Service.

DigitalPersona Server Service

The DigitalPersona Server Service is used by the Client Service to perform operations such as user authentication and retrieval of user policies and other user data such as their email address, etc.

The components of the Server Service are described in the following pages.

Authentication Token Manager

The server implementation of the Authentication Token Manager is similar to the Client implementation. The main goal of this Authentication Token Manager is to enumerate the Authentication Token Providers installed on the DigitalPersona Server and load them into the Server Service.

The Authentication Token Manager redirects all authentication requests to the appropriate Authentication Token Provider.

Authentication Token Providers

The goal of the Authentication Token Provider is to perform the enrollment of, and authentication by, specific authentication methods/credentials on the Server. Each credential (authentication method) must implement its own Authentication Token Provider.

The pluggable architecture for Authentication Token Providers allows DigitalPersona to easily implement and add new authentication methods to the Server.

The Authentication Token Provider uses the Database Connector to store and retrieve necessary data to/from the DigitalPersona Database.

Database Connectors

The Database Connectors allow other components (mostly the Authentication Token Providers) to store and retrieve data in the DigitalPersona Database.

Currently, only two types of Database Connectors are supported:

  • AD Database Connector

  • AD LDS Database Connector

Active Directory (AD) Database Connector

The AD Database Connector is an auxiliary component that allows other DigitalPersona Server components to communicate with the DigitalPersona Server Database located in Microsoft Active Directory (AD).

DigitalPersona uses the Active Directory Service Interfaces (ADSI) to communicate with AD.

Active Directory Lightweight Directory Services (AD LDS) Database Connector

The AD LDS Database Connector is an auxiliary component that allows other DigitalPersona Server components to communicate with the DigitalPersona Server Database located in Microsoft AD LDS database.

DigitalPersona uses the Active Directory Service Interfaces (ADSI) to communicate with AD LDS.

DigitalPersona Server Database

The DigitalPersona Server Database is used by the DigitalPersona Server Service to store/ retrieve user specific data such as security-sensitive data, i.e. user credentials and secrets or public user data such as user name, e-mail, etc.

Currently, two types of DigitalPersona databases are supported:

  • Microsoft Active Directory

  • Microsoft AD LDS database

Microsoft Active Directory

This is a standard Microsoft Active Directory forest where information about Active Directory users is stored.

Microsoft AD LDS Database

The Server Database is based on Microsoft Active Directory Lightweight Directory Services (AD LDS).

The AD LDS schema is extended to support DigitalPersona-specific data in a user record.

Policies

Active Directory Group Policy Objects (GPOs) are used to create and manage DigitalPersona policies, which can be set using the standard GPO Editor. Any Domain Administrator or Delegated Administrator can set DigitalPersona policies.