Hacker News Reader

Comment by 7bit | Hacker News Reader

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)

View on HN

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.

Reply on news.ycombinator.com