8 ms·

Beer Drinkers Guide to SAML

200 points by dedalus 7y ago

mirekrusin 7y ago
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.
- sascha_sl 7y ago
  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.
  - Edmond 7y ago
    Cheers for keycloak, title pun intended :) We use it for Solvent (https://codesolvent.com https://codesolvent.com) login to product instances and it works excellently.
    - i_haz_rabies 7y ago
      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.
      - Edmond 7y ago
        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.
      - sascha_sl 7y ago
        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.
- swiley 7y ago
  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.
  - lvh 7y ago
    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!
    - swiley 7y ago
      Why are the people who left taking corporate devices with them? Or alternatively, why are you trusting new employees phones? That’s absolute insanity.
      - lvh 7y ago
        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?
        swiley 7y ago
        > 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.)
bouke 7y ago
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?
- bilekas 7y ago
  SOAP.. Oh god I just vomited a little bit.. Bad PTSD. This is an architecture question that I don't think has 1 answer for all scenarios to be fair!
  - bouke 7y ago
    Oops, edited, thanks. I’m not looking for 1 answer perse, mostly looking for opinions.
- owenmarshall 7y ago
  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.
  - leetrout 7y ago
    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/grouper/ https://www.internet2.edu/products-services/trust-identity/g...
- spydum 7y ago
  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)
megadrive 7y ago
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.
lvh 7y ago
The biggest problem with SAML is probably XML-DSig. The spec is ridiculously complex, but unfortunately the implementations are no better. You're de facto either using libxmlsec1 or the Java stdlib. libxmlsec1 is (anecdotally) a terrifying mess of C that most SAML integration libraries desperately want you to run in-process with your server. 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.
- zeveb 7y ago
  > 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.
  - lvh 7y ago
    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 https://latacora.micro.blog/2019/07/24/how-not-to.html
  - 7y ago
trey-jones 7y ago
Did something happen to Alice? Who is Stu? I have so many questions.
- rantwasp 7y ago
  Alice did not want to be associated with alcoholic Bob.
- floatrock 7y ago
  Bob enjoys Beer, Stu is a Software User who enjoys Salesforce. Alice is just absent today.
SubiculumCode 7y ago
SAML is not that common an acronym. Would it have killed to start out with a definition?
- forgot-my-pw 7y ago
  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.
  - commandlinefan 7y ago
    It's also an incredibly common acronym.
    - SubiculumCode 7y ago
      I have been a computer nerd (now a neuroscience scientist nerd) for decades. I didn't know SAML.
  - SubiculumCode 7y ago
    Thanks. Generally, it is advised to provide the definition the first time you use an acronym.
- lvh 7y ago
  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.
m1keil 7y ago
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.
- wraithm112 7y ago
  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.

200 points by dedalus 7y ago

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.

sascha_sl 7y ago
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.
- Edmond 7y ago
  Cheers for keycloak, title pun intended :) We use it for Solvent (https://codesolvent.com https://codesolvent.com) login to product instances and it works excellently.
  - i_haz_rabies 7y ago
    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.
    - Edmond 7y ago
      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.
    - sascha_sl 7y ago
      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.
swiley 7y ago
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.
- lvh 7y ago
  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!
  - swiley 7y ago
    Why are the people who left taking corporate devices with them? Or alternatively, why are you trusting new employees phones? That’s absolute insanity.
    - lvh 7y ago
      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?
      - swiley 7y ago
        > 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.)

bouke 7y ago

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?

bilekas 7y ago
SOAP.. Oh god I just vomited a little bit.. Bad PTSD. This is an architecture question that I don't think has 1 answer for all scenarios to be fair!
- bouke 7y ago
  Oops, edited, thanks. I’m not looking for 1 answer perse, mostly looking for opinions.
owenmarshall 7y ago
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.
- leetrout 7y ago
  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/grouper/ https://www.internet2.edu/products-services/trust-identity/g...
spydum 7y ago
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)

megadrive 7y ago

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.

lvh 7y ago

The biggest problem with SAML is probably XML-DSig. The spec is ridiculously complex, but unfortunately the implementations are no better. You're de facto either using libxmlsec1 or the Java stdlib. libxmlsec1 is (anecdotally) a terrifying mess of C that most SAML integration libraries desperately want you to run in-process with your server. 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.

zeveb 7y ago
> 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.
- lvh 7y ago
  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 https://latacora.micro.blog/2019/07/24/how-not-to.html
- 7y ago

trey-jones 7y ago

Did something happen to Alice? Who is Stu? I have so many questions.

rantwasp 7y ago
Alice did not want to be associated with alcoholic Bob.
floatrock 7y ago
Bob enjoys Beer, Stu is a Software User who enjoys Salesforce. Alice is just absent today.

SubiculumCode 7y ago

SAML is not that common an acronym. Would it have killed to start out with a definition?

forgot-my-pw 7y ago
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.
- commandlinefan 7y ago
  It's also an incredibly common acronym.
  - SubiculumCode 7y ago
    I have been a computer nerd (now a neuroscience scientist nerd) for decades. I didn't know SAML.
- SubiculumCode 7y ago
  Thanks. Generally, it is advised to provide the definition the first time you use an acronym.
lvh 7y ago
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.

m1keil 7y ago

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.

wraithm112 7y ago
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.