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 3-D Secure and ActiveDevice protocols.
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.
ActiveDevice is a device agnostic protocol for strong authentication of online users, which uses a variety of two-factor authentication techniques.

Authentication Server¶

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 authentication server is used for user authentication in 3-D Secure and ActiveDevice processes. The user is redirected to the authentication server by the merchant plug-in during the 3-D Secure process and by the ActiveDevice plug-in in the two-factor authentication. The authentication pages are stored in the database and served via the authentication server itself.

The authentication server is responsible for processing of the PAReq and generation of PARes message pair in the 3-D Secure process.

The authentication server is responsible for processing of the UAReq and generation of UARes message pair in the ActiveDevice process.

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, DPI (ActiveDevice Plug-In)

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 and ActiveDevice processes. The verify enrolment server consumes VEReq and UEReq messages and generates VERes and UERes 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.

Challenge Server (3DS2)¶

Default path: /acs/ca

Inbound connections: User's browser, 3DS SDK app

RMI Server¶

Default port: 4242 and 4241

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).

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 (Issuers 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 and user 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 users (pre-registration and final registration models).

Enrolment Server¶

A fully customisable enrolment website, which allows cardholders to enrol their cards with the authentication schemes.

Default port: Determined by the application server

Default path: /enrolment/

Protocol: HTTP/HTTPS

Inbound connections: User's browser

Outbound connections: Database server

Other requirements: Must be able to access the HSM

The enrolment pages are stored in the database. These pages are customised per issuer. The enrolment server uses XSL to combine issuer's customised look and feel and enrolment process with the cardholder enrolment and authentication criteria provided as XML.

The enrolment server is only used for enrolment of pre-registered cardholders with static password to allow them to participate in authenticated e-commerce transactions via 3-D Secure 1 protocol.

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, Enrolment 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¶