Deployment types

VeridiumID solution deployment relies on several technical, security and business requirements which drive the final choice of installation type. The following chapters will describe each of these to understand how to choose the best deployment type.

General considerations

VeridiumID server key components

Throughout this document we will refer to the VeridiumID Application Layer and Persistence layer. Whilst an exhaustive components list can be provided, those directly relevant to this documentation are:

• Application Layer

  • Apache Tomcat → Hosts VeridiumID’s core API’s, in the form of web applications, for enrollment, authentication and administration. 

  • HaProxy → Used to perform SSL termination when a third-party web-application firewall is not in the topology or network zone.

  • SSP, Freeradius, fido, opa

• Persistence Layer

  • Apache Cassandra → Apache Cassandra is a highly scalable, high-performance distributed database designed to handle large amounts of data across many commodity servers, providing high availability with no single point of failure. User, device and transactional information are stored here.

  • Apache Zookeeper → Utilized as a repository for server configuration, reducing the number of changes required on the file system. Typically, only replicated regionally.

  • Elasticsearch → Utilized for keeping user sessions history.

VeridiumID server Services Layered / Unified:

VeridiumID can be deployed through 2 options :

• Unified Setup

The unified deployment has all Veridium services on the same host, i.e. the application layer and the persistence layer are together on the same machine. This is the PoC Layer Setup

• Layered Setup

The layered deployment has Veridium services split on several nodes , i.e. the application layer and the persistence layer are not on the same machine(s).

VeridiumID server connectivity SNI / Ports

Having the service setting defined, the connectivity type can be set to either SNI or Ports.

• SNI Setup: All Services connections are going through HTTPS ( TCP 443 ) and the redirection is based on hostname of the FQDN. This is the setup used for PoC's. Please refer to SNI Installation chapter for more information

• Ports Setup: Hostname is the same for all services but each Veridium Service is listening on specific port(s). This setup is used for production to integrate with reverse proxy and firewall. Please refer to Ports Installation chapter for more information

Both setup are applicable to single or multiple node deployment. This setup only deals with the way to connect to VeridiumID services.

VeridiumID server architecture deployment options

Based on the layers presented previously, there are several types of VeridiumID server installation types. Based on requirements and installation context, we can distinguish following types of installation:

1. Single node - Unified installation - used for Proof of Concept installation. All components of VeridiumID server are deployed on a single server ( all layers are on a single node ).

2. Multiple nodes - Unified installation - used typically as Production deployment in smaller/mid size companies. This is a deployment with High availability ensured. This is a load balanced architecture across several single node unified installations.

3. Multiple nodes - Layered installation - used typically as Production deployments in large Enterprise customers. This is a deployment with High availability ensured. Each layer of server (Database, application layer, etc), is deployed on dedicated server. Several independent Service lines typically geographically load-balanced. This deployment will have typically the following node types :

   1. Webapp node
      This type of node will be used in order to deploy WEB layer packages (for example: web applications and load balancers).

   2. Persistence node
      This type of node will be used in order to deploy data layer packages (for example: database solutions, configuration managers). Persistence nodes require a second node in order to use for back-ups (from Cassandra, Zookeeper configurations) and archived data.

   3. Ansible node
      This node will be used as the central node from which the installation/configuration will take place. It can be used a persistence node for the installation.

Please contact Veridium to get support on best practices and optimized architecture recommendations to match your architecture, constraints and requirements.

SNI Installation

The SNI setup is the easiest and simplest way to deploy VeridiuID server. It only requires HTTPS ( TCP 443 ) to be available. it is used for PoC's.
As redirection is based on hostname, several DNS records need to be created ( as aliases ). Here is an example for the following FQDN : poc.veridium-poc.com

Note: To display and check URLs configured on a VeridiumID install, execute the following command:

cat /home/veridiumid/host_list.txt

Ports Installation

The Ports setup is intended for production deployment. It exposes each Veridium component to other architecture components ( proxy / WAF ..etc..) with a specific port. This setup allows the usage of distributed and multinode architecture.

No service redirection is performed, so a single DNS record need to be created.

Here is an example for the following FQDN : poc.veridium-poc.com

Note: To display and check URLs configured on a VeridiumID install, execute the following command:

cat /home/veridiumid/host_list.txt

Single Node

This can be deployed as single node in one datacenter or as single node in 2 datacenters.

All the applications are installed on a single node, both Webapp and Persistence. It can be installed in CDCR, meaning one node in each Datacenter. One datacenter is active and second is passive. In this kind of architecture, it can be lost one datacenter.

Unified Deployment:

This is used to have redundancy even in the same datacenter.

All the applications are installed on each node. It can be installed in CDCR. ne datacenter is active and second is passive. In this kind of architecture, it can be lost one datacenter and one of 3 servers.

Layered Deployment;

This is used to have redundancy even in the same datacenter and also separation between Webapp and Persistence, if it necessary to have separation between webapp and persistence.

In this architecture, a datacenter can be lost, also inside a datacenter a Webapp and a Persistence can be lost.