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:
- The Guard blocks a request to a web application’s resource and sets up a session with the Engine that it’s pre-configured to talk to. It does this by using a JAX-RPC web service invocation to the Engine, telling it who it is and to prepare the Engine for an incoming AuthenticationStatement from the user’s IdP. The Guard uses WS-CallBack to tell the Engine where to send a message when the attributes are ready. The Engine prepares itself and responds to the Guard with the location of the WAYF that is in use
- The Guard sets up a local session for the user and redirects them to the WAYF, using the Shibboleth profile. However, the “shire” parameter is set to point to the Engine’s attribute consumer service. The Guard will not deal with Shibboleth directly. This keeps it lightweight and simple to deploy
- The user chooses their institution from the WAYF, gets authenticated by their IdP’s SSO and the resulting SAML AuthenticationStatement is sent to the Engine
- The Engine receives the SAML Response from the IdP’s SSO, containing the AuthenticationStatement, extracts the NameIdentifier, does a metadata lookup on the IdP’s providerId and sends a SAML Request to the IdP’s AA to get attributes for the user
- Upon arrival of the attributes, the Engine matches the attribute set to a Guard session, finds out the location of the Guard’s notification web service, previously passed to it by the Guard via WS-CallBack and signals to the Guard that it’s attributes are ready.
- The Guard then invokes a web service at the Engine to retrieve the attributes, examines them against it’s policies and makes a decision on whether to grant or deny access to the resource
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.