
SSO Wall of Shame: vendors that treat SSO as luxury feature, not core security - bdcravens
https://sso.tax/
======
jiveturkey
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. 

~~~
eropple
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.) 

------
joelennon
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. 

------
hamandcheese
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." 

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

Enterprise SSO is a great lever for price discrimination. 

------
majormjr
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. 

~~~
eropple
_> 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.