the gsk works
Thu, Dec 7, 2006
So, after a few late nights and some head scratching, not to mention serious classloader issues, I’ve now shibbed Sakai 2.2.2. I used the newly released Guanxi SP 1.3.0. At the moment, the Engine is separate with just a Guard in the /shibb portal but now I know the shibboleth portal concept works I’ll bring in the Engine to make it a standalone system.
The major problem I had was the “closed” nature of the Shibboleth subsystem, i.e. the Guard and the Pod. The Pod was causing classloading problems, so get round them I just bunged the whole lot in /shared/lib and it worked, as I knew it would.
But now that the proof of concept is out of the way, I’m going to do a GSKPod which will conform to Sakai’s api/impl architecture, with the api going in /shared/lib and all the Guanxi SP stuff staying put in /webapps/shibb/WEB-INF/lib. It’ll be the /shibb portal’s job to do the subsystem bridging, from a Guanxi Pod to a GSKPod. That should get round the classloading problems and make the GSK a proper Sakai player. I think I’ll implement all the SAML Assertion policy management in the GSKPod. What’s now emerging is an architecture whereby the low level Guanxi SP (Engine + Guard) do the Shibboleth work and the GSK takes over and adds application specific bells and whistles, in as generic a way as possible. So raw SAML comes out of the Guard and is refined in the GSK. It’s the GSK that applications will work with.
The shibboleth functionality requires CARET’s FilterUserDirectoryProvider though as I don’t replace anything in Sakai. The /shibb portal is complementary and does not affect normal Sakai login. As Sakai can’t chain UDPs, the FilterUserDirectoryProvider is used to do the chaining. It just has one UDP in it’s chain, a GuanxiUserDirectoryProvider, which delegates to a GuanxiPodManager, implementing the PodManager interface. It’s this GuanxiPodManager that I’ll refactor to work with GSKPods.
But the /shibb portal concept works. I’ve proved that today.