8 ms·

SAML Is Insecure by Design

300 points by aj3 5y ago

ezekg 5y ago
> (Note: this post is all pseudo code - it’s not real SAML. Here’s a real example if you’re interested.) *clicks link knowing full well the travesty about to be witnessed* So many businesses want me to support SAML. I always say no.
- Fizzadar 5y ago
  Aha, brings back memories. Had to implement SAML login as a Service Provider once - a true abomination of a protocol, will never go near it again, and that was the easier side of things.
teknofobi 5y ago
Why does Microsoft seem to default to SAML for organisations using Azure AD? 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.
- aj3 5y ago
  Well, it is de facto standard in Microsoft world. Honestly, I don’t actually share author's opinion, but it is well presented.
- merb 5y ago
  where does it default to saml? btw. we use azure ad and only rely on openid connect.
  - syshum 5y ago
    Most likely they are talking about adding Non-Gallery Applications (Custom Applications) for SSO, the only option there is SAML For OpenID Connect the developer has to sign up with Azure and have their app to the Gallery, you can not add a custom add yourself Right now there are over 1100 Gallery apps using SAML, and only 500 using OpenID Connect
    - hirsin 5y ago
      This is inaccurate. Multi tenant apps can simply be signed into via OIDC and they're added to your tenant, if you allow it. All Microsoft apps use OIDC and are not allowed to use SAML, but SaaS app developers are not quite as far ahead. But yes, we don't support dynamic registration of apps for eg OIDC/oauth
      - tehbeard 5y ago
        So no OIDC for "internal" apps? I had thought I'd missed something when setting up some customers, and having to refactor to use SAML for SSO where we'd used OIDC for g-suite, but you're saying unless I throw it on the gallery (public app store?), It's only SAML?
        merb 5y ago
        no. you register and you can either use saml or openid connect. btw. when you register your app you select if it is only for your tenant or for multiple tenants (or for microsoft accounts). your app never gets in the "public app store" unless you manually submit to. btw. this information is all public on their great docs.
        tehbeard 5y ago
        > this information is all public on their great docs. Public it may be, searchable it does not seem to be. Every search seems to direct me towards [1] , Which is about gallery apps, and then directs me to a Table of contents entry that doesn't seem to exist (the closest I found was a tutorials page which is about connecting to a bunch of pre-existing SaaS apps, not for a "custom-developed app") ...maybe this is something where I have to burn half a week playing with Azure AD on a trial account to figure out.. [1] https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/add-application-portal-setup-oidc-sso https://docs.microsoft.com/en-us/azure/active-directory/mana...
        merb 5y ago
  - teknofobi 5y ago
    It might just be cultural with the customers I’ve integrated with, but we’ve had a policy of requesting OIDC and then only doing SAML if that causes hiccups, and of a handful of SSO integrations with customers on the Microsoft stack there has always been hiccups. There might be other correlations here, such as the IT departments at Microsoft shops in our cases being more driven by consultants and managers.
    - wtatum 5y ago
      I've definitely seen this cultural bias towards SAML. I think it may be the case that a lot of enterprises have done a recent transition into Azure AD but have the same staff who had managed a legacy AD FS and have not adjusted with the times. My approach has been to use Keycloak as an identity broker. It's implementation is quite robust and supports a lot of flexibility in terms of mapping custom assertions and the like. But the actual application "only speaks OIDC" and relies on access tokens to be reissued by Keycloak.
    - user5994461 5y ago
      ADFS on-premise support both since version 2016, some people are not aware of that. Azure support both. The way it works in enterprise is that somebody wrote guidelines years ago that external software must support SSO with SAML. Then the guidelines were never updated and in some cases the company never realized they can support OIDC out of the box. The exception is education, where Shibboleth is very entrenched with federations spanning all universities in some countries. Another exception for healthcare/defense that may not have updated any of their systems for 20 years, though they may not be customer if they have no internet connectivity and no SSO :D
- hirsin 5y ago
  The Enterprise Apps section is heavily SAML based, but if you want to look up how to write an app for AAD you won't likely find any SAML docs, you'll find the OIDC docs and oauth SDKs we build. If you see other places where you feel we default to SAML, I'd love to fix that.
  - throwaway984393 5y ago
    Probably the wrong person to ask, but it would be great if there were guides on replacing SAML with OIDC, if you're already using AzureAD. Our architects are so f'ing clueless they're still telling us to use SAML rather than OAuth2/OIDC to integrate our apps with AzureAD. But if there was an official guide, I could send an e-mail blast to a few higher-ups and say "SAML is teh suck, but here is MS's guide on upgrading to OIDC, it's easy, no more excuses plz kthx"
    - hirsin 5y ago
      Very much so the right person to ask! This is great to hear that there's a need for this. I think our mental model of a lot of enterprises is that "old code" stays SAML and new code (that isn't copy paste from old) is OIDC. If there's actual desire to migrate apps between the protocols, that's great. Can't promise easy though given the diversity of starting places. Thanks!
      - throwaway984393 5y ago
        Actually our tendency is to re-use the old solution on the new code if it provides the same functionality. We still have people trying to use LDAP because nobody wants to take the time to learn something new. A migration guide makes it much more likely that they'll make an attempt to use the new thing. Our desire to upgrade pretty much only comes from Architects telling us "thou shalt follow my shiny new standard" (and by the way, they read your docs; if you suggest SAML be dropped, they'll update their standards!). In that case we have to find time to upgrade, and of course we never just document how to do it once for our whole org, so all these engineers will be wasting time re-learning how to do the same upgrade. I'll bet you we'd save hundreds to thousands of hours per year by having really good migration docs. Even if your migration guide doesn't cover everything, they still take a significant chunk out of the time we need to figure it all out, and it lowers the mental barrier to the change.
