My recent posts about SAML got me thinking about a couple of common misconceptions I see from customers surrounding the technology.
The first and most important misconception is articulated by this quote:
"there is no SAML Fairy"
- Brian Eidelman
In other words there's nothing magical about SAML. Browsers don't "speak" SAML. SAML isn't like an HTTP cookie (and it's not like a chocolate chip one either, but I digress). SAML is just a means to convey identity from one place to another, so adding SAML into your architecture doesn't do anything to make it more secure. Application sessions will still be managed with cookies, hidden form fields, information in the query string or whatever it is that the app already did.
The other misconception / misunderstanding is that SAML can take care of all of your SSO problems. Or as a customer recently put it "if I just setup one authentication point for my enterprise and then use SAML to sign onto all of my applications I don't need a Web SSO solution like [OAM, OpenSSO, SiteMinder, etc]". This product space is usually called Web Access Management, abbreviated as WAM, which is pronounced like, but is unrelated to the band with a similar sounding name.
I've seen this same idea discussed by customers, application vendors and others so it seems pretty common. The fact the idea is common is bad, but it's the fact that it's both wrong and widespread that concerns me, and is why I'm writing this post.
The motivations people have put forward for using SAML in this way have included:
and of course...
From a customer's perspective these are all valid desires and laudable goals. Unfortunately the reality is that SAML is simply not a replacement for a true web access management solution. The WAM space is one of those classic "elephant in the distance" problems - it's a whole lot bigger than you think it is when you start.
The main features of a WAM product (according to Wikipedia) are:
Authentication Management includes obvious things like checking a username and password (i.e. HTTP Basic authentication or from an HTML form) or Certificates. It also includes features like requiring different authentication methods for different resources. The rest of the above are fairly self explanatory. I'd add a few more features that are common across most of the products in the space:
If you use SAML for SSO you can centralize authentication, and if you do things carefully you can almost certainly get a limited form of Single Sign-On working. But trying to get most of the other items on my lists above is actually a whole lot harder than you might think.
Consider the use case where you have two applications protected with either a WAM solution or some sort of SAML integration. With a conventional WAM product you'd be able to log into either one and move back and forth seamlessly; your session would be active on either one or both apps for as long as specified in the central configuration and if you log out of one you would be logged out of all. Contrast this with the SAML solution...
You could do central login by configuring the existing login page of each application to kick off a Service Provider initiated SSO, and as long as your session was live at the central IdP you could go back there to get an assertion for the application. Of course you'd need to make sure that the central session didn't time out too early or you lose all SSO capabilities. You could also configure SAML to support Single Logout (SLO), though doing SLO across more than a handful of Service Providers gets problematic quickly.
So what are you missing? Lots of stuff...
There are some other important features of WAM products, but those are the ones that come to mind immediately.
Then in addition to all of the features you're missing you introduce a bunch of additional problems. Such as? How about the fact that each Service Provider requires an x.509 certificate? And the fact that setting up a SAML Service Provider is still painful (even with the Metadata exchange protocol). And the fact that when you stand up a new SP you have to configure settings on the IdP.
None of which you have to worry about with a WAM product.
So when it comes to web browsers use SAML for the things it was intended to do - propagating identity across boundaries. And use WAM products for your intra-company SSO.
Do you disagree? Are you using SAML for your web SSO solution successfully? Have you figured out something I haven't?
Let me know below.