ADSS Server Architecture & Interfaces

The following diagram provides an overview of the ADSS Server product architecture and available interfaces:

Architecture

ADSS Server is a Java 17 EE application and uses current versions of Apache Tomcat v10.1.25 and OpenJDK 17.0.12. The use of specific Tomcat and JDK versions will be reviewed from time to time. These should be used as 'black box' supported environments for ADSS Server and not used more generally. These versions can co-exist with any other Java version on a platform and any other web application container. Because of its Java 17 EE architecture, deploying ADSS Server with other web containers such as WebLogic and JBoss can be considered on a project basis but is really not required - ask sales@ascertia.com for information. Note the web containers packaged by Ascertia are fully supported by Ascertia as part of the ADSS Server support agreement.

The primary development environment for ADSS Server is Windows Server, however Linux is becoming increasingly popular and support for RedHat and SuSe versions and variants, as well as Solaris 11, are made available. Support for other variants or operating systems is available on request. ADSS Server has been designed to be able to run in almost any suitable Java 17 EE environment.

ADSS Server requires a database to store its policy configuration, other internal data as well as system events and transaction logs. ADSS Server uses Hibernate technology to work with a range of database management systems. The primary development database is Microsoft SQL Server Enterprise Edition however others such as SQL Server Express, Oracle, PostgreSQL and MySQL are tested and approved for use. See the ADSS Server Installation Guide for further details on supported versions and for MySQL information. Note, unfortunately Oracle doesn't allow Ascertia to freely redistribute the JDBC driver for MySQL and so this must be downloaded before installation.

Deployment Architecture

ADSS Server is deployed as three separate Apache tomcat server instances. These components are named as ADSS Server Core, ADSS Server Console and ADSS Server Service. These components can be installed either on a single machine in a typical installation or on multiple machines in a load-balanced environment. Detail of each of these components is listed below:

ADSS Server Core

The ADSS Server Core component performs following core operations:

Logs Archiving
Automatic HMAC Verification to ensure integrity of database records
Automatic renewal of infrastructure certificates (issued by the local CA)
Automatic publishing of CRLs (issued by the local CA)
Automatic synchronization of the configuration files
License Management

At a time period when ADSS Server Core is stopped, all of the above mentioned operations will also be stopped. The other two components i.e. ADSS Server Console and ADSS Server Service will continue to provide their services despite the ADSS Server Core is stopped

It is possible to install more than once instances of ADSS Server Core which work in a high availability environment. At a single instance of time only one ADSS Server Core instance can act as a primary instance, Other instances running as secondary can take primary's place when the primary instance is not working properly. More details on ADSS Server Core high availability configurations can be found here.

ADSS Server Console

The ADSS Server Console component is used to make ADSS Server administrative configurations. It is possible to install more than once instances of ADSS Server Console which work in a high availability environment. At a single instance of time only one ADSS Server Console instance can act as a primary instance and is used for configurations. Other instances running as secondary can take primary's place when the primary instance is not working properly. More details on ADSS Server Console high availability configurations can be found here.

ADSS Server Service

The ADSS Server Service component is used to process incoming requests from the relying parties. These requests can be for any of the licensed ADSS Server services e.g. Signing, Verification, XKMS, SCVP, LTANS etc. Details of each of these services are provided in the later chapters of this guide. It is possible to install more than once instances of the ADSS Server Service component. When multiple instances of the ADSS Server Service component are installed, the ADSS CRL Monitor module runs in the high availability environment while all other services run individually but these can be load balanced by deploying an additional hardware load balancer module which is not in scope of the ADSS Server deployment.

External Interfaces

The following diagram shows the external interfaces of ADSS Server:

The interfaces are numbered for reference and described below:

The ADSS XKMS Service and ADSS Verification Services can be configured to relay certificate validation requests to external XKMS Servers.
The ADSS SCVP Service can be configured to relay certificate validation requests to external SCVP Servers.

Internal Modules

ADSS Server is a multi-function application providing a wide range of trust services; it can often be the case though that not all services are required by every business application. Ascertia therefore licenses the ADSS Server modules individually. Ascertia also groups the service modules into the following packages:

ADSS Enterprise Server

ADSS Enterprise Server is aimed at organisations wishing to primarily deploy digital signature creation and verification services. It comes with the following modules:

The ADSS Certification Service is also included in this package if it is required to create and certify end-user signing keys. These keys/certificates are then saved on ADSS Server (possibly inside an HSM) thereby providing a server-side digital signature capability.

The above figure shows how the ADSS Service modules (shown in blue) provide trust services to external applications. Utility modules (shown in brown) are lower-level modules which provide their services to the service modules. There are additional lower-level modules and components shown in green which provide underlying generic functionality to the higher modules. Each of the modules is described in detail later in this manual.

ADSS Infrastructure Server

ADSS Infrastructure Server is aimed at organisations wishing to deploy PKI infrastructure components such as CAs, OCSP, XKMS, SCVP, Long-term Archiving (LTANS)  and Time stamp (TSP) Servers.

ADSS Infrastructure Server can be provided with the following modules:

It is of course possible to package ADSS Server for specific customer needs. Each licensed module is visible to the ADSS operator (assuming their operator role has access rights to it) through the Service Module menu line  as shown below. Unlicensed modules or ones where the operator role has not been assigned sufficient privileges to access a module are removed from the GUI. Note the second line shown below is for the Utility Modules; these are common to all the above services:

Any module that is not assigned to the operator’s role will be hidden from the operator console. E.g. the Approval Manager, which is part of the Dual Control feature, is hidden in the above screenshot. Only those licensed elements of ADSS Server are shown to an operator and any unlicensed modules are hidden and remain invisible.