stouset 5y ago
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. 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. I tried to write a standards-based implementation and gave up. The standard is enormous, and consists of three parts: 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 Half the problem comes from the fact that it'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'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'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. The whole thing is a tire fire. Note, I last worked with it about a decade ago so I may have gotten some of the characterizations wrong.
- lol768 5y ago
  > 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. Yup, and its complexity leads to something of a shortage of libraries in the first place so there's not much choice. There's still no good modern maintained OSS .NET 5 library for doing SAML. There are some commercial offerings (ComponentSpace have a neat product and they weren't affected by VU#475445 either) but my worry is that folks will end up using whatever free libraries they can find without thinking too much about the consequences.
  - 8mcoLwmQoWZ3s 5y ago
rustybolt 5y ago
> SAML uses signatures based on computed values. "Computed values" is almost as general as "unit". It tells me absolutely nothing.
- humodz 5y ago
  Yeah, it'd much appreciated if the author explained that a bit more in the "why is saml insecure?" section
  - eightnoneone 5y ago
    He literally does just that in the very next section; “Why is signing computed values dangerous?”
    - NavinF 5y ago
      I assume he was being sarcastic
    - eyelidlessness 5y ago
      Really the only complaint I have about the article is this separate heading was unnecessary, and signaled to people who read fast with a short attention span might take that short section as “author assumed knowledge not in evidence”/“I’m not the intended audience”.
- nybble41 5y ago
  The issue isn't that the signature is based on a computed value—the input would always be computed at some point. The issue is that the signature checking code interprets the document one way and the code using the document interprets it another way. This is less likely to occur (though not quite impossible) when the input to the signature check is defined to be a simple byte array rather than a complex XML document where only certain parts are covered by the signature. One way to avoid this would be to require the input to be in some non-malleable normalized form: If normalization changes the document in any way then it fails the signature check. The advantages of this approach are that it doesn't require Base64-encoding the signed content and that it has no problem with embedded signature blocks.
mormegil 5y ago
Well the whole critique applies directly to the XML Signature Standard, doesn't it (of which the SAML standard is just a user/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 http://www.w3.org/TR/xmldsig-bestpractices/ http://www.w3.org/TR/xmldsig-bestpractices/
- kabes 5y ago
  Mostly yes. But the SAML spec itself also has too many degrees of freedom, which just means too many potential bugs. SAML could get rid of 90% of the spec and still support 99% of what it is used for, while having way less security pitfalls.
  - rstuart4133 5y ago
    The same could be said for x509 - so much crud for what boils down to a 3rd party signing a domain name asserting you have control over it. The unneeded complexity causes innumerable interoperability problems. As for the problems caused by ambiguous representations, the most memorable one for me was the bitcoin malleability problem which boiled down to a thing people based a transaction ID on having multiple representations. Bitcoin used DER format precisely because it isn't supposed to allow multiple representations of the same thing mind you - that bug was created by openssl following John Postel's advice "be conservative in what you do, be liberal in what you accept".
lol768 5y ago
> Let’s get rid of SAML. Good luck, it's prolific throughout so many enterprises and academic institutions. We might see some support start to materialise for OIDC as larger enterprises start to make use of e.g. AzureAD properly, but you'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've had X years of experience with it and their supplier on-boarding processes are built around it. The entire Jisc UK Access Management Federation is based on top of SAML, so that'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's likely that once you have the infrastructure set-up for this it gets used for more and more services.
- mordae 5y ago
  cough eIDAS cough
  - lol768 5y ago
    > eIDAS I'm sure a lot of governments have based regulations and standards on top of SAML... it seems exactly like the sort of thing they'd be drawn to - "mature", more complex than necessary, verbose. Pretty sure Gov.UK Verify is SAML-based, though I get the impression the new single sign-on solution (now entirely in-house with no external IdPs?) will be OIDC based.
- avmich 5y ago
  > Good luck, it's prolific throughout so many enterprises and academic institutions. Peasy easy. Just start mounting SAML vulnerabilities attacks on all those organizations with friendly suggestions to fix their problems, on top of juicy demonstrations of dangers. After a few will be affected, a trend will appear - in all kinds of media, among other things - that one ought to move from SAML. Of course the teachings should be done remotely, from friendly jurisdictions. /s We have this problem with security for years, not, decades even. Vista (Microsoft OS) was universally hated - <appropriate xkcd picture with blinking Hitler inserted> - as it tried to address gaping holes in XP security; fortunately Win 7 was much more user-friendly, so security still had some wins. But not nearly "ultimate" wins, no.
bob1029 5y ago
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 still don't fully comprehend after reading 2 dead trees worth of Azure docs. Ignoring all other business constraints, the most secure architecture in my mind is integrated security w/ single-instance applications which are isolated to their own physical hosts. Integrated security can include MFA as long as the additional factors are scoped exclusively to each applications' secure environment. 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.
dmarlow 5y ago
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/services?
- hirsin 5y ago
  If you want to federated eg AAD with Gsuite, it'll be via SAML, but I don't know of any consumer service that's ever supported SAML. It's so weird the author used Twitter when they were one of the classic original Oauth creators.
  - dmarlow 5y ago
    My thoughts exactly! A lot of the "social" things are OAuth based, not SAML. I know Google has both, but when doing consumerish things via Google, that's also OAuth based (iirc).
runningmike 5y ago
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.
- yokto 5y ago
  ... which is a way of being insecure by design. Design does not happen in a vacuum and must take the context and the audience into account.
  - eyelidlessness 5y ago
    This. I ducked out of an open security-related NPM RFC and decided my efforts are better spent recommending alternative package managers, because the maintainers/proposal advocates were exceedingly disinterested in addressing a wide variety of edge cases with a “you shouldn’t do that” attitude. Well, yeah I agree, but people can/will/do do that. If your security solution doesn’t account for how it might be misused, it’s insecure by design. Edit: it’s the audit assertions proposal for anyone interested. I consider it so high risk that I’m actively working to move projects in my purview off NPM in case it lands.
teknopurge 5y ago
The author did a good job, but these were(are) known issues for quite a while. TLDR: implementation bugs with known countermeasures. https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf https://www.usenix.org/system/files/conference/usenixsecurit... (from 2012) We'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/metadata.
- explorigin 5y ago
  This. Lots of SAML libraries don't fully implement the spec but I second what parent says. It does well for federation attributes.
- tptacek 5y ago
  The other word for "implementation bug" is "footgun". Standards with lots of footguns are bad standards. SAML has a lot of footguns. It is a bad standard.
jcims 5y ago
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. Getting rid of SAML will be like getting rid of SMS 2FA.
- yrro 5y ago
  This is because with the HTTP artifact binding, the SP (relying party) gets the claims directly from the IdP, and can therefore trust that the contents aren't malicious, right? It would therefore be comparable to OpenID Connect's authorization code flow.
  - jcims 5y ago
    Yep
    - yrro 5y ago
      Thanks!
- mooreds 5y ago
  For others who may be unfamiliar with HTTP artifact binding, I found this blog post useful: https://everything1know.wordpress.com/2019/02/19/saml-2-0-artifact-binding/ https://everything1know.wordpress.com/2019/02/19/saml-2-0-ar...
jimmaswell 5y ago
The vulnerabilities happened, we're aware of them now, and the major libraries (which you should be using anyway) will be sure to fix them. This isn't a compelling case to throw away SAML, just to be mindful not to make certain implementation errors.
- eyelidlessness 5y ago
  I think this is missing a huge part of the point of the article: the complexity of the standard and the domain space it provides makes implementation errors more likely. It’s akin to saying “making a web browser is easy, just follow the spec”; but the spec is a sprawling set of standards, with many layers of revisions and many important details left up to implementations. In both cases, implementations may not be nearly as cautious about the finer points of the spec. That’s a huge weight for either to carry, and probably the only reason we haven’t seen a similar proliferation of browser implementations with horrific vulnerabilities is that the spec is so huge and the incentives to build a new one are so low.
baby 5y ago
Nobody wants to write or maintain SAML code -> SaaS and other types of companies start solving this issue at scale -> SAML becomes code that is mostly going through a handful of large companies that sell products in this space -> since the protocol is now centralized, it can be updated to a better protocol
tptacek 5y ago
I think I agree with all of this. SAML is by far the worst commonly-used industry cryptographic protocol (you could generalize and say "anything reliant on XML signatures is the worst industry cryptographic protocol", 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). 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/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't safely build SAML on `encoding/xml` (it doesn't even really handle namespaces!) 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'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/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 in a single system. It's bananas. 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 and embedded signatures. There'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't sneak arbitrary subtrees into the middle of a SAML response --- but there's at least one extension field in a SAML message that has an any-typed free-form tag. It's also worth remembering that SAML's problem domain is difficult even setting the XML part of this aside. It'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's tricky to audit! People stick up for SAML because what it does (facilitating centralized SSO) is extremely valuable; it's probably more valuable than the bugs are harmful, as long as you'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'd consider beyond all the standard SAML checks also rejecting any message that doesn't have the same shape as what Okta, Onelogin, Google, or Shib generates. But if you have the option, I'd also say avoid SAML.
growup12345 5y ago
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.
- deleted 5y ago
  [deleted]
