All change: New job, new challenges

I've worked for the University of Cambridge Computing Service and subsequently for University Information Services for almost 17 years. At the end of this month I'm going to step back from my current responsibilities and go and do something almost entirely new.

With the support of UIS's management and at my request I'm about to be seconded to work with Dr Ian Lewis, University Director of Infrastructure Investment, on the Intelligent City Platform that he's developing as part of the University's collaboration with Connecting Cambridgeshire's Smart Cambridge' project  and the Greater Cambridge Partnership (formerly The City Deal). This involves a whole group of technologies (remote sensing, mapping, GIS, data handling, etc., etc.) that I've always been interested in but never had the time to work with. I'm looking forward to the new opportunities.

Over the years I've done quite a few things for the Computing Service and UIS, many of which I'm still involved with managing and developing. Plans are afoot for rearranging and reassigning those responsibilities, but at least in the short term this change is going to throw additional work on my already overstretched colleagues. If you are a consumer of any of the things I've previously been responsible for then please cut my colleagues a little slack while these reorganisations complete. One advantage of the agreed secondment arrangement is that for the short term I'll still be available to provide answers to all those questions that I've somehow failed to answer in the documentation.

Onward and upwards...

x509 certificate chaining

Our x509 certificate supplier recently change the root and intermediate certificates needed to use them (without warning, which was unhelpful). Sorting this out caused me to have to re-learn how certificate chaining is supposed to work.

As far as I can see, the primary rule is that the 'Issuer' DN of one certificate must match the 'Subject' DN of a certificate corresponding to the key that signed the first certificate.As an optimisation or hint, certificates can contain a 'Authority Key Identifier' which should match the 'Subject Key Identifier' of a certificate corresponding to the key that signed the first certificate. Quite what a key identifier is is not defined though there are suggestions. In most cases it's some sort of digest of the corresponding public key.

If you really want to know how certificate paths are built and validated then see RFC 4158 and RFC 5280.

Updating SAML Service Provider keys for Shibboleth IdsP

SAML Service Providers (SPs) maintain one or more key pairs for use when interacting with Identity Providers (IdPs). The public part of these key pairs are distributed to IdP via SAML metadata or otherwise.

SP keys are used for two purposes:

1. The SP uses them to sign authentication requests
2. IdP use them to encrypt attribute assertions in responses for decryption by the SP (encryption is optional, but commonly enabled)

Keys need to be replaced occasionally. This can be difficult to achieve without service disruption because the public parts are distributed and it's impractical to update all copies simultaneously. For a Shibboleth IdP, coping with replacement of an SP key used for signing isn't problematic -- a new key can be added to the SP's metadata ahead of deployment and the IdP will be happy with signatures made with either. However once two keys appear in the metadata the IdP may use either to encrypt assertions and this will only work if the SP is happy to perform decryption with either key.

For Shibboleth SPs this isn't a problem, because they can be configured to accept multiple keys for decrypting assertions while using a nominated key for creating signatures. There's a well known procedure for rotating the key on such a SP, see for example documentation on the UK federation site and in the Shiboleth Consortium Wiki. This amounts to:

• Create new key pair on the SP
• Configure the SP to accept either key for decryption but not use the new one for signing (by adding the new one with use="encryption")
• Add the new key to the SPs metadata for both use="signing" and use="encryption" (or just without a 'use' attribute)
• Wait for the metadata to propagate, or directly update all IdPs
• Switch the SP to use the new key for signatures (by removing use="encryption" from the new one and adding it to the old one)
• Completely remove the old key from the SPs metadata
• Wait for the metadata to propagate, or directly update all IdPs
• Remove the old key from the SP configuration

Some SPs don't support this. However it is only encryption that causes a problem. The main reason for encrypting assertions is to prevent users seeing what the IdP is saying about them, but in man cases there's nothing in the assertions that the user can't see by other means. So temporarily disabling encryption while rolling a SP key is a possibility. This means that the key can be rolled without downtime with the following revised procedure:

• Setup custom relying party on the IdP for the SP that suppresses encryption. Something like this:

<rp:RelyingParty id="<SP entityID>"
   provider="<IdP entityID>"
   defaultSigningCredentialRef="IdPCredential" >

   <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
       encryptAssertions="never" 
       encryptNameIds="never" />

 </rp:RelyingParty>

• Add the new key to the SP's metadata
• Wait for the metadata to propagate, or just update all IdPs.
• Switch the SP to use the new key
• Remove old key from metadata
• Wait for the metadata to propagate, or just update all IdPs.
• Remove the custom relying party configuration

Note that this requires coordinated work on every IdP with which the SP works so it's not practical on a large scale. It will however work where there's essentially a one-to-one SP -> IdP relationship, as in many SaaS scenarios.

Tools such as the Firefox SAML tracer, the Chrome SAML Dev Tool extension and the SAML Chrome panel are  really helpful for checking that each step of the process has completed before moving in to the next.