guanxi service provider news
Tue, Jun 21, 2005
The old cake trolley has been taking a bashing lately as the Guanxi Distributed Service Provider (SP) moves from vapour, to design to implementation. Currently it’s at the stage of gathering attributes with the next stage being to signal the readiness of said attributes to the appropriate Guard.
To quickly run over what the SP is and why it’s distributed, I’ll blether on for a bit while the cake trolley gets refilled. It might help for readers to have the architecture open by clicking on the image below:
It’s distributed in that an institution may download the Guanxi SP and deploy the main Engine on a high availability, high throughput server and use it to provide SAML functionality for all their participating web applications. It’s the Engine’s job to co-ordinate authentication information and attribute gathering on behalf of web applications. It’s even possible to deploy as many Engines as an institution deems fit to provide failover and/or load balancing.
How is this load balancing acheived? Well, the other module in the Guanxi SP is the Guard. This is a lightweight Servlet Filter that sits in front of a web application, such as the Bodington VLE. It’s the Guard’s job to block requests to designated areas of a web application. It then delegates all SAML/Shibboleth processing to the Engine(s). To get hold of a Guard, it’s envisaged that the owner of a web application may request a Guard from the institution’s Engine, which will package and deliver a pre-configured module (a jar file) and some XML config files. The interesting part being that if an institution has multiple Engines each Guard can be pre-configured to communicate with a different Engine, thus balancing the SAML load in a high traffic application environment. That’s where the distributed nature of the SP is evident.
The flow goes like this:
As you can see, the Engine does all the Shibboleth work, coordinating the profile and performing metadata lookups to match authentication information with attribute requests. All the Guard does is block, retrieve attributes from the Engine and make a decision.
Hopefully this architecture will make it easy for web resource owners to quickly join federations and open up their data to Shibboleth compatible consumers.