This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
documentation:architecture [2016/11/04 15:41] 127.0.0.1 external edit |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== ADUCID architecture ====== | ||
- | |||
- | This document describes ADUCID< | ||
- | |||
- | To understand this document, the reader is required to have knowledge of web technologies, | ||
- | |||
- | See also [[developers: | ||
- | |||
- | ====== 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.). | ||
- | |||
- | ==== 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 [[: | ||
- | |||
- | |||
- | ===== 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. | ||
- | |||
- | ==== 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/ | ||
- | |||
- | ==== 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://, | ||
- | |||