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.
SAML: A Technical Primer
31–40 of 100 posts
Re: SAML: A Technical Primer
#32Earlier quoted context omitted.
Oh, I thought it stood for: "Suffering A Massive Lot" - jk Let's just say my interaction with managing websites that used SAML was less than pleasant.
> Let's just say my interaction with managing websites that used SAML was less than pleasant. My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks. It combines all the wonderful antipatterns you can name: a protocol where near everything is optional a…
I was also the SAML person at one point in my career and I 100% agree. I used to laugh at all the HN criticisms of JWT because of how much of a nightmare SAML is.
Re: SAML: A Technical Primer
#33Earlier quoted context omitted.
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.
Lol, yeah, having SAML means putting XML parsing into critical security points. No thanks.
Is it that different from parsing JSON? A honest question, what's the difference? Billion laughs attacks and similar?
Re: SAML: A Technical Primer
#34Everyone 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.
Anyone who thinks OIDC is way easier than SAML has never implemented OIDC (or SAML).
Re: SAML: A Technical Primer
#35Surprisingly the page doesn't explain the meaning of SAML. It's Security Assertion Markup Language https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...
(S)uggest (A)lternative (M)odern (L)ogin: OIDC/Oauth2 ? The "Continue with" buttons that include Microsoft, Google, and Apple, tend to pick up most SMBs without SAML SSO headaches on either side. Like so: https://www.xsplit.com/user/auth https://id.atlassian.com/login Use an email domain restriction, and you have by and large SSO; the user can only log into your SaaS if the user is an active account at that company.…
As someone who worked at a very large SaaS company this is a good recommendation if the vast majority of your customers come from large enterprises with competent IT departments.
The problem is when you work with smaller shops that don’t have IT departments or worse bad IT departments you’re going to pay a fortune in support costs.
Use an open source identity provider or pay someone to do it for you.
Re: SAML: A Technical Primer
#36This 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.
If your CISO wants to use SAML for anything, fire your CISO.
Frankly I’d suggest the same thing about Okta but as bad as they are whatever you do to avoid them would probably be worse in practice.
Re: SAML: A Technical Primer
#37Earlier quoted context omitted.
Oh, I thought it stood for: "Suffering A Massive Lot" - jk Let's just say my interaction with managing websites that used SAML was less than pleasant.
> Let's just say my interaction with managing websites that used SAML was less than pleasant. My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks. It combines all the wonderful antipatterns you can name: a protocol where near everything is optional a…
Cthulhu does not appreciate being associated with this.
Re: SAML: A Technical Primer
#38Earlier quoted context omitted.
Lol, yeah, having SAML means putting XML parsing into critical security points. No thanks.
Is it that different from parsing JSON? A honest question, what's the difference? Billion laughs attacks and similar?
It's not just XML formatting; it's bizarro stuff like XML canonicalization and comments, and it's in a signature format. It really might be the worst mainstream cryptosystem in the entire industry.
Re: SAML: A Technical Primer
#39This 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.
If your CISO wants to use SAML for anything, fire your CISO. Frankly I’d suggest the same thing about Okta but as bad as they are whatever you do to avoid them would probably be worse in practice.
I gather that you've fired every CISO you've ever had.
Re: SAML: A Technical Primer
#40Everyone 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.
Anyone who thinks OIDC is way easier than SAML has never implemented OIDC (or SAML).
Could you elaborate? I'm interested.