Kim writes about SAML's use of redirection protocols.. To start with, he forgets to mention a few important facts as part of his discussion:
- SAML defines a profile for an Enabled Client/Proxy (ECP) which is an evolution of the Liberty Alliance's LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).
- The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.
That said, there are still several statements in Kim's analysis that I feel obligated to respond to. These include:
Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on. (”Trust us.”)
First off, the user only see's nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don't want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace's implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.
Secondly, the analogy is way off base, trying to make this seem like I'm bing pick-pocketed by someone I don't know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of "I give one of my providers permission to reach into my bank account and withdraw money to pay my bill". I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.
So, returning to the axes for linkability that we set up in Evolving Technology for Better Privacy, we see that from an identity point of view, the identity provider “sees all” - without the requirement for any collusion. Knowing each other’s identity, the relying party and the identity provider can, in the absence of appropriate policy and suitable auditing, exchange any information they want, either through the redirection channel, or through a “back channel” that dispenses with the user and her browser altogether.
The IdP does not "see all". The IdP only sees that you have visited a particular relying party. It does not see what you do at the relying party. Knowing that I visited Amazon, is not the same thing as knowing what I looked at and/or purchased at Amazon.
Secondly, my choice of an IdP (as with most others) would be made based upon the appropriate policies and auditing capabilities at that IdP (just like I don't choose to use Johnny down the block as my bank, I choose a reputable firm and just as I would require the exact same policies and auditing in any client that I chose to use to act as my identity selector (yes, I have to *trust* Cardspace's or Credentica's implementation of policies just as I have to trust an IdP's).
In fact all versions of SAML include an “artifact” binding intended to facilitate this. The intention of this mechanism is that only a “handle” need be exchanged through the browser redirection channel, with the assumption that the IP and RP can then hook up and use the handle to “collaborate” about the user without her participation.
That isn't the intention at all. The intention, as Kim surely knows, is to pass a message by reference rather than by value. For the non-programmers in the audience, this means that I have a message that I need to send to the relying party (in this case that message contains an assertion, which can be big and complex and which has additional security requirements if passed through someone else's hands -- yes, the user can count as someone else). Instead off sending the token to the client to have the client then send it up to the relying party, I can send a small artifact that the relying party then presents to the IdP to get the token. The protocols explicitly define what the artifact is exchanged for -- it was never intended as, nor can it be used within the protocol definitions, as a general collaboration handle.
In many enterprise implementations, the artifact is used to allow the IdP to issue assertions to the Relying Party that don't need to be signed by the IdP. Clearly that isn't something I could do if the assertion was sent to the client (otherwise we'd be talking about how I took the token and edited it say I was Bill Gates when I sent it to his bank).
In considering the use cases for which SAML was designed, it is important to remember that redirection was not originally designed to put the “user at the center”, but rather was “intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent… for example, if the communicating parties do not share a direct path of communication.” In other words, an IP/RP collaboration use case.
All SSO use cases (where one party authenticates a user and asserts an identity for that user at a relying party), redirection or not, would then be, by Kim's definition, an IdP/RP collaboration since the RP (Relying Party) is relying on the identity presented by the IdP. This has nothing to do with redirection or user involvement, or SAML in particular.
As Paul Masden reminded us in a recent comment, SAML 2.0 introduced a new element called RelayState that provides another means for synchronizing or exchanging information between the identity provider and the relying party; again, this demonstrates the great amount of trust a user must place in a SAML identity provider.
No. RelayState is designed for the RP to send information to itself, not the IdP, so that it can remember what the user was trying to access when the user is returned to the RP following a successful SSO operation. This is primarily used in the case where the RP is unable to set a cookie in the user's browser to remember that information. SAML even points out that as little as possible data should be included in the RelayState.
Paul's point in his comment was that if an RP used this incorrectly, they could leak information. The SAML specs contain exactly this caution.
I don't claim to say that SAML is the end-all for every use case. I do believe that we need to support multiple methods, some of which have different privacy implications. I also don't want some privacy weenies making life intolerable by the need for a confirmation of every thing that I already said it was OK to do. I do trust some of the parties that I interact with and want to be able to automate as much as I feel comfortable doing. I have no problem with the privacy weenie that wants to turn on the "let me approve everything" -- just don't force me to live that way as well.
Tags :
identity
/ privacy
/ SAML
/ CardSpace
/ liberty
My latest gadget is my new Dell Latitude D830. This replaces my older Dell Precision M70 and includes all the available bells and whistles. 2.4GHz Intel Core 2 Duo processor, 160GB 7200RPM drive, 4GB memory, 802-11a, g, and *n*, thumbprint reader, TPM, theoretically long battery power, and, of course, Windows Vista Ultimate. It is also thinner and lighter than my former laptop (and the Dell latitude D810's we have here).
