modelling the digital trust domain

Fri, Jul 18, 2008

As Guanxi 2.0 progresses towards official release and I’ve ironed out a lot of issues and streamlined parts of the system, I thought it was time I took a few steps back, as a painter might, to get an idea of the overall picture and the aims of the application. As skill level increases in a particular domain, in this case Shibboleth, one may work up through the Dreyfus levels, to reach an understanding that encompasses not only the internal workings of the application but the wider context in which it sits. Although Guanxi is primarly a Shibboleth implementation, there are other SSO systems out there, which I should keep an eye on, such as OpenID and OAuth. As well as that, each wagon circle has its own vocabulary and protocol exchanges but underlying all is the concept of trust.

In the UK Federation, the trust fabric is expressed in SAML2 metadata [PDF] with a set of extensions that are manifestations of an underlying technical problem that had to be surmounted in the early days of Shibboleth, to do with SSL certificates not being propagated to SAML entities. So with Shibboleth, there are three steps to verifying the authenticity of a SAML entity, such as a Service Provider (SP) trusting an Identity Provider (IdP):

  • The SP examines the entityID of the IdP and uses this as a lookup into the metadata it holds for all trustable entities. This is basically a first order sanity check asking, “who are you” and “should I even be talking to you”.
  • The next step involves the SP verifying the digital signature of the SAML message coming from the IdP and checking whether the subject name of the certificate can be resolved to an aspect of the entity in the metadata.
  • The final step is when the SP then extracts the root issuer of the IdP’s certificate, checks it can trust it (via the metadata extensions mentioned above) and then verifies the root signature of the IdP’s certificate.
So there are some complicated manoeuvres to perform when enforcing a trust model such as the one in use in Shibboleth federations. On top of that, there is the concept of federation itself. This is a purely human concept which has no place in the software implementation of the SAML profile used to build a federation. I feel pretty confident in stating that for two reasons. What I’ve seen of federations and what Scott Cantor has said recently:

As far as the software is concerned, there‚Äôs no such thing as a federation” [ref]

Federations are there to keep lawyers in business and to keep members in check. They specify who can and who cannot join, based on profile implementations, what level of assurance they can offer on the validity and integrity of their data and whether they can comply with tracking requests to pursue errant users of Service Providers. In a way, they’re a necessary evil as humans will, given enough rope, eventually become pirates. Federations are gentlemens’ clubs designed to keep out the pirates. That also means that there are two layers in systems that work with federations. There’s the core SAML layer, which satisfies the demands of the federations’ lingua franca, SAML and Shibboleth in particular and the application layer where the federation rules are implemented, for example logging and tracking functionality, such as the requirement to satisfy section 6 of the UK Federation Rules of Membership [PDF].

However, there are other trust models to deal with, so in the next few posts I’m going to look into using my favourite agile methodology, Domain Driven Design, to find a ubiquitous language with which to describe the digital trust domain and use that domain model to implement a generic trust engine for Guanxi. Will it be possible to encompass multiple trust requirements in one domain? I don’t know, yet but it will certainly be an interesting voyage in the stormy seas of digital identity.

comments powered by Disqus