This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
developers:advanced-integration:principles [2016/10/26 07:48] 127.0.0.1 external edit |
— (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. | ||
- | |||
- | \\ | ||
- | |||