SAML Is Insecure by Design

What kills me about SAML is that instead of this straightforward XML style:<p><pre><code> &lt;claims&gt; &lt;nameid&gt;foo.bar@test.com&lt;&#x2F;nameid&gt; &lt;givenname&gt;Foo&lt;&#x2F;givenname&gt; &lt;surname&gt;Bar&lt;&#x2F;surname&gt; &lt;&#x2F;claims&gt; </code></pre> It instead encodes elements and attributes <i>using</i> elements and attributes, in the manner of the classic &quot;inner platform effect&quot; anti-pattern:<p><pre><code> &lt;saml:AttributeStatement&gt; &lt;saml:Attribute Name=&quot;uid&quot; NameFormat=&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:basic&quot;&gt; &lt;saml:AttributeValue xsi:type=&quot;xs:string&quot;&gt;test&lt;&#x2F;saml:AttributeValue&gt; &lt;&#x2F;saml:Attribute&gt; &lt;saml:Attribute Name=&quot;mail&quot; NameFormat=&quot;urn:oasis:names:tc:SAML:2.0:attrname-format:basic&quot;&gt; &lt;saml:AttributeValue xsi:type=&quot;xs:string&quot;&gt;foo.bar@test.com&lt;&#x2F;saml:AttributeValue&gt; &lt;&#x2F;saml:Attribute&gt; &lt;&#x2F;saml:AttributeStatement&gt; </code></pre> This is roughly the equivalent of the SQL table schema where there&#x27;s one table with the columns &quot;rowid, columnname, value&quot; along with a &quot;schema table&quot; that some hand-rolled code uses to validate that the data table contains only data that is valid according to the schema.<p>It&#x27;s not XML, it&#x27;s XML <i>squared:</i> using XML to <i>encode</i> XML concepts instead of just using XML directly.

On top of this, I have inside knowledge that some extremely common libraries that implement SAML were built not by reading and understanding the spec, but simply by looking at sample XML documents in the wild and writing code that handled it.<p>Multiple exceedingly obvious vulnerabilities have been the result. One fun one was: looking at an XML signature in the document, verifying it, then ignoring the assertion it was claiming to sign and just trusting the assertion at the document root.<p>I tried to write a standards-based implementation and gave up. The standard is enormous, and consists of three parts:<p><pre><code> 1. The definitions of what each XML tag means in a vacuum 2. Patterns on how to assemble those XML tags into a document that means something useful 3. Protocols that exchange these documents back and forth to accomplish some authentication objective </code></pre> Half the problem comes from the fact that it&#x27;s meant to do anything and everything, and so you can theoretically just mix and match all the above parts to get what you want. But that also means that it&#x27;s exceedingly simple to mix and match stuff in ways that are subtly (or not so subtly) insecure. The other half comes from the fact that the standard is so damned complicaed in order to handle everything under the sun that it&#x27;s damn near impossible to wrap your head around it all. So people just glance at the spec occasionally and just write something that handles documents they see in the wild and hope for the best, with predictable outcomes.<p>The whole thing is a tire fire.<p>Note, I last worked with it about a decade ago so I may have gotten some of the characterizations wrong.

&gt; Let’s get rid of SAML.<p>Good luck, it&#x27;s prolific throughout so many enterprises and academic institutions.<p>We might see some support start to materialise for OIDC as larger enterprises start to make use of e.g. AzureAD properly, but you&#x27;re still going to see tons of universities especially running their own Shib instance. And larger enterprises are going to be difficult to shift off of SAML when they&#x27;ve had X years of experience with it and their supplier on-boarding processes are built around it.<p>The entire Jisc UK Access Management Federation is based on top of SAML, so that&#x27;ll power the vast majority of academic resource authentication flows. You can argue that security is less of an issue for this use-case (particularly when e.g. Sci-Hub exists) but I think it&#x27;s likely that once you have the infrastructure set-up for this it gets used for more and more services.

