User Tools

Site Tools


documentation:architecture

This is an old revision of the document!


ADUCID architecture

This chapter describes internal functionality of ADUCID. It is a foundation of No-code integration

Target application

Target application is any application that uses ADUCID® services. Examples of such applications include web applications with standard thin client (standard browser), mobile applications with server counterpart, classic client-server applications, or even universal system tools which are not normally viewed as applications, e.g. a VPN system for remote access, Wi-Fi connection, terminal access (e.g. X terminal), etc.

From the system point of view, the application consists of a client part and a server part (TA Client and TA Server), which communicate with each other in their own manner via an R1 interface.

With No-code integration all applications are insulated behind AAA Proxy.

Server part of ADUCID®

The entire server part along with the operating system and all third-party systems required to operate the server part of ADUCID are supplied as complete virtual appliance but can be installed as a set of components.

The server side consists of these parts:

AIM

ADUCID® Identity Machine – delivers ADUCID® server functionality, performs all ADUCID® operations and provides access to user data stored along with electronic identities in the database.

AIM is controlled by the target application using the R4 interface. Using this interface, it also provides services for working with user data.

Using the R3 interface, it communicates with the client part of ADUCID®.

SQL database

SQL database is used to store ADUCID identites, events and licensing logs. The default SQL DB is Postgress but can be replaced with any JPA compatible DB.

Admin applications

Proofing applications

PEIG - Client part of ADUCID

see PEIG

Interfaces

ADUCID uses 4 basic interfaces:

R1

R1 is an application interface handled by customer application itself. In mobile application integration R1 is encapsulated in PEIG API.

R2

R2 is an interface between client application and PEIG. This communication can be handled via:

  • URI scheme on mobile phones scheme aducid
  • Scanning a QR code
  • Integrated using PEIG API
  • Low level R2 is implemented as UNIX Socket or Windows Pipe

On Windows and OS X PEIG R2 can be called using auxiliary application PEIG which acceps RUI as an arguments and sends it via Unix socket / Windows pipe

R3

R3 is an internal interface between PEIG and AIM which uses http transport and SOAP protocol.

R4

R4 is interface between server application and AIM. Like R3 it uses http (or https) transport and SOAP protocol.

R4 is “a low level” layer. It is encapsulated in ADUCID WEB Platform SDK or ADUCID Client SDK for simplified integration.

Communication between components

A fundamental unit of activity in ADUCID® is an operation. Such operation can be an authentication, creation (initialization) of an electronic identity, a change in electronic identity, etc. Operations can have their own parameters.

Communications diagram

The server part of the target application first requests the required operation via the R4 control interface and specifies its AIM parameters.

The result is a unique, one-time authId operation identifier that can be initiated either by the target application or AIM.

The client part of the target application transmits the PEIG® startup event through the R2 interface. The startup event includes authId and the R3 interface URL.

Communication between the client part and the server part of the target application via the R1 interface is handled by the target application.

The startup event from the R2 interface is sent to PEIG® . PEIG® then starts processing the operation by transmitting the authId to R3 URL. AIM manages the entire operation process that consists of transmitting and processing several messages between PEIG® and AIM.

In terms of communication, PEIG® is a client and an AIM a server. In terms of control, the operation is managed by the AIM (based on target application request submission).

When the operation is concluded, a random, one-time secret authKey is generated on PEIG® (if successful), which is then transmitted to the client part of the target application along with authId via R2.

<font 11.0pt/11;;inherit;;inherit>The server part uses authId and authKey for further communication with AIM via the R4 interface in order to obtain electronic identity attributes and to work with user data (personal objects). In order for these requests to be carried out successfully, correct values for authId and authKey (one-time secret that was transmitted at the end of a successful operation at the client part of the target application) must be transmitted.</font>

PEIG finishes its activity by using a return URI. The return URI is transferred from AIM to PEIG during PEIG activity. The return URI is typically https://, to activate a registered web browser.

documentation/architecture.1530021795.txt.gz · Last modified: 2018/06/26 14:03 by tjotov