lightweight profile

Wed, Jul 21, 2004

shibb 1.3 is on the way: Shibboleth 1.3 draft

The point of Guanxi, from a Siva perspective is to shibbolethise Siva. What does that mean? At the moment, Siva is a toolkit that can be downloaded and plugged in to an institution’s development infrastructure. It’s a jar that provides all the functionality that’s needed, among other things, to manage and query various directories, such as Novell NDS. It can only be used by a compiled app using the jar directly.

What if the attribute part of Siva were SAMLised and made into a web service? Using the Internet2 implementation of the SAML protocol, extending if necessary and using that to accept shibb-type attribute requests, the point being to aggregate attributes from various stores within an institution and resolve namespace conflicts.

Public keys are the key. Automatic registration of an institution’s key on the Siva side would allow that institution to then sign attribute requests and send SAML messages direct to another institution’s Siva.

It could be extended to allow inter-institutional account maintenance, if that’s pratical or indeed needed. Haven’t really thought out the use cases yet so I can’t dismiss it out of hand.

Where would a lightweight profile fit within shibboleth? Here’s a use case:

  • joebloggs@uhi logs in to a remote Bodington instance at Leeds. There’s a potential clash of users here as there’s already a joebloggs enrolled at Leeds and with an account on the Leeds Bodington instance
  • joebloggs@uhi must append his domain to the his local username : Login =
  • Leeds Bodington, which has the Siva authenticator module installed, detects the presence of the domain on the username
  • The Leeds Siva authenticator then negotiates attributes via SAML from the UHI lightweight “origin” web service
  • Attribute requests are signed, so I would propose that each service at an institution that is Siva enabled should have it’s own public/private key pair. This would allow finer control of what services can request attributes and can allow an institution to prevent rogue systems from contacting remote Siva instances. Well, they could still contact but the remote Siva would refuse as the registered key would not match what was presented.
  • Using SAML signed assertions, the two Sivas would communicate to provide Leeds with attributes about the UHI student
  • These attributes could then be stored temporarily within the Bodington session as XML, ready to be passed to the authoriser which checks to see if the student has enough attribute defined privileges to continue

It’s shibboleth compliant in that a Siva SAML web service will accept signed attribute requests from either a remote Siva or a standard shibboleth system.

comments powered by Disqus