zlacker

I always thought this was insane, but now I wonder if "SSO Pricing"/tax is just the "real price" and the "Base pricing" is really the new free trial? Of course the SSO/real pricing is too high, and everyone negotiates it down, but the point is I suspect the "base pricing" is just a trial teaser that's probably not sustainable for many vendors in terms of margins. I'm just guessing here, maybe someone with some inside insight from one of these vendors can advise.

>>pwarne+(OP)
I'd rather consider it "SME pricing" vs "Enterprise pricing". Typically only companies above a certain size use SSO systems, and even larger ones require it for everything. Coincidentally bigger companies are also willing to pay more, so putting a high price on SSO enables SaaS to profit from those deep pockets without pricing themselves out of the market for smaller companies.

>>wongar+kf
Schools, colleges, and universities typically have SSO but no budget or purchase authority.

>>westur+Ql
Just slap an education discount on it and call it a day. There are plenty of reasons to do that anyway, you want students to get trained on your software and use it in their formative years as much as possible.

Many go even further and just give the product away for free for educational institutions and individual students (Github, Jetbrains and Tableau come to mind as examples)

>>wongar+4p
For a small-scale implementation in a university, open core without SSO is no-go: nobody has any money or purchase authority.

>>wongar+kf
> Typically only companies above a certain size use SSO systems, and even larger ones require it for everything.

I believe it's historically grown but it's not true anymore. More companies would use it if they could as this makes your processes way more automated, easier and more secure. Also more companies take security seriously (i.e. more and more companies get ISO27001/SOC2 compliant) but just can't afford the Enterprise prices.

>>pwarne+(OP)
Great question, and as a vendor with multiple products that suffer from an SSO tax here is my $.02

As a small team we get constant requests to integrate with a customers SAML provider - eventually we just switched to https://workos.com/pricing We explain to our customers that we have a hard cost for the integration and we pass that cost to them directly. The SSO version of our product and our self signup product do the same thing the same way - it's the compliance or risk management requirement mandated by our customers that require that we sell it the way we do. In our case our SSO or Enterprise version is $125 more expensive than the self signup product. Our money is in the product itself not in the SSO.

>>wongar+kf
Things like Google Workspace et al. make it super easy to use SSO (ok a bit difficult but usable) even for smaller companies and honestly it should be used by basically everyone as a core security practice. It's annoying that companies charge out the rear end for a basic security feature. It'd be like charging to let people use 2FA/security keys.. just super stupid/arrogant.

>>bks+x21
So, uh, is that cost a “SAML is a compatibility minefield and requires constant tweaking” cost or a “we need to allocate some of our people to figure out the network setup together with yours” cost? Or something else entirely?

>>bks+x21
Great approach. Wish there would be more vendors like that. This way we wouldn't even need to talk about SSO-Tax, availability of SCIM/SAML etc.

>>wongar+kf
And of course part of why SMEs don't use it or don't use it everywhere is that suppliers make it much more expensive to do that because they insist security is only for Enterprise customers.

>>wongar+kf
Of course small companies don't use it, because it is outrageously expensive.

>>wongar+kf
That may have made sense 5-10 years ago. Todays expectations on security and convenience are very different.

Everybody deserves sso, regardless of size of company.

With the rise of micro services and DevOps, the number of applications used in an org has also exploded, adding even more reason to use SSO. Paying such big markup for every one of them is not sustainable for an SME.

>>manana+0i1
it's most likely "we couldn't be bothered to implement saml in-house or use one of the many existing libraries, so we punted it of to okta"

saml has annoyances, but it doesn't have so many annoyances that every customer needs to be a custom integration. the majority of users using saml are going to be coming from a handful of idps, typically adfs or google.

>>loik76+LV1
re: "we couldn't be bothered to implement saml in-house" This is NOT nearly as simple at that statement lays it out to be.

I am also from a SaaS vendor and we are using a 3rd party to integrate to the various SSO providers our customers have. We have not tacked on any additional cost to our customers for this as we also believe this to be baseline. But I do like the approach of at least covering costs.

For us it was not a matter of "not being bothered to implement saml in-house". We carefully considered our options. However, implementing it ourselves means we must have an in house expert on SAML and understanding the various IDPs.

It also requires someone to tightly monitoring any security issues that may appear in the wild that could impact our implementation. (We do still need to keep our eyes open, but we can leverage our vendor for help here.)

Resources required to this ourselves is a minimum of at least 1 full time engineer and someone who can be their backup, we need additional testing resources, and more. Making this roll < full time will hurt you down the road.

I'd rather our people can be focused on the problems our product is built to solve for our customers and then we can work with experts in the SSO space to guide / help us in solving that problem.

On the other hand: the 3rd party we're working with likes to come back every few months with a "Oh! We didn't know you were going to do (fill in the blank), we need to add another dollar per user per month for that."

Neither approach is perfect. But I lean towards keeping our teams as focused as possible on our product.

(PS: I have been with other orgs who've done SAML in house, and it is not simple. Don't underestimate it. It hurt, and we burned a lot of resources that could of been making our product better.)

>>detaro+1K1
That means they can live without it. Enterprises can't so they pay for it. Making customers pay for what they need is reasonable. Sure, everybody would like to have every feature for free...