6 ms·

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 enterpri

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.

ataylor284_ 2y ago
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.
christkv 2y ago
We have customers using SAML and ours a pain. At least one or two issues a year.
- adeinega 2y ago
  I second this.
- mooreds 2y ago
  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?
  - christkv 2y ago
    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.
ucarion 2y ago
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.
- MrDarcy 2y ago
  Which IDP’s are you speaking of? All major players support OIDC now. Google, Apple, Microsoft, Amazon, login.gov.
  - adeinega 2y ago
    Login.gov is pretty open about its preferences :) 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/ https://developers.login.gov/saml/getting-started/
  - p_l 2y ago
    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)
    - adeinega 2y ago
      Where do they say that?
      - adeinega 2y ago
        https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html 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.
distortedsignal 2y ago
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?
- koolba 2y ago
  > 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!
  - tptacek 2y ago
    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.
  - rb12345 2y ago
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.)
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)
seandoe 2y ago
What about for an idp-initiated flow? Last time I checked on this SAML was the more logical choice.
- mdavidn 2y ago
  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#ThirdPartyInitiatedLogin https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...
- jahewson 2y ago
  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-idp-initiated-sso https://www.identityserver.com/articles/the-dangers-of-saml-...
- jcmfernandes 2y ago
  OIDC supports Initiating Login from a Third Party: https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin 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.
nenecmrf 2y ago
[dead]
memset 2y ago
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?
- smashed 2y ago
  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.
barryrandall 2y ago
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).
- high_5 2y ago
  Even higher-ed&research will deploy OpenID federations. The spec is WIP: https://openid.net/specs/openid-federation-1_0.html https://openid.net/specs/openid-federation-1_0.html
  - rglauco 2y ago
    [dead]
  - barryrandall 2y ago
    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.
ratiolat 2y ago
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"
- mdavidn 2y ago
  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.
  - eropple 2y ago
    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.)
  - ratiolat 2y ago
    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.
    - rb12345 2y ago
      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.

ataylor284_ 2y ago

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.

christkv 2y ago

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

adeinega 2y ago
I second this.
mooreds 2y ago
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?
- christkv 2y ago
  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.

ucarion 2y ago

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.

MrDarcy 2y ago
Which IDP’s are you speaking of? All major players support OIDC now. Google, Apple, Microsoft, Amazon, login.gov.
- adeinega 2y ago
  Login.gov is pretty open about its preferences :) 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/ https://developers.login.gov/saml/getting-started/
- p_l 2y ago
  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)
  - adeinega 2y ago
    Where do they say that?
    - adeinega 2y ago
      https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html 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.

distortedsignal 2y ago

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?

koolba 2y ago
> 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!
- tptacek 2y ago
  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.
- rb12345 2y ago

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

7bit 2y ago

seandoe 2y ago

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

mdavidn 2y ago
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#ThirdPartyInitiatedLogin https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...
jahewson 2y ago
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-idp-initiated-sso https://www.identityserver.com/articles/the-dangers-of-saml-...
jcmfernandes 2y ago
OIDC supports Initiating Login from a Third Party: https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin 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.

nenecmrf 2y ago

[dead]

memset 2y ago

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?

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

barryrandall 2y ago

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

high_5 2y ago
Even higher-ed&research will deploy OpenID federations. The spec is WIP: https://openid.net/specs/openid-federation-1_0.html https://openid.net/specs/openid-federation-1_0.html
- rglauco 2y ago
  [dead]
- barryrandall 2y ago
  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.

ratiolat 2y ago

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"

mdavidn 2y ago
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.
- eropple 2y ago
  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.)
- ratiolat 2y ago
  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.
  - rb12345 2y ago
    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.