Introduction

Summary: authentication with client certificates, especially Belgian eID, https protocol

Kauri's security module currently supports authentication using the Belgium's electronic identity card (a smart card). From the web-server's point of view, this is just a case of https using client certificates. On the client side, there is software installed to interact with the smart card.

The work for this project is server-side and as such has little to do with the eID card, so people who don't have such a card (thus, are not from Belgium) are also able to do the work. We could probably also look into providing a test card, if necessary.

If you do have a Belgium eID, you can easily check what we currently have by checking out Kauri trunk, building it, doing "cd samples/kauri-security-sample" and exeucting "../../kauri(.sh)"

While the current eID authentication for Kauri already works, there is still some work to do (verification of certificates) and some room for improvement (allowing to enable client authentication only for certain URLs). These are detailed below.

Verification of the certificates

The certificates sent by the client need to be verified in multiple ways. For example, it should be checked they are not expired (using the data stored in the certificate). It should also be verified that they are not revoked, by either downloading a certificate revocation list or using an online check (OCSP).

Java does provide various APIs for this, see the TrustManager, the CertPathValidator, and so on.

What needs to be done is:

  • check what verifications need to be done in general, check what Java's ssl engine already does by default, and hence what remains to be done by us
  • check whether we can do certificate revocation checks on that level, or whether we do it better later on in Kauri
  • make sure the verification happens in an efficient way. For example, it doesn't make sense to redo all the checks on each HTTP request, thus we need some cache.

Allowing to enable client certificates only for certain URL paths

Right now, the HTTPS connector of Restlet (provided by Jetty) allows to either enable or disable client authentication. You can't enable it for just certain parts of the URL space.

However:

  • Apache's mod_ssl does seem to have this feature
  • Java's SSLEngine javadoc mentions that rehandshaking is possible, whereby you can reconfigure if client authentication is necessary

So it seems like it should be technically possible.

The work here would be to look how this can be made possible in Kauri. Maybe it is already possible on the level of Jetty, since it seems like Servlet's allow configuring it for certain url patterns (using <auth-method>CLIENT-CERT</auth-method> in the web.xml).