This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
documentation:architecture [2018/06/26 11:35] tjotov [ADUCID architecture] |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== ADUCID architecture ====== | ||
- | |||
- | |||
- | ====== Basic components ====== | ||
- | |||
- | {{: | ||
- | |||
- | == 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, | ||
- | |||
- | 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< | ||
- | |||
- | The server part of ADUCID< | ||
- | ==== AIM ==== | ||
- | |||
- | ADUCID< | ||
- | |||
- | 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< | ||
- | |||
- | 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 is used to store ADUCID identites, 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). | ||
- | |||
- | === 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 ==== | ||
- | |||
- | See [[documentation: | ||
- | |||
- | |||
- | ===== PEIG - Client part of ADUCID ===== | ||
- | |||
- | 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 ===== | ||
- | |||
- | 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. | ||
- | |||
- | ==== 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 ===== | ||
- | |||
- | A fundamental unit of activity in ADUCID< | ||
- | |||
- | {{: | ||
- | |||
- | == 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< | ||
- | |||
- | 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< | ||
- | |||
- | In terms of communication, | ||
- | |||
- | When the operation is concluded, a random, one-time secret authKey is generated on PEIG< | ||
- | |||
- | <font 11.0pt/ | ||
- | |||
- | 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://, | ||
- | |||