A Gentle Introduction to SAML | Hacker News Reader

A Gentle Introduction to SAML

ssoready.com

244 pointsnoleary95 comments

If given the option, go with OpenID Connect instead. Both the OIDC and SAML standards are overly complex and designed to accommodate more use cases and enterprise configurations than they should. That said, OIDC is based on OAuth 2 and does not depend on XMLDSig. That's a win, in my book. OIDC library support is good, and getting basic federated login working for common patterns is relatively easy.

Is anyone going around choosing SAML today, though? XML fever has come and gone.

Usually SAML happens because customers ask for it, OIDC isn't as widely implemented by IDPs as SAML is, so you end up implementing SAML and moving on with life.

Which IDP’s are you speaking of? All major players support OIDC now. Google, Apple, Microsoft, Amazon, login.gov.

We strongly recommend choosing OpenID Connect (OIDC) over SAML due to its modern, API-centric design and support for native mobile applications.

https://developers.login.gov/saml/getting-started/

I love to see OIDC gaining traction, though I will say that for setting up any sort of custom workforce federation, the administrative experience for OIDC applications often feels like an afterthought. I haven’t looked at all implementations, but I have recent experience federating SAML and OIDC applications in Okta, Google Workspace, and Entra ID.

Amazon also has pretty explicit preference for SAML if you want to fine-grain certain things, it's much easier if you need to connect AWS to external SSO without going through AWS SSO (which, last time I checked, had to be "global" thing for whole fleet of accounts, which makes problems when you need some sub-accounts to have different SSOs)

Where do they say that?

They say this in how you simply are limited in what you can pass and control when using OIDC Vs SAML.

SSO -> token that works only for specific role, where the specific user is supposed to be able to take many roles, is very hard to do with OIDC unless you can mangle OIDC tokens properly, whereas it's way simpler to do with SAML

I'd love to read about that more if you can share links explaining those details.

Whatever you've described sounds more like internal problems / challenges of their own implementations than anything else... especially the OpenID Connect as a delegated authentication protocol itself.

https://docs.aws.amazon.com/cognito/latest/developerguide/ex... tells me they support these IDPs 1. Facebook 2. Login with Amazon 3. Google 4. Sign in with Apple 5. Open ID Connect providers, and finally 6. SAML identity providers

If we look a bit closer, we notice that the first four use OpenID Connect under the hood. These names are fancy names for OpenID Connect with a little bit of something extra on top from Apple, Google, and so forth.

AWS SSO, ASS Cognito, and SSO (SAML/OIDC) integration in AWS IAM/STS are all three different things, with separate behaviours, problems, typical Amazon undocumented pitfalls, etc.

I second this. OIDC is much nicer and my experience using it with federated identity sources through AWS Cognito was smooth. The sad reality is that SAML is already entrenched in many enterprise environments and unavoidable.

Unless your customers are primarily in higher education/research, then just take the time to figure out SAML. Higher ed collaboration requires eduGAIN, which requires SAML (because SAML has mature multilateral federation support).

Even higher-ed&research will deploy OpenID federations. The spec is WIP: https://openid.net/specs/openid-federation-1_0.html

I believe they will eventually. But first, the spec needs to be finalized (in progress), implemented in all the libraries that need to support it (some in progress, some unaware this is coming), and deployed by all federation managers and members worldwide (planning in progress). I'm excited for OpenID multilateral federation, but it's going to coexist alongside SAML for an excruciatingly long time. Probably not as long as IPv4 or Python 2, but the better part of a decade seems plausible.

From adminstration and user perspective Oauth (Oauthorization) is alot more confusing though.

"Why is google asking me to grant access to my google drive for SAAS X, I just want to login to SAAS X via Google"

You can't compare OAuth with SAML. OAuth is authorization and comes only ever after authentication, which is OIDC.

But to respond to your critic: It is good that apps let you know that you are IN FACT not merely logging into something, but grant that app access to your Google Drive. This is a very important information! Imagine your mom signs into ClashOfClangs (a malicious clone) and the IdP would in fact NOT tell your mom that the app will have access to all her files because it may be confusing

This sounds like a complaint with Google's implementation, not with OAuth in general. The correct scopes should limit information sharing to the user's profile. All of the security and privacy concerns that necessitate an explicit user interaction apply to SAML too.

