This document aims to solve the problem associated with allowing a certificate holder (e.g. of a DNI-e, the electronic National Identity Card in Spain) to use a digital signature to logon to a Web application (i.e. a service portal).

Normally, the user will generate from a browser the signature he/she will need to perform the logon.The user can do this by downloading and executing a Java signature applet e.g. OpenSignX, provided that the corresponding Java plug-in is installed in the browser. 

Logon as a general issue 

Currently, several different mechanisms are available to an application when verifying the identity of the user who wants to access it. At present, mechanisms based on Public Key Cryptography (and on the corresponding PKI) are considered to be one of the most secure measures for resolving the user authentication problem. Two mechanisms in particular stand out. Firstly, there is an authentication mechanism that uses public key certificates (with a specific use for authentication); usually, this involves partial delegation to the transport layer (i.e. TLS). Secondly, we have an authentication mechanism that is performed by including a digital signature in a message in the application layer.

In principle, these two options are equally valid. However, the second one has the advantage of allowing the application to store the logon requests; this facilitates any subsequent auditing or integrity-checking processes.  Furthermore, depending on the type of certificate used to generate the signature, non-repudiable evidence on the start of each session is made available to the application. In this way, thanks to the signature of the logon request, the application is protected if the user claims later that the logon was never performed.

Signature-based Logon

A procedure for signature-based logon includes the following three basic steps:

• The user signs a logon message.
• Checking of the signed message for its semantic matching to a logon request in the application; checking if the signature is recent so as to avoid repetition attacks.
•  Verification of the user's signature in the logon message.

Generation of the Logon Message Signature 

In a signature-based logon, it is obvious that the signature must be produced locally because the cryptographic device used to generate the signature will always be in the user's possession. Consequently, the Web application must implement both the presentation of the text that the user has to sign to perform logon (WYSIWYS) and the sending of the request to the cryptographic device so that it generates the signature when the user requires it. We have already mentioned that an element of code that can take on the responsibility of implementing these functions is a Java signature applet (another possibility is an ActiveX control). Obviously, the fact that a signature applet is responsible for providing the cryptographic device with the text that the user must sign, means that the user must establish a trust relationship with this applet. Therefore, the applet must be signed with a code signing  key which the user can trust (i.e. the certification chain of the signature key's associated public key begins at one of the root certificates trusted by the user).

Important
In conclusion, the "SOA approach" cannot be used to generate the signature for logon; it is the application (i.e. the applet) that must implement this functionality directly. 

How to Check if the Signature is recent and if it Protects a Logon Request Message 

• It checks if the message received contains pre-established text (e.g. "I request logon to the www.mysite.com Web application. I understand and accept all the provisions of the contract that regulate access to this website")
• It checks if the message received contains information about the instance in time when the signature was generated (e.g. 2008-04-22T15:40:00Z); once the signature has been verified, the application checks that another logon message with the same instance in time was not received previously from the same user.
• It checks that both the text used to request the logon and the instance in time stated in the message are protected by the signature.

Important
In conclusion, due to the simplicity of the above-mentioned checks, it is not necessary to implement them with the "SOA approach". The application (server side) can implement this functionality directly.

Signature Verification 

With regard the verification of the signature, the following must be taken into account:

• The programming required to verify a signature entails a high level of difficulty. Highly specialized programmers are needed if verification is to be carried out securely and correctly.
• The functionality for verifying signatures may be required by several applications of the company. Therefore, it is recommended that the company manages the configuration associated to this functionality (e.g. CA certificates, certificate validation mechanism) centrally and in auditable fashion.
• None of the actions for verifying a signature must require the use of secrets which are only accessible locally.

Important
In conclusion, the best way of integrating the signature verification functionality needed by an application to complete the user logon is through the consumption of a signature verification Web service. In particular, we recommend using the TrustedX signature verification service. 

Logon as an Aspect of Access Control 

Logon, and therefore, user authentication, is one of the aspects of the access control problem; authorization and auditing are the other aspects.

An SOA solution can deal with all the aspects of access control, particularly if it includes TrustedX as a fundamental element.

In this howto, we will focus solely on resolving the problem of identifying the users of an application through the consumption of the TrustedX signature verification service. And so, we will leave the following issues for discussion at a later date: the handling of the other aspects of access control and the study of how to implement the totality of an application's access control through the consumption of the TrustedX Web services.

Important
This text does not provide a hypothesis on how the application manages authorization. This could be done by delegating the function to TrustedX (i.e. consuming its services) or by implementing it directly.

Description of the Solution

Lets see now a detailed description of the proposed solution

For a user being able to log in an application by generating a signature using a Java applet 

