4 ms·

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

by 7bit 2y ago

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)

tptacek 2y ago
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.
- ucarion 2y ago
  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-unfortunate/ https://ssoready.com/blog/engineering/xml-dsig-is-unfortunat...
  - tptacek 2y ago
    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.
    - mooreds 2y ago
      > 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/archives/202308/msg00003.html 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/202308/msg00004.html https://lists.oasis-open.org/archives/security-services/2023... (Ironically, the TLS cert for that site has also expired.)
- mwcampbell 2y ago
  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?
  - cjcampbell 2y ago
    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.
    - 7bit 2y ago
      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 .
    - 7bit 2y ago
      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
- mooreds 2y ago
  > 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 https://github.com/FusionAuth/fusionauth-samlv2 It does depend on Jakarta XML: https://jakarta.ee/specifications/xml-binding/ https://jakarta.ee/specifications/xml-binding/
hunter2_ 2y ago
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.
- 7bit 2y ago
  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.

by 7bit 2y ago

tptacek 2y ago

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.

ucarion 2y ago
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-unfortunate/ https://ssoready.com/blog/engineering/xml-dsig-is-unfortunat...
- tptacek 2y ago
  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.
  - mooreds 2y ago
    > 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/archives/202308/msg00003.html 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/202308/msg00004.html https://lists.oasis-open.org/archives/security-services/2023... (Ironically, the TLS cert for that site has also expired.)
mwcampbell 2y ago
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?
- cjcampbell 2y ago
  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.
  - 7bit 2y ago
    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 .
  - 7bit 2y ago
    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
mooreds 2y ago
> 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 https://github.com/FusionAuth/fusionauth-samlv2 It does depend on Jakarta XML: https://jakarta.ee/specifications/xml-binding/ https://jakarta.ee/specifications/xml-binding/

hunter2_ 2y ago

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.

7bit 2y ago
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.