- eyelidlessness 5y ago
  Well, shit. I was surprised I made it almost to the bottom of the comments without becoming incredibly fucking annoyed by something ignorant and opinionated, but here we are. Swearing, used effectively (which I noted the article does before I got here), is a damn fine part of speech that’s valuable both for emotional expression and for relatable levity.
  - growup12345 5y ago
    You might want to learn to do some practice in reading comprehension: swearing in speech is not the same as swearing in writing.
    - eyelidlessness 5y ago
      Oh. Shit. You fucking think speech is oral communication rather than communicating ideas in any damn format or medium. How crapping sad you think so.
sleevi 5y ago
As others have noted, many of these issues are fundamental to XML DSig, which is insecure by design. [1] 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]. 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. 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. 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. 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. 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. [1] https://www.nccgroup.com/globalassets/resources/us/presentations/isec-hill-attacking-xml-security-bh07.pdf https://www.nccgroup.com/globalassets/resources/us/presentat... [2] https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 [3] https://openid.net/specs/openid-connect-discovery-1_0.html https://openid.net/specs/openid-connect-discovery-1_0.html
- lol768 5y ago
  > 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. I would bet a lot of money that a non-trivial number of people do exactly this in the real-world using SAML (Shibboleth: FileBackedHTTPMetadataProvider or DynamicHTTPMetadataProvider). It's not always manually managed.
