shibbing sakai with the gsk
Sat, Oct 28, 2006
So I’ve come up with the idea of a Guanxi Shibb Kit (GSK). Basically what it is, is a shibb portal for Sakai. It’s minimal, has no traditional tool or site support. All it does is log a user in and then redirect to the main portal, which at the moment is Charon.
But surely that’s a security hole? having a portal that does auto-login? You might think so but in fact it’s not as the shibb portal will be protected by a Guanxi Guard. To access the logic that automatically logs you in to Sakai, you have to go through the shibboleth process of going to the WAYF and authenticating at your IdP. When you arrive back at the shibb portal, your SAML assertions are inspected, the attributes are unpacked from the SAML Attribute Assertions and are placed in a Pod in your Sakai session.
At the point of Pod injection, the shibb portal considers you are fit to enter Sakai, so it logs you in and redirects you to the main portal, Charon. Now Charon should recognise your session is set up and you’re ready to go so it should just redirect you to where you want to go in Sakai.
The GSK will come with a Pod specific UserDirectoryProvider and GroupProvider, which will be chained into the system using Caret’s chaining system. So whereas LDAP providers get their user and group information from an LDAP store, the Pod providers will get their information from Pods.
I’ve got the shibb portal installed. Now I just have to figure out how to forward to the Charon portal. I suspect it’ll be something to do with ActiveTool.forward().
However it’s a real bind debugging Sakai. It just takes so much memory the laptop is really really struggling. In Eclipse which hogs most of the memory anyway, click, wait 30 seconds, toggle breakpoint, wait 30 seconds, click, wait 30 seconds, open declaration, wait 30 seconds. All while Sakai is taking a few minutes to start up.
So I’m off to debug the Mercury portal to see how it forwards to tools.