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
This reads like a something written from the perspective of somebody involved in the creation of a SaaS product, but that has never actually been involved in buying one.

To summarise your comment, my notes in parentheses:

* This isn’t as good as SSO (I’m sure that OP knows that).

* It doesn’t meet your requirements (I trust OP to know what their requirements are, and I myself have been in situations where this would be useful).

* Implementing SSO from scratch isn’t hard. (That doesn’t mean bupkis to someone that wants to use SSO functionality of a SaaS product that they are subscribed to. Also, I’m highly skeptical of any SSO implementation that was ‘easy’ to write).

* SSO’s usefulness is limited without proper access controls within the product (…yes?)

* Only ‘enterprise’ customers want/need SSO. (This is a clear example of uninspired SaaS companies drooling over the white elephant ‘enterprise’ customer: someone with a bunch of money, that will pay for your value-add crap without batting an eyelid. I’ve worked in plenty of settings that I wouldn’t call “enterprise”, but that would’ve benefited highly from SSO. Unfortunately SSO is always locked behind AT BEST a significantly higher seat cost, but usually with a very high floor, and often behind a “contact sales” funnel. Replace “enterprise” with “business”, because that’s the reality. Then…look at your (probably B2B) SaaS product’s package differentiations, and tell me that you aren’t screwing people).

* Enterprise plans usually come with way more than just SSO (Yes! half the point is that most people don’t want this stuff! It’s mostly shovelware to make it not look so egregious to pay so much more for SSO! You’re right! SSO is a small part of that! So why force people to buy the rest of the stuff if they don’t want it? Oh, that’s right, because you’re lining up behind the other SaaS vampires to prey on basically any organisation of more than 5 people that wants have their ducks in a row).

It really just sounds like you’re trying to justify your employer’s crappy yet common sales tactics, and we’re just coming along for the ride.

>>KyeRus+rq
I'm my own employer, and I'm usually way more passionate about writing features in my problem domain than implementing SSO & other enterprise features, which BTW are not in any way a differentiator or usable as a sales tactic. It's just that without SSO you won't be able to sell any enterprise software anymore, at least if it's a web-based product. SSO isn't something that SaaS startups try to push on enterprises, it's rather the inverse.

Our customers, which are often regular people working for BigCo that try to solve their own work problems aren't overly fond of SSO either, they just need to implement it as a policy since most companies enforce it from the top. You can debate whether that makes sense but if you're running an organization with tens of thousands of employees then not having a unified authorization & access control solution in place is regarded a bad practice, and for very good reasons. SSO solves many real problems that were extremely painful before, where you'd have either no common authorization at all or would need to write LDAP integrations. For all the flak it gets, SSO is orders of magnitude easier to implement and better at enforcing security best practices.

And the reason most SaaS vendors don't put price tags on their website is that it's extremely hard to do pricing as software integration in most enterprise environments still requires a ton of consulting and bespoke development, so if you e.g. put a 10.000 USD price tag on that you're setting yourself up for failure as you typically won't be able to estimate the integration cost until you've talked to the customer and assessed their needs and their IT environment. Deployments have become better as tools like Docker and Kubernetes become more ubiquituous, but it will still take many months to years in most places.

And writing an SSO implementation isn't difficult thanks to many libraries that are available and that do the heavy lifting. In the end SAML-based SSO isn't much more than reading a metadata document, forwarding a user to an external URL, parsing the response document and verifying its signature and generating a local access token for the user. The complexity lies somewhere else, e.g. in the role mapping and in working around the quirks of the specific SSO environment you encounter. Customers e.g. love to use non-standard fields to map organizations, users will often have inconsistent role and organization mappings, the customer wants to add some additional metadata field etc. etc. etc...