[HN Gopher] SAML: A Technical Primer
___________________________________________________________________
SAML: A Technical Primer
Author : ned_at_codomain
Score : 97 points
Date : 2024-09-27 18:38 UTC (4 hours ago)
(HTM) web link (ssoready.com)
(TXT) w3m dump (ssoready.com)
| pmontra wrote:
| Surprisingly the page doesn't explain the meaning of SAML. It's
| Security Assertion Markup Language
| https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...
| politelemon wrote:
| Thanks, I had wondered about that, though I was certain that
| the S didn't mean simple.
| mirekrusin wrote:
| Everybody who worked with it knows that S stands for Shitty.
| nocman wrote:
| 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.
| thrwaway1985882 wrote:
| > 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 and two standards-
| compliant implementations can refuse to cooperate in any
| number of ways, hair raising security decisions (XML-DSIG?!
| configurable crypto? ughh), and half-baked features (back-
| channel SLO, anyone?)
|
| It's a Lovecraftian horror that actually makes me appreciate
| JWTs.
| emj wrote:
| Do you renew the certificates used to distribute the public
| keys in SAML metadata, and if so why do you do it? I have
| had a hard time convincing people it is useless to renew
| those certs and have yet to find an implementation that
| care about those certificates.
| davewritescode wrote:
| 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.
| stouset wrote:
| Cthulhu does not appreciate being associated with this.
| Terretta wrote:
| (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.
|
| Storing user passwords yourself is a liability, indirect or
| direct: https://www.reuters.com/technology/eu-privacy-
| regulator-fine...
| davewritescode wrote:
| 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.
| ned_at_codomain wrote:
| Oh, good callout!
|
| The document is open source:
| https://github.com/ssoready/docs/pull/55
| 1270018080 wrote:
| Since we're here, I hope someone creates another all encompassing
| SP/IDP emulator like samltest.id used to until the owner stopped
| paying. That made my life so much easier as a developer when SAML
| stuff came up. No one else has come close.
| loloquwowndueo wrote:
| I use this one https://sptest.iamshowcase.com/
|
| (Well, used : in luckily no longer in charge of an IdP with a
| bespoke SAML implementation so I don't need to deal with this
| crap anymore!)
| ucarion wrote:
| FWIW back in the day, samltest.id was a dummy IDP, whereas
| sptest.iamshowcase.com is a dummy SP. You could hook these
| two up to each other and see the whole flow.
| ucarion wrote:
| I'm working on that at the instant (I wrote this article).
| Sadly the samltest.id squatter wants at least $15k, super lame.
| dummyidp.com it is!
| simonskrede wrote:
| I'm not familiar with samltest.id and what it provided, but
| https://mocksaml.com/ is a useful IDP testing tool.
| cryptonector wrote:
| > What is the point of SAML?
|
| > You care about supporting SAML because your customer wants your
| product to support SAML. This is sound reasoning on your part.
| But why does your customer want SAML support?
|
| > One click to login: why your users like SAML
|
| What? No, the users don't know about SAML.
|
| Anyways, no, users don't like SAML. OIDC has a much nicer UX.
| randlet wrote:
| They specifically said "customers" not "users" and in my
| experience (healthcare) they're correct. Being able to tell
| customers IT departments you support SSO via SAML goes a long
| way towards getting a purchase approved.
| cryptonector wrote:
| Ah, thanks for that clarification.
| tbeseda wrote:
| SAML-snark aside, this is a great primer. Definitely useful in
| explaining to different stakeholders what we're talking about
| when we talk auth.
| eqvinox wrote:
| > You care about supporting SAML because your customer wants your
| product to support SAML. This is sound reasoning on your part.
|
| Is it just me or is anybody else going 'the fuck did I just
| read?' here? It's... incredibly condescending?
| marvel_boy wrote:
| It is not you. Also SAML is just a nigthmire.
| fabian2k wrote:
| If the customer is using an identity provider like Microsoft
| Entra, is there any reason not to just use OIDC instead of SAML?
| tptacek wrote:
| No. If you can use OIDC, you should do so; in fact, if you
| can't use OIDC, you should consider rearchitecting so that you
| can. SAML is that bad.
| fabian2k wrote:
| 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 on
| premise cases, if you're in the cloud you probably use an
| identity provider that supports OIDC already.
| ned_at_codomain wrote:
| Yeah, SAML will probably fade away (slowly). And sometimes,
| you might be able to convince the customer just to use
| OIDC.
|
| But human behavior change is hard and expensive. For the
| most part, it's just easier to give the customer what
| they're asking for / what they expect, even when you know
| they're wrong.
|
| When you're trying to push an enterprise deal over the
| finish line, this is often just not a good enough reason to
| introduce friction with your buying committee.
|
| And if you have to support SAML for one stubborn customer
| eventually, you might as well support SAML for all
| customers that really want it.
| tptacek wrote:
| 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.
| bitexploder wrote:
| Lol, yeah, having SAML means putting XML parsing into
| critical security points. No thanks.
| robmccoll wrote:
| Even better: XML signatures, which are very easy to get
| wrong in both signing and verification.
| poincaredisk wrote:
| Is it that different from parsing JSON? A honest
| question, what's the difference? Billion laughs attacks
| and similar?
| tptacek wrote:
| 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.
| galdor wrote:
| Microsoft Entra having first class support for OIDC really
| helps; I remember seeing a decision diagram in their
| documentation recommending using OIDC for new projects, it
| can help negotiating. Google Workspace also works just fine
| with OIDC, and so does Okta.
|
| I've been told that the only source of problems is going to
| be companies using Shibboleth, even though there seems to
| be an OIDC plugin.
| tptacek wrote:
| 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.
| stouset wrote:
| 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.
| paulddraper wrote:
| I gather that you've fired every CISO you've ever had.
| stouset wrote:
| If I'd been in a position to, I would have. Except for Sam
| Quigley, who was the fucking best.
| tptacek wrote:
| Sam is great.
| recursive wrote:
| 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.
| paulddraper wrote:
| Anyone who thinks OIDC is way easier than SAML has never
| implemented OIDC (or SAML).
| jcrites wrote:
| Could you elaborate? I'm interested.
| pdq wrote:
| I investigated both and implemented OIDC. It was difficult,
| but compared to the SAML and XML complexity, I'd say it was
| much easier.
___________________________________________________________________
(page generated 2024-09-27 23:00 UTC)