ID Maan comments:
Little puzzled with your views respect to SAML:
“It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent “disappearing†of the user.”
As I understand WS-Trust is a token agnostic protocol. Delegation on other hand can be essentially considered as the capability of the securty token. So, isn't WS-Trust in a way dependent on the security token capabilities to provide for delegation? In other words, if you state SAML is insufficient to solve delegation problem, so is WS-Trust protocol that uses SAML tokens?
No wonder he is puzzled. I should have been clearer. Let me try again.
We all agree the SAML token is a fine and good way of expressing sets of claims.
But beyond the token, there is the SAML protocol – one way of moving SAML tokens around.
I think the SAML protocol suffers from having a single-token design. Why?
I don't think delegation problems can be solved through a single token. Once you are expressing the identities of both a user and a delegate, you need to be able to request and convey two (or more) tokens – in the sense of integral things from separate sources. In the simplest case, one represents the user, one the delegate.
To be clear, I wasn't hitting on the SAML protocol in all its applications. I was arguing that WS-Trust, which has the ability to move and request multiple tokens simultaneously and establish relationships between them, solves the delegation problem more cleanly from an architectural point of view.
When SAML was being elaborated, before the user-centric identity wave, we saw the user as being represented by the portal service. She had no independent existence. So you didn't need multiple tokens.
Since Identity 2.0, all this has changed.
I hate to do this again, but I feel compelled to comment. Everything you say here about the SAML protocol is wrong.
It is not a single token design, never has been. A lot of the changes in SAML 2.0 were designed by me explicitly to better support delegation scenarios, and it does support them (usually by using multiple SAML tokens or with a token exchange model). And on top of all that, it supports non-SAML tokens exactly like WS-Trust does, it just requires a SAML token around them.
You've noted problems with the use of SAML assertions, and some of them are quite valid. These issues are not. On the contrary, it is WS-Trust which lacks interoperable profiles around performing delegation in conjunction with SSO. SAML and Liberty have them. That's the reality of things.
Eventually those profiles will get written, but that's no excuse for claiming that existing specs don't already support these use cases. SAML has NEVER viewed the “portal as root” model as a means of handling delegation. It was designed explicitly to stop that practice.
While the notion of delegating to a service seems nice in theory, I'm concerned that it can get real messy in a hurry. The service would often want to re-delegate to other services, and so forth. It can get real complicated real fast. If Law 1 includes the ability of a user to understand the consequences of what's happening with her identity, then you might quickly exceed the user's ability to comprehend, anticipate, or whatever.
Furthermore, how about the ability to audit identity transactions. How many log files will an auditor need to round up, correlate and from whom in order to obtain confirmation about who did what and when? How many coupons, receipts, SAML assertions, etc. will an auditor want to see? Where are they? Are they even available?
I'm not arguing for any particular point of view here. All I'm really saying is that the area of delegation is a large, fertile, and as yet unexplored area. So let's have fun exploring.
I don't think it's a prerequisite that a user understand everything that's happening in order to recognize there are good and bad ways of building systems. If we limit ourselves to what users can understand, we'd never implement much of anything.
The whole point is to limit the bad stuff that can happen when users don't understand. At least that's how I approach it. As for auditing, try and audit a system without delegation. I guess it's a quick audit, since nobody can prove much of anything about it.