guanxi shibb kit in sakai

Tue, Nov 28, 2006

Following on from the proof of concept, I’ve come up with the Guanxi Shibb Kit (GSK). In a nutshell, it’s a separate Sakai portal (/shibb) that acts as a “holding area” for shibboleth users who want to get into a normal Sakai. Think of it as quarantine for users until they can be verified via shibboleth transactions. Once they get their SAML jab, the GSK puts a Sakai name badge on them and sends them off to the main Sakai portal, which is usually /portal. The whole shibboleth process is turned on and off via one setting in sakai.properties, shibb.enabled. If this is set to false then all shibboleth functionality is turned off.

Now, they say a picture is worth a thousand words. In this case it’s worth a few million, so here it is. Click on the image to get a bigger version. GSK in Sakai

As you can see, normal Sakai users are in no way inconvenienced by their Shibboleth counterparts, lepers that they are. That lot go in the back door, via the /shibb portal, where they are immediately halted, marked as unclean and told to go off and authenticate at their Identity Provider. It’s the Guanxi Guard that does this. What it does is, when it detects an access attempt on the shibb portal, it handshakes with the Engine, which is the Guanxi SAML Engine and tells it that it wants a new session set up. The Engine responds with the WAYF location once it has verified the Guard is who it says it is and the Guard then redirects the user to the WAYF and their Identity Provider (IdP).

The user authenticates at their IdP and the resulting SAML AuthenticationStatement is sent to the Engine, not the Guard. That’s how Guanxi works. It’s a distributed Service Provider, based on secure web services. This means you can have the Engine anywhere and I mean anywhere, not just in the Sakai domain. It can be anywhere on the ‘net. The secure web services and metadata make sure that Engines trust (or don’t trust) Guards. Not cookies. That means you could have one Engine providing SAML services to hundreds of Sakai /shibb portals. All Sakai instances on the planet could use a small set of Guanxi SAML Engines to provide shibboleth services to their Guards in their /shibb portals. But that’s another story.

Once the Engine gets the AuthenticationStatement, it matches up an ID in it with a session that a Guard previously set up with the Engine. The Engine then gets the attributes for the user identified in the AuthenticationStatement by constructing a SAML Attribute Query and sending it to the user’s Attribute Authority (AA). The AA sends the attributes back to the Engine, which forwards them on to the Guard.

Now that the Guard has attributes for the user it can inspect them and apply any policies about getting in to the main Sakai portal. If all is well, the Guard will construct a Pod into which it will bung all the SAML attributes for the user. It then stamps the user’s forehead with a big “OK” and sends them off to the main /portal site via a browser redirect. That’s the user now in Sakai. They’ve been given the green light by /shibb and if /portal needs to know about them it will get access to their info via a couple of federated providers, which we’ll take a look at now.

Although you can turn shibboleth on and off from sakai.properties, you also need a couple of special providers for all this to work. These are:

  • FilterUserDirectoryProvider, developed by CARET which “chains” User Directory Providers (UDP) together. If one UDP fails to recognise the user, the next one in the chain is tried. In this way requests for info on a shibboleth user will fail against an LDAP UDP but pass against a Pod UDP.
  • FilterGroupProvider, developed by UHI, which “chain” Group Providers (GP) together. If one GP fails to recognise the user, the next one in the chain is tried. In this way requests for info on a shibboleth user will fail against an LDAP GP but pass against a Pod GP.
So what’s a Pod UDP and GP? They’re interfaces onto a collection of Guanxi Pods that hold SAML attributes on users that the /shibb portal has processed and passed. Whereas an LDAP UDP gets it’s info from an LDAP store, a Pod UDP gets it’s info from a Guanxi Pod. The Pod UDP will know how to get the right Pod for the user and will use that to give info on the user to Sakai. Likewise the Pod GP.

Pods can be persisted to the Sakai database so that shibboleth users are “always there” if you want to add them to groups when they’re not logged in to Sakai. However, there’s a caveat to bear in mind. Their persisted presence in Sakai is subject to the Time To Live (TTL) of their SAML attribute assertions. i.e. if their AA states that they are a member of UHI but only for the next 24 hours then their Pod will refuse to acknowledge them after those 24 hours have elapsed and Sakai will have to say goodbye to them. This is all policy for eLearning though. If an AA is only dishing out short lived assertions then it’s no use for eLearning.

And that, dear readers, is a whole different kettle of fish…

comments powered by Disqus