Differences

This shows you the differences between two versions of the page.

--- documentation:architecture [2016/11/04 15:41]
127.0.0.1 external edit
+++ — (current)
@@ Line 1: / Line 1: @@
-====== ADUCID architecture ======
-This document describes ADUCID<sup>®</sup>  at the system level necessary for integrating with target application.
-To understand this document, the reader is required to have knowledge of web technologies, programming and integration of web applications.
-See also [[developers:advanced-integration:start|Advanced integration manual]]
-====== Basic components ======
-{{:developers:aducid-system-diagram.png?nolink&600x546}}
-== System diagram for 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.
-===== Server part of ADUCID® =====
-The entire server part of ADUCID<sup>®</sup>  along with the operating system and all third-party systems required to operate the server part of ADUCID<sup>®</sup>  are supplied as complete virtual appliances.
-The server part of ADUCID<sup>®</sup>  consists of following parts:
-==== AIM ====
-ADUCID<sup>®</sup>  Identity Machine – delivers ADUCID<sup>®</sup>  server functionality, performs all ADUCID<sup>®</sup>  operations and provides access to user data stored along with electronic identities in the LDAP 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<sup>®</sup>  .
-Another part of AIM is the provider of cryptographic services (AIM Crypto Provider) that can be implemented through different manners - e.g. as a software library or hardware device (HSM, etc.).
-==== LDAP ====
-Data for electronic identities and user data along with other operational data is stored in the standard LDAP database.
-==== SQL database ====
-HyperSQL database is used to store ADUCID events and licensing logs.
-==== Admin applications ====
-ADUCID comes with a set of support applications. All admin applications require a particular role, proofing and personal factor (first admin gets these automatically).
-=== UserAdmin ===
-UserAdmin is a user and PEIG management tool. It also shows statistics and licensing.
-=== SecAdmin ===
-SecAdmin is meant to configure security parameters of ADUCID AIM (encryption algorithms, key length, expiration periods etc.)
-=== RoleAdmin ===
-Allows administrators to assign ADUCID roles. Without a role, an ADUCID user has only very limited rights. There are special groups to configure / administrate AIM features:
-  * useradmin – can manage users and their PEIGs
-  * operator – can manage user PEIGs only
-  * roleadmin – can assign user roles
-  * secadmin – can alter AIM security
-  * regadmin – can proof users
-==== Proofing applications ====
-See Identity proofing
-==== Profile application ====
-A simple application that demonstrates user log on and PEIG (replica) self-management.
-=====   =====
-===== PEIG  - Client part of ADUCID =====
-see [[:documentation:client|PEIG]]
-===== PEIG proxy QR code =====
-PEIG can act as super secure feature for QR code authentication. In this case PEIG authentication is turned off (but PEIG is running). QR code is not server by AIM-proxy but rather created by PEIG-proxy module. This is one of most secure setups in ADUCID topology (see Binding documentation for details) and definitely secure than displaying QR code using browser.
-===== 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 Papi (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**
-  * Redirect adapter (from browser to Windows / OSX PEIG) is local port 44240
-  * Scanning a QR code
-  * <font 11.0pt/11;;inherit;;inherit>Integrated using Papi</font>
-==== 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 SDK or ADUCID JAVA SDK for simplified integration.
-==== Windows PEIG PC, OSX PEIG ====
-Windows/ OSX PEIG runs on the same computer as user’s browser. Browser processes AIM-proxy script which calls PEIG Redirect Adapter module on local host port.
-=== PEIG USB ===
-Windows / OSX PEIG has option to store identity files on a USB. This feature is accessible for every PEIG PC / OSX installation inserting USB disk and preparing it for ADUCID.
-==== iOS PEIG and Android PEIG ====
-PEIG can run on mobile phones or tablets with Android 4.0+ or iOS 8+. PEIG can be called in used in two ways:
-  * QR code scanning using phone / tablet camera
-  * calling aducid:// URI schema (on Android Intent is preferred)//
-Users can authenticate into desktop application scanning a QR code using mobile PEIG (or QR code displayed by another PEIG).
-Native applications are also supported. They can call PEIG directly using schema / intent or use PEIG API (Papi) – See Integration with mobile applications
-==== Personal factor (PF) ====
-To proof his/ her identity ADUCID provides a feature called personal factor. PF something only user know or has.
-== Secret ==
-The most common PF is some kind of secret. User can define a picture sequence or number sequence.
-== NFC ==
-On Android phone a user can use a NFC tag as his / her secret.
-== Apple Touch ID ==
-On iOS devices with fingerprint sensor (iPhone 5S or better) user can activate fingerprint factor as addition to his / her secret.
-==== Replicas ====
-With ADUCID user is not limited to just one device. On the contrary he / she can have “unlimited” number of devices called replicas. Replicas are PEIG with different cyber id referring to the same person.
-To create a replica, the user needs another PEIG. Then he / she starts replica process (from application). Using a device with a camera it’s very simple – user just scans QR code display on one device using another.
-===== PEIG proxy QR code =====
-PEIG can act as super secure feature for QR code authentication. In this case PEIG authentication is turned off (but PEIG is running). QR code is not server by AIM-proxy but rather created by PEIG-proxy module. This is one of most secure setups in ADUCID topology (see Binding documentation for details) and definitely secure than displaying QR code using browser.
-===== 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 Papi (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**
-  * Redirect adapter (from browser to Windows / OSX PEIG) is local port 44240
-  * Scanning a QR code
-  * <font 11.0pt/11;;inherit;;inherit>Integrated using Papi</font>
-==== 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 SDK or ADUCID JAVA SDK for simplified integration.
-===== Communication between components =====
-A fundamental unit of activity in ADUCID<sup>®</sup>  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.
-{{:developers:aducid-communication-diagram.png?nolink&601x376}}
-== 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<sup>®</sup>  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<sup>®</sup>  . PEIG<sup>®</sup>  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<sup>®</sup>  and AIM.
-In terms of communication, PEIG<sup>®</sup>  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<sup>®</sup>  (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://,|https://,]] to activate a registered web browser.

ADUCID 4.x

User Tools

Site Tools

Differences

Page Tools