1. A user accesses a service portal via a Web browser. Next, he/she performs an action in the graphical interface of one of the portal pages with the aim of accessing an area of restricted access.
2. The Web application responds to the user action by downloading an applet in the browser. This applet must be signed by its editor with the corresponding code signing certificate.
3. The Java plug-in in the browser verifies the applet signature and informs the user of the result of this verification. Moreover, if the plug-in determines the signature to be valid (i.e. that the signature is authentic and so that the integrity of the applet code is guaranteed), it will request the user's permission to execute it.
4. When the applet is executed, it will request the user to insert the cryptographic device in the reader:
   
5. Next, the applet will present a form that states the following:
• The intention of the user to logon
• The instance in time when the logon will be performed
In this form you select the certificate which will be used to generate the signature required to perform logon (the user may be required to enter the PIN of the cryptographic device).




6. When the user presses the Sign button, the signature applet will request the PIN needed to access the cryptographic device. Then, it will generate a XAdES-BES signature which protects both the text used to request the logon and the time at which this logon is requested. Following this, the signature will be sent to the server side of the Web application
7. When the Web application (server side) receives the signature generated by the applet, it checks if the two previously mentioned elements (i.e. the logon text and the time of the logon request) are really protected by the signature. In other words, it checks if the <SignedInfo> element of the XML signature references an Object element that contains (regardless if base64-encoded or not) the text and the instance in time mentioned above. An example of an Object element is given below.

	<dsig:Object Id="Id1101546766521506652682621207">
	Solicito realizar logon en la aplicación web del
	sitio www.misitio.com.
	Reconozco conocer y aceptar todas las disposiciones 
	contractuales que regulan
	el acceso a este sitio.2008-04-27T18:00:52+02:00
	</dsig:Object>
	

8. The Web application extracts the instance in time that corresponds to the logon (LogonTime and compares it to the instance in time indicated by the system clock (ApplicationTime). The logon request will be rejected if the difference between the two instances (absolute value) is greater than the maximum allowed time difference MaximumOffset

   |LogonTime - ApplicationTime| < MaximumOffset

9. The Web application will check for any logon requests in the cache which were generated by the same signer (i.e. the same certificate) and which contain the same instance in time. If the check proves positive, the logon request will be rejected for being considered a repetition attack.
10. Finally, the Web application will submit a signature verification request to the TrustedX signature verification service. If this verification determines the signature as valid, Trusted will provide the identity of the signer. The application will consider this identity as having been accredited by the user who requested the logon.The Web application will record, in the cache, that the logon was performed by this user at the instance in time that appears in the verified signature, and by using use the certificate involved in the signature.
11. The TrustedX signature verification service will respond with information on the level of trust that was granted to the verified signature. This level of trust can be used later to grant or deny authorization to the user when he/she performs the different actions available in the application (see Electronic Signature Verification using TrustedX).
12. If you opt for a solution which, based on the use of suitable certificates, guarantees the non-repudiation of the logon messages, you must bear in mind that it will be necessary to manage the long-term nature of the signatures of these messages and that the TrustedX services can also be used for this management (see Non repudiation and long-term signatures).

     

Final Considerations  

• We have described the solution in a way that takes for granted the advantage of displaying in the applet's graphic interface the data whose signature will be needed by the user to perform the logon (i.e. WYSIWYS). In this way, if the user uses a certificate recognised for generating signatures with non-repudiation commitment (i.e. the nonRepudiation bit in the KeyUsage extension is activated) to produce the signature, this signature could be considered to be a recognised electronic signature. Therefore, this signature could be considered to be non-repudiable evidence proving that the logon request did actually take place.
•  Obviously, this may not be necessary in all cases. In such circumstances, the presentation of the text and the instance in time that are going to be signed could be omitted. Moreover, we recommend that you oblige the user to select a certificate that has the sole use of authentication (and not for generating non-repudiable signatures).
•  To protect against repetition attacks, a randomly generated nonce could be used instead of the instance in time when the logon is requested. However, this option incurs the difficulty of forcing the Web application to "indefinitely" save the record of used nonces.
•  The Web application in which the user wants to perform logon will also have to be authenticated in TrustedX before it can use the TrustedX signature verification service. This authentication can be carried out from time to time (i.e. by including the authentication credentials of the application in the header of the SOAP message requesting the service) or through previous logon of the application to TrustedX (i.e. starting a session).
•  You can use the OpenSignX signature applet. Currently, this applet encodes in base64 the text that has to be signed before the signature in question is produced. This must be taken into account when implementing the verifications mentioned in point five of the proposed solution.

Go to discussion forum (1)