guard to engine communication
Thu, Jun 23, 2005
The Guanxi Service Provider (SP) is distributed in that the main Engine can be remote from the Guards that protect web applications. Each Guard is assigned it’s own providerId, in Shibboleth speak, when it’s created, configured and deployed and it’s the Guard’s job to initiate a Shibboleth session at the Engine. Once this is done, the next thing the Engine sees is a SAML Response containing an AuthenticationStatement and also, optionally, an Audience.
How to match this SAML Response coming from an IdP with a previously initiated Guard session? It could be done using the Audience element in the Response but this isn’t guaranteed to be there in SAML1.1. Apparently in SAML2 it will be there but whether it contains anything useful in such an identification scenario is not certain.
So, I plumped for the shire parameter that is initally sent to the IdP from the WAYF or SP:
http://some.idp.url/SSO?shire=http://some.sp.url/SP &target=http://some.resource.url &time=1110371915 &providerId=urn:guanxi:guard
The providerId in the above IdP query string refers to the Guard. It’s the Guard’s providerId. The problem is, how to get the IdP to return that providerId to the SP. It’s usually not required as it’s the SP making the request so it knows about the response. In this case, the Guard made the request but the Engine gets the response. As I said, relying on Audience might not work, so the way around it is to add the Guard’s providerId to the shire param:
http://some.idp.url/SSO?shire=http://some.sp.url/SP?providerId=urn:guanxi:guard &target=http://some.resource.url &time=1110371915 &providerId=urn:guanxi:guard
Now the Guard can “bounce” it’s identity off the IdP to the Engine and the SP can then become a truly distributed system, not being constrained by cookie domain limitations. Cookies are still used at the Guard to manage authorised sesssions to the resources it protects but domain crossing between the Guard and the Engine is done by the IdP Bounce technique.