mwcampbell 5y ago
How is Shibboleth SP's track record on SAML vulnerabilities, either patching them quickly or avoiding them altogether? 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'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's interested, our Shib SP container setup, with the Python shim app, is here: https://github.com/PneumaSolutions/shib-sp https://github.com/PneumaSolutions/shib-sp It's probably still too specific to our application, but might be useful as a starting point for others.
- xenophonf 5y ago
  Shibboleth is written by one of the authors/editors of the SAML 2.0 standard, with well funded support and a global community of very smart folks using/maintaining it. It's a pretty mature piece of software. Things get dicier when you go to languages like JavaScript, where there aren't really well maintained SAML implementations. But then that's true for everything.
  - mwcampbell 5y ago
    > Things get dicier when you go to languages like JavaScript, where there aren't really well maintained SAML implementations. Elixir for me. That's why I ended up running Shib SP with a Python-based Shim app in a container.
nwhatt 5y ago
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.
- mariusor 5y ago
  But at least Google can be used as a SAML idP for external services, which is what I think the author meant. SAML as far as I know doesn't specify how exactly an identity provider authenticates a user but only how, once a user is authenticated, the user has a specific "identity" in the context of the service provider that initiated the authorization/authentication process. Therefore the authentication mechanism on Google/Facebook's side can be OAuth or something else, but once completed, the mechanism to convey the identity of the user to the originating service is SAML.
elevation 5y ago
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/authorize the user against the company Active Directory. Assuming you now require that you deploy a solution which is free of SAML2, what do you deploy instead?
- p_l 5y ago
  keep pretty much everything you just mentioned, just with OIDC, and possibly add Zanzibar-like system for permissions with OIDC tokens being limited to just being identity bearers?
jiggawatts 5y ago
What kills me about SAML is that instead of this straightforward XML style: <claims> <nameid>foo.bar@test.com</nameid> <givenname>Foo</givenname> <surname>Bar</surname> </claims> It instead encodes elements and attributes using elements and attributes, in the manner of the classic "inner platform effect" anti-pattern: <saml:AttributeStatement> <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">foo.bar@test.com</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> This is roughly the equivalent of the SQL table schema where there's one table with the columns "rowid, columnname, value" along with a "schema table" that some hand-rolled code uses to validate that the data table contains only data that is valid according to the schema. It's not XML, it's XML squared: using XML to encode XML concepts instead of just using XML directly.
- dboreham 5y ago
  Oh wow. I'd never looked close up. That's fascinating, and a term of art I expect to use in the future. Btw I think your SQL example is called "EAV Schema" and does have a legitimate purpose once in a while.
  - paulmd 5y ago
    these days if you are modeling the "sparse, high-dimensional data" of the kind that EAV schema does well, you probably should be reaching for JSON columns instead of EAV schema.
    - jiggawatts 5y ago
      Some databases support "sparse columns", which use EAV under the hood but are better optimised: https://docs.microsoft.com/en-us/sql/relational-databases/tables/use-sparse-columns https://docs.microsoft.com/en-us/sql/relational-databases/ta...
hardwaresofton 5y ago
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] > 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). 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't seem to get used much outside of academia but it's very minimal and understandable, and OAuth/SAML work in a roughly similar pattern (but different, CAS is centralized though there are proxies). It's now stewarded by a company called apereo[1]. Agreed with the other commenters though, SAML login is an "enterprise" feature, so it's going to be around for a very long time -- things that warrant upselling tend to stick around. [0]: https://developers.yale.edu/cas-central-authentication-service https://developers.yale.edu/cas-central-authentication-servi... [1]: https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-Specification.html https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-Spe...
GNOMES 5y ago
SAML + 2FA would still be strong vs say username/password + 2FA? An attacker would need the assertion + 2FA authenticator code.
jmann99999 5y ago
I worry that this thread dissuades people from doing SAML. For our business we do only do Identity Provider SAML and it works wonderfully. 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.
- yrro 5y ago
  Just be careful that it's now not too easy for users to log in...
  - donalhunt 5y ago
    You can configure the application side to re-request authentication. This is similar to how Google requires you to sign in with a password when accessing sensitive endpoints like passwords.google.com.
    - yrro 5y ago
      Oh, I only meant that with SAML, the SP has to deal with maliciously-constructed assertions. A buggy SP (and as the comments on this article show, these are common) can be fooled into allowing an attacker to bypass authentication. Thereby making it a little bit too easy for users to log in. ;)
ljm 5y ago
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. The author constantly disclaims their approach. Why are they demonstrating in json, and why are they demonstrating in what they call 'pseudo-saml' when everything they need is right there? They don't prove that SAML is insecure, because there is no vulnerable SAML in the post.
- mooreds 5y ago
  > 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. I wasn't sure what the point of that was either. I found that confusing and it seemed to detract from the strengths of the article.
rurban 5y ago
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'd oversights. Signing the normalized content is of course a nightmare, given that there is no spec'd normalization.
- tptacek 5y ago
  No, this is an XML-specific problem. JWT is bad, but it's not "you can create arbitrary forests of signed and unsigned trees" bad. XML sort of begs you to do that. JSON doesn't even support comments.
  - ptomato 5y ago
    Though there are attempts underway to do inline signing of JWT (https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ https://datatracker.ietf.org/doc/draft-jordan-jws-ct/), though that's still not nearly as bad as XML-DSIG of course. I'm sure some vulns will shake out of it.
ulrikrasmussen 5y ago
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. I think OIDC is better than SAML (it avoids the particular problem with malleable signatures described in TFA). You can actually read 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).
- danjac 5y ago
  > 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 Thankfully we've progressed from that era. s/XML/YAML
