4 ms·

Visual explanation of SAML authentication (2020)

84 points by rkwz 2y ago

Teknomancer 2y ago
Nothing Hackernewsworthy here.
- sammyteee 2y ago
  Seems like Karma farming
- noisem4ker 2y ago
  This is probably related to another article about SAML from yesterday: https://news.ycombinator.com/item?id=41036982 https://news.ycombinator.com/item?id=41036982
JackSlateur 2y ago
This article is confusing in some parts. It should highlight one very interesting bit : there are no direct TCP connections between the SP and the idp. Everything flows through the user. SAML is perfectly suitable for offline services (network equipement with web frontend, for instance)
- rb12345 2y ago
  That's true for SAML2, but not SAML1 - not that anything should be using SAML1 these days.
  - honzaik 2y ago
    Well that depends on the binding right? In case you use the "artifact binding" then theres also direct communication between SP and IdP. I havent seen it in the wild and I am also no professional, but I saw it in the 2.0 standard, e.g., see https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html#5.1.3.SP-Initiated%20SSO:%20%20POST/Artifact%20Bindings|outline https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-...
    - jf 2y ago
      It’s hard enough to debug SAML as it is, I can’t imagine debugging artifact binding without having full control of both the SP and IdP.
gorkish 2y ago
> To put it simply, it’s the enterprise equivalent of the “Login with Google” or “Login with Facebook” buttons we see in apps around the internet. This is a little pedantic since the original article is from 2020 when using SAML might have still been worthwhile to invest time into... But today OpenID Connect (OIDC) is the Enterprise equivalent of these features, or rather these products from major vendors are each just their implementations of OpenID Connect. If you have the choice, you should probably be looking at OIDC instead of SAML for federated identity today.
- noddingham 2y ago
  Not saying you're wrong, I only want to add to your context by saying (in my experience) within higher education SAML is the way federated identity is done. InCommon has been around for a long time and makes it pretty easy, and Shibboleth is very popular. Have a great day!
  - gorkish 2y ago
    Being around longer or being widely implemented within some market segment is not a great reason to advocate for expanding its use. I could play devil's advocate for Kerberos or NIS just as easily as you can for SAML. It's fine if you must integrate with an existing system, but it's instant tech debt if you build a new system around it today.
    - barryrandall 2y ago
      Nothing else is suitable for multilateral, full-mesh federation yet. The OIDC multilateral federation standard hasn't been finalized or fully implemented yet, and it takes years to coordinate this kind of change in a federation.
      - gorkish 2y ago
        So use SAML for that part; education is still a big market and they have a case for delegating the responsibility of establishing and managing trust relationships to a federation provider that most b2b and b2c applications will not have. Fortunately most of these identity systems are happy to proxy for downstream OIDC/OAuth IdCs anyway, so the argument that you may not want to implement SAML IdC in your own application is still valid even in this context.
SushiHippie 2y ago
(2020)
- dang 2y ago
  Added above. Thanks!
rmrfchik 2y ago
Implemented SAML sso last month. SAML protocol and formats look so fragile and confusing. XML looks outdated in modern days and XML signatures/encryption are hard. Protocol requires deflated base64 on some step, but you can't enflate/deflate easily with cli tools. On other step only base64 is required (why?). All seems error prone and inconsistent. And I feel it can be done much much much simpler.
- noleary 2y ago
  Yeah, I won't dispute this at all. I've spent a fair amount of time forcing myself to develop expertise in SAML ... and it kind of sucks. Any chance you'd share which libraries you used, if any? I'm really trying hard to compile resources that make SAML SSO less of a nightmare, and part of that effort involves tracking down bad documentation.
  - rkwz 2y ago
    I've used Passport SAML for Node - https://github.com/node-saml/passport-saml https://github.com/node-saml/passport-saml
  - rmrfchik 2y ago
    I used onelogin's java-saml-toolkit. But at first I reproduced all process by hand until I groked it. And then I hated it. To be hones, it's not such pain in the ass.
