SSO Wall of Shame: vendors that treat SSO as luxury feature, not core security | Hacker News Reader

SSO Wall of Shame: vendors that treat SSO as luxury feature, not core security

sso.tax

39 pointsbdcravens7 comments

nonsense.

author is complaining that the business model of others doesn't align with his need to have the tiniest possible budget and spend the bare minimum on security. boo hoo hoo. if you need sso, suck up the cost and yes, you'll have to pass it on to your customers. if you don't like the pricing model of the saas vendor you're using, how about try to build the service in-house. suddenly you'll realize how cheap even the enterprise offering is.

The author is not complaining on behalf of his own company, my dude. The author is pointing out a problem that affects everybody else who should be using SSO instead of risking their businesses with shared passwords, YOLO provisioning, and manual offboarding. And those people do not have a budget or a security team. But they probably have Google Apps.

SSO is, in 2018, just being decent about security. It is hard enough to operate securely; it is shitty behavior to make it inordinately harder for nontechnical people to do the right thing. (SCIM, however? That's something that directly benefits enterprises who have to operate in bulk.)

While supporting SSO authentication is relatively trivial via SAML2, which is supported by virtually every identity provider solution in the market, configuring this is likely a frequent point of support contact and configuration problems.

Something that is typically much less trivial is user provisioning from an identity provider. Most companies availing of SSO will require an automated user provisioning process also be in place. While the SCIM standard is pretty good, and support for it is getting better, implementations of it in identity providers are quite varied and often incomplete, not to mention poorly documented. Companies often also need to provision data that is not stored in the identity provider, so you can imagine the challenge in providing alternative solutions to make that work.

As others have already pointed out, it’s far more likely however that vendors see the requirement for SSO as a signal that a company is larger and falls more in the “enterprise” tier of pricing, allowing them to instantly provide something of value at a higher pricing point. SSO is treated much the same as things like premium support and SLAs - you charge extra because the customers who want it can afford to pay for it.

On the one hand, if you have an IT department to care about such things, you probably have the extra money to upgrade. Woe is you.

At the same time, most large-ish companies (around 100+ employees I'd guess) will also have a person whose job is to negotiate pricing with all their vendors, and the discounts can be substantial.

Maybe SaaS products should just be more transparent and say "Want to have more than 50 users? Pay us double."

There is higher support surface area, each customer's IdP is a point of integration...

Enterprise SSO is a great lever for price discrimination.

Supporting SSO is generally non trivial as each customer's SSO setup differs and requires different configuration options. I don't see issues with charging for SSO support if the application already has a secure method of authorization and the customer would like to tie authentication into their own system.

> Supporting SSO is generally non trivial as each customer's SSO setup differs and requires different configuration options.

It's SAML2 and it's 2018. Not one of the ~20 services I've integrated with our provider has received so much as an email from us about the setup process on our end.

This is a solved problem.

Reply on news.ycombinator.com