4 ms·

Not really. Especially if both systems are already in place and they just need to turn it on. The swipe system should be a very minor or zero part of the rent,

Not really. Especially if both systems are already in place and they just need to turn it on. The swipe system should be a very minor or zero part of the rent, not double.

throw10920 2y ago
> Not really. Especially if both systems are already in place and they just need to turn it on. This isn't a valid analogy to SSO. SSO doesn't just cost extra to develop (which in itself is a valid reason for charging more), but it costs extra to maintain - you can find several other comments in this thread alone talking about how difficult it is to support SSO from a technical/customer service perspective. People are expensive - both when writing code, and when supporting it.
- langcss 2y ago
  This is the same for all features no? If customers need additional human support for SSO then that can be charged separately. In my experience most customers can get it working with no hassles or have hassle but their own tech resources figure it out. Few need to get support. As a feature it is probably less work to implement and maintain than the simplest of product features. YMMV if you have a complicated integration but if you just want to sign people in and assign them to a group for security it isn't hard. Maybe we are talking cross purposes? I am talking about SSO with SAML and IdP rather than OAuth. I suspect the reason for the SSO Tax is it is an predictor of "does this customer have money". Customers with more money to spend and absolutely need SSO to meet their policies will overlap alot.
  - throw10920 2y ago
    > If customers need additional human support for SSO then that can be charged separately. Aren't the majority of enterprise contracts negotiated with support included? I thought that that was one of the main value adds for medium-to-larged sized companies.
    - langcss 2y ago
      I think so. Even more reason to not need SSO tax ;-)
happyopossum 2y ago
That’s never the case though - you don’t just “turn on” SAML integration. It’s a huge support burden, with every SAML provider requiring unique (and frequently updated) documentation, testing, and support enablement. And that’s assuming you don’t include auth in any of your release testing cycles (which you should). If you do, now you’re including unit and end to end testing with Okta, MS, Google, OneLogin, Jumpcloud, Ping, and anyone else your customers choose to use. Don’t forget to run those tests with both SAML and OIDC. And make sure the engineers who know how to co figure each of those vendors’ SSO systems are aligned with your testing schedules. Also don’t forget that you need dev/partner accounts with all of those vendors. And they’ll need to be active when you test.

Not really. Especially if both systems are already in place and they just need to turn it on. The swipe system should be a very minor or zero part of the rent, not double.

throw10920 2y ago

> Not really. Especially if both systems are already in place and they just need to turn it on. This isn't a valid analogy to SSO. SSO doesn't just cost extra to develop (which in itself is a valid reason for charging more), but it costs extra to maintain - you can find several other comments in this thread alone talking about how difficult it is to support SSO from a technical/customer service perspective. People are expensive - both when writing code, and when supporting it.

langcss 2y ago
This is the same for all features no? If customers need additional human support for SSO then that can be charged separately. In my experience most customers can get it working with no hassles or have hassle but their own tech resources figure it out. Few need to get support. As a feature it is probably less work to implement and maintain than the simplest of product features. YMMV if you have a complicated integration but if you just want to sign people in and assign them to a group for security it isn't hard. Maybe we are talking cross purposes? I am talking about SSO with SAML and IdP rather than OAuth. I suspect the reason for the SSO Tax is it is an predictor of "does this customer have money". Customers with more money to spend and absolutely need SSO to meet their policies will overlap alot.
- throw10920 2y ago
  > If customers need additional human support for SSO then that can be charged separately. Aren't the majority of enterprise contracts negotiated with support included? I thought that that was one of the main value adds for medium-to-larged sized companies.
  - langcss 2y ago
    I think so. Even more reason to not need SSO tax ;-)

happyopossum 2y ago

That’s never the case though - you don’t just “turn on” SAML integration. It’s a huge support burden, with every SAML provider requiring unique (and frequently updated) documentation, testing, and support enablement. And that’s assuming you don’t include auth in any of your release testing cycles (which you should). If you do, now you’re including unit and end to end testing with Okta, MS, Google, OneLogin, Jumpcloud, Ping, and anyone else your customers choose to use. Don’t forget to run those tests with both SAML and OIDC. And make sure the engineers who know how to co figure each of those vendors’ SSO systems are aligned with your testing schedules. Also don’t forget that you need dev/partner accounts with all of those vendors. And they’ll need to be active when you test.