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
Hey, could you please edit out the swipes in your comments? You've got some great points here and you obviously know what you're talking about, but the first bit and last bit really acidify what you're saying.

(To be clear: I'm not talking about the "SaaS vampires" bit - it's colorful language that's not targeting anyone in particular; it's flamebait, but not so bad that we'd post a scolding. It's the personal swipes in the first and last sentences that are the problem.)

If you could make your substantive points within the site guidelines, that would be the sweet spot. They're here: https://news.ycombinator.com/newsguidelines.html.