Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SAML: A Technical Primer

ssoready.com

Post reply on HN
Print view View original

61–70 of 100 posts

Re: SAML: A Technical Primer

#61

Post by xnyan »

ralala wrote: post #47
tptacek wrote: post #23

This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.

OIDC is better when using the authorization code flow because it does not only rely on cryptography while validating the token. The relying party needs to talk to the IdP. This is better from a security perspective, because past vulnerabilities have shown, that implementing the cryptography right in every relying party is challenging. You can achieve similar security with SAML when using the artifact binding. Note: I…

SAML is an unfortunate a necessity in most enterprise environments. There’s almost always something, usually more than one, where SAML is the only option. I do think in 2024, everyone should also offer SAML alternatives in parallel .

Re: SAML: A Technical Primer

#62

Post by xyzzy_plugh »

tptacek wrote: post #26
fabian2k wrote: post #24

Earlier quoted context omitted.

That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for…

We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all. At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.

There's a surprisingly long line of folks who would gladly get their face ripped off for SAML. In my experience, it's worth it.

Re: SAML: A Technical Primer

#63

Post by victor106 »

ralala wrote: post #47
tptacek wrote: post #23

This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.

OIDC is better when using the authorization code flow because it does not only rely on cryptography while validating the token. The relying party needs to talk to the IdP. This is better from a security perspective, because past vulnerabilities have shown, that implementing the cryptography right in every relying party is challenging. You can achieve similar security with SAML when using the artifact binding. Note: I…

> because it does not only rely on cryptography while validating the token

When using PKCE the relying party can use JWKS to validate the token instead of talking to the IdP.

Are you suggesting that, that is somehow insecure?

Re: SAML: A Technical Primer

#64

Post by admax88qqq »

victor106 wrote: post #63
ralala wrote: post #47

Earlier quoted context omitted.

OIDC is better when using the authorization code flow because it does not only rely on cryptography while validating the token. The relying party needs to talk to the IdP. This is better from a security perspective, because past vulnerabilities have shown, that implementing the cryptography right in every relying party is challenging. You can achieve similar security with SAML when using the artifact binding. Note: I…

> because it does not only rely on cryptography while validating the token When using PKCE the relying party can use JWKS to validate the token instead of talking to the IdP. Are you suggesting that, that is somehow insecure?

They are suggesting that it’s easy to make mistakes when writing the JWT auth code as opposed to just talking to the IdP using TLs

Re: SAML: A Technical Primer

#65

Post by deathanatos »

xnyan wrote: post #61
ralala wrote: post #47

Earlier quoted context omitted.

OIDC is better when using the authorization code flow because it does not only rely on cryptography while validating the token. The relying party needs to talk to the IdP. This is better from a security perspective, because past vulnerabilities have shown, that implementing the cryptography right in every relying party is challenging. You can achieve similar security with SAML when using the artifact binding. Note: I…

SAML is an unfortunate a necessity in most enterprise environments. There’s almost always something, usually more than one, where SAML is the only option. I do think in 2024, everyone should also offer SAML alternatives in parallel .

Sure, but that would arise because you've followed the advice in the article.

If you're a relying party, and you want to integrate with Okta, Google, other OIDC-supporting IdPs … implement OIDC!

If you're on the RP side and you have to integrate with an IdP that only speaks SAML and not OIDC, well, then you're probably out of luck and just have to make the call: is it worth the business? Maybe it is. Then you implement SAML.

Re: SAML: A Technical Primer

#66

Post by deathanatos »

recursive wrote: post #31

Everyone in here is saying SAML is dead and long live OIDC. The company I work for has SAML support, but not OIDC. As far as I understand it, all the customers are asking for SAML. I've never heard a request for SAML. This is in the health care sector.

I also work in healthcare. There are some entities out there doing OIDC, but SAML is pretty popular, unfortunately.

Healthcare, as an industry, is not making decisions based on what constitutes "good engineering", for the most part. There are so many other things I'd burn to the ground that are just ancient, ass-backwards things that the rest of the industry has moved on from, but healthcare clings to. (…IPSec, for example. God I'd like to not have to do double-NAT'ing with providers who don't even understand NAT and just expect me to recognize IP addresses that are only internal to their network and never exposed to me, ever again.)