jf 2y ago
As someone with a decade of hands-on SAML experience, I highly recommend against implementing SAML. Use OIDC instead. This article covers many of the reasons to avoid SAML: https://workos.com/blog/fun-with-saml-sso-vulnerabilities-and-footguns https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an...
- bradgessler 2y ago
  Ultimately you end up implementing whatever your customers want implemented.
  - haswell 2y ago
    As someone who has implemented SAML and OIDC at many large companies, I disagree with the general thrust of this comment. Customers usually care most about a specific outcome. If that outcome can be achieved using OIDC instead of SAML, some orgs will go with the recommendation instead of the initial request. I bring this up because most customers asking for SAML were doing so either because that’s what they were told they needed, or because it’s what they did last time. When presented with additional options and more importantly the rationale behind those options, many customers either switched gears or started working towards OIDC and changed SAML to an intermediate step along the way. Push for the best solution. Sometimes it doesn’t change anything, but it often does, and even when it doesn’t, it raises awareness of the alternatives. (There will always be some subset of orgs with immovable standards that are immune to good rationale, but these need not prevent progress elsewhere).
- brazzledazzle 2y ago
  OIDC is way easier in my experience.
- Salgat 2y ago
  The vulnerabilities are rather to easy to address as a service provider. It boils down to 1) Use Https, 2) Assert both the request expiration and that you (the service) are the intended recipient of the request, and 3) Assert the signature (using the metadata you received from the identity provider through a trusted channel). I don't know why people say SAML is complex or hard, it's just you accepting a redirect from an identity provider with an XML payload you validate against.
pisipisipisi 2y ago
Visual explanation of HTML shopping.
dang 2y ago
Recent and related: A Gentle Introduction to SAML - https://news.ycombinator.com/item?id=41036982 https://news.ycombinator.com/item?id=41036982 - July 2024 (94 comments)
nunez 2y ago
In my limited experience with SAML and OAuth, the best way to learn it is to set it up yourself, I.e. toy app to identity provider and back. It can be a flustercuck for sure.
oslis 2y ago
[dead]

84 points by rkwz 2y ago

Teknomancer 2y ago

Nothing Hackernewsworthy here.

sammyteee 2y ago
Seems like Karma farming
noisem4ker 2y ago
This is probably related to another article about SAML from yesterday: https://news.ycombinator.com/item?id=41036982 https://news.ycombinator.com/item?id=41036982

JackSlateur 2y ago

This article is confusing in some parts. It should highlight one very interesting bit : there are no direct TCP connections between the SP and the idp. Everything flows through the user. SAML is perfectly suitable for offline services (network equipement with web frontend, for instance)

rb12345 2y ago
That's true for SAML2, but not SAML1 - not that anything should be using SAML1 these days.
- honzaik 2y ago
  Well that depends on the binding right? In case you use the "artifact binding" then theres also direct communication between SP and IdP. I havent seen it in the wild and I am also no professional, but I saw it in the 2.0 standard, e.g., see https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0-cd-02.html#5.1.3.SP-Initiated%20SSO:%20%20POST/Artifact%20Bindings|outline https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-...
  - jf 2y ago
    It’s hard enough to debug SAML as it is, I can’t imagine debugging artifact binding without having full control of both the SP and IdP.

gorkish 2y ago

> To put it simply, it’s the enterprise equivalent of the “Login with Google” or “Login with Facebook” buttons we see in apps around the internet. This is a little pedantic since the original article is from 2020 when using SAML might have still been worthwhile to invest time into... But today OpenID Connect (OIDC) is the Enterprise equivalent of these features, or rather these products from major vendors are each just their implementations of OpenID Connect. If you have the choice, you should probably be looking at OIDC instead of SAML for federated identity today.

