Product Architecture

This section describes the product architecture and its logical components. Understanding the logical units of the application should help you with designing the actual implementation of the product to meet the deployment and security requirements of your organisation.

In this guide we use the term server for any software component that can be accessed via a client application, in a standard client/server architecture. To avoid any confusion we use the term physical server when referring to the hardware itself.

Internal Components¶

Server components are implemented as servlets that can be deployed to any one of the commercial application servers supported by ActiveAccess.

Access Control Server (ACS)¶

ACS is the authentication component of the system. It provides a facility allowing communication and messaging with other authentication components during an authentication.

ActiveAccess ACS supports the 3-D Secure protocol.
3-D Secure 1 is an authentication standard for online eCommerce transactions introduced by Visa and adopted by Mastercard, JCB, American Express and Diners Club International.
3-D Secure 2 is an update of the 3-D Secure 1 authentication standard, created by EMVCo to support app-based authentication and integration with digital wallets, as well as a frictionless authentication flow.

Verify Enrolment Server (3DS1)¶

Default port: Determined by the application server

Default path: Refer to the table in Access Control Server

Protocol: HTTP/HTTPS

Inbound connections: Directory server

Outbound connections: Database server

Other requirements: Must be able to access the HSM

The verify enrolment server is used in the 3-D Secure 1 processes. The verify enrolment server consumes VEReq messages and generates VERes messages accordingly.

Note that any changes to the fully qualified URL of the verify enrolment server must be reported to the 3-D Secure 1 providers in order to update the corresponding directory servers.

Payer Authentication Server (3DS1)¶

Default port: Determined by the application server

Default path: /acs/pa

Protocol: HTTP/HTTPS

Inbound connections: Cardholder's browser

The payer authentication server is used for cardholder authentication in the 3-D Secure process. The cardholder is redirected to the authentication server by the merchant plug-in during the 3-D Secure process. The authentication pages are stored in the database and served via the authentication server itself. The payer authentication server is responsible for the processing of the PAReq and generation of PARes message pair in the 3-D Secure 1 process.

Authentication Server (3DS2)¶

Default port: Determined by the application server

Default path: Refer to the table in Access Control Server

Protocol: HTTP/HTTPS

Inbound connections: Directory server

Outbound connections: Database server, Directory server

Other requirements: Must be able to access the HSM

The authentication server is used for cardholder authentication in 3-D Secure 2 process. The authentication server consumes AReq messages and generates ARes messages accordingly. For each AReq that is received, if challenge is required, the authentication server generates and RReq message to notify the directory server of the result of challenge, then consumes and RRes message in response to RReq.

Note that any changes to the fully qualified URL of the authentication server must be reported to the 3-D Secure 2 providers in order to update the corresponding directory servers.

Challenge Server (3DS2)¶

Default port: Determined by the application server

Default path: /acs/ca

Protocol: HTTP/HTTPS

Inbound and outbound connections: Cardholder's browser, 3DS SDK app

The Challenge server is used in the 3-D Secure 2 process. The challenge server consumes CReq messages and generates CRes messages accordingly.

RMI Server¶

Default port: 4241 and 4242

Protocol: JRMP (TCP)¹

Inbound connections: Other ActiveAccess RMI servers, MIA

Outbound connections: Database server, Other ActiveAccess RMI servers

Other requirements: Must be able to access the HSM

The RMI server is used to synchronise a cluster of ActiveAccess servers. This is mainly to notify other ActiveAccess servers of changes in the settings of the cluster or to apply settings to multiple ActiveAccess servers from a single ActiveAccess administration interface.

RMI server is used when ActiveAccess components are deployed on multiple servers or multiple ActiveAccess servers are used for load balancing.

AHS Client (3DS1)¶

Default port: N/A

Default path: N/A

Protocol: HTTPS

Inbound connections: None

Outbound connections: Authentication history server, Database server

Other requirements: Must be able to access the HSM

In accordance with 3-D Secure 1 specification, a copy of transaction response (PARes) must be sent to the card scheme's designated server known as the Authentication History Server (AHS). The AHS client is responsible for sending the transaction record (PATransReq) to the designated AHS server.

Note that some 3-D Secure providers may not require or support an AHS.

Rules Engine¶

Default port: None

Default path: None

Protocol: None

Inbound connections: None

Outbound connections: Database server

Other requirements: None

The Rules engine is used for applying business rules for checking authentication requests processed or transparently authenticated by local or remote authentication servers.

Authentication exemption rules for local and remote authentication servers are:

• Soft Launch List

• Merchant Whitelist

• Merchant Watchlist

• Location Watchlist

• Domestic & International Transaction Amount Threshold

• Stand-In Transaction Threshold (remote authentication model)

Registration enforcement rules for local authentication servers are:

• Amount Threshold

• Merchant Blacklist

External Messaging Adapter¶

Default port: N/A

Default path: N/A

Protocol: HTTP/HTTPS

Inbound connections: N/A

Outbound connections: Centralised Authentication and Authorisation Service (CAAS), Database server

Other requirements: Must be able to access the HSM

The external messaging adapter manages the messaging requirements for connecting ActiveAccess to the issuers' remote systems.

