3 ms·

Everyone 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 customer

Everyone 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 ago
Anyone who thinks OIDC is way easier than SAML has never implemented OIDC (or SAML).
- jcrites 2y ago
  Could you elaborate? I'm interested.
- pdq 2y ago
  I 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 ago
    XML 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 ago
      The 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.
      - osigurdson 2y ago
        XML=JSON=YAML=TDL (tree describing language)
        deleted 2y ago
        [deleted]
        sam_lowry_ 2y ago
        Not really.
        osigurdson 2y ago
        But pretty close.
      - paulddraper 2y ago
        > 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 Huh? > 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. You are correct that is the hardest part of SAML, but to be clear, there's a SignatureValue element that is separate from SignedInfo. And you can use a library to sign. I don't see many implementing their own JWT signatures either.
- cyberax 2y ago
  I have implemented the server-side of OIDC to support the single sign-on for AWS account management. It was a breeze, around 200 lines of Go code. I tried that with SAML (back then, it didn't require kludgy X.509 thumbprint management in AWS), and I ran away crying after a couple of days trying to understand why it fails.
deathanatos 2y ago
I also work in healthcare. There are some entities out there doing OIDC, but SAML is pretty popular, unfortunately. Healthcare, as an industry, is not making decisions based on what constitutes "good engineering", for the most part. There are so many other things I'd burn to the ground that are just ancient, ass-backwards things that the rest of the industry has moved on from, but healthcare clings to. (…IPSec, for example. God I'd like to not have to do double-NAT'ing with providers who don't even understand NAT and just expect me to recognize IP addresses that are only internal to their network and never exposed to me, ever again.)
surfpel 2y ago
I implemented SAML SSO for Django at my prev company about a year ago. I procrastinated for a few months and by the time I implemented it, the whole company started retiring it in favor of OIDC. I was about to do that too but I quit right before. Looked much easier to do OIDC with Django. Seemed like SAML was on the way out in general, even Django extensions weren’t prioritizing it and information resources for implementing SAML weren’t great. Long live OIDC I guess.

paulddraper 2y ago

Anyone who thinks OIDC is way easier than SAML has never implemented OIDC (or SAML).

jcrites 2y ago
Could you elaborate? I'm interested.
pdq 2y ago
I 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 ago
  XML 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 ago
    The 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.
    - osigurdson 2y ago
      XML=JSON=YAML=TDL (tree describing language)
      - deleted 2y ago
        [deleted]
      - sam_lowry_ 2y ago
        Not really.
        osigurdson 2y ago
        But pretty close.
    - paulddraper 2y ago
      > 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 Huh? > 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. You are correct that is the hardest part of SAML, but to be clear, there's a SignatureValue element that is separate from SignedInfo. And you can use a library to sign. I don't see many implementing their own JWT signatures either.
cyberax 2y ago
I have implemented the server-side of OIDC to support the single sign-on for AWS account management. It was a breeze, around 200 lines of Go code. I tried that with SAML (back then, it didn't require kludgy X.509 thumbprint management in AWS), and I ran away crying after a couple of days trying to understand why it fails.

deathanatos 2y ago

I also work in healthcare. There are some entities out there doing OIDC, but SAML is pretty popular, unfortunately. Healthcare, as an industry, is not making decisions based on what constitutes "good engineering", for the most part. There are so many other things I'd burn to the ground that are just ancient, ass-backwards things that the rest of the industry has moved on from, but healthcare clings to. (…IPSec, for example. God I'd like to not have to do double-NAT'ing with providers who don't even understand NAT and just expect me to recognize IP addresses that are only internal to their network and never exposed to me, ever again.)

surfpel 2y ago

I implemented SAML SSO for Django at my prev company about a year ago. I procrastinated for a few months and by the time I implemented it, the whole company started retiring it in favor of OIDC. I was about to do that too but I quit right before. Looked much easier to do OIDC with Django. Seemed like SAML was on the way out in general, even Django extensions weren’t prioritizing it and information resources for implementing SAML weren’t great. Long live OIDC I guess.