That's the thing - authentication capability is basically sideeffect of Oauth/OIDC. SAAS x can request whatever they want via OIDC and then user can either accept it or decline it. This is protocol, not google specific matter. Ask ordinary user how they understand what is being asked from them when they are trying "to log in" via OIDC/Oauth. With SAML it's the other way around - administrator chooses what is being sent to SAAS x, user does not need to decide anything nor do they get hard to understand prompts.

I'd say the main difference is that OAuth is granting the SP the ability to "do stuff" as the original user (including reading the user's profile details, as OIDC does), as opposed to SAML's approach of just sending attributes describing them.

For what it's worth, it is certainly possible for SAML SPs to flag that certain attributes should/must be released to them via their metadata, but the actual release is at the whim of the IdP and its operators. It's also possible for a SAML IdP to expose that level of detail to its end users and allow them to agree/disagree to the attribute release, although I'd be surprised if that behaviour was particularly common in practice.

The difference between OIDC and OAuth boils down to exchanging attribute assertions describing a user as opposed to the delegation of a specific set of allowed actions, as OAuth was intended to do. OIDC and SAML are basically the same thing, with OIDC being a somewhat less frightening and more modern protocol.

Reading the user's profile information _is_ the delegated action. OAuth providers were already doing this prior to OIDC but in incompatible ways. OIDC standardized how that information is requested and returned.

No, the whole point of OIDC is that permission to read your profile is not semantically the same thing as authenticated sign-on.

Should, but don't. OAuth2/OIDC implementations tend to be way more transparent about the asks being made between an IdP and SP. It can be confusing. (I agree, however, it's the right path.)

What about for an idp-initiated flow? Last time I checked on this SAML was the more logical choice.

OIDC supports Initiating Login from a Third Party: https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

Unlike SAML's "take this assertion" IdP-initiated flow, OIDC went for a "start an authentication with this IdP, for this user, and send them back here". Much, much safer.

The "OIDC way" would be an endpoint on the service provider ("relying party" in the spec) that immediately redirects into authentication. The spec does have a section describing this.

https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

IDP-initiated flows are less secure, as they cannot prevent unsolicited logins. Last time I checked Google went as far as to block this flow in their Firebase Auth product.

https://www.identityserver.com/articles/the-dangers-of-saml-...

While designed to accommodate many use-cases (which ist Not a bad thing), I'm curious what you seem overly complex? They're both pretty straight forward (except for single logout in SAML, which was never truly resolved and just left to die)

XML-DSIG is probably one of the 3 worst cryptosystems ever designed (don't ask me what the other two are, I'm just sure XML-DSIG is one of them) and the system is so complicated that a huge percentage of the deployed base of SAML systems, regardless of their language and library choices, backend onto the same ancient libxmlsec codebase.

If I could avoid doing SAML (we have so far!), I would avoid doing so as long as I could.

Agreed. XML Signatures is the worst part of SAML. It's a spec that's basically begging to be done wrong. I remain confused as to what W3C were thinking.

https://ssoready.com/blog/engineering/xml-dsig-is-unfortunat...

SAML literally predates most modern cryptography, including basic notions like the inseparability of encryption and authentication. It's a backwater that until relatively recently was confined to clanking enterprise deployments, and OIDC means it will never be modernized; the "next modernizing step" would be to simply turn it into OIDC.

> it will never be modernized; the "next modernizing step" would be to simply turn it into OIDC.

To say nothing of the fact that the standards body responsible for pushing SAML forward has shut down:

> At the request of the members (https://www.oasis-open.org/apps/org/workgroup/security/email...), the Security Services (SAML) TC has closed.

Source: https://lists.oasis-open.org/archives/security-services/2023...

(Ironically, the TLS cert for that site has also expired.)

I was so afraid of getting my SaaS's SAML implementation wrong that I decided to run Shibboleth SP, which is basically the reference SAML service provider implementation, even though that practically meant running Shibboleth SP and Apache httpd in a separate container, with a small Python WSGI app running under Apache to basically redirect back to an endpoint in the main app. (I didn't want to run the whole main app behind Apache just to support the SSO use case.) This was three years ago, and at the time we especially wanted to sell to the academic market, so I think SAML was still pretty much a requirement.

Are any of the big IdP's (Microsoft, Google, Okta, etc.) still SAML-only?

They all support OIDC, though in my experience, it’s moderately more clunky to deploy unless a “blessed” integration exists in the app store/directory. Okta provides the best experience of the three. Google Workspace admins have to drop out to Google Cloud to federate an app that’s not in the OIDC store. Entra ID falls somewhere in the middle between the two.

