Beer Drinkers Guide to SAML(duo.com)
duo.com
Beer Drinkers Guide to SAML
https://duo.com/blog/the-beer-drinkers-guide-to-saml
57 comments
> The biggest problem with SAML is probably XML-DSig.
I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML. My personal opinion is that it set the industry back by a decade. It just blows my mind the amount of effort (time & money) which was poured into such a flawed architecture.
Ditto Java, really. The early-2000s vision was one great mass of Java & XML. Why we didn't stick with Lisp & S-expressions I'll never know.
I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML. My personal opinion is that it set the industry back by a decade. It just blows my mind the amount of effort (time & money) which was poured into such a flawed architecture.
Ditto Java, really. The early-2000s vision was one great mass of Java & XML. Why we didn't stick with Lisp & S-expressions I'll never know.
I'm a lisper and dislike XML as much as the next guy, but XML-DSig seems like a fundamental mistake and sexp-dsig would not have been a better spec. All of the problems you get from in-band signing and encryption are still there--case in point, our blog post on how not to sign a JSON object[0] would be a fine spike on a blog post about why XML-DSig is bananas.
(One counterexample I can think of: you probably wouldn't do CDATA and comments the same way as XML did, which led to Kelby Ludwig's fantastic SAML auth bypass--which also gets a review in that blog post.)
[0]: https://latacora.micro.blog/2019/07/24/how-not-to.html
(One counterexample I can think of: you probably wouldn't do CDATA and comments the same way as XML did, which led to Kelby Ludwig's fantastic SAML auth bypass--which also gets a review in that blog post.)
[0]: https://latacora.micro.blog/2019/07/24/how-not-to.html
> I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML.
The alternative was SGML. Would you have preferred that, because that was the 'only' over option at the time.
It would be like saying twenty years from now: "wow, I'd love to learn why people used fossil-fuelled cars instead of EVs: ICE cars are so inferior". Well, at the time nothing better had been developed and we did the best we can.
The alternative was SGML. Would you have preferred that, because that was the 'only' over option at the time.
It would be like saying twenty years from now: "wow, I'd love to learn why people used fossil-fuelled cars instead of EVs: ICE cars are so inferior". Well, at the time nothing better had been developed and we did the best we can.
The problem with SAML et al is not Java or XML. The problem is the spec conflating transport protocol concerns with the content format concern.
If you can cleanly separate the transport component's cryptography (making sure the content is secure and private) from the formatting and processing of the actual content it makes things a lot clearer.
If you can cleanly separate the transport component's cryptography (making sure the content is secure and private) from the formatting and processing of the actual content it makes things a lot clearer.
Everyone should test their SAML deployments for XML signature wrapping vulnerabilities. XML-DSig is ridiculously complex.
The basic idea is simple: Take a valid SAML assertion and embed it, signature and all, inside a forged SAML assertion. Test your ACS endpoint to make certain it is rejected by the service provider.
https://www.usenix.org/system/files/conference/usenixsecurit...
The basic idea is simple: Take a valid SAML assertion and embed it, signature and all, inside a forged SAML assertion. Test your ACS endpoint to make certain it is rejected by the service provider.
https://www.usenix.org/system/files/conference/usenixsecurit...
There's a bunch of things you need to test SAML implementations for, from comment handling to audience checking to SSRF. It's not an easy feature to get right and there's no one good source on all the issues.
My best advice for safely using SAML is: use a library that everyone uses and that is well tested. This is a place where I might stand up a separate service in a different language to get a popular SAML library rather than the shady one that is most convenient for your preferred platform.
My best advice for safely using SAML is: use a library that everyone uses and that is well tested. This is a place where I might stand up a separate service in a different language to get a popular SAML library rather than the shady one that is most convenient for your preferred platform.
I agree with all of this (no wonder since Thomas' opinions and mine largely come from the same place), but dark horses like Kelby Ludwig's canonicalization bug make me even happier if I can outsource that infrastructure to a vendor, perhaps exacerbated since I'm also an infrastructure-focused person.
I'm not all starry-eyed about Cognito, but I know the next libxmlsec1 0day isn't my problem. (Except of course that probably is because some clients don't have Cognito :-))
I'm not all starry-eyed about Cognito, but I know the next libxmlsec1 0day isn't my problem. (Except of course that probably is because some clients don't have Cognito :-))
Any suggestions on what that library/language could be?
We are deploying software to multiple clients and usually oidc is accepted. ADFS2016 has it, Azure AD has it, PingIdentity has it.
I hate it's so java-centered.
I mean, how do you do SAML in C++/Rust/Go?
I mean, how do you do SAML in C++/Rust/Go?
The OpenSAML library has native versions available for both Java and C++. There is a native SAML implementation for Python, and a native SAML client implementation for Go.
Great article but if I wanted to explain it to somebody in one sentence I'd say "It's like sign-in with google, but for enterprises", by "enterprises" i mean "more shit" - xml/soap/overcomplicated kind of shit.
as the resident keeper of the keycloak (aka RedHat SSO) which can and does do both SAML and OIDC (what google uses) in our organization I only sort of agree. SAML is overcomplicated, but OIDC also has a lot of bloat, although it's more optional there. It's just trying to solve too many problems for too many parties at once. Back and front channel logout, your choice of symmetric or asymmetric crypto, at least 3 types of different tokens, and 3 ways to get subsets of them with various subtypes, depending on if you're a client application, a web application that can redirect, a web application that can't redirect, an app on a TV... Oh, and did I tell you about the authorization framework? With assessment servers? There's that too!
Thankfully in the real world both seem to be implemented in the absolute minimal way to get things working.
Thankfully in the real world both seem to be implemented in the absolute minimal way to get things working.
Cheers for keycloak, title pun intended :)
We use it for Solvent (https://codesolvent.com) login to product instances and it works excellently.
We use it for Solvent (https://codesolvent.com) login to product instances and it works excellently.
How have you guys solved "from scratch" configuration for keycloak? I've worked with it a bit over the years and I've never found a way to get it into a state I want programmatically without hacky bash scripts and modifying the json templates.
Maybe we got lucky with the configuration but we use the approach documented for the keycloak-saml-adapter with Jetty as the app server.
There is still a lot work done to ensure keys are generated in the proper locations and that necessary product id values (corresponds to SAML SP entityID) are generated.
In short, it is not a simple plug-n-play, lots of hacking to get the result we needed but the adapter itself does what it needs to do.
There is still a lot work done to ensure keys are generated in the proper locations and that necessary product id values (corresponds to SAML SP entityID) are generated.
In short, it is not a simple plug-n-play, lots of hacking to get the result we needed but the adapter itself does what it needs to do.
believe it or not, but we do FROM jboss/keycloak:9.0.0, add a theme jar, throw it on k8s with 2 pods and a postgres behind it and that's it.
Our clients are mostly SAML SaaS software and our own implementation of gatekeeper (which is also a kubernetes ingress) with short lifetime OIDC ID tokens, long lifetime refresh tokens and seamless background refreshing.
Our clients are mostly SAML SaaS software and our own implementation of gatekeeper (which is also a kubernetes ingress) with short lifetime OIDC ID tokens, long lifetime refresh tokens and seamless background refreshing.
So much easier than SSO would be installing certs on all the client machines when they’re provisioned. Support for client side certs on iOS sucks balls of course so no one does this.
I love mTLS a lot more than the average bear[0], but the main reason I see companies deploy SSO is centralized access control and access management (particularly for offboarding), which client certs are only a tiny fraction of. Since they're typically long-held, you're now proposing either a rigorous revocation scheme or continuous reissuance, and neither seems to be deployed anywhere outside of maybe the DoD. (And Gemini? Maybe?) So: as much as I'd love that to be the case, I don't think that we're "iOS' UX for client certs" away from that being a plausible replacement.
[0]: Thomas Pornin is far from average!
[0]: Thomas Pornin is far from average!
It really shouldn't be any more work to revoke a certificate or just maintain a whitelist/blacklist of certificates than it should be to just disable a user account.
Certificates are only more difficult because nobody seems to have put in the effort to automate them, and client software hasn't put in any effort to make the experience nice.
Certificates are only more difficult because nobody seems to have put in the effort to automate them, and client software hasn't put in any effort to make the experience nice.
Even if we stipulate that's true: that's precisely my point, nobody has built the tooling to make any of it good, but companies need a reasonable access control story today.
Why are the people who left taking corporate devices with them?
Or alternatively, why are you trusting new employees phones? That’s absolute insanity.
Or alternatively, why are you trusting new employees phones? That’s absolute insanity.
They don't need to take a corporate device with them. They need to have exfiltrated a credential during the (long) time they had alone with the laptop. You trust new employees' phones the way you decided to trust anything else: a risk assessment based on what the company is willing to bear, taking into account compensating controls like MDM.
Are you suggesting "no creds that live outside of trusted elements physically tied to a device we own" is an ubiquitous property of access management?
Are you suggesting "no creds that live outside of trusted elements physically tied to a device we own" is an ubiquitous property of access management?
> no creds that live outside of trusted elements physically tied to a device we own.
I’ve never worked full time at a software company that allowed credentials on employee personal devices. Supposedly because most consumers are up to their eyes in malware, often from the moment they buy the devices, not because the employees are untrustworthy (it would be difficult to have a functioning business where you can’t trust the employees.)
I’ve never worked full time at a software company that allowed credentials on employee personal devices. Supposedly because most consumers are up to their eyes in malware, often from the moment they buy the devices, not because the employees are untrustworthy (it would be difficult to have a functioning business where you can’t trust the employees.)
I’m currently typing on a personal mobile device that is trusted by my software employer
You don't appear to have engaged with my core point: policy is not access control.
What use does SAML still hold with the advent of OIDC? When building enterprise software, should I bother implementing SAML or is OIDC support commonplace?
Anecdotal from my experience in Presales selling Enterprise software. Out of 10 enterprise segment customers:
- 8/9 would prefer SAML
- 2/3 have a compliant IdP which supports OIDC (ADFS needs to be v4.0 therefore run on Windows Server 2016+)
You'd be a fool to only focus on OIDC, at least for the next few years. As Azure gobbles up the Enterprise segment, Azure AD can be used to provide OIDC which will be nice. Though most admins who we work with are far more comfortable with SAML.
To be completely honest, the major of customers who are primarily interested in OIDC are coming from Google and/or GCP shops (which are few and far between).
You'd be a fool to only focus on OIDC, at least for the next few years. As Azure gobbles up the Enterprise segment, Azure AD can be used to provide OIDC which will be nice. Though most admins who we work with are far more comfortable with SAML.
To be completely honest, the major of customers who are primarily interested in OIDC are coming from Google and/or GCP shops (which are few and far between).
In my experience with enterprise SASS products they mostly use SAML and most companies I work for use it. At the time I was trying to switch to OAuth or OpenID but the support was severely lacking for off the shelf enterprise software, especially older stuff. ForgeRock was also giving the identity management team issues so SAML was the only option.
In the Enterprise space you will definitely want to offer both. Most enterprises still sadly leverage ADFS which is SAML2.0. Fortunately a ton of shops are adopting cloud IDaaS, so OIDC is becoming the standard (mostly because SAML for native apps is awkward)
ADFS v4 on Windows Server 2016 up allows oidc.
Everyone supports SAML, not everyone supports OIDC, and for everyone besides GSuite SAML is absolutely still the default even from the IdP side.
There's a subtle difference where the de facto best practices deployment for SAML includes cryptographic audience restriction: each IdP/RP pair generates a key just for that interaction. With OIDC, GSuite (or whatever) authenticates you to the RP. With SAML, _a SAML configuration on your GSuite install does_. You want this, because optional (largely: non-cryptographic) audience restrictions fail more than half the time and when they do they fail open.
(If you're thinking "if that's true why isn't all of this just Kerberos": you're not wrong, at least from a protocol design perspective.)
There's a subtle difference where the de facto best practices deployment for SAML includes cryptographic audience restriction: each IdP/RP pair generates a key just for that interaction. With OIDC, GSuite (or whatever) authenticates you to the RP. With SAML, _a SAML configuration on your GSuite install does_. You want this, because optional (largely: non-cryptographic) audience restrictions fail more than half the time and when they do they fail open.
(If you're thinking "if that's true why isn't all of this just Kerberos": you're not wrong, at least from a protocol design perspective.)
I like SAML because it does not involve http requests to fetch user profile (unless I'm missing something and OIDC allows that too). The whole user profile comes with the signed or encrypted payload.
As a result you can have identity provider sitting in an unreachable / private network.
Or.. Your identity provider doesn't even have to be a network service at all. We have some integration tests around systems using SAML for authentication. SAML authentication statements in test environments are generated by the test suite and fed to SPs via Selenium controlled browser.
As a result you can have identity provider sitting in an unreachable / private network.
Or.. Your identity provider doesn't even have to be a network service at all. We have some integration tests around systems using SAML for authentication. SAML authentication statements in test environments are generated by the test suite and fed to SPs via Selenium controlled browser.
The OIDC "id token" is a JWT that contains identity assertions, just like SAML would. You can go fetch the profile via HTTP, but that's mostly because major providers have quietly conceded that JWT is a nightmare, and encoded that fact in their API.
What do you mean here? Encoded in their API?
And If they don’t like JWT, why don’t they use something else?
And If they don’t like JWT, why don’t they use something else?
Major IdPs tend to provide an endpoint where you can send them the JWT, they validate it and return its contents as a plain JSON response. You're effectively trading JWT parsing for HTTPS.
They can't walk JWT back now without breaking existing apps, because parsing it yourself was advertised as an option.
They can't walk JWT back now without breaking existing apps, because parsing it yourself was advertised as an option.
SAML is more common in enterprise, it's a tad older and it does dual way authentication that OIDC can't do (the enterprise and the auth provider both sign messages and whitelist one another).
However OIDC is catching up quickly. It's supported by ADFS 2016, Azure, Google and all major IAM products now. It's also a lot easier to integrate, to use and to debug.
So both will be supported by all companies over the coming decade. Even dinosaur companies like banks that are very backward, because they follow Microsoft lifecycle.
However OIDC is catching up quickly. It's supported by ADFS 2016, Azure, Google and all major IAM products now. It's also a lot easier to integrate, to use and to debug.
So both will be supported by all companies over the coming decade. Even dinosaur companies like banks that are very backward, because they follow Microsoft lifecycle.
If you are doing enterprise software I think you’ll find OIDC support less important - I don’t think most enterprise IdPs support it.
If you want one target: you’ll want SAML to federate against ADFS. That gets you going with an open standard and targeting one of the most common IdPs.
If you want one target: you’ll want SAML to federate against ADFS. That gets you going with an open standard and targeting one of the most common IdPs.
Yep and I'll add my experience at UNC was stellar where we allowed users to self-service AD via Grouper[0] and then Ping sourced information from there. It was integrated with AWS IAM and several other services, too.
[0] https://www.internet2.edu/products-services/trust-identity/g...
[0] https://www.internet2.edu/products-services/trust-identity/g...
Thanks, this article made understanding the basics a lot clearer than other things I found recently when looking.
I haven't had to configure an IdP or SP [yet] but application we work with does use SAML to authenticate, and I only have to make small configuration to that application side.
Good to have a better, albeit very basic, understanding at least of what the Shibboleth IdP and SP are doing.
I wish that SAML would stop being referenced as Enterprise oriented and that some SPs would stop providing support for it only in their highest payment tiers. As every company nowadays have G Suite or something similar, they almost certainly have an Idp ready.
It's the only thing that most SaaS things charge for now-a-days. Slack, Dropbox, Github Enterprise, etc. They know that regulated businesses have requirements to have SSO and things like this, so they can charge out the nose for it. You can go for a very long time with paying little to nothing for most of these services until you need SSO.
Did something happen to Alice? Who is Stu? I have so many questions.
SAML is not that common an acronym. Would it have killed to start out with a definition?
The guide does do that, but, regardless: like a lot of acronyms, they've become terms of art and spelling them out is not instantly helpful to people who have used SAML before the way that say, spelling out "ICYMI" or "FYI" would be.
It's in the 3rd paragraph:
Simply put, Security Assertion Markup Language (better known as its acronym, SAML) is a protocol for authenticating to web applications. Federating identities is a common practice that amounts to having user identities stored across discrete applications and organizations. SAML allows these federated apps and organizations to communicate and trust one another’s users.
Simply put, Security Assertion Markup Language (better known as its acronym, SAML) is a protocol for authenticating to web applications. Federating identities is a common practice that amounts to having user identities stored across discrete applications and organizations. SAML allows these federated apps and organizations to communicate and trust one another’s users.
Thanks.
Generally, it is advised to provide the definition the first time you use an acronym.
Generally, it is advised to provide the definition the first time you use an acronym.
It's also an incredibly common acronym.
I have been a computer nerd (now a neuroscience scientist nerd) for decades. I didn't know SAML.
There's a totally palatable mini-SAML within SAML waiting to come out. It already exists informally: it's whatever GSuite and Okta's default metadata.xml will give you, and it summarizes to "one signature, on the outside, no encryption".
You kind of need to do SAML, though, unless you don't care about selling to companies at all. Smaller companies may or may not be able to do OIDC, but pretty much everyone can do SAML. You just want to have someone else be responsible for the SAML laundromat part (that is: ingesting gross SAML from the Internet and translating it to a friendly consistent format, which doesn't necessarily have to be SAML too). For all its flaws, Cognito fits that bill, as does Okta.