After having implemented this recently, I have to agree with many points. It just feels so clunky to me and there are really shitty caveats with sign out and session lifetime that I <i>still</i> don&#x27;t fully comprehend after reading 2 dead trees worth of Azure docs.<p>Ignoring all other business constraints, the most secure architecture in my mind is integrated security w&#x2F; single-instance applications which are isolated to their own physical hosts.<p>Integrated security can include MFA as long as the additional factors are scoped exclusively to each applications&#x27; secure environment.<p>There is obviously a huge convenience speed bump if you leave it here, but there are small, incremental enhancements you can make to dramatically improve the UX without centralizing everything at the convenience of your attackers. For instance, you allow users to link accounts between 2 popular systems, and then rely on a simple pin code or similar for quickly jumping between them.

Well the whole critique applies directly to the XML Signature Standard, doesn&#x27;t it (of which the SAML standard is just a user&#x2F;application)? And sure, it is very complex and prone to bugs and security issues in implementations. Cf. e. g. the list of potential problems in <a href="http:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;xmldsig-bestpractices&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;xmldsig-bestpractices&#x2F;</a>

I do wish the author kept it all with XML instead of doing some JSON conversion and then disclaiming it every time. I wish they used real, accurate, examples.<p>The author constantly disclaims their approach. Why are they demonstrating in json, and why are they demonstrating in what they call &#x27;pseudo-saml&#x27; when everything they need is right there?<p>They don&#x27;t prove that SAML is insecure, because there is no vulnerable SAML in the post.

Having a security protocol that is so complex that it is practically impossible for a single person to understand all aspects of it sounds like a recipe for disaster. Most XML-based standards from that era seems to suffer from the disease of wanting to capture every possible use case, with the result of being so general purpose and configurable that they end up being almost meaningless - in practice, implementations will only work for a very specific profile of the standard, and that is then what you need to implement, because implementing all of the standard is an insurmountable task. Because the standard is so general, it ends up becoming unusable as a reference for validating your implementation, and as a result, you end up using non-normative descriptions of the specific profile as a reference, or even worse, you validate your implementation against a random set of example documents that you have seen on the web.<p>I think OIDC is better than SAML (it avoids the particular problem with malleable signatures described in TFA). You can actually <i>read</i> the standard to understand how the protocol works, whereas SAML is a jumble of abstract nonsense. I still think OIDC is a bit too complex, and I wonder if it really needs all those different profiles (hybrid flow, authorization code flow, implicit flow).

Another protocol that is much easier to understand (v1 is anyway) and was a really great least-bullshit introduction to how centralized auth should work is the Central Authentication Service (CAS) protocol developed at Yale[0]<p>&gt; The Central Authentication Service (CAS) was developed here at Yale University between 2000-2002. In 2003, a release of the server core code was refactored in collaboration with Rutgers University and in 2004 we collectively placed the code in the public domain under the oversight of Jasig (later Apereo).<p>v1 of the spec is a relatively short read, and relatively easy to implement correctly. I even wrote an implementation way back when with some homegrown changes (JSON for responses). It doesn&#x27;t seem to get used much outside of academia but it&#x27;s very minimal and understandable, and OAuth&#x2F;SAML work in a roughly similar pattern (but different, CAS is centralized though there are proxies). It&#x27;s now stewarded by a company called apereo[1].<p>Agreed with the other commenters though, SAML login is an &quot;enterprise&quot; feature, so it&#x27;s going to be around for a very long time -- things that warrant upselling tend to stick around.<p>[0]: <a href="https:&#x2F;&#x2F;developers.yale.edu&#x2F;cas-central-authentication-service" rel="nofollow">https:&#x2F;&#x2F;developers.yale.edu&#x2F;cas-central-authentication-servi...</a><p>[1]: <a href="https:&#x2F;&#x2F;apereo.github.io&#x2F;cas&#x2F;5.1.x&#x2F;protocol&#x2F;CAS-Protocol-Specification.html" rel="nofollow">https:&#x2F;&#x2F;apereo.github.io&#x2F;cas&#x2F;5.1.x&#x2F;protocol&#x2F;CAS-Protocol-Spe...</a>

