the saml loopback profile
Thu, Dec 8, 2005
Been playing around with WSS profiles and came up with the SAML Loopback Profile. It’s basically a way for SPa to initially get a SAML Subject from an IdP and then pass that Subject to SPb, which can then pass it to SPc and so on, up to SPn.
The point being that each SP can send the Subject back to the IdP to get attributes specific to that SP. I called it the Loopback profile as it allows an SP to “loopback” to an IdP with a Subject.
Of course, some work is needed to polish it up, such as how to pass the location of the IdP along with the Subject.
However, it’s shaping up to be the digital identity of a user. An agent if you like. The agent can be sent from one SP to another and if an SP needs attributes for the user represented by the agent, for example to access restricted searches, it can loopback to the IdP based on what the agent tells it.
One thing that came out of a conversation at the JA-SIG in Austin the other day was the need for a set of attributes that could be released to SPs that aren’t in the federation. At some point, the agent is going to cross a federation boundary and an extra-fed SP is going to loopback to an IdP that doesn’t have metadata for it. That’s the interesting part. What can the IdP release to it? A set of “collaboration attributes”? Perhaps attributes that the agent has access to and is allowed to negotiate release to an extra-fed SP on behalf of the user?
I had a brain dump at the ASK project architecture meeting at the University of Manchester the other week and this document was the result. It’s a comparison of the Single Sign-One With Constrained Delegation Profile with the proposed, nascent, Loopback Profile.