Why clunky? I can only talk about Microsoft, but they follow the specs and I found nothing clunky about it, because following the RFCs, everything worked exactly as expected .

Why clunky? I can only talk about Microsoft, but they follow the specs and I found nothing clunky about it, because following the RFCs, everything worked exactly as expected

> backend onto the same ancient libxmlsec codebase

If anyone is looking for SAML bindings and is using java and wants to avoid libxmlsec, my employer has an open source set of bindings for processing SAML requests: https://github.com/FusionAuth/fusionauth-samlv2

It does depend on Jakarta XML: https://jakarta.ee/specifications/xml-binding/

While the difficulty of achieving single logout (SLO) is interesting technically, we can zoom out a bit and see that SLO died because all web logout processes are pointless given how screen lock and user switching have become ubiquitous. It hasn't always been the case, but it is now. If you're letting someone use your OS session, they can auto-fill passwords from your password manager, maybe install a keylogger, who knows what else. You must lock your OS session, at which point you can keep web sessions logged in.

I agree. I was merely stating the status quo. There was no decision to quit implementing SLO, the discussion was just stopped at one point.

We have customers using SAML and ours a pain. At least one or two issues a year.

Are they config time issues or runtime? That is to say, do the issues occur when you are integrating a new customer, or are they with current customers where something changes or pops up and there's an issue?

The most common problem is they forget to upgrade their yearly certificates or mess up the deployment. Other times they don’t have their servers correctly configured to read our manifest and thus miss certificate updates from our side. Or they mess up the payload configuration so we don’t receive the principal.

I second this.

I'm curious - what is the issue with XMLDSig? I think XML is kind of a mess with the whole "billion laughs" attack, but other than that, are there problems with DSig that I don't know about?

In addition to reasons shared by other commenters, my main concern is XML Signature Wrapping.

XMLDSig APIs are not well designed. They check whether signatures in a document are valid, but signatures are not required to cover the entire document. XMLDSig APIs do not make it easy to confirm that signatures cover a specific element of interest, like saml:Subject.

An adversary can stuff a valid assertion within a forged one, and many popular SAML implementations would accept the forged assertion. This is mostly fixed now, but it's still one of those things that I must validate for myself in all new SAML service providers that I can influence.

https://www.usenix.org/system/files/conference/usenixsecurit...

https://arxiv.org/pdf/2106.10460

Try implementing XMLDsig yourself and you'll quickly learn how awful it is. Aside from the other comments mentioned in these replies, one of the horrible things about XMLDsig is that it requires you to mutate ("canonicalize") the XML that is to be signed. Then, the signature is injected into the document that was signed ... to be removed by the verifier before it has to canonicalize the document, etc, etc

> what is the issue with XMLDSig?

There's a wealth of issues, some generic and some specific to the (not so well thought out...) choices made by the SAML spec.

For starters, the XML signature spec requires canonicalization of the message (which is XML). But the message itself need not be the canonicalized message. So the SAML implementer, if they follow the spec, must process the untrusted input and canonicalize it prior to verifying the signature.

Add in that you can override just about every aspect of the signature algorithm, canonicalization details, and even what parts of the message are actually signed, and you get huge number of places where things can either go wrong or may be overlooked.

Then throw in "XML Encryption" (again with canonicalization) which could be done on the whole message or just the assertions.

Then throw in that you can sign the encrypted portion, or the unencrypted portion, or just the assertions, or encrypt the signatures, or ...

So in short, there's too many ways to do too many thing.

Which leads to a massive surface area of code if you actually follow the spec. Which leads to libraries that either do not follow the spec (e.g., ignoring encryption and just checking signatures in a known location), or think that they follow the spec but will happily ignore missing assertions or out of date certificates.

SAML sucks. But hey, it's still better than having your own passwords!

There's also detached signatures and flexible tag matching, which lead to implementations that have provide rigid schemas with semantic passes to make sure there's no place to smuggle either additional signed content to confuse verifiers, or content that will get signed that changes the message semantics. The whole thing is deeply unsound. OIDC is no great shakes, but even 10 years ago nobody would ever design a signed message scheme that looked like SAML.

