Kim responds to my note about SAML Bashing:
...which is, by the way, absolutely NOT my intent. I’m simply trying to understand how SAML relates to linkability, as I am doing for all the other major identity technologies. I can’t take up all the points he raises, but encourage the reader to look at his piece…
Perhaps I reacted too negatively, but the analogy of some unknown clerk reaching into my pocket really irked me as that clearly isn't what happens and it appears to be written to instill unreasonable fear in an implementation of a browser-based SSO protocol.
I’m not criticizing or discussing the profile for an Enabled Client/Proxy. I was talking about SAML as we know it - in the mode which has been widely deployed in portals all over the world.
I think such analysis should be based upon the capabilities of the protocol and not about what some deployments have chosen to do within their environment (where they clearly felt that browser-based SSO meets their needs (and in many cases is mandated by the deployment scenario).
I think Conor is misunderstanding my intentions. I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor’s b) and c) above would apply. But we are looking at linkability precisely to judge the threats in the case that parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.) So arguing that the identity provider will behave properly has nothing to do with what I am exploring: risk. I’ll try to build Conor’s concerns into my ongoing discussion.
I'm sure there's some misunderstanding here. I normally find that I agree with most of what Kim has to say and really respect his opinions.
As far as the trustworthiness is concerned, there's nothing that is completely trustworthy, not even if I make the decisions myself and hand-code the response messages from the keyboard (I'm sure that I will make mistakes of judgment and or typos).
I would ad that the same "attacked in ways that undermine their trustworthiness" applies to client implementations that try to enhance privacy protection. They too are subject to being attacked. Nothing is totally foolproof and I'm not sure which has more likelihood of successful attack, a service maintained under contractual agreements or open software systems in the hands of end user.
I certainly have chosen to put my money in a bank rather than store it under my mattress. Yes, the bank is more likely a target for a robbery, but they are legally obligated to maintain my funds, even if they are robbed. Similar decisions will be made by many people in the identity space (and yes, some out there will always keep their funds in their mattress).
2 comments:
Do you believe WS-Federation addresses many of the issues that SAML didn't cover?
No I don't. WS-Federation, for the most part, is a "not-invented-here" duplication of the functionality that was already present in SAML. Rather than trying to work with the SSTC to extend it to meet their needs, they chose to go their own path, duplicating much functionality and trying, unsuccessfully, to position it as an evolution -- which it clearly isn't.
Post a Comment