Deployment Modes

The deployment of ActivID AS should take into consideration the need for high-availability of the authentication services and implement server failover measures to ensure operational continuity.

The ability to call the ActivID AS services in a manner that is shielded from system failure, depends on the infrastructure options taken.

ActivID AS consists on a set of stateless services and these do not need to share state across the application server nodes. Only one instance of theActivID AS can run per node.

The ActivID Authentication Portal, Management Console and Self-Service Portal are stateful and should be load-balanced with session affinity the load balancer (bind a user's session to a specific server instance).

The following sections describe the possible deployment configurations that involve the ActivID AS components and portals.

Each of these components can be deployed on the same host or on separate hosts. For performance, scalability, and security, it is recommended that you deploy these components on separate hosts.

Important:  
  • The following deployment configurations are provided for illustration purposes only. Each deployment has specific requirements. To define the best deployment option, please contact HID Global Professional Services for assistance.
  • This section does not cover Hardware Security Modules (HSM) deployment options. HSMs can be deployed within an ActivID AS host and be used exclusively by that host or they can be networked and shared by multiple ActivID AS hosts. As is the case for other components of the solution, it is recommended using more than one HSM in order to avoid single points of failure.

Simple Pilot Deployment with Local RFE

This is a simple deployment that does not enable high availability. It is usually used for small deployments, proof of concepts, and pilots. For information on how to install RADIUS Front End separately, refer to the ActivID Authentication Server RADIUS Front End Solution Guide available from the ActivID Customer Portal.

Basic High Availability with Three Host Servers

This figure is an illustration of a typical basic High Availability deployment recommended for production environments.

Each ActivID AS server points to a primary database and is automatically replicated on a standby database. In case of a failure of the primary database, ActivID AS can automatically use the standby database, using technologies such as Oracle Data Guard.

Depending on whether or not RADIUS services are required, RFE servers may not be mandatory. Each of the RFE servers can reside on the same hosts as the ActivID AS server or be deployed separately.

High Availability, High Performance, Large Scale, Multi-Database

Instead of a single ActivID AS server, more servers can be added for scalability and performance. Depending on whether RADIUS services are required, RFE servers may not be mandatory. Each of the RFE servers can reside on the same hosts as the ActivID AS server or be deployed separately. If deployed with more RFEs and standby databases, then more performance and disaster scenarios can be addressed.

Separated Presentation Layer

The ActivID Management Console (the Presentation Layer) can be deployed on the same host or a different host than ActivID AS.

Typical Large Scale

In this model, best suited for large-scale deployments, multiple ActivID AS servers are deployed. Some of them are used in production for authentication exclusively, and others are used specifically for administration. An additional set of servers is used for offline auditing and reporting.

They all access the same data from a replicated and fault-tolerant database cluster. The Offline Audit database only replicates and archives audit records.