deanclatworthy 5y ago
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: - that library is not supported as such. It was published under the DVV but that’s it. - 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. - integration was time consuming and difficult to debug errors. Would not recommend.
pteraspidomorph 5y ago
> Sure, purists may argue that storing XML inside XML as a string or bytes is ugly Ho ho ho, they really haven't looked at a lot of XML.
thayne 5y ago
SAML uses xml. That alone makes it at least difficult to do securely due to XXE vulnerabilities.
commandlinefan 5y ago
ASN.1 signatures aren'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's just that it's been around long enough that (we hope) the kinks in the system have been discovered and worked out.

300 points by aj3 5y ago

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

Fizzadar 5y ago
Aha, brings back memories. Had to implement SAML login as a Service Provider once - a true abomination of a protocol, will never go near it again, and that was the easier side of things.

teknofobi 5y ago

Why does Microsoft seem to default to SAML for organisations using Azure AD? 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.

aj3 5y ago
Well, it is de facto standard in Microsoft world. Honestly, I don’t actually share author's opinion, but it is well presented.
merb 5y ago
where does it default to saml? btw. we use azure ad and only rely on openid connect.
- syshum 5y ago
  Most likely they are talking about adding Non-Gallery Applications (Custom Applications) for SSO, the only option there is SAML For OpenID Connect the developer has to sign up with Azure and have their app to the Gallery, you can not add a custom add yourself Right now there are over 1100 Gallery apps using SAML, and only 500 using OpenID Connect
  - hirsin 5y ago
    This is inaccurate. Multi tenant apps can simply be signed into via OIDC and they're added to your tenant, if you allow it. All Microsoft apps use OIDC and are not allowed to use SAML, but SaaS app developers are not quite as far ahead. But yes, we don't support dynamic registration of apps for eg OIDC/oauth
    - tehbeard 5y ago
      So no OIDC for "internal" apps? I had thought I'd missed something when setting up some customers, and having to refactor to use SAML for SSO where we'd used OIDC for g-suite, but you're saying unless I throw it on the gallery (public app store?), It's only SAML?
      - merb 5y ago
        no. you register and you can either use saml or openid connect. btw. when you register your app you select if it is only for your tenant or for multiple tenants (or for microsoft accounts). your app never gets in the "public app store" unless you manually submit to. btw. this information is all public on their great docs.
        tehbeard 5y ago
        > this information is all public on their great docs. Public it may be, searchable it does not seem to be. Every search seems to direct me towards [1] , Which is about gallery apps, and then directs me to a Table of contents entry that doesn't seem to exist (the closest I found was a tutorials page which is about connecting to a bunch of pre-existing SaaS apps, not for a "custom-developed app") ...maybe this is something where I have to burn half a week playing with Azure AD on a trial account to figure out.. [1] https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/add-application-portal-setup-oidc-sso https://docs.microsoft.com/en-us/azure/active-directory/mana...
        merb 5y ago
- teknofobi 5y ago
  It might just be cultural with the customers I’ve integrated with, but we’ve had a policy of requesting OIDC and then only doing SAML if that causes hiccups, and of a handful of SSO integrations with customers on the Microsoft stack there has always been hiccups. There might be other correlations here, such as the IT departments at Microsoft shops in our cases being more driven by consultants and managers.
  - wtatum 5y ago
    I've definitely seen this cultural bias towards SAML. I think it may be the case that a lot of enterprises have done a recent transition into Azure AD but have the same staff who had managed a legacy AD FS and have not adjusted with the times. My approach has been to use Keycloak as an identity broker. It's implementation is quite robust and supports a lot of flexibility in terms of mapping custom assertions and the like. But the actual application "only speaks OIDC" and relies on access tokens to be reissued by Keycloak.
  - user5994461 5y ago
    ADFS on-premise support both since version 2016, some people are not aware of that. Azure support both. The way it works in enterprise is that somebody wrote guidelines years ago that external software must support SSO with SAML. Then the guidelines were never updated and in some cases the company never realized they can support OIDC out of the box. The exception is education, where Shibboleth is very entrenched with federations spanning all universities in some countries. Another exception for healthcare/defense that may not have updated any of their systems for 20 years, though they may not be customer if they have no internet connectivity and no SSO :D
hirsin 5y ago
The Enterprise Apps section is heavily SAML based, but if you want to look up how to write an app for AAD you won't likely find any SAML docs, you'll find the OIDC docs and oauth SDKs we build. If you see other places where you feel we default to SAML, I'd love to fix that.
- throwaway984393 5y ago
  Probably the wrong person to ask, but it would be great if there were guides on replacing SAML with OIDC, if you're already using AzureAD. Our architects are so f'ing clueless they're still telling us to use SAML rather than OAuth2/OIDC to integrate our apps with AzureAD. But if there was an official guide, I could send an e-mail blast to a few higher-ups and say "SAML is teh suck, but here is MS's guide on upgrading to OIDC, it's easy, no more excuses plz kthx"
  - hirsin 5y ago
    Very much so the right person to ask! This is great to hear that there's a need for this. I think our mental model of a lot of enterprises is that "old code" stays SAML and new code (that isn't copy paste from old) is OIDC. If there's actual desire to migrate apps between the protocols, that's great. Can't promise easy though given the diversity of starting places. Thanks!
    - throwaway984393 5y ago
      Actually our tendency is to re-use the old solution on the new code if it provides the same functionality. We still have people trying to use LDAP because nobody wants to take the time to learn something new. A migration guide makes it much more likely that they'll make an attempt to use the new thing. Our desire to upgrade pretty much only comes from Architects telling us "thou shalt follow my shiny new standard" (and by the way, they read your docs; if you suggest SAML be dropped, they'll update their standards!). In that case we have to find time to upgrade, and of course we never just document how to do it once for our whole org, so all these engineers will be wasting time re-learning how to do the same upgrade. I'll bet you we'd save hundreds to thousands of hours per year by having really good migration docs. Even if your migration guide doesn't cover everything, they still take a significant chunk out of the time we need to figure it all out, and it lowers the mental barrier to the change.

