6 ms·

SAML (and 2FA to a lesser extent) comes with some serious support burdens on the companies offering it. There's a long tail of more or less broken SAML implemen

SAML (and 2FA to a lesser extent) comes with some serious support burdens on the companies offering it. There's a long tail of more or less broken SAML implementations on both the service and identity provider sides, provisioning issues, configuration issues, "Sally can't login on Tuesdays" issues, duplicated slightly-inconsistent data in IdP and Service side records issues... If you as a SaaS provider outsource your SAML integration to a third party provider like Okta or Auth0, the auth provider pricing is immediately on a "call us" tier, with a per-federation pricing in the low four figures for each company connecting via SAML. Let me just state that again, to have company X connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege, not counting the base enterprise tier pricing for the auth.

derefr 6y ago
Sounds like SAML needs the same "everyone gets together to make a FOSS implementation that knows about the weird quirks of all the implementations it interacts with" approach that e.g. the Samba project was founded upon.
- Saaster 6y ago
  I agree. There's a million SAML for Java/Python/Node.js/Foo libraries out there, all with a long list of issues and known cases that don't work correctly, security issues etc. but it's the wrong model in my opinion. Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.
  - chrisweekly 6y ago
    +1 Wish I had more upvotes to give. This should exist.
  - snuxoll 6y ago
    Nod to Keycloak / Red Hat SSO here, it’s my goto solution for dealing with identity these days.
  - vetinari 6y ago
    > it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta You want Keycloak - https://www.keycloak.org/ https://www.keycloak.org/ - then.
    - tasssko 6y ago
      +1 for keycloak
  - user5994461 6y ago
    If you want JWT tokens, you should be using OpenID Connect instead of SAML. There is very little reasons to use SAML in 2020, it's over complicated and has little support. OpenID Connect does 95% of the same, much better. If you want self hosted IAM solutions. The most common one is Microsoft active directory. It provides both SAML and OpenID Connect integrations out of the box as of ADFS 2016. Still, SAML requires to onboard applications individually, create keys, and stuff. It's not plug and play, it really needs humans on both sides to add a new service.
    - Saaster 6y ago
      Unfortunately the demand for SAML is 100% customer driven. As service providers, we don't control the other end (the customer's IdP/AD). Even in cases where the IdP supports both SAML & OIDC, I see almost no one choosing to use OIDC (a case of the devil you know?). The only real users of OIDC in an enterprise setting I see as a service provider, is G Suite businesses.
cactus2093 6y ago
This doesn't make sense. Login of any kind can be a tricky problem, you need to handle passwords, rate limits, email verification, password resets, etc. In most popular web frameworks there are libraries you can drop-in that handle all of this for you (like Devise in rails). There are drop-in libraries like OmniAuth (again for ruby/rails) to make handling multiple types of Oauth login simple. The same could clearly be done for SAML (and I've even implemented SAML and SCIM auth and user management for Okta before in an app, it's not difficult). The problem is that the only organizations that would make this single issue of SSO support a deal-breaker are bigger companies who can afford to be upsold, so everyone treats this as an up-sell feature. This comes at the expense of the smaller companies, who can't afford to care as much about security. The industry should be making things secure by default as much as possible, and there's a big gap here in what basically every SAAS company is doing.
- Saaster 6y ago
  Passwords, rate limits, resets, etc. are the same for everyone, and so are the problems and the solutions to those. SAML on the other hand is different for each organization. Providers pay Auth0 and the like to have developers on staff who know the pitfalls and quirks of ADFS 3.0 on Windows Server 2012 R2, so they don't have to. Dealing with a single Okta as IdP integration is like the absolute best-case scenario there is. There is also zero consistency in what actual data IdPs returns out of the box to the SPs, so now you're walking the customer's admin through setting up the proper attribute mappings, etc. I also very much disagree that SAML is a net security benefit, at least directly. It's for convenience, top-down visibility and control into what people are using, de-provisioning services, onboarding and offboarding users at scale etc. e.g. problems that only big companies have. Many SAML implementations are just as likely to add truck-sized security holes to the service provider when done poorly, and a lot of them are done poorly.
  - tptacek 6y ago
    It's a little odd to say something is not a "net security benefit" and, in the next sentence, make a powerful case for it as a net security benefit. SSO is probably the most important organization security tool there is, and a survey of tech company CSOs will average it in the top 3, if not the top 2 technology acquisitions most would make at a new firm (this is a question I've actually surveyed).
