Going Deep

Vittorio Bertocci: WS-Trust - Under the Hood

Download this episode

Download Video


Most developers will never need to dig into the gory details of WS-Trust and WS-Security: CardSpace, WCF and non-Microsoft stacks take care of the details for you.

But you’re not like the others, are you! Making decisions on design & architecture requires deeper understanding of every option.

Tune in and watch Vittorio unfolding on the whiteboard how keys are exchanged, what’s the magic behind digital signatures, how relying parties use policies, how exchanges are secured at the message level and more, in complete platform independence. This information is just as valid even if you approach WS-Trust from non Microsoft technologies.

Vittorio's blog has a wealth of information. Check it out.



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • Rossj
      That looks like really interesting stuff, and I think I'd like to see more WS-* stuff.  But how does Microsoft view Tim Bray's criticism of WS-*? He's particularly scathing of WS-TRANSFER quoting someone as saying it is HTTP over SOAP ..

      Time Bray wrote:

      No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it’s going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.
      I look at Google and Amazon and EBay and Salesforce and see them doing tens of millions of transactions a day involving pumping XML back and forth over HTTP, and I can’t help noticing that they don’t seem to need much WS-apparatus.

    • BuckyBit
      I would humbly emphasize on the aspect that any (automated) implementation on a web-services-basis of PKI (public key infrastructure) should be applauded.

      Business, Government, Citizens will eventually have to communicate in secure ways online. They can do it already but it is time-consuming and to complicated for the everage person or business-transaction. Nonetheless, implementing it into Web-Services is a way to go. 

      On the other hand: whoever wants to keep the insecure infrastructures shall keep it, as long as it is legal. 

      I don-t use creditcards (online OR offline)and I don-t buy/sell on Ebay because I don-t trust neither of them for now.


    • Vittorio
      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 Big Smile

      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 Big Smile


    • 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!


    • John Melville-- MD
      Does WS-Trust support a situation where I only partially trust the Token service?

      As you explained it the token service makes up a session key and then tells it to both parties.  I might trust the driver's license bureau to certify people's identity but not trust them to evesdrop on my session by keeping the session key.  (I could always do another public key operation inside the session but I still have to be pretty careful to make sure the token service doesn't play man in the middle.)  I would like to see this assurance built into the framework.

      I also might trust the token service to certify my identity but not trust them to know I am visiting a wine shop (or a purveyor of even more questionable wares.)  Why must the token service encrypt it as directed to a particular service?  I would much rather have it sign a plaintext certificate of my identity and send it to me securely.  I can then encrypt the signed certificate and who I send it to is my own business.  (I worry a lot more because it breaks the user's current metaphore of a wallet of cards.  The DMV is currently none the wiser if I use my driver's license to get in to a bar.)

      I know that the above problems both have relatively simple solutions as noted above.  I also know that no standard can be all things to all people (all though many have tried.)  Simply put: does WS-trust support scenerios where I only partially trust the token service, and if so how.
    • 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 Smiley. 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) Smiley



    • Cyonix
      For another good video on identity look here: http://www.identity20.com/media/OSCON2005/

      The above video made me understand the problems with current identity solutions in use today and how we need some open standards such as Microsoft’s WS-* infrastructure.

      Btw i think we need some really simple samples & instructions on how to implement these 20 or so WS stardards..

      I haven't looked heaverly into the WS-* stuff and i am planning on doing so, however i want to be able to do the following on my webservice:


      I realise this is probably far too simplistic but it would be nice Smiley

    • freemen
      Thank you for this Nice session ...very didactic...

      WS trust in indeed interesting as building block...but people using it must know that their work is not finished at security level, the multiparty protocol must still be carefully designed...Smiley

      Examples of things I would think about

      1.In your example regarding the age, how does the "wine seller" know that "22" is really the age of the person submitting the SAML token to him and that the token was not stolen and just sent to him ?

      shouldn't there be a signdrivingdeptprivkey (certificate user, age corresponding to certificate user presented when the user requested assertion from the "drive dept")?

      2. I suppose also that there is a need to have all parties (wine reseller, user, Drive dept) be all securely synchonized with the same time server (in some kind of secure way?) in order to make sure that the signed assertions are all still "fresh" and avoid making the relying party accept old assertions that could have become osbolete?

      3. What about replays of RSR ?


    • 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 Smiley

      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 Smiley


    • Cyonix
      Vittorio wrote:
      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


      Very nice, I might download the latest CTP and have a look into WCF.

      Thanks for responding to all our comments and questions Smiley
    • raymond
      Great video Charles and Vittorio.

      At the start of the video, Charles, I thought you were going to give a shout-out to all the paisanos on Channel 9, besides littleguru, PaoloM, Crash `, and the thousands of lurking Italians and soccer fans.

      Is this WINE protocol that the vast majority of programmers do not need to know about but just trust it works?Wink




    • gkrall
      So how do you see lightweight identity protocols such as OpenID and Cardspace working together?

    • 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 Smiley


    • Adenocard
      Awesome video. Was it me, or did the man in the middle look alot like Vittorio Smiley   Let's do a architecture chalktalk online with someone else now on WCF and then WF...   cool!

    • freemen

      Thanks Vittorio for the quick answers...although I still need some papers to really understand the "guts of it"

      Is there a public site where the complete cryptographic protocol would be described for review?

      Quoting "Saint Thomas": for the type of things I do, I generally prefer to double check protocols...Big Smile

      Freemen...and also born free Smiley


    • 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 Smiley
      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. 


    • bruno_spine​lli
      Hi Vittorio,

      Nice explanation :O ... I perceived some similarities with Kerberos Architecture ... Is WS-Trust based on Kerberos Architecture ?


      Bruno Spinelli.
    • dejawoo

      Hi Vittorio,


      like the video thankx was useful. I got one question how I can send extra parameter to STS. I know that I cannot extend the UsernameSecuritytoken. I tried to send SAML token but it s requiring to be signed... can u give me some hints. is it possible to issue a token without having another local tokenprovider.. ruslan.

    • 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.

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

      Hi Vittorio,

      great to hear from you.. thanx.

      no I m not working with different technology. I work in .Net enviornment. but Im kind a feeling my self new in .Net 3.0. specifically WCF. Resources gives me lot s of hints but could not help me to achieve my task. so here s my problem.

      Im havng a client which should send to my first STS username+password+extra parameter. As I know I can not extend UsernamePasswordToken. So how can I send it to my STS. I have seen building a custom token. I tried it works fine when there is single point to query. I mean not three parties as in federated scenario. And another thing bothering me that with the magic of bindings all happening in single hop. The fact that my client should get list of endpoints of actual service from STS. so in my case I guess it will not work. I have to do myself in sequence. If I m doing it in sequence.. then there is no point for WS-Trust is not it?

      could you help me please... thank you. my direct address is deja_woo@hotmail.com

    • wjansoone
      I would like to watch the video but it seems to be unavailable, could someone check this.

      Thanks in advance,

    • Vittorio
      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 Smiley ) 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 Smiley ) I suggest you use the download button (which BTW ultimately points here).
      Thanks for your interest!

    • ramzy
      hello, great presentation!iam a grad student in canada and working on distributed security for web services.iam thinking of a PKI based protocol where you dont need to share any previous information with communicating agents.in WS trust,the client is authenticated thru his drivers license # but what of situations where u know nothing about each other?no trusted party?anyone apart from Vitorrio can contact me thru honeyramzy@gmail.com for assistance.thanks

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.