This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
documentation:architecture [2018/06/26 11:39] tjotov |
documentation:architecture [2018/11/12 13:13] mpospisek [SQL database] |
||
---|---|---|---|
Line 3: | Line 3: | ||
{{: | {{: | ||
- | This chapter describes internal functionality of ADUCID. It is a foundation of[[integration: | + | This chapter describes internal functionality of ADUCID. It is a foundation of [[integration: |
===== Target application ===== | ===== Target application ===== | ||
Line 10: | Line 10: | ||
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. | 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 [[integration: | ||
===== Server part of ADUCID® ===== | ===== Server part of ADUCID® ===== | ||
- | The entire 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 |
- | The server | + | The server |
- | ==== AIM ==== | + | |
+ | ==== AIM ==== | ||
ADUCID< | ADUCID< | ||
AIM is controlled by the target application using the R4 interface. Using this interface, it also provides services for working with user data. | 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< | + | Using the R3 interface, it communicates with the client part of ADUCID< |
- | + | ||
- | 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.). | + | |
==== SQL database ==== | ==== SQL database ==== | ||
- | SQL database is used to store ADUCID identites, events and licensing logs. | + | SQL database is used to store ADUCID identites, events and licensing logs. The default SQL DB is PostgreSQL but can be replaced with any JPA compatible DB. |
==== Admin applications ==== | ==== Admin applications ==== | ||
- | ADUCID comes with a set of support applications. All admin applications | + | See [[documentation: |
- | === PeigAdmin === | ||
- | PeigAdmin is a PEIG management tool. It also shows statistics and licensing. | ||
- | |||
- | === UserAdmin === | ||
- | |||
- | UserAdmin is similar to PeigAdmin but also manages proofing data. | ||
- | |||
- | === SecAdmin === | ||
- | SecAdmin is meant to configure security parameters of ADUCID AIM (encryption algorithms, key length, expiration periods etc.) | ||
==== Proofing applications ==== | ==== Proofing applications ==== | ||
Line 53: | Line 44: | ||
see [[: | see [[: | ||
- | |||
- | ===== 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 ===== | ===== Interfaces ===== | ||
Line 64: | Line 51: | ||
==== R1 ==== | ==== R1 ==== | ||
- | R1 is an application interface handled by customer application itself. In mobile application integration R1 is encapsulated in Papi (PEIG API). | + | R1 is an application interface handled by customer application itself. In mobile application integration R1 is encapsulated in PEIG API. |
==== R2 ==== | ==== R2 ==== | ||
Line 70: | Line 57: | ||
R2 is an interface between client application and PEIG. This communication can be handled via: | R2 is an interface between client application and PEIG. This communication can be handled via: | ||
- | * Uri scheme on mobile phones scheme **aducid** | + | * URI scheme on mobile phones scheme **aducid** |
- | * Redirect adapter (from browser to Windows / OSX PEIG) is local port 44240 | + | |
* Scanning a QR code | * Scanning a QR code | ||
- | * <font 11.0pt/ | + | * 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 | ||
==== R3 ==== | ==== R3 ==== | ||
Line 83: | Line 72: | ||
R4 is interface between server application and AIM. Like R3 it uses http (or https) transport and SOAP protocol. | 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 | + | R4 is “a low level” layer. It is encapsulated in ADUCID WEB Platform |
- | + | ||
- | ==== 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. | + | |
- | + | ||
- | + | ||
- | ===== 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/ | + | |
- | + | ||
- | ==== 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 ===== | ===== Communication between components ===== | ||
Line 143: | Line 97: | ||
When the operation is concluded, a random, one-time secret authKey is generated on PEIG< | When the operation is concluded, a random, one-time secret authKey is generated on PEIG< | ||
- | <font 11.0pt/ | + | 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, |
- | 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. | + | PEIG finishes its activity by using a return URI. Then, depending on scenario, final action |