They should use YunoHost! By far one of the most impressive things about YunoHost is that a good number of the services you can run with it have directory service integration! https://yunohost.org/en/users
Why SMBs Don't Deploy SSO
21–30 of 59 posts
Re: Why SMBs Don't Deploy SSO
#22Earlier quoted context omitted.
They aren't conflating anything. OIDC or SAML should not be "taxed" extra. I do work for a number of small businesses and they can't afford the "enterprise cost" for things, so there is a shared password vault instead because there is no centralized management of users. The small businesses all have some form of SSO available, whether they are using Azure Entra ID or Google Workspaces, they have a central location fo…
I address this here https://news.ycombinator.com/item?id=40752797
To be clear, SMBs should be allowed to use Google Sign-in or Azure’s equivalent for the base pricing. I think this is table stakes for features (and security).
SAML? No chance. SMEs don’t need it and my comments above explain why vendors will never offer it.
Re: Why SMBs Don't Deploy SSO
#23Earlier quoted context omitted.
I don’t doubt that, however the vendor doesn’t get a choice over the IDP and Azure isn’t even the worst! Last week we had to create a custom Metadata XML file for a customer because their IDP doesn’t accept self-signed certificates. For a certificate we send them. That we can validate on a call with them. And it’s completely undocumented in their IDP’s docs.
That shouldn't mean that you lock the feature out for customers that do have someone that can troubleshoot it/get it up and running without help. Lock support for SSO up behind a paywall, not the actual feature.
What do you do when the customer locks themselves out? We have a good reputation for support so suddenly throwing up “sorry, no” will tank that.
This still doesn’t override positioning. Companies can make more money by charging more money for it, so they do.
Re: Why SMBs Don't Deploy SSO
#24Missing one of the key reasons: most SMBs are sharing seats (usually in violation of the license terms for the products they're using), which is rather harder with good SSO products. Per seat licensing for b2b products is lucrative, but carries the risk that you're just pushing your customers to share passwords, which is usually way worse for security.
Forced two factor auth can often solve this kind of thing though.
Why would that help? Where I work we have a central server with some phones connected that act as the 2FA devices for every service where not all employees have their own account, with an internally developed browser extension that grabs the access code from this server upon login.
Re: Why SMBs Don't Deploy SSO
#25Earlier quoted context omitted.
Forced two factor auth can often solve this kind of thing though.
Why would that help? Where I work we have a central server with some phones connected that act as the 2FA devices for every service where not all employees have their own account, with an internally developed browser extension that grabs the access code from this server upon login.
1Password and LastPass both offer this feature, too.
Don’t use LastPass though.
Re: Why SMBs Don't Deploy SSO
#26Earlier quoted context omitted.
Agreed, they’re conflating things like Google Sign-in with enterprise offerings like SAML. Companies generally give away Google Sign-in for “free” as it’s a great growth vector and gives SMEs a sort-of SAML setup for low cost. It’s also really easy for the vendor to support: you just click the button and you’re in. Granted, it lacks some of the benefits of SAML, such as permissions assignment from a central source. B…
They aren't conflating anything. OIDC or SAML should not be "taxed" extra. I do work for a number of small businesses and they can't afford the "enterprise cost" for things, so there is a shared password vault instead because there is no centralized management of users. The small businesses all have some form of SSO available, whether they are using Azure Entra ID or Google Workspaces, they have a central location fo…
> OIDC or SAML should not be "taxed" extra.
But it costs extra. That cost is passed on to the consumer.
The major hurdle is that it's expensive!
Take a typical small business SaaS - providing SSO instead of standard passwords can take more time and effort to purchase or develop and to roll out than the actual SaaS software.
Okay, lets say you buy SSO: offloading to a service is going to cost a minimum of an extra $20/month/user.
Building it? That's going to take months of developer time, not to mention that this is a high-touch/high-feedback feature, which is going to eat up the service employees time.
And then the rollout, which almost always needs a month of external consultants getting everything working correctly.
I'm doing a small SaaS, $15/user/month; if anyone has any good recommendations that aren't going to to cost me a quarter of my current sale price, I'm all ears.
Even if it's DIY, as long as I don't burn a month of dev-time just for integration/deployment.
Re: Why SMBs Don't Deploy SSO
#27Missing one of the key reasons: most SMBs are sharing seats (usually in violation of the license terms for the products they're using), which is rather harder with good SSO products. Per seat licensing for b2b products is lucrative, but carries the risk that you're just pushing your customers to share passwords, which is usually way worse for security.
Forced two factor auth can often solve this kind of thing though.
Only if you require text message based two factor. Password managers like 1Password allow you to store your OTP within them and share that + the password internally within your team
Re: Why SMBs Don't Deploy SSO
#28Earlier quoted context omitted.
I address this here https://news.ycombinator.com/item?id=40752797
To be clear, SMBs should be allowed to use Google Sign-in or Azure’s equivalent for the base pricing. I think this is table stakes for features (and security). SAML? No chance. SMEs don’t need it and my comments above explain why vendors will never offer it.
Google Sign-In is locking people to using Google's infrastructure. If an SMB has already deployed using Azure you don't get access using SSO, instead you have to fall back to username/password?
Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult.
Re: Why SMBs Don't Deploy SSO
#29Earlier quoted context omitted.
> Single sign-on (SSO) is a mechanism for outsourcing the authentication for your website (or other product) to a third party identity provider, such as Google, Azure AD, Okta, PingFederate, etc. OK, so SSO==OAuth. What TFA doesn't mention is that we're enabling surveillance capitalism by SSO. "Who owns the customers" might well be an SMB consideration.
The SMB is the customer, they should already have a single place for all their users and for authentication. SSO doesn't have to be Google, Azure, Okta, PingFederate, you can run a stand-alone instance of Keycloak for instance and have OIDC and SAML available to provide SSO functionality.
Probably more the M than the S in SMB.
I'm fond of saying "Everything is easy, when you know how to do it", but getting these security details absolutely right isn't entry-level.
Re: Why SMBs Don't Deploy SSO
#30Full disclosure: I work at WorkOS ( https://workos.com/ ), we provide SSO (among other things) as a service. I glanced through the report and it comes to the normal conclusion that SSO is hard and expensive to get right. Do SMBs focus on providing value to their customers in the problem space that they are experts at or do they spend months just getting sign-in working? Yeah I get the concern about the "SSO tax" but…
We’re current users of workos, for both the SSO and directory sync (which I love) features, but unfortunately the pricing means we have to charge our customers more for it. SSO+DS exceeds the cost of our base plan leading us to having to look at other alternatives and move away eventually :(