Your SaaS Cloud Provider Does An Awful Job At Implementing SAML And That’s Totally OK

The SaaS provider you just selected claims SAML compatibility? That’s awesome for you! This will enable you and your users to use this new service in a much more secure and user-friendly way. Imagine the pain if there was one more user ID and password to manage.

But you know what? “SAML compatible” means very little these days. I’m not saying that the SaaS providers are not “SAML compatible.” I’m saying that “compatible” is sometimes used in the most loose way possible.

I’m totally fine with that and I can explain why.

SAML 2.0 is an extensive standard with lots of features. Some are essential, some are nice to have and others are rather obscure. And, by obscure, I don’t mean the good kind of obscure I wrote about in my last blog post.
Back in the days there were SAML conformance tests with operational modes like “IdP lite”, “IdP,” etc.
That made sense then (2005… pre-iPhone!) but the primary driver for identity federation (cloud computing) wasn’t there yet, so those operational modes were based on assumptions what features customers would probably need.

It turns out those assumptions weren’t totally accurate – which comes as a surprise to exactly no one I guess.

Let me give you an example of an essential functionality of SAML: Web SSO.
Sparing you the full details, rest assured that the specifications go into great detail how a Web SSO message is formatted and how it travels from the IDP to the SP.  SAML authentication requests, authentication responses, POST binding etc. … without it you wouldn’t be able to log into your shiny new SaaS app using RSA SecurID Access for example.

Less commonly implemented is the part of SAML 2.0 that talks about the setup of the relationship between an IDP and a SP.
Ever wondered what that URL is that some call “Assertion Consumption Service”, others call it “SP URL” or “IDP URL,” or others label as “Service URL”? SAML metadata helps greatly with this. Small XML files that prevent typos and take away the guesswork where to copy & paste those URLs.  I’m a huge fan of metadata and consider them essential. Others might disagree and consider this a “nice to have”. At least missing metadata support doesn’t mean things don’t work – the setup is a bit harder but you’ll get it to work eventually.

A “nice to have,” in many cases, are authentication context classes. These are fields in a SAML assertion that communicate to the SP how a user got authenticated at the IDP. That is useful if the SP actually cares about that fact. The SP could for example request a certain authentication class (e.g. TimeSyncToken) from the IDP. Most times however it is the IDP that would control what authentication method to use when federation to a particular SP and not let the SP make that decision. In that case the authentication context classes don’t really matter much at all.

I have two obscure features of SAML as examples: Persistent NameIDs and NameID management.

• Persistent NameIDs come from time where the assumption was that there is a non-flat namespace and that users will have accounts (with login credentials!) at the IDP and SP and that they want to link those two accounts in a secure and privacy maintaining way.
  In the SaaS cloud world I haven’t seen this. Persistent NameIDs have a very specific workflow behind them: a user logs into the SP and IDP and tells them both to link up the two accounts. This could also be done in bulk but in any case the link ID is supposed to be opaque. Opaque in this case meaning it has no relationship to the userID on either side. Think of a random string – not related to any profile data the user has e.g. employee ID.
• The NameID management protocol is supposed to let users manage those links and break them or re-new them if needed.
  Never seen this or even heard of it before? That’s exactly my point.

There is much more to SAML e.g. attribute statements, name ID formats, signatures, encryption etc.

Take all this and you get a feeling that maybe SAML isn’t trivial to implement after all.
That is… if you want to implement the entire standard. What about if you just pick the parts you actually need? Maybe just Web SSO?

That is way easier than even the “SP lite” operational mode I mentioned earlier. OrangeHRM is an example of this approach. Does that mean their SAML implementation is bad? Far from it. It is not complete – it only does SSO using the POST binding but would you rather have that obscure persistent NameID feature implemented or whatever useful HR function OrangeHRM should provide in the next release?

“How hard can it be to implement SAML? It’s just XML!” – that’s what I heard a few weeks ago from a customer. I was politely pointing out that SAML is indeed XML based, but that doesn’t automatically make it hard or easy to implement. It’s the extent to which SAML should be supported that makes it easy or hard.

If I have to choose between a severely restricted but secure SAML implementation and having no SAML support at all… I would choose the first option every single time.

The post Your SaaS Cloud Provider Does An Awful Job At Implementing SAML And That’s Totally OK appeared first on Speaking of Security - The RSA Blog.