Overview

The main purpose of this document is to explain the manner to integrate the 4Identity system into a generic customer scenario.

The generic customer scenario is composed of an:

• Application server that host two applications:
  • The application for signature able to browse a generic PDF file and run the signature against the 4Identity. It was chosen a PDF file due that after the file signature this can be tested using a normal pdf reader:
  • The application for authentication able to authenticate a user using a certificate.
• Web Server that host the 4Identity server components called SMARTENGINE. This component mainly manage the channel built between the 4Identity Client and the browser. Moreover, the SMARTENGINE is also an active part on the Authentication functionality while for the signature process is responsible only of the channel lifecycle.
• User’s desktop client that host the 4Identity Client and run the web browser used to access the web application hosted into the application server.

Figura 1 – Use case

The custom code shown in the following paragraphs has the main objective to drive the developer for the main 4identity functionalities of Signature and Authentication. This custom code is only an example like a “How To Use” 4Identity functionalities and so it is not a programming best practice.

Signature process overview

For the success of a signature process, the requirements for the Application Server (AS) are:

1. The AS must generate\store the file (for example a .pdf) that the user has to sign. This file will be downloaded using a specific URL via a GET http/https.
2. The AS must be able to receive the signed file through a POST. When the loading is complete the AS must respond with a redirect.

The following diagram shows how the:

• Web Browser (WB);
• The 4Identity Client (4C);
• Application Server (AS);
• SmartEngine (SE);

interact during the process of generating a digital signature.

What follows is a description of the various messages exchanged.

Figura 2 – Sequence diagram

1. The WB requires from AS the html page that contains the user interface to start the digital signature process. (see the integration chapter for further information);
2. The JavaScript loaded (bit4id-sign.min.js) will build the channel between the WB – 4C – SE;
3. The 4C will download the document to sign as written into the div tag with class bit4id-document;
4. The user insert the PIN;
5. The 4C will sign the document and send it via a POST message to the address specified in the action attribute;
6. Once the file has been received, AS will respond to the 4C with an HTTP redirect;
7. The 4C will then transfer the redirection request to the web browser.

Authentication process overview

The Authentication process is similar to the signature use case, with the addition of a server to server verification step.

The following diagram shows how the:

• Web Browser (WB);
• The 4Identity Client (4C);
• Application Server (AS);
• SmartEngine (SE);

interact during the authentication process.

What follows is a description of the various messages exchanged.

1. The WB request the login page to the AS, with this page the authentication process start (see the integration chapter for further information);
2. The JavaScript bit4id-auth.min.js will build the channel between the WB – 4C – SE;
3. Once the channel is built, the user insert the PIN for the authentication;
4. At this step start a challenge response against the SE;
5. the SE send a POST message to the AS with the authentication result and in case of successfully authentication with all the user information;
6. The AS, at this point, according to the SE Post message, execute its business logic and respond to the SE with an HTTP redirect;
7. The SE, using the long-held request from WB, sends back the URL redirection to 4C which will, in turn, redirect the WB;