stouset 5y ago

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. 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. I tried to write a standards-based implementation and gave up. The standard is enormous, and consists of three parts: 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 Half the problem comes from the fact that it'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'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'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. The whole thing is a tire fire. Note, I last worked with it about a decade ago so I may have gotten some of the characterizations wrong.

lol768 5y ago
> 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. Yup, and its complexity leads to something of a shortage of libraries in the first place so there's not much choice. There's still no good modern maintained OSS .NET 5 library for doing SAML. There are some commercial offerings (ComponentSpace have a neat product and they weren't affected by VU#475445 either) but my worry is that folks will end up using whatever free libraries they can find without thinking too much about the consequences.
- 8mcoLwmQoWZ3s 5y ago

rustybolt 5y ago

> SAML uses signatures based on computed values. "Computed values" is almost as general as "unit". It tells me absolutely nothing.

humodz 5y ago
Yeah, it'd much appreciated if the author explained that a bit more in the "why is saml insecure?" section
- eightnoneone 5y ago
  He literally does just that in the very next section; “Why is signing computed values dangerous?”
  - NavinF 5y ago
    I assume he was being sarcastic
  - eyelidlessness 5y ago
    Really the only complaint I have about the article is this separate heading was unnecessary, and signaled to people who read fast with a short attention span might take that short section as “author assumed knowledge not in evidence”/“I’m not the intended audience”.
nybble41 5y ago
The issue isn't that the signature is based on a computed value—the input would always be computed at some point. The issue is that the signature checking code interprets the document one way and the code using the document interprets it another way. This is less likely to occur (though not quite impossible) when the input to the signature check is defined to be a simple byte array rather than a complex XML document where only certain parts are covered by the signature. One way to avoid this would be to require the input to be in some non-malleable normalized form: If normalization changes the document in any way then it fails the signature check. The advantages of this approach are that it doesn't require Base64-encoding the signed content and that it has no problem with embedded signature blocks.

mormegil 5y ago

Well the whole critique applies directly to the XML Signature Standard, doesn't it (of which the SAML standard is just a user/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 http://www.w3.org/TR/xmldsig-bestpractices/ http://www.w3.org/TR/xmldsig-bestpractices/

kabes 5y ago
Mostly yes. But the SAML spec itself also has too many degrees of freedom, which just means too many potential bugs. SAML could get rid of 90% of the spec and still support 99% of what it is used for, while having way less security pitfalls.
- rstuart4133 5y ago
  The same could be said for x509 - so much crud for what boils down to a 3rd party signing a domain name asserting you have control over it. The unneeded complexity causes innumerable interoperability problems. As for the problems caused by ambiguous representations, the most memorable one for me was the bitcoin malleability problem which boiled down to a thing people based a transaction ID on having multiple representations. Bitcoin used DER format precisely because it isn't supposed to allow multiple representations of the same thing mind you - that bug was created by openssl following John Postel's advice "be conservative in what you do, be liberal in what you accept".

lol768 5y ago

> Let’s get rid of SAML. Good luck, it's prolific throughout so many enterprises and academic institutions. We might see some support start to materialise for OIDC as larger enterprises start to make use of e.g. AzureAD properly, but you'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've had X years of experience with it and their supplier on-boarding processes are built around it. The entire Jisc UK Access Management Federation is based on top of SAML, so that'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's likely that once you have the infrastructure set-up for this it gets used for more and more services.

mordae 5y ago
cough eIDAS cough
- lol768 5y ago
  > eIDAS I'm sure a lot of governments have based regulations and standards on top of SAML... it seems exactly like the sort of thing they'd be drawn to - "mature", more complex than necessary, verbose. Pretty sure Gov.UK Verify is SAML-based, though I get the impression the new single sign-on solution (now entirely in-house with no external IdPs?) will be OIDC based.
avmich 5y ago
> Good luck, it's prolific throughout so many enterprises and academic institutions. Peasy easy. Just start mounting SAML vulnerabilities attacks on all those organizations with friendly suggestions to fix their problems, on top of juicy demonstrations of dangers. After a few will be affected, a trend will appear - in all kinds of media, among other things - that one ought to move from SAML. Of course the teachings should be done remotely, from friendly jurisdictions. /s We have this problem with security for years, not, decades even. Vista (Microsoft OS) was universally hated - <appropriate xkcd picture with blinking Hitler inserted> - as it tried to address gaping holes in XP security; fortunately Win 7 was much more user-friendly, so security still had some wins. But not nearly "ultimate" wins, no.

bob1029 5y ago

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 still don't fully comprehend after reading 2 dead trees worth of Azure docs. Ignoring all other business constraints, the most secure architecture in my mind is integrated security w/ single-instance applications which are isolated to their own physical hosts. Integrated security can include MFA as long as the additional factors are scoped exclusively to each applications' secure environment. 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.

dmarlow 5y ago

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/services?

hirsin 5y ago
If you want to federated eg AAD with Gsuite, it'll be via SAML, but I don't know of any consumer service that's ever supported SAML. It's so weird the author used Twitter when they were one of the classic original Oauth creators.
- dmarlow 5y ago
  My thoughts exactly! A lot of the "social" things are OAuth based, not SAML. I know Google has both, but when doing consumerish things via Google, that's also OAuth based (iirc).

runningmike 5y ago

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.

yokto 5y ago
... which is a way of being insecure by design. Design does not happen in a vacuum and must take the context and the audience into account.
- eyelidlessness 5y ago
  This. I ducked out of an open security-related NPM RFC and decided my efforts are better spent recommending alternative package managers, because the maintainers/proposal advocates were exceedingly disinterested in addressing a wide variety of edge cases with a “you shouldn’t do that” attitude. Well, yeah I agree, but people can/will/do do that. If your security solution doesn’t account for how it might be misused, it’s insecure by design. Edit: it’s the audit assertions proposal for anyone interested. I consider it so high risk that I’m actively working to move projects in my purview off NPM in case it lands.

teknopurge 5y ago

The author did a good job, but these were(are) known issues for quite a while. TLDR: implementation bugs with known countermeasures. https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf https://www.usenix.org/system/files/conference/usenixsecurit... (from 2012) We'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/metadata.

explorigin 5y ago
This. Lots of SAML libraries don't fully implement the spec but I second what parent says. It does well for federation attributes.
tptacek 5y ago
The other word for "implementation bug" is "footgun". Standards with lots of footguns are bad standards. SAML has a lot of footguns. It is a bad standard.

jcims 5y ago

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. Getting rid of SAML will be like getting rid of SMS 2FA.

yrro 5y ago
This is because with the HTTP artifact binding, the SP (relying party) gets the claims directly from the IdP, and can therefore trust that the contents aren't malicious, right? It would therefore be comparable to OpenID Connect's authorization code flow.
- jcims 5y ago
  Yep
  - yrro 5y ago
    Thanks!
mooreds 5y ago
For others who may be unfamiliar with HTTP artifact binding, I found this blog post useful: https://everything1know.wordpress.com/2019/02/19/saml-2-0-artifact-binding/ https://everything1know.wordpress.com/2019/02/19/saml-2-0-ar...

jimmaswell 5y ago

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

eyelidlessness 5y ago
I think this is missing a huge part of the point of the article: the complexity of the standard and the domain space it provides makes implementation errors more likely. It’s akin to saying “making a web browser is easy, just follow the spec”; but the spec is a sprawling set of standards, with many layers of revisions and many important details left up to implementations. In both cases, implementations may not be nearly as cautious about the finer points of the spec. That’s a huge weight for either to carry, and probably the only reason we haven’t seen a similar proliferation of browser implementations with horrific vulnerabilities is that the spec is so huge and the incentives to build a new one are so low.

baby 5y ago

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

tptacek 5y ago

I think I agree with all of this. SAML is by far the worst commonly-used industry cryptographic protocol (you could generalize and say "anything reliant on XML signatures is the worst industry cryptographic protocol", 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). 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/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't safely build SAML on `encoding/xml` (it doesn't even really handle namespaces!) 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'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/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 in a single system. It's bananas. 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 and embedded signatures. There'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't sneak arbitrary subtrees into the middle of a SAML response --- but there's at least one extension field in a SAML message that has an any-typed free-form tag. It's also worth remembering that SAML's problem domain is difficult even setting the XML part of this aside. It'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's tricky to audit! People stick up for SAML because what it does (facilitating centralized SSO) is extremely valuable; it's probably more valuable than the bugs are harmful, as long as you'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'd consider beyond all the standard SAML checks also rejecting any message that doesn't have the same shape as what Okta, Onelogin, Google, or Shib generates. But if you have the option, I'd also say avoid SAML.