closeparen 6y ago
What about OpenID Connect? That seems a lot simpler, and also has open source implementations that aren't too intimidating.
- tptacek 6y ago
  It's not a technology problem. Integration with "foreign" SSOs is complicated no matter what protocol you use, with lots of corner cases and support costs, but these features are expensive for the same reason that single-day-turnaround short-notice flights between Chicago and NYC tend to be expensive: the people who want them have money to spend on them, and it isn't their money. That money pays for the cheap seats everyone else sits in.
  - user5994461 6y ago
    SAML is a technology problem, on top of all other problems. The messages are under specified and overcomplicated, doing incredibly obscure stuff (XML signing and canonization for one) that nobody can understand and implement. That's mainly why it's so hard to use and there is so little support from libraries. As security researcher, we could nitpick all days on security being hard, no matter the solution. It is factually true but it doesn't help developers, fact is, developers would be better off ignoring SAML and going with OIDC instead.
    - tptacek 6y ago
      1. I don't think this particular thread is a good venue to litigate SAML vs. OIDC. 2. I think the product complexity issues are, like, 95% the same whether you use OIDC or SAML. 3. I think no matter how much simplification you got from using OIDC instead of SAML, none of it is going to offset the actual reason why SSO integration is a paid feature. 4. I agree that SAML is much worse than OIDC from a protocol implementor's perspective even if I'm not so sure that it's much better from a developer's perspective, so wouldn't want to find new reasons to disagree.
      - user5994461 6y ago
Haegin 6y ago
It's a paid service, but AWS Cognito supports SAML in a similar way to Okta/Auth0 but with a much lower initial cost (you just pay a reasonable rate for what you use, not multiple thousands of dollars to get it up and running). I used it to build a SAML integration at the end of last year and have been pretty happy with it so far.
- Saaster 6y ago
  I've looked at Cognito in depth, and it seems like an abandoned service. Hundreds of open issues that got rolled into the Amplify issue tracker, with little to no response. It lacks some pretty basic SAML capabilities, like IdP-initiated logins. If your customers want to put you as an icon in their Okta dashboard or whatever, can't do it. They reported that as being "on their roadmap" in 2017. It does work for the basic use cases, so I would still consider that an better option than rolling your own for the average service provider.

derefr 6y ago

Sounds like SAML needs the same "everyone gets together to make a FOSS implementation that knows about the weird quirks of all the implementations it interacts with" approach that e.g. the Samba project was founded upon.

Saaster 6y ago
I agree. There's a million SAML for Java/Python/Node.js/Foo libraries out there, all with a long list of issues and known cases that don't work correctly, security issues etc. but it's the wrong model in my opinion. Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.
- chrisweekly 6y ago
  +1 Wish I had more upvotes to give. This should exist.
- snuxoll 6y ago
  Nod to Keycloak / Red Hat SSO here, it’s my goto solution for dealing with identity these days.
- vetinari 6y ago
  > it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta You want Keycloak - https://www.keycloak.org/ https://www.keycloak.org/ - then.
  - tasssko 6y ago
    +1 for keycloak
- user5994461 6y ago
  If you want JWT tokens, you should be using OpenID Connect instead of SAML. There is very little reasons to use SAML in 2020, it's over complicated and has little support. OpenID Connect does 95% of the same, much better. If you want self hosted IAM solutions. The most common one is Microsoft active directory. It provides both SAML and OpenID Connect integrations out of the box as of ADFS 2016. Still, SAML requires to onboard applications individually, create keys, and stuff. It's not plug and play, it really needs humans on both sides to add a new service.
  - Saaster 6y ago
    Unfortunately the demand for SAML is 100% customer driven. As service providers, we don't control the other end (the customer's IdP/AD). Even in cases where the IdP supports both SAML & OIDC, I see almost no one choosing to use OIDC (a case of the devil you know?). The only real users of OIDC in an enterprise setting I see as a service provider, is G Suite businesses.

cactus2093 6y ago