The vulnerabilities happened, we&#x27;re aware of them now, and the major libraries (which you should be using anyway) will be sure to fix them. This isn&#x27;t a compelling case to throw away SAML, just to be mindful not to make certain implementation errors.

&gt; (Note: this post is all pseudo code - it’s not real SAML. Here’s <i>a real example</i> if you’re interested.)<p>*clicks link knowing full well the travesty about to be witnessed*<p>So many businesses want me to support SAML. I always say no.

Looking at Keycloak as a SAML2 provider to get a beyondcorp-ish setup to enable remote work without VPN. Every employee gets a yubikey, and all web assets are protected by a reverse proxy which checks the yubikey via webauthn, authorizes the request with a KeyCloak SAML IdP which would authenticate&#x2F;authorize the user against the company Active Directory.<p>Assuming you now require that you deploy a solution which is free of SAML2, what do you deploy instead?

&gt; SAML uses signatures based on computed values.<p>&quot;Computed values&quot; is almost as general as &quot;unit&quot;. It tells me absolutely nothing.

Minor nitpick: sign in with Google and Facebook don’t use SAML, they use OAuth and OpenID Connect. Leading with those as an example undermines the authors later points.

Why does Microsoft seem to default to SAML for organisations using Azure AD?<p>All our enterprise customers on the Microsoft stack indicate SAML as the only viable option, whereas those on Google Workspace or on more custom IdAM setups in my experience don’t care if you as a vendor prefer SAML or OpenID Connect.

I think I agree with all of this. SAML is by far the worst commonly-used industry cryptographic protocol (you could generalize and say &quot;anything reliant on XML signatures is the worst industry cryptographic protocol&quot;, and if you go looking for stuff like that outside of SAML, you should know that a lot of the bugs are portable between systems).<p>I think the root cause of insecurity here is the near-universal attempt to use general-purpose XML libraries to build SAML. When the Go instability bugs were announced, I think there was a general take from the Go community that `encoding&#x2F;xml` was not an appropriate foundation for SAML libraries, and, in this instance, I think the Go community was right: I think it should have been self-evident that you couldn&#x27;t safely build SAML on `encoding&#x2F;xml` (it doesn&#x27;t even really handle namespaces!)<p>When I did my own SAML in Go at my last job, I wrote my own soup-to-nuts XML, including DSIG canonicalization. It was annoying, but you can&#x27;t get SAML wrong; you need to be able to predict what every component in the system is going to do. What makes this worse is that most SAML systems defer the cryptographic stuff to libxml&#x2F;xmlsec; for obvious reasons, some of them sane, nobody wants to implement DSIG themselves. But then they interpret the signed message in a general-purpose XML library, and now you have competing XMLs <i>in a single system</i>. It&#x27;s bananas.<p>In the esoterica of DSIG, there are even worse problems. DSIG is a very flexible format; it has has pluggable canonicalizations, happily supports multiple signed subtrees under different keys in the same parent message, and supports both detached <i>and</i> embedded signatures. There&#x27;s a famous, respawning DSIG bug where you can trick validators into verifying a signature on one subtree but passing on a different subtree to the calling application. A researcher at Duo Security tricked SAML implementations by embedding comments in text fields, which, after canonicalization, tricked parsers into returning altered text fields. Technically, SAML responses are supposed to be strictly schema-validated, so you can&#x27;t sneak arbitrary subtrees into the middle of a SAML response --- but there&#x27;s at least one extension field in a SAML message that has an any-typed free-form tag.<p>It&#x27;s also worth remembering that SAML&#x27;s problem domain is difficult even setting the XML part of this aside. It&#x27;s pretty common to find very bad authorization vulnerabilities in multitenant SAML RPs, because you have to check mesaages carefully beyond their signatures. Many of the high-level OAuth2 protocol issues port over to SAML as well. It&#x27;s tricky to audit!<p>People stick up for SAML because what it does (facilitating centralized SSO) is extremely valuable; it&#x27;s probably more valuable than the bugs are harmful, as long as you&#x27;re using well-known tools that people have already been incentivized to scrape for SAML vulnerabilities. If I was adding SAML support to something new, I&#x27;d consider <i>beyond</i> all the standard SAML checks also rejecting any message that doesn&#x27;t have the same shape as what Okta, Onelogin, Google, or Shib generates.<p>But if you have the option, I&#x27;d also say avoid SAML.

