Hacker News Reader

Comment by mdavidn | Hacker News Reader

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.

View on HN

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/

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?

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.

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.

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.

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"

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.

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.)

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.

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

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

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-...

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.

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.

I second this.

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'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?

> 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...

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

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.

Reply on news.ycombinator.com