Risk Engine Adapter¶

Default port: N/A

Default path: N/A

Protocol: N/A

Inbound connections: N/A

Outbound connections: RESTful RBA adapters

Other requirements: N/A

The Risks engine is used for applying risk rules for checking authentication requests processed or transparently authenticated by local or remote authentication servers. In an authentication, a challenge may be necessary because the transaction is deemed high-risk, e.g. above certain thresholds.

For risk assessment, ACS sends/receives proper data elements to/from risk assessment systems via middleware.

There are two types of risk adapters available:

• Native API version of Risk Adapter

• Restful API version of Risk Adapter

Out of Band (OOB) Authentication Adapter¶

Default port: N/A

Default path: N/A

Protocol: N/A

Inbound connections: N/A

Outbound connections: RESTful OOB adapters

Other requirements: N/A

The OOB is challenge activity that is completed outside of, but in parallel to, the 3-D Secure flow.

ActiveAccess performs Out Of Band (OOB) challenges through OOB adapters. OOB adapters connect the existing OOB authentication system with ActiveAccess. During 3-D Secure 2 challenge flows where OOB authentication is required, the ACS will trigger the external OOB process, perform interactions with the cardholder via the OOB adapters.

For this purpose, the ACS communicates with the existing OOB system via a middleware. This middleware is the OOB adapter. The OOB adapter can either be loaded locally by the ACS (Native API) or communicated with via HTTP calls (REST API).

Decoupled Authentication Adapter¶

Default port: N/A

Default path: N/A

Protocol: N/A

Inbound connections: N/A

Outbound connections: RESTful Decoupled adapters

Other requirements: N/A

Decoupled Authentication is authentication activity that is completed outside of, but in parallel to, the 3-D Secure flow. ActiveAccess performs Decoupled Authentication challenges through Decoupled Authenticator adapters. Decoupled Authenticator adapters connect the existing Decoupled authentication system with ActiveAccess. During 3-D Secure 2 flows where Decoupled authentication is required, the ACS will trigger the external Decoupled Authenticator process, and perform interactions with the cardholder via the Decoupled Authenticator adapters. For this purpose, the ACS communicates with the existing Decoupled Authentication system via a middleware. This middleware is the Decoupled Authenticator adapter. The Decoupled Authenticator adapter can either be loaded locally by the ACS (Native API) or communicated with via HTTP calls (REST API).

Administration Server¶

The management and reporting utility for the system is the administration server used by administrative users.

Default port: Determined by the application server

Default path: /mia/

Protocol: HTTP/HTTPS

Inbound connections: Administrator browser (Issuer's admin staff and internal admin staff)

Outbound connections: Database server, Registration Server, RMI Server

Other requirements: Must be able to access the HSM

The administration server is used by technical and issuer and helpdesk staff who are in charge of operations, maintenance and customer support. The administration server allows access to various system and business settings, and cardholder information, transactions, reports and logs.

Registration Server¶

A web service providing issuers the ability to enrol cardholders in real-time with the authentication schemes.

Default port: Determined by the application server

Default path: /registration/

Protocol: HTTP/HTTPS

Inbound connections: Issuer's registration software (such as Card Loader utility), Administration server

Outbound connections: Database server

Other requirements: Must be able to access the HSM

The registration API is used by issuers to register cardholders (pre-registration and final registration models).

Whitelisting Server¶

A web service providing issuers the ability to see/remove cardholders’ whitelisted merchants in real-time via the Administration Server and add cardholder’s whitelisted merchants in real-time via the Access Control Server.

Default port: Determined by the application server

Default path: /whitelist/wl/api/merchant/

Protocol: HTTP/HTTPS

Inbound connections: Issuer’s software (such as issuer's website), Administration server

Outbound connections: Database server

Other requirements: Must be able to access the HSM

The Whitelist API is used by ActiveAccess and Issuers to manage cardholders' whitelisted merchants.

Database Server¶

Default port: 1521

Default path: N/A

Protocol: TCP

Inbound connections: Authentication server, Verify enrolment server, RMI Server, AHS Client, Rule Engine, External Messaging Adapter, Administration server, Registration server.

Outbound connections: None

Other requirements: None

Logical View of ActiveAccess¶

The following diagram displays the logical view of ActiveAccess with the components explained earlier on this page.

Production Setup with Disaster Recovery¶

In this setup, the ActiveAccess application is setup on Application 1 and Application 2 servers, using one database server (Database 1). Requests sent to the ACS will be forwarded to the Application servers (Application 1 and Application 2), as configured by the load balancer.

Both Application 1 and Application 2 servers will use Database 1. Database 2 is a replication of Database 1, and is on stand-by. If connection to Database 1 fails, Database 2 will be used.

Production Setup with Clustering¶

In this setup, the ActiveAccess application is setup on Application 1 and Application 2 servers, using two database servers (Database 1 and Database 2) which share the same storage. Requests sent to the ACS will be forwarded to the Application servers (Application 1 and Application 2), as configured by the load balancer.

All application and database servers are active. Application 1 and Application 2 servers will use Database 1 and Database 2 based on the configurations and their ability to establish a connection.

Hardware and Software Requirements¶