How is Shibboleth SP&#x27;s track record on SAML vulnerabilities, either patching them quickly or avoiding them altogether?<p>My company needed to implement SAML SP support in one of our products so we could get academic customers, particularly those that are part of the InCommon federation. We contracted with a company that specializes in SAML and Shibboleth to help us get it right. We decided to use Shibboleth SP running in a container; that container also has Apache httpd (as practically required by Shib SP) and a little Python shim app that generates a JWT and passes it back to our main app. Hopefully that&#x27;s a good way of using the nearest thing to a canonical SAML SP implementation, without running our whole application through Apache httpd. In case anyone&#x27;s interested, our Shib SP container setup, with the Python shim app, is here:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;PneumaSolutions&#x2F;shib-sp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;PneumaSolutions&#x2F;shib-sp</a><p>It&#x27;s probably still too specific to our application, but might be useful as a starting point for others.

As others have noted, many of these issues are fundamental to XML DSig, which is insecure by design. [1]<p>However, the “what does the future hold” of OIDC is not much brighter. OIDC is based on JSON Web Tokens (JWT), which manages to avoid some of these issues (e.g. signs the encoded value), but introduces new ones (JSON interpretation bugs, algorithm substitution bugs, etc). They’re similarly terrible by design [2].<p>However, what OIDC does relating to signing is far worse. In many OIDC deployments, the idea is you use something called “OIDC Discovery” [3] to discover the expected signing keys for the OIDC server. You fetch those regularly (e.g. daily), and do so over TLS. With SAML, you exchange certificates, and then rotate them every 2-3 years (with things blowing up on expiration), but with OIDC, you often end up using OIDC-Discovery, and thus can change keys daily.<p>This means that a single malicious TLS certificate can be used to MITM your OIDC Discovery exchange, and from there, impersonate any user from the identity provider to your system, the relying party.<p>I spend my days in the TLS trenches, working to improve the CA ecosystem, but I absolutely would not trust the security of all users to a TLS certificate. The reality is that BGP hijacks are still a regular thing, as are registrar hijacks. Even if you find out about a malicious certificate (via Certificate Transparency), and revoke it, virtually none of your tools doing the OIDC-Discovery fetch (like programming languages or curl) support revocation checking, and even if they did, it doesn’t work at Internet scale. To deal with this problem, some relying parties do a form of poor-man’s certificate pinning, but now they’re at risk of even greater operational failures than SAML expiration in the start.<p>In practice, it seems plenty of OIDC clients just shrug and go “yolo” - if they’re talking TLS to the IDP, that’s good enough, and no need to bother with signature validation of the assertion at all.<p>For all my hatred of XML DSig and SAML, I’ve seen few auth standards as bad as OIDC: because it looks good, but is hell to implement correctly. At least with SAML, you know it looks bad to begin with, so you’re hopefully on guard.<p>[1] <a href="https:&#x2F;&#x2F;www.nccgroup.com&#x2F;globalassets&#x2F;resources&#x2F;us&#x2F;presentations&#x2F;isec-hill-attacking-xml-security-bh07.pdf" rel="nofollow">https:&#x2F;&#x2F;www.nccgroup.com&#x2F;globalassets&#x2F;resources&#x2F;us&#x2F;presentat...</a> [2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14292223" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14292223</a> [3] <a href="https:&#x2F;&#x2F;openid.net&#x2F;specs&#x2F;openid-connect-discovery-1_0.html" rel="nofollow">https:&#x2F;&#x2F;openid.net&#x2F;specs&#x2F;openid-connect-discovery-1_0.html</a>

