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.
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.
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.)
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...
> 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.
That's your perspective, but let me try another one: So many SaaS products have a free/low-cost tier that allows people to get basic functionality for nothing or extremely cheaply. Users are clearly not unhappy with this and the vendor gets market share and awareness.
However, there is still a cost - and that cost ends up getting subsidised by commercial customers that have a hard need on a small number of features.
That, and the fact that even 'small' business customers these days make you fill out the same 'security review' forms that they don't understand and never read, can require a lot of hand-holding (especially if they have a procurement or legal person who wants to get their requirements in) and can take forever to do a Proof-of-Concept.
ALL of those things have costs and guess what, they end up being added to those small number of 'must have' features.
That is why a base tier might be free but suddenly you add something like SSO and the cost doubles...
> 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.
Eh, practically every service will let you 'log in with google' (or equivalent) for free if you're the sort of user who prefers that to a password manager.
SaaS companies want to charge a lower price to price-sensitive customers like bootstrapping startups, and a higher price to price-insensitive customers like big corporations; and they need some way to draw the line. And the moment you've got time to waste on things like SOC2 that drive you towards SSO - you are a price-insensitive organisation.
It’s sort of funny to me that if you go back to the timeshare computer systems of the 70s, everyone took for granted that you logged into the “network” and then the access you had depended on the permissions your user had. Today, we log into our computers and then we spend lots of time every day juggling credentials for the third party services we use. And, to make it worse, companies expect you to use various SaaS apps for day-to-day life and then block (or the apps just don’t provide) all the means to automate repetitive tasks.
Oh yeah, that's indeed a step back when you compare it like this.
Especially today, automation should be possible everywhere. There is no real reason for that. SaaS apps could just stop blocking that and everyone would be happy. Some just need to start...
"Login with X" is terrible because you don't much of a choice for X. Google is generally there but maybe I don't trust Google as a gatekeeper for everything I do on the Internet. I certainly don't trust Facebook, which tends to be the #2 spot for the "Login with X" option.
> as most security certifications require SSO as a best practice, manually syncing users from different tools won't cut it
Having taken a couple companies through SOC2, I can say that's not true.
Lots of apps being used by enterprises don't even have support for SSO at all, even if you were willing to pay the tax. Audits can't require you to use something that does not exist. Thus, the manual syncing and comparing is a frequent ritual of audit compliance (and to be fair, is something that should be done regularly even if no auditor is asking for 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.
That's not the problem though, the issue is third party apps that don't want/care to support SSO. You can't go and modify their code.
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.