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.
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.
> 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.
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.
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).
This article is confusing in some parts. It should highlight one very interesting bit : there are no direct TCP connections between the SP and the idp. Everything flows through the user. SAML is perfectly suitable for offline services (network equipement with web frontend, for instance)
Well that depends on the binding right? In case you use the "artifact binding" then theres also direct communication between SP and IdP. I havent seen it in the wild and I am also no professional, but I saw it in the 2.0 standard, e.g., see https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-...
> To put it simply, it’s the enterprise equivalent of the “Login with Google” or “Login with Facebook” buttons we see in apps around the internet.
This is a little pedantic since the original article is from 2020 when using SAML might have still been worthwhile to invest time into... But today OpenID Connect (OIDC) is the Enterprise equivalent of these features, or rather these products from major vendors are each just their implementations of OpenID Connect. If you have the choice, you should probably be looking at OIDC instead of SAML for federated identity today.
Not saying you're wrong, I only want to add to your context by saying (in my experience) within higher education SAML is the way federated identity is done. InCommon has been around for a long time and makes it pretty easy, and Shibboleth is very popular. Have a great day!
Being around longer or being widely implemented within some market segment is not a great reason to advocate for expanding its use. I could play devil's advocate for Kerberos or NIS just as easily as you can for SAML. It's fine if you must integrate with an existing system, but it's instant tech debt if you build a new system around it today.
Nothing else is suitable for multilateral, full-mesh federation yet. The OIDC multilateral federation standard hasn't been finalized or fully implemented yet, and it takes years to coordinate this kind of change in a federation.
So use SAML for that part; education is still a big market and they have a case for delegating the responsibility of establishing and managing trust relationships to a federation provider that most b2b and b2c applications will not have. Fortunately most of these identity systems are happy to proxy for downstream OIDC/OAuth IdCs anyway, so the argument that you may not want to implement SAML IdC in your own application is still valid even in this context.
Implemented SAML sso last month. SAML protocol and formats look so fragile and confusing.
XML looks outdated in modern days and XML signatures/encryption are hard.
Protocol requires deflated base64 on some step, but you can't enflate/deflate easily with cli tools. On other step only base64 is required (why?).
All seems error prone and inconsistent. And I feel it can be done much much much simpler.
Yeah, I won't dispute this at all. I've spent a fair amount of time forcing myself to develop expertise in SAML ... and it kind of sucks.
Any chance you'd share which libraries you used, if any? I'm really trying hard to compile resources that make SAML SSO less of a nightmare, and part of that effort involves tracking down bad documentation.
I used onelogin's java-saml-toolkit.
But at first I reproduced all process by hand until I groked it. And then I hated it.
To be hones, it's not such pain in the ass.
In my limited experience with SAML and OAuth, the best way to learn it is to set it up yourself, I.e. toy app to identity provider and back. It can be a flustercuck for sure.
A Gentle Introduction to SAML - https://news.ycombinator.com/item?id=41036982 - July 2024 (94 comments)