Hacker News Reader

Comment by jf | Hacker News Reader

As someone with a decade of hands-on SAML experience, I highly recommend against implementing SAML. Use OIDC instead.

This article covers many of the reasons to avoid SAML: https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an...

The vulnerabilities are rather to easy to address as a service provider. It boils down to 1) Use Https, 2) Assert both the request expiration and that you (the service) are the intended recipient of the request, and 3) Assert the signature (using the metadata you received from the identity provider through a trusted channel). I don't know why people say SAML is complex or hard, it's just you accepting a redirect from an identity provider with an XML payload you validate against.

> I don't know why people say SAML is complex or hard

This is a position only people with deep knowledge of SAML can take. Once you understand it, it’s not so bad. But most people - including experienced engineers with decent knowledge of various authentication protocols - find SAML pretty impenetrable, and many of the people implementing it are doing so by following a series of documented procedures that they do not otherwise understand.

Source: was a PM for the authentication stack on a big enterprise platform and helped countless customers with their SAML confusion.

Anything involving XmlDSig is far, far more complicated than it lets on. I doubt even the SAML experts know it 100%, maybe no one does.

The main issue that I have with XmlDSig is that the signatures are stored inside of the document being signed. Because of that, you can’t properly implement the standard without writing enough of an XML parser to do the canonicalization needed to properly compute and verify the hashes used for signatures. In practice, this means you need approximately an entire XML stack just to hash some data, something that is a simple operation otherwise.

Remember to make sure your XML parser doesn’t fetch remote DTDs. You’ll also want to make sure that the code which validates the signatures in the SAML assertion reports to you which specific parts were signed. You will also want to validate the schema of the assertion. Also make sure to reject assertions which aren’t signed at all. Don’t forget to store the ID of the assertion to avoid replay attacks.

Ultimately you end up implementing whatever your customers want implemented.

As someone who has implemented SAML and OIDC at many large companies, I disagree with the general thrust of this comment.

Customers usually care most about a specific outcome. If that outcome can be achieved using OIDC instead of SAML, some orgs will go with the recommendation instead of the initial request.

I bring this up because most customers asking for SAML were doing so either because that’s what they were told they needed, or because it’s what they did last time. When presented with additional options and more importantly the rationale behind those options, many customers either switched gears or started working towards OIDC and changed SAML to an intermediate step along the way.

Push for the best solution. Sometimes it doesn’t change anything, but it often does, and even when it doesn’t, it raises awareness of the alternatives.

(There will always be some subset of orgs with immovable standards that are immune to good rationale, but these need not prevent progress elsewhere).

OIDC is way easier in my experience.

Reply on news.ycombinator.com