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

Yeah, that video is not only amazing for its delivery but it also makes a lot of good points about identity

The use of WS-* IS that simple, if you use a modern stack: when programming with WCF, it's enough to choose the right binding for having all the things we mentioned in the video applied transparently... and if you want more control, you can go in the configuration and specify if you want just a signature, or signature AND encryption, etc etc... make a search for WCF and security, and you'll find out that what you propose is actually less simplistic of what's offered by the product out of the box

HTH

Vittorio

Hello Gkrall,
apologies for the delay.
There are many ways in which CardSpace and OpenID can work in synergy, and the first sites supporting both are starting to show up. I've received word from my good friend Richard Turner, the product manager for Windows CardSpace, that some guidance on this very topic is on its way. As soon as we will have something published, I will post the relevant link on this thread: alternatively, whoever is interested in staying up to date on CardSpace should seriously consider subscribing to Richard's feed

HTH,

Vittorio

Hello Freeman.
I am *totally* for the Saint Thomas paradigm: that's the reasons for which we shot this video, for the ones who want to know how things really work 
The intent of the video (& the visual notation) was (over)simplifying & summarizing what would be otherwise buried in a number of not-so-easy documents, but if you're interested in going directly to the source here there's the list of fundamentals (in decreasing abstraction level order):

• WS-Trust. It describes how to acquire a token, assumes knowledge of what a token is and how it works. In the video I also mention WS-SecureConversation once the session has been bootstrapped.
• WS-Security is KEY for understanding the details (that I oversimplified) of how a token is used in the context of a soap message. After you've read the WS-Trust and the WS-Security spec, you may take a look at the scenarios used in the ws-trust interop workshop: they give a good idea of how SAML is used witht he session key, if I remember OK. Ah, before doing that it may be useful to take a look at the SAML Token profile, and maybe tot he SAML specification itself.
• All those specifications assume that you have working knowledge of the basic blocks, that's to say XML Signature and XML Encryption.

Years ago I was working as a consultant on projects where we had to interop from WSE 1 & 2 with competitor's products, so I actually had to read some of those specs in some details to troubleshoot early clashes (namespaces, canonicalizations, etc): nowadays I never dive that deep, since all details are managed by the modern stacks. 
HTH,

Vittorio 

Hello Bruno.
Though there are similarities between the two systems, WS-Tust is not based on Kerberos. It is interesting to remark that WS-Security can use kerberos-derived tokens, anyway, hence Kerberos systems can participate in trust related transactions.
HTH,

Vittorio

Hello Dejawoo,
thanks for the nice words
I ma not sure I understand exactly the context of the issues you are having. Are you working with a specific product/technology?

Hello Wilke,
thanks for bringing this to our attention. I sent a mail to the channel9 guys, but I think we'll have to wait until vacation time is over.
Thanks & happy holidays!

Vittorio

Helo guys,
thanks for your patience.
The "Donwload" button now works; fixing the in-page streaming will happen in some time, though.
Hence for now if you want to see the video (have a lot of coffee handy if you want to stay awake ) I suggest you use the download button (which BTW ultimately points here).
Thanks for your interest!

Vittorio

Hello guys,
thanks for your patience.
The "Donwload" button now works; fixing the in-page streaming will happen in some time, though.
Hence for now if you want to see the video (have a lot of coffee handy if you want to stay awake ) I suggest you use the download button (which BTW ultimately points here).
Thanks for your interest!

Vittorio