growup12345 5y ago

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.

deleted 5y ago
[deleted]
eyelidlessness 5y ago
Well, shit. I was surprised I made it almost to the bottom of the comments without becoming incredibly fucking annoyed by something ignorant and opinionated, but here we are. Swearing, used effectively (which I noted the article does before I got here), is a damn fine part of speech that’s valuable both for emotional expression and for relatable levity.
- growup12345 5y ago
  You might want to learn to do some practice in reading comprehension: swearing in speech is not the same as swearing in writing.
  - eyelidlessness 5y ago
    Oh. Shit. You fucking think speech is oral communication rather than communicating ideas in any damn format or medium. How crapping sad you think so.

sleevi 5y ago

As others have noted, many of these issues are fundamental to XML DSig, which is insecure by design. [1] 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]. 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. 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. 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. 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. 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. [1] https://www.nccgroup.com/globalassets/resources/us/presentations/isec-hill-attacking-xml-security-bh07.pdf https://www.nccgroup.com/globalassets/resources/us/presentat... [2] https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 [3] https://openid.net/specs/openid-connect-discovery-1_0.html https://openid.net/specs/openid-connect-discovery-1_0.html

lol768 5y ago
> 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. I would bet a lot of money that a non-trivial number of people do exactly this in the real-world using SAML (Shibboleth: FileBackedHTTPMetadataProvider or DynamicHTTPMetadataProvider). It's not always manually managed.

