I don't want to get sidetracked into a discussion of the nuances the SAML protocol and token independence, but imagine readers will want me to share a comment by Scott Cantor – one of the principal creators of Shibboleth. He knows something about SAML too – since he was the editor of the Version 2.0 spec. He is responding to my recent post about why communications protocol, trust system and token payload must become three orthogonal axes:
SAML doesnâ€™t have the problem Kim is referring to either. Both trust model and token format are out of scope of SAML protocol exchanges. The former is generally understood, but the token issue is the source of a lot of FUD, or in Kimâ€™s case just misunderstanding SAML. This is largely SAMLâ€™s own fault, as the specs do not explain the issue well.
It is true that SAML protocols generally return assertions. What isnâ€™t true is that a SAML assertion in and of itself is a security token. What turns a SAML assertion into such a token is the SubjectConfirmation construct inside it. That construct is extensible/open to any token type, proof mechanism, trust model, etc.
So the difference between SAML and WS-Trust is that SAML returns other tokens by bridging them from a SAML assertion so as to create a common baseline to work from, while WS-Trust returns the other tokens by themselves. This isnâ€™t more or less functional, itâ€™s simply a different design. I suppose you could say that it validates both of them, since they end up with the same answer in the end.
An obvious strategy for bridging SAML and OpenID is using an OpenID confirmation method. That would be one possible â€œsimpleâ€ profile, although others are possible, and some have been discussed.
I'm not sure I really misunderstand SAML. I actually do understand that the SubjectConfirmation within SAML offers quite a bit of elasticity. But SAML does have a bunch of built-in assumptions within the Assertion that make it, well, SAML (Security Assertion Markup Language). These aren't always the assumptions you want to make. I'll share one of my own experiences with you.
CardSpace supports a mode of operation we call “non-auditing”. In this mode, the identity of the relying party is never conveyed to the identity provider.
The identity provider can still create assertions for the relying party, sign them, and send them back to CardSpace, which can in turn forward them to the relying party. If done properly, using a reasonable caching scheme, this provides a high degree of privacy, since the identity provider is blind to the usage of its tokens. For example, one could imagine a school system issuing my daughter a token that says she's under sixteen that she could use to get into protected chat rooms. In non-auditing mode the school system would not track which chat rooms she was visiting, and the chat room would only know she is of the correct age. This is certainly an increasingly important use case.
My first instinct was to use SAML Assertions as the means for creating this kind of non-audited assertion. But as Arun Nanda and I started our design we discovered that SAML – even SAML 2.0 – just wouldn't work for us.
In the specification (latest draft), section 2.3.3 says a SAML Assertion MUST have a unique ID. It must also have an IssueInstant. When that is the case, the identity provider can always collaborate with the relying party to do a search on the unique ID or IssueInstant, so the desired privacy characteristics dissipate.
Being a person of some deviousness who just wants to get things done, I said to Arun, “I know you won't like this, but I wonder if we couldn't just create an ID that would be the canonical ‘untraceable identifier’?” I hesitate to admit this and do so only to show I really was trying to get reuse.
But within a few seconds, Arun pointed out the following stipulation from section 1.3.4:
Any party that assigns an identifier MUST ensure that there is negligible probability that that party or any other party will accidentally assign the same identifier to a different data object.
I could have argued we weren't reassigning it “accidentally”, I suppose. But there you are. I needed a new “Assertion” type – by which I'm referring to the payload hard-wired into SAML.
It isn't that there is anything wrong with a SAML Assertion. The “ID” requirement and “IssueInstant” make total sense when your use case is centered primarily around avoiding replay attacks. But I had a different use case, and needed a different payload, one incompatible with the SAML protocol. And going forward, I won't be the last to operate outside of the assumptions of any given payload, no matter how clever.
I have looked deeply at SAML, but am convinced that protocol, payload (call it assertion type or token type, I don't care) and trust fabric need all to be orthogonal. SAML was a great step forward after PKI because it disentangled trust framework from the Assertion/Protocol pairing (in PKI they had all been mixed up in a huge ball of string). But I like WS-Trust because it completes the process, and gets us to what I think is a cleaner architecture.
In spite of all this, I totally buy Scott's uberpoint that for a number of common use cases SAML and WS-Fed (meaning WS-Trust in http redirection mode) are not more or less functional, but simply a different design.
5 thoughts on “What is meant by “token independence”?”
I've seen other complaints about the ID and timestamp requirements in SAML, and if they prevent people from doing things they want to do, I think the answer is to fix them. OASIS is an open venue, somebody just has to suggest it. My biggest complaint is that Microsoft historically wouldn't participate, and I think the standard is worse for it. Since MS does use the standard in places, at least an old version, I think it hurt itself in the process.
As an aside, I don't think it's enough to remove a couple of XML attributes to avoid the correlation attack you're talking about. I think it requires non-traditional cryptography to present a signed claim of anything from a third party in such a way that the whole bag of bits can't be used as a correlatable handle. It's doable, but it's not doable with typical approaches to encryption or key proofs. At least I don't think it is.
(That's not to say the limitation you raise isn't legitimate. It's a necessary fix, just not a sufficient one.)
My use of the ID and timestamp are just examples – my argument applies to any fixed content.  I suppose if you made every element of the SAML payload optional, you would get to a flexible payload, but don't think that's the right approach. Better to let SAML assertions be what they are and allow other flowers to bloom as well.
I don't know that Microsoft would have been any wiser in guiding SAML than those who developed the specification were. After all, it was very forward thinking and solved a number of problems.
It might have made everyone feel better today if my ideas about a payload-agnostic protocol were aimed at improving a technology Microsoft was partly responsible for, but I wouldn't change anything I was saying or doing.
You don't need special cryptography as long as you are willing to employ “bearer tokens” to convey non-unique assertions. You do need blind signatures once you want to associate tokens with proof keys. The work of Stefan Brands and Jan Camenisch makes this all possible – both have shipped toolkits recently. But as you say, the traceable ID and IssueInstant in SAML would be non-starters.
I figured you had bearer tokens in mind. I think that's a problem because of the ability to copy and reuse them. They work for unimportant things, but unimportant things don't need a managed card approach anyway.
As far as the schema is concerned, most of the assertion content is in fact optional, and I disagree that there's no value in that approach. A common token is IMHO a prerequisite for any real/useful commonality in the identity layer. That's where we'll have to agree to disagree and just advocate for what we think is best.
A sidenote: the ID thing is actually more of an XML signing problem than a SAML problem. To sign things right now in XML, you either have to rely on unique identifiers or on very hard to process XPath mechanisms. The uniqueness thing does predate the heavy use of signing in SAML, but the real challenge in relaxing it comes from the third-party signing use case.
I hope that people can work together to come up with new signature specs that accomodate the new crypto work and fix some of these limitations. And I think we would agree that they should not be specific to WS-Trust.
I agree that bearer tokens are far from ideal. That's why I am interested in the “anonymous credentials” of Brands and Camenisch. Point is, you still need to drop ID and at least change the way IssueInstant is used.
You are right we need to agree to disagree, but I can't help sharing what bothers me about the “optional” approach (and this comes from experience at having built systems that suffered from the problems I'm describing). I think it will be both SIMPLER and SAFER to keep each token quite tightly defined, so switching TOKENS switches defined SETS OF BEHAVIORS in their entirety rather than creating 100,000 potential combinations – many of which can be dangerous and all of which have to be tested.
Interesting comments about the signature problem. Yes, I'd like to work on this with you.
Agree that the mechanisms should not be specific to WS-Trust!
In another post [here], law 5 is cited. It is indeed a worthwhile law, but as mentioned above, care must be exercised that you don't have so much plurality that you end up trying to build a Tower of Babel. Are tokens the unifying commonality that can avoid this? Or is it claims? Or what? I don't know and mehinks that's something that remains to be worked out.
Anyway, that's just techie stuff. Let's not ge to bogged down in it. I think the real significance of law 5 is along the “trust fabric” axis. There needs to be a plurality of choices among the parties participating in the trust fabric. For example, in the famous Dick Hardt talk, beer buyers can present different cards frpm different motor vehicle departments (IdPs) that will provide testimony about their age. The beermonger (RP) will accept any of them.
And a side note for what it's worth. Perhaps there's another “orthogonal” axis. This comment was posted from a Macintosh!
Comments are closed.