User:Msalle@nikhef.nl

Projects:

nl.nikhef.slcshttps

Introduction

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

The aim is to change the IMDI BCBrowser such that it can access corpora using client side certificates obtained from an online CA.

TODO: use case description, problem, Shibboleth versus PKI Certificates...

Description

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

From a (mostly) User point of view:

1. User clicks/chooses initialization option
2. java browser starts a webbrowser...
3. which via the online CA at SURFnet...
4. redirects webbrowser to WAYF (Where Are You From) server where user chooses his Identity Provider.
5. User logs in at IdP
6. Webbrowser redirects back to online CA. User closes webbrowser.
7. After confirmation by user, java browser now connects itself to online CA
8. java browser retrieves certificate from online CA and the user can use it to authenticate with client side certificates.

Technical overview:

1. Initialization procedure:
   1. javabrowser creates a per-session keypair (i.e. never 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 send 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.

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 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.

[[Image:Imdi handshake.png

IMDI Browser handshake]]

Code and Files

• full zip-archive (Full zip including jar file, build, and javadoc)
• zip-archive (Zip including only sources, run ant to get the rest)
• JDK1.5 jarfile
• Javadoc API
• SVN repository with source

Talks:

• Talk at BiGGrid meeting, Nikhef, 27 May 2009

Note that you also need the BouncyCastle provider. Direct link to the JDK1.5 jarfile

gLite security

See e.g. Nikhef Site Access Control pages