7 ms·
SAML: A Technical Primer
- pmontra 2y agoSurprisingly the page doesn't explain the meaning of SAML. It's Security Assertion Markup Language https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...
- politelemon 2y agoThanks, I had wondered about that, though I was certain that the S didn't mean simple.
- mirekrusin 2y agoEverybody who worked with it knows that S stands for Shitty.
- nocman 2y agoOh, 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 2y ago> 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 2y agoDo 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.
- terom 2y agoRenewing the certificates seems technically pointless, but some organizations/federations require it. Rotating the keys would make some sense, but just swapping the cert for a new one issued against the same keys doesn't. It's the easiest way to fulfill those requirements, because you don't need to synchronize the metadata updates, the signatures are always valid with both the old and new cert.
- emj 2y agoMake senses, most bigger federations do not bother with this luckily for us it is just specific idps. > synchronize the metadata updates Sadly I know many implementations that do not handle key changes in the metadata in a smooth way. The two SPs I have from Adobe both require manual updating of one key per idp, making a switch pain to synchronize.
- thrwaway1985882 2y agoAll my x509s for SAML signing are self-signed, and all my self-signed certs live for 9999 days and I plan to let someone else figure out the fallout from that as I'm going to be /retired/. No one has ever really complained. Some IdPs I've integrated with use certificates that are signed by public CAs and it's always a hassle because the ergonomics around it are terrible. IMO, I think rotation is wildly useless too. It might make sense in a world where my signing certificate was decoupled from the metadata someone else has to very likely load by hand.
- davewritescode 2y agoI 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.
- Terretta 2y ago(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://www.xsplit.com/user/auth https://id.atlassian.com/login 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-fines-meta-91-million-euros-over-password-storage-2024-09-27/ https://www.reuters.com/technology/eu-privacy-regulator-fine...
- davewritescode 2y agoAs 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.
- Terretta 2y agoI'd argue you're half right. Yes, it is a good recommendation if the customers have an IT Department. But I'd argue you're missing the other half. It's an even better recommendation if the customer is using M365, Google Workspaces, or Apple Business Manager, without an IT Department, since they don't need an IT Department at all to get effectively the same benefit as SSO. After your initial setup to accept OIDC as the SaaS or PaaS, neither you nor the customer have to do an "integration" to support additional customers of Microsoft, Google, or any other OIDC provider you add. You could let your customer validate an email domain to ensure their sign-ins are theirs, but other than that, once you support OIDC with their provider, nobody has to do anything. Something on the order of 80% of SMB in the U.S. are on O365/M365 by some measures, and judging from startups here, every tech startup thinks everyone's on Google Workspaces like they are, so that's the other 80%. :-) Toss in socials if you are B2C instead of B2B, and of course Apple IDs if you are targeting users by "wallet share". You get the key benefit of SSO while your clients do not need to integrate one by one. And... > Use an open source identity provider or pay someone to do it for you. Or, don't do that effort at all, use what's baked in and just take the win.
- noleary 2y agoOh, good callout! The document is open source: https://github.com/ssoready/docs/pull/55 https://github.com/ssoready/docs/pull/55
- deleted 2y ago[deleted]
- 1270018080 2y agoSince 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 2y agoI use this one https://sptest.iamshowcase.com/ 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 2y agoFWIW 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 2y agoI'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 2y agoI'm not familiar with samltest.id and what it provided, but https://mocksaml.com/ https://mocksaml.com/ is a useful IDP testing tool.
- sharat87 2y agoVery beta and work-in-progress, https://littletools.app/saml-provider https://littletools.app/saml-provider. I intend to work on it further once my kid is… well, a little less of a toddler. :)
- cryptonector 2y ago> 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 2y agoThey 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 2y agoAh, thanks for that clarification.
- tbeseda 2y agoSAML-snark aside, this is a great primer. Definitely useful in explaining to different stakeholders what we're talking about when we talk auth.
- eqvinox 2y ago> 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 2y agoIt is not you. Also SAML is just a nigthmire.
- samllmas 2y agoMire: N. a complicated or unpleasant situation from which it is difficult to extricate oneself. Indeed.
- baq 2y agoIt’s a statement of fact…?
- fabian2k 2y agoIf the customer is using an identity provider like Microsoft Entra, is there any reason not to just use OIDC instead of SAML?
- tptacek 2y agoNo. 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 2y agoThat 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.
- noleary 2y agoYeah, 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 2y agoWe'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.
- tptacek 2y agoThis 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 2y agoIf 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 2y agoI gather that you've fired every CISO you've ever had.
- NewJazz 2y agoDo you mean chooses it over OIDC, or even when a product can only do SSO via SAML?
- ralala 2y agoOIDC 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 work professionally with Keycloak and also offer reviews of OIDC and SAML implementations.
- recursive 2y agoEveryone 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 2y agoAnyone who thinks OIDC is way easier than SAML has never implemented OIDC (or SAML).
- jcrites 2y agoCould you elaborate? I'm interested.
- pdq 2y agoI investigated both and implemented OIDC. It was difficult, but compared to the SAML and XML complexity, I'd say it was much easier.
- paulddraper 2y agoXML is marginally more complicated than JSON: attributes and namespaces. Apples to apples, is it's not much different. XSD is just as complex as JSONSchema. Verbose? Sure. But people love XML so much, they invented JS-and-XML (JSX). :shrug:
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- unscaled 2y agoThe problem is not XML by itself. XML adds a considerable amount of complexity to JSON[1] and when writing security-oriented software complexity matters quite a bit[2]. But this is still a level of complexity that can be managed. Most other XML-based protocols aren't as bad as SAML. No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signature needs to be embedded inside the XML it's signing, instead of being attached to it, like every other signature standard on the planet. [1] The added complexity is not just attributes and namespace, but also entities, DTD and processing instructions. If you want even the most basic type checking, XML schema becomes mandatory. This is important, since JSON doesn't need a schema for handling basic types, and in fact OAuth 2.0 and Open ID Connect do not rely on JSON Schema at all. [2] See the OWASP cheatsheet for all the ways accepting XML input from the internet can put your application in danger: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_... No equivalent document exists for JSON.
- mooreds 2y agoAlso worth noting that per the spec, the RelayState can only be 80 bytes. > As well in "HTTP Redirect Binding" or "HTTP POST Binding", The RelayState value MUST NOT exceed 80 bytes From https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf https://docs.oasis-open.org/security/saml/v2.0/saml-bindings... At FusionAuth, we have an open issue for this: https://github.com/FusionAuth/fusionauth-issues/issues/2467 https://github.com/FusionAuth/fusionauth-issues/issues/2467 which you can read for more details. SAML is full of these kinds of gotchas. We have an open source library which provides Java SAML bindings: https://github.com/FusionAuth/fusionauth-samlv2 https://github.com/FusionAuth/fusionauth-samlv2
- ucarion 2y agoYeah, I didn't even mention the other bindings (HTTP-Redirect, Artifact, etc.) because they're not widely supported. Only SAML's HTTP-POST binding enjoys "every IDP supports this exact protocol" status. FWIW, the for library I work on -- github.com/ssoready/ssoready -- we sidestepped this issue by simply not using SAML RelayState at all under the hood. Between the fact that it's vulnerable to attacker manipulation, and the size limits, it's not worth the pain. We just implement SAML RelayState / OAuth `state` via good old database persistence.
- mooreds 2y agoWe've found some usage of http-redirect and support it. But we've gotten requests for Artifact and other more esoteric features (encrypted assertions). It's definitely an example of the 80/20 rule. > We just implement SAML RelayState / OAuth `state` via good old database persistence. I'm not sure I understand how this helps. You still need to support the parameter so that folks can pass information through the login state (for deeplinking, among other use cases). Which means you still need to process it and therefore are committed to either being noncompliant with the spec or providing functionality that is limited to 2005 sensibilities. What am I missing?
- ucarion 2y agoWhat I'm saying is you can implement the functionality of the parameter -- i.e., arbitrary data that survives a round-trip through a SAML login -- without literally using RelayState. For example, the ID of a SAML `AuthnRequest` always gets echoed back to you in the SAML `Response`. So you can use that as an opaque identifier. You store ID/state pairs in the database when you start SAML logins, and look them back up when the assertion comes back to you. Basically, that's what we do on behalf of our customers. It's a bit more work for us to implement, but it gives SSOReady customers the "deeplinking" functionality without the weird caveats that RelayState carries.
- rast1234 2y ago[dead]
- userbinator 2y agoCryptographically authenticating SAML assertions is the most perilous part of implementing SAML The incredible overengineering of the XML signature specification is certainly to blame for this recent SAML verification vulnerability (from the same site): https://news.ycombinator.com/item?id=41586031 https://news.ycombinator.com/item?id=41586031
- ratiolat 2y agoI really wish that OIDC / Oauth(orization) would be less confusing from user experience and security perspective. What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account). SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit. SAML ain't perfect either because there's no practical way to "sign me out everywhere"
- solatic 2y agoNo reference to SCIM? OIDC is far preferable to SAML, but the last time I touched this, half the reason why customers preferred SAML was because their IdP supported SCIM but only for SAML applications.
- ucarion 2y agoThat's a very fair point! I'm going to add mention of SCIM / directory sync. I feel like it's easiest to stick that into the CISO section, since a big part of SCIM is just the deprovisioning aspect? And yeah, you're right -- Okta, for example, doesn't let you add SCIM to an OIDC application. It's unfortunate -- there's no deep technical reason you can't mix OIDC and SCIM -- but it is the world we live in.
- solatic 2y ago> a big part of SCIM is just the deprovisioning aspect? The "just" makes it sound like this is a minor point. This is a huge point. Enterprises are forced by their customers and regulators to show that terminated employees lose access immediately. There are two ways to make that happen: force everything to flow through a VPN, and SCIM. Most SaaS providers do not support IP allowlisting needed to enforce that all traffic flows through the VPN, and the only alternative to enforce that user sessions are terminated immediately is if the SaaS keeps sessions in a database and those sessions are revoked as part of SCIM. Otherwise the sessions could continue to be valid for days or even longer, presenting a risk of allowing terminated employees to wreck untold havok.
- ucarion 2y agoOh don't get me wrong at all -- deprovisioning is huge indeed! I'm not going to misleadingly edit my initial comment, and your comment is fair. I said "just" when I should have said "precisely". As in, I was already talking about how SAML interacts with "Bob from Sales got fired, probably should kick him out of the CRM". SAML gives you "Bob can't log into the CRM ever again", SCIM gives you "... and his CRM user and sessions are immediately revoked". To be clear, SSOReady also has a "SCIM made easy" API, we definitely know about and care about helping people implement SCIM: https://ssoready.com/docs/scim/scim-quickstart https://ssoready.com/docs/scim/scim-quickstart
- deleted 2y ago[deleted]