User:Msalle@nikhef.nl

Projects:

nl.nikhef.slcshttps

Introduction

This project is a joined project between The Max Planck Institute for Psycholinguistics (MPI), SURFnet and Nikhef.

In the context of the ISLE Meta Data Initiative (IMDI) the Max Planck Institute for Psycholinguistics has developed a number of software tools, such as the IMDI BCBrowser, to handle and explore corpora from the MPI and other institutes. These corpora were until now disclosed via Apache's basic authentication mechanism. Recently they were in addition also disclosed using the Shibboleth system, since MPI joined in some EU projects requiring the use of federated login. This Shibboleth system is developed for use with web browsers and is less suitable for standalone applications such as the IMDI browser, which can download whole datasets. Hence it was necessary to look for a solution that would somehow allow both the direct Shibboleth access for web browsers but also enable non-webbrowser tools to use a federated login. The different authentication methods should all be consistent and intuitive for the user.

In the `Grid' world, Authentication and Authorization is based on the use of PKI (Public Key Infrastructure) in the form of X.509 certificates. Delegation (service A tries to access service B on behalf of the user) is implemented using proxy certificates (short lived, fully functional certificates, that can be traced back to the original user). This PKI system works well for many different applications, including web browsers, but is complex and difficult for many users.

In order to try to get the best of both worlds, Shibboleth and PKI, there have been a number of initiatives to set up so-called SLCS services, Short-lived Credentials Services (see for example the SWITCH SLCS service). These services are connected to Online CA's that hand out fully functional, but short-lived, certificates to users, who authenticate using their institution login. By moving the identity vetting to the home institution, the process of receiving and using a certificate can stay mostly hidden for the user, thus greatly improving their user-friendliness.

Aim of the project

It was decided to set up a project to look at the usability of such a SLCS service for access control of the IMDI corpora. Using PKI for authentication would have a number of extra benefits. First of all, as noted above, it can also be used for delegation, which in the IMDI browser use case would practically mean that while the user goes to a single point of entry, corpora can then try to obtain the requested information at other sites, corpora etc. on behalf of the original user (the `Shopping Basket' model). Secondly, it will make it possible to get access to the computing and data facilities of the Grid. Finally, from a technical point of view client-side certificates are relatively easy to implement. This project is also interesting as a technology study for the pan-European CLARIN project (Common Language Resources and Technology Infrastructure). As a first step it is therefore necessary to implement working PKI based authentication in the existing repository systems, both on client and server side, with certificates obtained from a SLCS service.

Work distribution

The developed implementation can be divided into four separate parts:

1. An SLCS service with Online CA, developed by SURFnet
2. A set of Java packages in the form of a JAR file, developed by Nikhef
3. Adaptions to the code of the MPI IMDI browser Java tool, implemented by Nikhef
4. Configuration of the Apache webservers at MPI such that they understand both plain Shibboleth and client side certificates from the SURFnet Onlince CA, implemented by MPI

Description of the Online CA/SLCS handshake

Method used by the IMDI browser to obtain a certificate, see also the image below.

From a (mostly) User point of view:

1. The user goes to a login/initialize function of the IMDI browser (this instructs the tool to create a private-/public keypair and a certificate signing request (CSR)) and...
2. ...lets the IMDI browser start a web browser...
3. ...to the SLCS with a hash of the CSR added
4. The user gets redirected (optionally via a Where Are You From (WAYF)) to an Identity Provider (IdP) for his own institution.
5. The user logs in at his IdP.
6. The web browser gets redirected back to the SLCS by the IdP, which informs the user he should go back to his application.
7. The user now has to instruct the IMDI browser that he is ready, which triggers the IMDI browser to send the full CSR to the SLCS.
8. This step is transparent for the user: the Online CA signs a new certificate with the eduPersonPrincipalName as subject and SLCS sends it back. The IMDI browser stores this certificate and will be using it together with the private key it has, for client side authentication when setting up new https connections.

Technical overview:

1. Initialization procedure:
   1. javabrowser creates a per-session keypair (it will never be saved to disk).
   2. javabrowser creates a certificate signing request (CSR)
2. javabrowser starts a webbrowser...
3. the URL is the online CA + a hash of the CSR.
4. Now the standard Shibboleth trajectory starts: Online CA redirects the browser to a WAYF where the user chooses his IdP.
5. User logs in at his/her IdP.
6. Webbrowser sends the user back to the online CA. The URL is now rewritten using Shibboleth, and the Online CA knows that the user, who sent the CSR hash, is authorized. The user now tells the javabrowser that (s)he is finished with the webbrowser.
7. The javabrowser sends the full CSR to the Online CA.
8. The Online CA:
   1. calculates the hash
   2. checks whether it is known/corresponds to a authorized user.
   3. if yes, signs the CSR
   4. sends a HTTP reply with the signed certificate.

   The signed certificate is stored inside the javabrowser and will be offered as client side certificate upon opening a HTTPS connection.

[[Image:Imdi handshake.png

IMDI Browser handshake]]

Notes:

• In Shibboleth terminology, The Online CA is a Service Provider (SP) whose service is the creation of certificates.
• In standard CA/RA certificate terminology, the online CA Service Provider is the CA, while the IdP plays the role of RA.
• The SLCS model used here is similar (but not identical) to the SWITCH model, which is described in detail in https://edms.cern.ch/document/770102/.
• Another SLCS-like project, which is actually aiming at long-term (+/- 1 year) certificates is the Confusa/Terena project.
• The main difficulty for these SLCS implementations is the interaction of a standalone, non-webbrowser based tool with Shibboleth, since Shibboleth IdP's only requirement is that they work with a webbrowser. On the other hand, the private key has to be present is the tool which eventually will be using the certificate. A number of solutions have been proposed and tried, but since the IdP is only guaranteed to work with a webbrowser we believe it is best to have the javabrowser start a webbrowser. The difficulty then is to guarantee the authentication across the two applications. We solved this by
  • sending a hash of the CSR during the authentication which can be checked later when the javabrowser sends the CSR itself
  • limiting the time between authentication and sending the CSR
  • requiring both tools to work from the same host.

Code and Files

• full zip-archive (Full zip file including jar file, classes and javadoc)
• zip-archive (Zip including only sources, run ant to get the rest)
• JDK1.5 jarfile
• Javadoc API
• Browsable SVN repository with source
• The code can be checked out using the command

svn checkout https://ndpfsvn.nikhef.nl/repos/pdpsoft/trunk/nl.nikhef.slcshttps 

Note that you also need the BouncyCastle provider to build and/or run. Direct link to the BouncyCastle 1.44 JDK1.5 jarfile

Talks

• Talk at BiGGrid meeting, Nikhef, 27 May 2009

gLite security

See e.g. Nikhef Site Access Control pages