Outdated certificates are actually fine with regards to SAML, oddly enough; the logic being that the trust is handled out of band at metadata level, and the certificate is just a public-key distribution method. (That applies to Shibboleth at least; other implementations may disagree.) This does of course assume that you have a means of safely keeping metadata for the other end of the trust relationship up to date. In an eduGAIN/local federation setting, that's easy enough to do with signed XML metadata feeds and daily fetches, but far less so for bilateral trust.

The XMLDSig stuff is definitely a mess though. There were definitely issues with comments in signed content allowing values to be truncated to the start of the comment, along with some similar weirdness with XML entities. And that's before any of your (entirely valid!) complaints...

Here's an interesting blog post on why SAML is insecure by design: https://joonas.fi/2021/08/saml-is-insecure-by-design/

Malleability sucks in this context.

Question: I’ve written an oidc provider that can bolt on to your existing auth. (It provides the endpoints to handle the oauth dance.)

Would this be useful to anyone?

Oidc middlewares already exist. Many authentication providers/software call it "federated login" or "social login" where they can delegate the credentials to a third party if so configured.

Maybe clarify what you can do better or different or just how exactly you're doing it and let the audience decide.

One advantage of SAML over OIDC - they standardized IDP initiated login, so you can skip the "login using..." button when sending an already logged in user to a third party system.

But the various XML canonicalization specs, XML transforms, embedding X509 certificates, all the mess they created to be able to embed signatures inside XML messages instead of just sending them separate from the assertions, is horrible to get right and will be a source of more security bugs for many, many years to come. https://www.google.com/search?q=canonicalization+CVE+SAML

> One advantage of SAML over OIDC - they standardized IDP initiated login, so you can skip the "login using..." button when sending an already logged in user to a third party system.

OIDC supports this, though it is an optional part of the standard. This is the initiate_login_uri metadata on a relying party. https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

OIDC standardadized Initiating Login from a Third Party: https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

It works very differently, but it will get the job done in a much safer way.

FWIW, the XML signature stuff in dot net just works. Once you get dot net's XML stuff itself working.

Having worked with implementing SAML for a large University-funded application, I learned more than I ever wanted to know but less than I needed to know

I regret learning nearly everything that I know about SAML.

This is exactly how it works every time I need to touch SAML. Spend two weeks with the ping identity manual, somehow get everything working, forget all about it until the next time a customer wants it :}

Ping ID is "SAML" - they actually don't comply with the spec. If you remove the Bearer element from the SAMLRequest, you should be on your way. Ask me how I know.

I see this comment often, but when I implemented SAML, the spec wasn't too unreadable... I did write my own IdP [0] instead of using something that existed though, since those were more complicated than I needed.

So maybe because I only implemented features I was using it wasn't bad. What did you struggle with?

[0] https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...

Ah yes, the dreaded University integration!

I was in charge of a SaaS offering for Academic and Public libraries years ago, and we had to add SAML functionality for the Academic side ... it was a frustrating few weeks, and I was glad when it was over.

A minor mistake: You say "An identity provider (ISP): the centralized service your user will use to authenticate". You mean "IDP", not "ISP".

(That happens to me w/ using uncommon initialisms that are one letter off from the ones I use more commonly. My muscle memory inevitably makes me type some fraction of the more common one even when I mean otherwise.)

Thanks, Evan! Fixed

When I had to figure out how to add SAML authentication to a custom application, I built a barebones, no-framework Java application[1] just to understand the webflow. A good way to understand it is to just set up your own IDP like Keycloak running locally and play around with it.

[1]: https://github.com/ataylor284/saml-example

I still can't find a convincing reason to use SAML over OIDC.

To me the SAML vs OIDC difference looks (also for the exchange format) pretty similar to the situations where XML vs JSON is used.

That is, I've always seen SAML as being very old / enterprise, and OIDC being the breath of fresh air that is JSON compared to XML.

I'd love to be proven wrong and start seeing SAML under a different lens as I don't currently see any benefit in starting a new project thst supports SAML

Just speaking practically, the biggest reason to support SAML is that customers use it.

Tons of companies still use old school Active Directory for SAML -- and aren't even quite ready to migrate to Entra (formerly Azure Active Directory).

> Just speaking practically, the biggest reason to support SAML is that customers use it.

This is a huge reason to support SAML, I agree. You can talk all day long about how OIDC is better, but if a customer or application only supports SAML, that's what needs to be implemented.

Especially since single sign-on is usually an enabler, not the whole value proposition of any application.

