Have you ever found yourself trying to explain to somebody why you need to have a certain certificate installed on a certain machine? Or which token is used to encrypt a certain part of a message? Or maybe when you have to acquire a token, or how you propagate a session key in full security?
Well, I found myself in similar situations many times. I soon discovered that a picture is indeed thousands times better than "you see, you require a token for a certain service so the STS will generate a session key and will encrypt it for that service in the token, while it will produce a requestedprooftoken encrypted with the requestor public key. The requestor will open the requestedproof and call the service, securing the call with the session key and adding the token containing the session key encrypted with the public key of the service and signed with the private key of the STS: the service will the retrieve the session key by decrypting..." and so on and so forth. It's even better to draw the picture in front of the person, so that you give him/her the time to get the hang of the structure rather than being overwhelmed by the sudden crowd of symbols. If it's impossible to draw at run time, a good guided walkthrough is still better than the verbal-only alternative.
In the following I describe the notation that I eventually developed for the above described purpose. I'd be happy to hear about alternatives or suggestions, of course. Couple of notes:
Let's start with the keys.
Let's then see how I represent the standard operations.
And let's close with the structures:
Finally, let's see a couple of examples.
The most WS-Security classic: X509s. Here you can clearly see that a client needs to own the public keys of every service it wants to deal with; furthermore, it is clear that the service can use the client's public key found in the message and it doesn't need to keep in the local store the public keys of all possible clients. Obvious? Maybe to you, my loyal reader, but I can assure you that after showing it I've seen quite a few "aha" moments in the eye of people not familiar with WSS :-).
This one is harder. Come with me:
This walkthrough makes many thing evident, including the fact that the client don't need anymore to keep WS public keys (with the notable exception of the STS); it also suggests that everytime you want to talk to a different service you need to have a new SAML reissued to you in order to havew the session key encrypted for the right target.
Almost one year ago the web space that was hosting all my blog images (since 2003) somehow lost all of