Re: SAML: A Technical Primer

#67

Post by mooreds »

tptacek wrote: post #23

This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.

Another thing to mention, as I have in the past[0], is that SAML is frozen in time and will no longer be updated. The link in that HN post has TLS errors now, but it says:

> At the request of the members, the Security Services (SAML) TC has closed.

0: https://news.ycombinator.com/item?id=41056529

There are tons of orgs that have built SSO on SAML so it won't die for a long time, but it's a frozen standard. From my understanding, it's frozen because no one wanted to put in the time to improve it.

Re: SAML: A Technical Primer

#68

Post by unscaled »

victor106 wrote: post #63
ralala wrote: post #47

Earlier quoted context omitted.

OIDC is better when using the authorization code flow because it does not only rely on cryptography while validating the token. The relying party needs to talk to the IdP. This is better from a security perspective, because past vulnerabilities have shown, that implementing the cryptography right in every relying party is challenging. You can achieve similar security with SAML when using the artifact binding. Note: I…

> because it does not only rely on cryptography while validating the token When using PKCE the relying party can use JWKS to validate the token instead of talking to the IdP. Are you suggesting that, that is somehow insecure?

PKCE (specifically the S256 method, but that's the one that you're supposed to implement in almost all cases) is by itself a cryptographic method, but there are few points to note here:

1. PKCE relies on very simple cryptography that is hard to implement incorrectly. There is only is only one protocol defined (SHA-256), and that protocol is considered safe. Allowing the "plain" protocol in the RFC was silly, but we were lucky that the RFC writers didn't go full bonkers like they did with JWT, and started digging up ancient ciphers in case someone really wants to run PKCE on a WW2 vintage Enigma machine. In short, PKCE has no weird or old cryptography.

2. PKCE is not considered mandatory or even recommended for confidential clients prior to OAuth 2.1 (which is still a draft). It is rarely implemented in these cases.

3. You cannot use JWKS for PKCE. I believe you are confusing PKCE with the ID Token, but the GP was specifically talking about the Authorization Code flow, where the ID Token doesn't really matter. If you're using that flow an unfortunate piece of over-engineered industrial waste[1], but if you're using the Authorization Code flow it doesn't matter: even if the ID Token is completely broken, it cannot hurt you, since you must have a correct authorization code to get it in the first place.

4. Even if PKCE itself gets broken somehow (the main risk being an IdP that allows downgrade attacks), this only makes the protocol vulnerable to CSRF on confidential clients. Only on public clients that rely on custom URL schemes (such as native apps), this can lead to a more serious exploit.

[1] Sadly, this is coming from the same people who wrote the PKCE spec. On one hand they think your system might be too constrained to support SHA-256, so we need to add the "plain" algorithm, but on the other hand, they make RSA signatures (including SHA-256!) a mandatory part of the Open ID Connect spec through this totally unnecessary token.

Re: SAML: A Technical Primer

#69

Post by tptacek »

xenophonf wrote: post #59
tptacek wrote: post #23

This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.

> just use OIDC OIDC doesn't scale, and OIDC Federation is still in draft. SAML Federation is mature with wide support and good discovery UX thanks to SeamlessAccess. SAML has a variety of standard attribute bundles, entity categories, frameworks, and profiles covering important integrations, e.g., identity assurance. These are slowly being defined in (or ported to) OIDC. I like OIDC and think highly of the people wo…

I don't know a lot of security engineers that agree, and while (as a SAML implementor) I have my own opinion, "don't do new SAML implementations" is mostly me parroting what I think is the consensus.

I think... it probably is as cut and dry as I'm suggesting.

Re: SAML: A Technical Primer

#70

Post by tptacek »

ralala wrote: post #55
tptacek wrote: post #52

Earlier quoted context omitted.

Most obviously, the precarity of XMLDSIG.

This is where artifact binding can greatly increase the security…. Browser sends artifact to RP, RP fetches assertion from IdP via HTTPs, afterwards verifies the signature. Signature verification is not implemented correctly? The attacker still needs to break HTTPS…. And then you would have a big problem anyway.

A common pattern of SAML vulnerability is one that allows logins from one org access to resources of another org, which is not mitigated by trusting IdP's.
Post reply on HN