zlacker

>>mathia+(OP)
How does that solve the problem SSO typically solves? It seems you're trying to replace it by syncing users from different tools? That seems worse than SSO and is unlikely to be acceptable, as most security certifications require SSO as a best practice, manually syncing users from different tools won't cut it. Also, implementing SAML-based SSO from scratch isn't that difficult, I did it for our enterprise product and it's barely 500 lines of code. However, we had a nice role-based access management in our tool already, so adding SSO was just a matter of mapping SSO data to our internal role models. That part is usually what causes most effort, i.e. fine-grained access control for different parts of your application, SSO just provides the identity and group management layer that you can use as a basis for that.

Apart from that, SSO is just a handy feature that non-Enterprise customers usually don't need while Enterprise customers do, so it's ideal for differentiating customers. That said an Enterprise edition contains much more than SSO in many cases, e.g. audit logging, containerized deployments, extensive support, etc.. That's what you pay for with an Enterprise offering, the SSO feature is just a small part of that.

>>ThePhy+Gj
> SSO is just a handy feature that non-Enterprise customers usually don't need while Enterprise customers do

This isn’t true, IMO, most people just don’t realize there’s an alternative to one user account per service. We’ve convinced non-enterprise users to use an objectively bad solution of password managers because every SaaS service hides their SSO option behind enterprise pricing.