noddingham 2y ago
Not saying you're wrong, I only want to add to your context by saying (in my experience) within higher education SAML is the way federated identity is done. InCommon has been around for a long time and makes it pretty easy, and Shibboleth is very popular. Have a great day!
- gorkish 2y ago
  Being around longer or being widely implemented within some market segment is not a great reason to advocate for expanding its use. I could play devil's advocate for Kerberos or NIS just as easily as you can for SAML. It's fine if you must integrate with an existing system, but it's instant tech debt if you build a new system around it today.
  - barryrandall 2y ago
    Nothing else is suitable for multilateral, full-mesh federation yet. The OIDC multilateral federation standard hasn't been finalized or fully implemented yet, and it takes years to coordinate this kind of change in a federation.
    - gorkish 2y ago
      So use SAML for that part; education is still a big market and they have a case for delegating the responsibility of establishing and managing trust relationships to a federation provider that most b2b and b2c applications will not have. Fortunately most of these identity systems are happy to proxy for downstream OIDC/OAuth IdCs anyway, so the argument that you may not want to implement SAML IdC in your own application is still valid even in this context.

SushiHippie 2y ago

(2020)

dang 2y ago
Added above. Thanks!

rmrfchik 2y ago

Implemented SAML sso last month. SAML protocol and formats look so fragile and confusing. XML looks outdated in modern days and XML signatures/encryption are hard. Protocol requires deflated base64 on some step, but you can't enflate/deflate easily with cli tools. On other step only base64 is required (why?). All seems error prone and inconsistent. And I feel it can be done much much much simpler.

noleary 2y ago
Yeah, I won't dispute this at all. I've spent a fair amount of time forcing myself to develop expertise in SAML ... and it kind of sucks. Any chance you'd share which libraries you used, if any? I'm really trying hard to compile resources that make SAML SSO less of a nightmare, and part of that effort involves tracking down bad documentation.
- rkwz 2y ago
  I've used Passport SAML for Node - https://github.com/node-saml/passport-saml https://github.com/node-saml/passport-saml
- rmrfchik 2y ago
  I used onelogin's java-saml-toolkit. But at first I reproduced all process by hand until I groked it. And then I hated it. To be hones, it's not such pain in the ass.

jf 2y ago

As someone with a decade of hands-on SAML experience, I highly recommend against implementing SAML. Use OIDC instead. This article covers many of the reasons to avoid SAML: https://workos.com/blog/fun-with-saml-sso-vulnerabilities-and-footguns https://workos.com/blog/fun-with-saml-sso-vulnerabilities-an...

bradgessler 2y ago
Ultimately you end up implementing whatever your customers want implemented.
- haswell 2y ago
  As someone who has implemented SAML and OIDC at many large companies, I disagree with the general thrust of this comment. Customers usually care most about a specific outcome. If that outcome can be achieved using OIDC instead of SAML, some orgs will go with the recommendation instead of the initial request. I bring this up because most customers asking for SAML were doing so either because that’s what they were told they needed, or because it’s what they did last time. When presented with additional options and more importantly the rationale behind those options, many customers either switched gears or started working towards OIDC and changed SAML to an intermediate step along the way. Push for the best solution. Sometimes it doesn’t change anything, but it often does, and even when it doesn’t, it raises awareness of the alternatives. (There will always be some subset of orgs with immovable standards that are immune to good rationale, but these need not prevent progress elsewhere).
brazzledazzle 2y ago
OIDC is way easier in my experience.
Salgat 2y ago
The vulnerabilities are rather to easy to address as a service provider. It boils down to 1) Use Https, 2) Assert both the request expiration and that you (the service) are the intended recipient of the request, and 3) Assert the signature (using the metadata you received from the identity provider through a trusted channel). I don't know why people say SAML is complex or hard, it's just you accepting a redirect from an identity provider with an XML payload you validate against.

pisipisipisi 2y ago

Visual explanation of HTML shopping.

dang 2y ago

Recent and related: A Gentle Introduction to SAML - https://news.ycombinator.com/item?id=41036982 https://news.ycombinator.com/item?id=41036982 - July 2024 (94 comments)

nunez 2y ago

In my limited experience with SAML and OAuth, the best way to learn it is to set it up yourself, I.e. toy app to identity provider and back. It can be a flustercuck for sure.

oslis 2y ago

[dead]