5 ms·

At a past company, we had discussion about this exact topic. Despite wanting to offer SSO on a free/low-tier, we simply could not justify it. SSO was by far ou

At a past company, we had discussion about this exact topic. Despite wanting to offer SSO on a free/low-tier, we simply could not justify it. SSO was by far our most expensive feature to support. It was the single largest bucket of support requests and a significant percentage of those requests required an engineer to get on a call with a customer (and their IT team). We evaluated building better product/tooling to self-serve, but we realized that it likely wouldn’t solve the issue. SSO is security critical, so anytime things go wrong people throw their hands up and say “nope, I’m not the one that’s going to hurt my company”. They really just needed someone on our end to give them confidence. Don’t get me wrong, we fixed many of the biggest issues - but there’s an endless supply of crap that can go wrong.

Aurornis 1y ago
> SSO was by far our most expensive feature to support. It was the single largest bucket of support requests and a significant percentage of those requests required an engineer to get on a call with a customer (and their IT team). I can confirm this is how it goes. You can theorize about how SSO should be straightforward or self-serve, but in practice the SSO feature creates a disproportionately large support and engineering burden. When you’re dealing with SSO support for a customer buying 100 expensive seats it can be easy to justify. When you’re debugging the SSO for some small shop with 3 licenses who will churn suddenly the moment their lead noticed a shiny new competitor, it’s not worth it.
lousken 1y ago
Sorry but that just means the feature is difficult to use on either side, so that would be at least 50% of your problem anyway. Provide good docs? How about that? Every time someone has a problem create docs for it and after some time those questions will reduce significantly. edit: also, for people implementing this the first time it should be obvious what happens when 1) they create a new account in your app (local) 2) if they create a new account within SSO provider 3) what happens with existing accounts during setup and if current users will be migrated over or not (or if they can use both singins)
- fabian2k 1y ago
  Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities. And customers don't necessarily read the docs, or even if they do they don't configure everything correctly. And we're not even at customization that is particular to the customer. How to represent that in their identity provider and how to get your application to follow that in the way the customer expects.
  - lousken 1y ago
    > Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities. no, you just provide the most used ones, once you have like top 5, that helps a lot > And customers don't necessarily read the docs, or even if they do they don't configure everything correctly. so just like with any other feature, really also you should be improving docs, if they are not clear, make them clearer it's basic sysadmin stuff, eventually 90% will understand and 10% will ask regardless of what you do, so just embrace yourself for those occasions
    - stackskipton 1y ago
      >also you should be improving docs, if they are not clear, make them clearer I've written the docs with a tons review and feedback, this saying comes to mind: "Nothing is foolproof to a sufficiently talented fool" There are no more sysadmins at most companies, it's just desktop support and maybe Office365 admin who was desktop support but got promoted because they were elite ClickOps. Powershell/Terraform, that's for those DevOps people over there and they want nothing to do with us.
      - lousken 1y ago
        mentioned those 10% sufficiently talented ;) not sure about US, but here in center of europe we still have sysadmins and not many devoops people
kmeisthax 1y ago
Are there specific ID providers or protocols that are particularly difficult to support? Would it make sense to bracket out SSO further between: - Providers that actually implemented SAML correctly and that we can support without being buried in tickets - Shitty Enterprise Grade™ systems you wouldn't dare to use voluntarily - Oh god you actually wrote your own IDP what is this cursed mess

Aurornis 1y ago

> SSO was by far our most expensive feature to support. It was the single largest bucket of support requests and a significant percentage of those requests required an engineer to get on a call with a customer (and their IT team). I can confirm this is how it goes. You can theorize about how SSO should be straightforward or self-serve, but in practice the SSO feature creates a disproportionately large support and engineering burden. When you’re dealing with SSO support for a customer buying 100 expensive seats it can be easy to justify. When you’re debugging the SSO for some small shop with 3 licenses who will churn suddenly the moment their lead noticed a shiny new competitor, it’s not worth it.

lousken 1y ago

Sorry but that just means the feature is difficult to use on either side, so that would be at least 50% of your problem anyway. Provide good docs? How about that? Every time someone has a problem create docs for it and after some time those questions will reduce significantly. edit: also, for people implementing this the first time it should be obvious what happens when 1) they create a new account in your app (local) 2) if they create a new account within SSO provider 3) what happens with existing accounts during setup and if current users will be migrated over or not (or if they can use both singins)

fabian2k 1y ago
Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities. And customers don't necessarily read the docs, or even if they do they don't configure everything correctly. And we're not even at customization that is particular to the customer. How to represent that in their identity provider and how to get your application to follow that in the way the customer expects.
- lousken 1y ago
  > Part of the problem is that every identity provider is different. So you'd have to provide docs for every single one of them and their particularities. no, you just provide the most used ones, once you have like top 5, that helps a lot > And customers don't necessarily read the docs, or even if they do they don't configure everything correctly. so just like with any other feature, really also you should be improving docs, if they are not clear, make them clearer it's basic sysadmin stuff, eventually 90% will understand and 10% will ask regardless of what you do, so just embrace yourself for those occasions
  - stackskipton 1y ago
    >also you should be improving docs, if they are not clear, make them clearer I've written the docs with a tons review and feedback, this saying comes to mind: "Nothing is foolproof to a sufficiently talented fool" There are no more sysadmins at most companies, it's just desktop support and maybe Office365 admin who was desktop support but got promoted because they were elite ClickOps. Powershell/Terraform, that's for those DevOps people over there and they want nothing to do with us.
    - lousken 1y ago
      mentioned those 10% sufficiently talented ;) not sure about US, but here in center of europe we still have sysadmins and not many devoops people

kmeisthax 1y ago

Are there specific ID providers or protocols that are particularly difficult to support? Would it make sense to bracket out SSO further between: - Providers that actually implemented SAML correctly and that we can support without being buried in tickets - Shitty Enterprise Grade™ systems you wouldn't dare to use voluntarily - Oh god you actually wrote your own IDP what is this cursed mess