Vittorio Bertocci: WS-Trust - Under the Hood

Hello RossJ,
thanks for the nice comment.
I can't speak for the entire Microsoft on such a broad topic, but I can certainly give you my opinion.

1) the alleged complexity of WS-* is invisible to the vast majority of developers and architect, in the same way in which everybody happily ignores the backoff algorythm that TCP uses for resending packets or how HTTPS acquires certificates and secure the session. Unless you're in the business of writing network stacks, you can ignore all WS-* details exactly like today you can ignore how COM+ manage to propagate a transaction.

2) WS-* covers an amazing amout of aspects. It is designed to be modular, so that you can consider only the set of specification spertaining the capabilities you are interested into. If somebody remembers Corba, I'm sure it would be enough to make a quick reality check in this respect.
The things it tries to accomplish are advanced, so a certain level of sophistication is intrinsic in the problem. The WS-Security subfamily is a good example: it's not just a matter of throwing a bunch of XML elements from A to B, it's allowing different technologies to interoperate in a uniform encapsulation (X509, Kerberos, SAML, u/pwd, they are all normated in the Security Token pattern), propagation and negotiation of keys, selective signatures/encryption, automatic negotiation of policies, secure session management... those are COMPLEX things, nonetheless they are needed in various situations (especially inside the enterprise and in enterprise to enterprise interaction)! We are paying the price of the negotiation once, so that the industry can then use those capabilities in interoperable fashion without going through that pain: but somebody has to pay that price at some point IF you want those advanced capabilities. That does not mean that WS-Security is a swiss knife: there are scenarios where it may be anti-economical to make use of it, because you have simple needs/tactical constraints/strong hypothesis. Again, if a scenario you're considering does not need the capabilites supplied by WS-Security does not imply that WS-Security is too complex, nor that there are no scenarios where WS-Security adds enormous value: it simply means that you don;t need WS-Security in that scenario. It's that simple

3) things like the Metasystem are enabled by the sheer existence of WS-* and consensus around it. Anything less generic and future-proof would not be able to provide the strategic solution we so desperately need in the identity space. And that's just one of the most visible problems in today's computing scene, I believe it will prove the value of building over those standards and will accelerate similar solution on other spaces

4) about WS-Transfer, specifically. It may have the same expressive power of HTTP or occupy an equivalent ecological niche, and I don't want to validate or deny that statement, but that's not the point. The point is that it's a module of an ecosystem based on more generic rules, and its value is in the composition. If I have all my phisical routers exposed as WS-Management compliant endpoints, I can use WS-Transfer on whatever transport for obtaining the fitness data I need. If my routers listen on a highly optimized TCP channel, why would I want to dive out and wrap them with HTTP? Or why would I need to add adapters around, if another device offers the same WS-Management endpoint on a queue and I want to aggregate their results? The point here is again context. Would I use WS-Trasfer for getting a list of products from Amazon and render them in a browser? Probably not, HTTP is already there for that. Would I use HTTP for probing my server farm and my network hardware, for aggregating a massive live data stream in the console I use for managing my multitenant application (that maybe SUPPLIES the product list that one of the tenant will download on his browser)? Well, you can imagine my answer

HTH,

Vittorio

Hello BuckyBit,

I hear your concerns. I believe that with the laws and the Metasystem the world is heading in the right direction: my suggestion is to keep an eye on that space, and contribute to the discussion with your opinion about what a system you'd trust should look like!

HTH,

Vittorio

"Trusting A" in this context mainly means "considering true the assertions made by A", which is not necessarily corresponding to the intuitive idea of trust in its colloquial use. So I would reformulate your question with "Does WS-Trust support a situation where the subject wants to preserve its privacy?". In this case, se answer is yes. To address the concerns you mention:

1. In the main sample I made the STS can't eavesdrop the conversation between the subject and the relying party, since such conversation is ENCRYPTED with the key of the relying party. The session key is used only for signing (and sometimes for bootstrapping another session negotiation that WON'T include the STS).
2. The case in which the subject does not want the STS to know with whom the issued token will be spent is contemplated, and I explicitly mention it in the video (when I make the example of a local library as opposed to the immigration department). The protocol explicitly allows that, but it is up to the single STSes to decide if they want to issue unscoped tokens or not.

I hope that the above addresses your questions . I would close with a warning: don't make the metaphor outlive its usefulness. Thinking of your capability of obtaining a token as a card is handy, but that does not mean that it has to mimic exactly its behavior. WS-Security and WS-Trust gives you possibilities that would be impractical in the traditional world, like the chance of an IP of choosing to whom its token will have to be spent with; exactly like the TabletPC uses the metaphor of the paper until it's handy, but does not heisitate to go beyond that when it makes sense (like when you magically add blank space between two lines of ink text already written)

HTH,

Vittorio

Hello Freemen,
thank you for the nice comment. Let me address your points:

1. The wine seller declares upfront that he will believe what the Department of Driving Licenses will say, so if the 22 is within something that was was signed by the DOL it will be trustworthy. Te wine seller also knows that whoever is sending the SAML token was actually the one who requested it, sinte the message is signed by the session key contained in the SAML token itself and encrypted for the wine seller: this fact can only mean that who is sending the token was the one who received the corresponding prooftoken. An attacker who just stole the SAML can attach the token to a forged message, but CANNOT SIGN WITH THE KEY CONTAINED IN IT.

2. the time synchronization is mentioned here and there in WS-Security, but not mandated at the protocol level. Every token has an expiration, usually pretty short, so the system is rather resilinet to small differences in time settings.

3. I'm not sure I understand what is RSR. If you mean RST, Request for Security Token: if somebody capture it and replay it within its validity window, the worst that can happen is that he will get back the RSTR: but for making sense of it it would need to 0wn the private key of the subject, at least for opening the prooftoken. If he doesn't own the private key he won't own the session key, and what we saind in 1. applies. Furthermore, in the session I simplified and didn't show the entire RSTR: however SAML and prooftoken are in the body of RSTR, hence encrypted in a single bunch for the subject. So capturing an RSTR would be less useful than capturing a subject-relying party intraction, since in the former the SAML token would be buried in a single scrambled fragment.

Thank you,

Vittorio