mwcampbell 5y ago

How is Shibboleth SP's track record on SAML vulnerabilities, either patching them quickly or avoiding them altogether? 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'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's interested, our Shib SP container setup, with the Python shim app, is here: https://github.com/PneumaSolutions/shib-sp https://github.com/PneumaSolutions/shib-sp It's probably still too specific to our application, but might be useful as a starting point for others.

xenophonf 5y ago
Shibboleth is written by one of the authors/editors of the SAML 2.0 standard, with well funded support and a global community of very smart folks using/maintaining it. It's a pretty mature piece of software. Things get dicier when you go to languages like JavaScript, where there aren't really well maintained SAML implementations. But then that's true for everything.
- mwcampbell 5y ago
  > Things get dicier when you go to languages like JavaScript, where there aren't really well maintained SAML implementations. Elixir for me. That's why I ended up running Shib SP with a Python-based Shim app in a container.

nwhatt 5y ago

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.

mariusor 5y ago
But at least Google can be used as a SAML idP for external services, which is what I think the author meant. SAML as far as I know doesn't specify how exactly an identity provider authenticates a user but only how, once a user is authenticated, the user has a specific "identity" in the context of the service provider that initiated the authorization/authentication process. Therefore the authentication mechanism on Google/Facebook's side can be OAuth or something else, but once completed, the mechanism to convey the identity of the user to the originating service is SAML.

elevation 5y ago

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/authorize the user against the company Active Directory. Assuming you now require that you deploy a solution which is free of SAML2, what do you deploy instead?

p_l 5y ago
keep pretty much everything you just mentioned, just with OIDC, and possibly add Zanzibar-like system for permissions with OIDC tokens being limited to just being identity bearers?

jiggawatts 5y ago

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

dboreham 5y ago
Oh wow. I'd never looked close up. That's fascinating, and a term of art I expect to use in the future. Btw I think your SQL example is called "EAV Schema" and does have a legitimate purpose once in a while.
- paulmd 5y ago
  these days if you are modeling the "sparse, high-dimensional data" of the kind that EAV schema does well, you probably should be reaching for JSON columns instead of EAV schema.
  - jiggawatts 5y ago
    Some databases support "sparse columns", which use EAV under the hood but are better optimised: https://docs.microsoft.com/en-us/sql/relational-databases/tables/use-sparse-columns https://docs.microsoft.com/en-us/sql/relational-databases/ta...

hardwaresofton 5y ago

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] > 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). 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't seem to get used much outside of academia but it's very minimal and understandable, and OAuth/SAML work in a roughly similar pattern (but different, CAS is centralized though there are proxies). It's now stewarded by a company called apereo[1]. Agreed with the other commenters though, SAML login is an "enterprise" feature, so it's going to be around for a very long time -- things that warrant upselling tend to stick around. [0]: https://developers.yale.edu/cas-central-authentication-service https://developers.yale.edu/cas-central-authentication-servi... [1]: https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-Specification.html https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-Spe...

GNOMES 5y ago

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

jmann99999 5y ago

I worry that this thread dissuades people from doing SAML. For our business we do only do Identity Provider SAML and it works wonderfully. 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.

yrro 5y ago
Just be careful that it's now not too easy for users to log in...
- donalhunt 5y ago
  You can configure the application side to re-request authentication. This is similar to how Google requires you to sign in with a password when accessing sensitive endpoints like passwords.google.com.
  - yrro 5y ago
    Oh, I only meant that with SAML, the SP has to deal with maliciously-constructed assertions. A buggy SP (and as the comments on this article show, these are common) can be fooled into allowing an attacker to bypass authentication. Thereby making it a little bit too easy for users to log in. ;)

ljm 5y ago

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. The author constantly disclaims their approach. Why are they demonstrating in json, and why are they demonstrating in what they call 'pseudo-saml' when everything they need is right there? They don't prove that SAML is insecure, because there is no vulnerable SAML in the post.

mooreds 5y ago
> 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. I wasn't sure what the point of that was either. I found that confusing and it seemed to detract from the strengths of the article.

rurban 5y ago

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'd oversights. Signing the normalized content is of course a nightmare, given that there is no spec'd normalization.

tptacek 5y ago
No, this is an XML-specific problem. JWT is bad, but it's not "you can create arbitrary forests of signed and unsigned trees" bad. XML sort of begs you to do that. JSON doesn't even support comments.
- ptomato 5y ago
  Though there are attempts underway to do inline signing of JWT (https://datatracker.ietf.org/doc/draft-jordan-jws-ct/ https://datatracker.ietf.org/doc/draft-jordan-jws-ct/), though that's still not nearly as bad as XML-DSIG of course. I'm sure some vulns will shake out of it.

ulrikrasmussen 5y ago

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. I think OIDC is better than SAML (it avoids the particular problem with malleable signatures described in TFA). You can actually read 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).

danjac 5y ago
> 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 Thankfully we've progressed from that era. s/XML/YAML

deanclatworthy 5y ago

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: - that library is not supported as such. It was published under the DVV but that’s it. - 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. - integration was time consuming and difficult to debug errors. Would not recommend.

pteraspidomorph 5y ago

> Sure, purists may argue that storing XML inside XML as a string or bytes is ugly Ho ho ho, they really haven't looked at a lot of XML.

thayne 5y ago

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

commandlinefan 5y ago

ASN.1 signatures aren'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's just that it's been around long enough that (we hope) the kinks in the system have been discovered and worked out.