This doesn't make sense. Login of any kind can be a tricky problem, you need to handle passwords, rate limits, email verification, password resets, etc. In most popular web frameworks there are libraries you can drop-in that handle all of this for you (like Devise in rails). There are drop-in libraries like OmniAuth (again for ruby/rails) to make handling multiple types of Oauth login simple. The same could clearly be done for SAML (and I've even implemented SAML and SCIM auth and user management for Okta before in an app, it's not difficult). The problem is that the only organizations that would make this single issue of SSO support a deal-breaker are bigger companies who can afford to be upsold, so everyone treats this as an up-sell feature. This comes at the expense of the smaller companies, who can't afford to care as much about security. The industry should be making things secure by default as much as possible, and there's a big gap here in what basically every SAAS company is doing.

Saaster 6y ago
Passwords, rate limits, resets, etc. are the same for everyone, and so are the problems and the solutions to those. SAML on the other hand is different for each organization. Providers pay Auth0 and the like to have developers on staff who know the pitfalls and quirks of ADFS 3.0 on Windows Server 2012 R2, so they don't have to. Dealing with a single Okta as IdP integration is like the absolute best-case scenario there is. There is also zero consistency in what actual data IdPs returns out of the box to the SPs, so now you're walking the customer's admin through setting up the proper attribute mappings, etc. I also very much disagree that SAML is a net security benefit, at least directly. It's for convenience, top-down visibility and control into what people are using, de-provisioning services, onboarding and offboarding users at scale etc. e.g. problems that only big companies have. Many SAML implementations are just as likely to add truck-sized security holes to the service provider when done poorly, and a lot of them are done poorly.
- tptacek 6y ago
  It's a little odd to say something is not a "net security benefit" and, in the next sentence, make a powerful case for it as a net security benefit. SSO is probably the most important organization security tool there is, and a survey of tech company CSOs will average it in the top 3, if not the top 2 technology acquisitions most would make at a new firm (this is a question I've actually surveyed).

closeparen 6y ago

What about OpenID Connect? That seems a lot simpler, and also has open source implementations that aren't too intimidating.

tptacek 6y ago
It's not a technology problem. Integration with "foreign" SSOs is complicated no matter what protocol you use, with lots of corner cases and support costs, but these features are expensive for the same reason that single-day-turnaround short-notice flights between Chicago and NYC tend to be expensive: the people who want them have money to spend on them, and it isn't their money. That money pays for the cheap seats everyone else sits in.
- user5994461 6y ago
  SAML is a technology problem, on top of all other problems. The messages are under specified and overcomplicated, doing incredibly obscure stuff (XML signing and canonization for one) that nobody can understand and implement. That's mainly why it's so hard to use and there is so little support from libraries. As security researcher, we could nitpick all days on security being hard, no matter the solution. It is factually true but it doesn't help developers, fact is, developers would be better off ignoring SAML and going with OIDC instead.
  - tptacek 6y ago
    1. I don't think this particular thread is a good venue to litigate SAML vs. OIDC. 2. I think the product complexity issues are, like, 95% the same whether you use OIDC or SAML. 3. I think no matter how much simplification you got from using OIDC instead of SAML, none of it is going to offset the actual reason why SSO integration is a paid feature. 4. I agree that SAML is much worse than OIDC from a protocol implementor's perspective even if I'm not so sure that it's much better from a developer's perspective, so wouldn't want to find new reasons to disagree.
    - user5994461 6y ago

Haegin 6y ago

It's a paid service, but AWS Cognito supports SAML in a similar way to Okta/Auth0 but with a much lower initial cost (you just pay a reasonable rate for what you use, not multiple thousands of dollars to get it up and running). I used it to build a SAML integration at the end of last year and have been pretty happy with it so far.

Saaster 6y ago
I've looked at Cognito in depth, and it seems like an abandoned service. Hundreds of open issues that got rolled into the Amplify issue tracker, with little to no response. It lacks some pretty basic SAML capabilities, like IdP-initiated logins. If your customers want to put you as an icon in their Okta dashboard or whatever, can't do it. They reported that as being "on their roadmap" in 2017. It does work for the basic use cases, so I would still consider that an better option than rolling your own for the average service provider.