This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
developers:advanced-integration:principles [2019/08/01 09:42] tjotov removed |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Principles of ADUCID integration ====== | ||
| - | |||
| - | Fundamental components and the way they communicate with each other, including basic principles of integration, | ||
| - | |||
| - | {{: | ||
| - | |||
| - | === ADUCID components === | ||
| - | |||
| - | * **Application** | ||
| - | * **AIM (ADUCID Identity Machine) **- A self-authenticating component. Delivers the interface for working with the identity and the authentication protocol interface. | ||
| - | * **PEIG-Proxy **- A client-side component that is used for communication between AIM, PEIG and the web browser (other client). | ||
| - | * **PEIG **- A component that maintains identities and performs authentication. It communicates with AIM through the PEIG-Proxy. | ||
| - | * **Client **- Usually an Internet browser. | ||
| - | ===== Authentication "user story" ===== | ||
| - | |||
| - | This chapter defines the typical authentication workflow from integrating application’s perspective: | ||
| - | |||
| - | - The application initiates an authentication session in AIM. | ||
| - | - The integrator forces the initiation of the authentication process on PEIG (it uses either the AIM-Proxy component or its own resources). | ||
| - | - Authentication is performed between PEIG and AIM, and the credentials are sent back to the integrating application. | ||
| - | - If the verification is successful, the application fetches user profile data from AIM. | ||
| - | |||
| - | The following text describes two ways to implement this scenario which demonstrate the basic integration principles: | ||
| - | |||
| - | * Use of the AIM-Proxy server adapter (simpler use) | ||
| - | * Direct control of the client part (transmission of requests to PEIG needs to be programmed) | ||
| - | |||
| - | ===== Use of the AIM-Proxy server adapter ===== | ||
| - | |||
| - | AIM-Proxy is supplied to simplify the authentication process through HTTP redirect — on PC platform over an HTTP redirect adapter or on a mobile platform over a direct PEIG-Proxy call. The application can delegate the authentication process to these components. AIM-Proxy for integrators delivers the IAIM-Proxy interface. | ||
| - | |||
| - | The figure on the next page illustrates how AIM-Proxy is used during the ADUCID authentication process. | ||
| - | |||
| - | {{: | ||
| - | |||
| - | === Integration using AIM-Proxy === | ||
| - | |||
| - | The following sequence diagram illustrates individual authentication steps. | ||
| - | |||
| - | {{: | ||
| - | |||
| - | === Sequence of events when using AIM-Proxy === | ||
| - | |||
| - | - The user moves to the secure page of the given application. | ||
| - | - The application creates a new authentication session in AIM (it uses either ADUCID Java SDK or direct access to AIM via the R4 interface). This generates an **authId** | ||
| - | - The AIM-Proxy component generates an AJAX page, which performs the following actions: | ||
| - | - It initiates the client-side authentication process, it is done through the following steps: | ||
| - | - Checks, if the ADUCID schema is supported, if it is, it calls this schema— **this****causes the start of mobile phone PEIG**- If step i/ was not successful, it tries to push totheHTTP redirect adapter— **this****causes the authentication session to start over PC PEIG, if it is running**- Without dependency on the success of steps i/ or ii/ **the****QR**** code is prepared and shown to the user**, if it is supported by current binding mode, The QR code is an alternative way to start an authentication session- It periodically checks the progress status of authentication against AIM: - On a mobile phone platform, | ||
| - | - On a PC platform, AJAX page checks the authentication status | ||
| - | |||
| - | ==== AIM-Proxy Interface (IAIM-Proxy) ==== | ||
| - | |||
| - | The interface of the AIM-Proxy component is based on HTTP protocol and defines the following commands (the interface address is [[http://< | ||
| - | |||
| - | | \\ **Command Name** | ||
| - | | \\ / | ||
| - | | \\ / | ||
| - | | \\ / | ||
| - | | \\ / | ||
| - | | \\ / | ||
| - | |||
| - | Example of using the interface: | ||
| - | |||
| - | < | ||
| - | http://< | ||
| - | </ | ||
| - | |||
| - | \\ | ||
| - | |||
| - | |||
| - | ===== Direct control of the client part ===== | ||
| - | |||
| - | This scenario represents the situation where the integrating application starts the authentication process in its own manner. Typically, this means inserting an AJAX script, which the AIM-Proxy component produces, into the application, | ||
| - | |||
| - | The integration is schematically illustrated in the following figure: | ||
| - | |||
| - | {{: | ||
| - | |||
| - | === Integration with direct control of the client part === | ||
| - | |||
| - | If the integrators want to develop their own way of interacting with PEIG, they can use the HTTP Redirect interface of the PEIG-Proxy component on a PC platform or by using the PEIG-Proxy on a mobile phone platform, which are defined as below. | ||
| - | |||
| - | |||
| - | ==== HTTP Redirect interface of the PEIG-Proxy component— PC platform ==== | ||
| - | |||
| - | | \\ **Endpoint** | ||
| - | | \\ The endpoint used to run the authentication process ([[http:// | ||
| - | | \\ Endpoint used to complete the authentication \\ \\ on the client and fetching the **authKey** ([[http:// | ||
| - | |||
| - | Example of running the authentication process: | ||
| - | |||
| - | < | ||
| - | http:// | ||
| - | </ | ||
| - | |||
| - | Example of completing the authentication process on the client side: | ||
| - | |||
| - | < | ||
| - | http:// | ||
| - | </ | ||
| - | |||
| - | \\ | ||
| - | |||
| - | |||
| - | ==== PEIG-Proxy — mobile phone platform ==== | ||
| - | |||
| - | All mobile phone platform applications are called over schema. This endpoint is defined to call a mobile phone PEIG: | ||
| - | |||
| - | | \\ **Endpoint** | \\ **Description** | | ||
| - | | \\ The endpoint used to run the authentication process (aducid:/// | ||
| - | |||
| - | The following is an example of starting the authentication process on the mobile phone client side: | ||
| - | |||
| - | < | ||
| - | aducid:// | ||
| - | </ | ||
| - | |||
| - | After successful authentication and fetching **authKey**, | ||
| - | ===== AIM (R4) Interface ===== | ||
| - | |||
| - | The AIM server provides the integrator with an R4 interface, which is accessible only to applications on the server side. | ||
| - | |||
| - | The communication interface is based on SOAP/HTTP and consists of a single R4 service available at: | ||
| - | |||
| - | < | ||
| - | http://< | ||
| - | </ | ||
| - | |||
| - | This interface is designed to facilitate direct communication of server applications with the authentication server and offers 4 basic commands: | ||
| - | |||
| - | | \\ **Name of operation** | ||
| - | | \\ AIMrequestOperation | ||
| - | | \\ AIMgetPSLAttributes | ||
| - | | \\ AIMexecutePersonalObject | ||
| - | | \\ AIMcloseSession | ||
| - | |||
| - | A WSDL describing the R4 interface is included on the supplied DVD in the following directory: integration/ | ||
| - | |||
| - | For easier work with the R4 interface, a Java SDK library has been created, which is described in a separate document, aducid-sdk-java.docx. To simplify the use of the R4 interface, we recommend using the supplied SDK, or reading the provided document. | ||
| - | |||
| - | The ADUCID Java SDK source codes distributed under Apache Server Licence 2.0 provide information on how to specify individual attributes of the web service. | ||
| - | |||
| - | \\ | ||
| - | |||