This only supports my point of considering SAML as being "ancient" - but I just don't know if it's true.

It's just a feeling seeing it mostly in banks and other old-school enterprises (AD plays a huge role here as you mentioned)

Not even close. Pretty much every enterprise uses it because, from an admin point of view, it does everything the customer wants. Centralised user management is pretty much mandatory for different compliance and AD and Okta meet those needs just fine.

Hell, from a user perspective, I don’t even hate the Okta SAML implementation now we have support for Yubikey enabled. Click a button, I’m in.

I certainly won't defend saml (it does suck), but saying oidc is a breath of a fresh air seems like an overstatement :).

Multilateral federation is SAML's killer app, and why higher education still uses it instead of OIDC.

I hope there will be some changes on that soon, have a look at https://openid.net/specs/openid-federation-1_0.html.

Ha, just found out you already posted the spec. Still, even if it gets published, IMO multilateral federations will migrate veeeery sloooooowly.

If you are interested in a conceptual guide to SAML, rather than a walk through which shows XML, this is still the best one I know of: https://duo.com/blog/the-beer-drinkers-guide-to-saml

Saw some simplifications in the post like where the signature goes (it can go in the assertion but also can go in the response) but appreciate this is a gentle intro, as the author states:

> I’ve omitted a lot of details here, some of which matter greatly for security reasons.

One thing about SAML is that, like HTML, the world is the best test case, and you can run into compatibility issues over and over (hyrums law and all that). My employer, FusionAuth, also supports SAML and has for years (first commit to our open source SAML bindings was in 2019) and there are still edge cases we run into.

Having dealt with the operational side of SAML implementations, as well as implementation of the spec, it would be nice if tools like this generated docs for customer setup that are app specific. This would go from initial setup to certificate updates to configuring custom attributes supported by the SP.

"SAML isn't a recipient for innovations" or something along this line was once said by Vittorio Bertocci... it's hard to add much to it.

OpenID Connect is a core for many new specs in the space, "OpenID for Verifiable Presentations" and "OpenID for Verifiable Credentials" just to name a few.

Any new company choosing one vs another, I suggest to take into account this aspect.

100%. See also my comment here about the committee improving it shutting down: https://news.ycombinator.com/item?id=41056529

I'm glad this company is building an open-source and straightforward solution for SAML integration. I struggled to find the right solution for my product and tried multiple libraries and services, including AWS Cognito.

Diving deep into OAuth and OIDC was crucial. Lesson learned: stick to the basics.

Glad the project seems useful to you :)

Any chance you'd share what went wrong with the other libraries/services? Curious to hear what mistakes we should avoid.

Sure! I think Cognito is a decent solution. However, client-app integration can be tricky, and the documentation is quite ambiguous in my opinion. The recommended implementation option is Amplify, but I had concerns because it doesn't support HTTP-only cookies.

I also experimented with NextAuth.js, but its documentation wasn't great, possibly because they're working on a new major version. I struggled particularly with supporting multi-tenancy with Microsoft AD.

I noticed that you offer SAML over OAuth. I'm curious to try that out.

Yeah, we made SAML over OAuth available mainly for ease of use in NextJS. Drop me a note (email in HN bio)if you end up trying us out. Would love to see whether we're on the right track.

In an app that's accessed through HTTPS only, is it enough to ensure the Assertions are signed?

I'm using the "WantAssertionsSigned" policy only and I'm wondering if it's secure or not

It's hard to answer questions like this in the abstract. The details matter.

If you want to understand and implement one of these in a day, check out CAS:

https://jasigcas.readthedocs.io/en/latest/cas-server-documen...

Unfortunately it’s hard to get JUST the 1.0 spec anymore And 2/3 weren’t really my cup of tea… but it’s still simpler and the basics (of honestly all these systems) is the same

I have no idea what I'm talking about but the comments in this thread have fully convinced me that this is a preferable state of affairs

You are 100% correct... SAML is one case where ignorance truly is bliss.

thank you for this

Anyone got a gentle introduction to OIDC?

A bit of self-promotion: this article I co-wrote covers both OAuth and OIDC: https://fusionauth.io/articles/oauth/modern-guide-to-oauth

I particularly like the idea of "modes" which discusses different ways of thinking about authentication and authorization based on who holds user data.

HN discussion here: https://news.ycombinator.com/item?id=29752918

Edit: updated link to HN discussion

Reply on news.ycombinator.com