The author did a good job, but these were(are) known issues for quite a while. TLDR: implementation bugs with known countermeasures.<p><a href="https:&#x2F;&#x2F;www.usenix.org&#x2F;system&#x2F;files&#x2F;conference&#x2F;usenixsecurity12&#x2F;sec12-final91.pdf" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;system&#x2F;files&#x2F;conference&#x2F;usenixsecurit...</a> (from 2012)<p>We&#x27;ve implemented SAML for 10s of millions of users and devices. The spec is verbose, but the approach solves common business issues. My suggestion is to use SAML simply: federations and passing attributes between trusted parties, allowing to verify the payloads. SAML can do a lot, but keep it simple and use OOB services for more orchestration&#x2F;metadata.

Nobody wants to write or maintain SAML code<p>-&gt;<p>SaaS and other types of companies start solving this issue at scale<p>-&gt;<p>SAML becomes code that is mostly going through a handful of large companies that sell products in this space<p>-&gt;<p>since the protocol is now centralized, it can be updated to a better protocol

I recently worked on an integration with suomi.fi which is mentioned multiple times in this article. I even used the DVV published fork of passport-Saml. I have a few points:<p>- that library is not supported as such. It was published under the DVV but that’s it.<p>- my understanding is the SAML is legacy they are trying to move away from. This is critical gov infrastructure so I doubt they take it lightly and I would presume it’s been incredibly heavily pen-tested.<p>- integration was time consuming and difficult to debug errors. Would not recommend.

ASN.1 signatures aren&#x27;t really much better - they go through a similar normalization step (BER vs. DER) and the payload contains the signature so you have to pull it out before validating the signature. It&#x27;s just that it&#x27;s been around long enough that (we hope) the kinks in the system have been discovered and worked out.

&gt; Sure, purists may argue that storing XML inside XML as a string or bytes is ugly<p>Ho ho ho, they really haven&#x27;t looked at a lot of XML.

I worry that this thread dissuades people from doing SAML. For our business we do only do Identity Provider SAML and it works wonderfully.<p>SAML has been a game changer for us. We are a SAAS business and 80% of our help desk tickets were people who could not log in. SAML has largely fixed that for us.

Until all of these old-ass systems that finally got to SAML move to a new SSO architecture this could largely be mitigated by using the HTTP artifact binding instead of POST or redirect.<p>Getting rid of SAML will be like getting rid of SMS 2FA.

Does FB use SAML for their login flows? I know Google has several different options and SAML is available, but was unaware about FB. Maybe in one of their more enterprisey apps&#x2F;services?

SAML + 2FA would still be strong vs say username&#x2F;password + 2FA? An attacker would need the assertion + 2FA authenticator code.

SAML uses xml. That alone makes it at least difficult to do securely due to XXE vulnerabilities.

It’s not insecure by design: use is so complicated that you never look back when you get it working. Too complex , so too error prone for most devs makes the risks of vulnerabilities high.

I found it a tad bit childish with all the swearing. Swearing is acceptable and sometimes natural in live speech but writing swear words is ugly and shows a lack of education and class, even if the actual education is of the highest calibre.

Note that XML is not the problem. The very same problems exist with json also. There is still no clarification on duplicate keys, key ordering, and similar unspec&#x27;d oversights.<p>Signing the normalized content is of course a nightmare, given that there is no spec&#x27;d normalization.