7 ms·

Why SMBs Don't Deploy SSO

38 points by kl4m 2y ago

Roguelazer 2y ago
Missing 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.
- revicon 2y ago
  Forced two factor auth can often solve this kind of thing though.
  - hananova 2y ago
    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.
    - scott_w 2y ago
      1Password and LastPass both offer this feature, too. Don’t use LastPass though.
    - plorkyeran 2y ago
      Or more primitively than that, I've seen small offices have an old shared phone with a bulging battery that's used for 2fa (or even just having it attached to someone's personal phone and just asking them for the code when you need to log in).
    - neilv 2y ago
      Impressive. Is the reason for this "2FA server" to circumvent per-seat licensing, or some other reason?
      - scott_w 2y ago
        It’s also because there might only be one super admin account allowed, which also needs to be the most secure. But you don’t want the person with the 2FA codes to wander off with them one day!
  - modo_ 2y ago
    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
    - noprocrasted 2y ago
      I've set up multiple times a phone-to-Slack proxy for this exact reason. In my case it was a VoIP number, but if that's blocked, Android has many SMS-to-webhook apps and even entry-level industrial LTE routers generally have this feature so you can use a real SIM card.
dswalter 2y ago
I'm largely in favor of SSO, but it's not without its downsides, going beyond capital costs: SSO can also be implemented in a way that introduces an onerous latency tax when using services.
- dijit 2y ago
  Because of proxying? SSO (SAML/OAUTH2) are usually implemented with a token, like normal auth. There should be no penalty aside from login.
- scott_w 2y ago
  I’m not sure about that beyond login. That said, Okta has gotten reasonably good when you have a Yubikey, so I’ve stopped complaining about it.
- justin_oaks 2y ago
  > SSO can also be implemented in a way Unless you're more specific, I'm going to assume that that "way" is the wrong way. Initial login shouldn't add more latency than a couple web redirects. The authentication token/assertion should be validated only once and not be needed until it expires or the user logs out.
sloankev 2y ago
https://sso.tax https://sso.tax
- smitty1e 2y ago
  > 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.
  - scott_w 2y ago
    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. But this is also why those features are so pricey: enterprise organisations derive the most benefit from it, and have a team dedicated to its maintenance.
    - ArchOversight 2y ago
      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 for users, but the cost is prohibitive for most products to get the upgrade to get access to SAML or OIDC for SSO.
      - scott_w 2y ago
        I address this here https://news.ycombinator.com/item?id=40752797 https://news.ycombinator.com/item?id=40752797
scott_w 2y ago
As someone who works on our SSO implementation, the reason for the SSO tax is twofold: - Positioning: it’s seen as an enterprise product so attracts enterprise pricing - Support: it’s genuinely a high touch feature which lots of customers fuck up all the time in the same way and always needs support and engineering help. Documentation for those issues? We have it, it doesn’t stop the support requests coming in. I was looking at a request this morning where the error message is coming from Azure itself and clearly says “this is not configured correctly.” The request hasn’t even reached our systems yet! Until SSO is as plug n play for users as Google Sign-in, SSO will continue to attract a high price point. And I’ll continue to push back on attempts internally to democratise it.
- ArchOversight 2y ago
  I feel like a lot of the issues are also due to Azure making it vastly more difficult than necessary to configure OIDC/SAML and get the right information over to the SP.
  - scott_w 2y ago
    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.
    - ArchOversight 2y ago
      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.
      - scott_w 2y ago
        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.
daft_pink 2y ago
I don’t want to bother with vendor lock in and an additional single point of failure. That’s why I don’t use sso
- dijit 2y ago
  SAML and OAUTH2 are open standards, and single-point of failure generally means a single server or host- but I take the point that having a centralised service becoming unavailable would affect new logins. However, you're rather naive if you think this is what would keep you locked in, changing authentication host (usually tied to mail, calendars, chat) is... difficult, and changing the SSO stuff is one of the easiest parts of the migration speaking from experience. SSO is quite useful when you have onboarding and offboarding, remembering every place a person had an account with access to critical company data is horrible and trying to convince people to not share passwords between them is horrible too- a breach in one, in those cases, is a breach in all.
tqwhite 2y ago
I've implemented SSO in a small business context. It's insanely hard. Absolutely not worth it. Until Apple and Microsoft find a way to a LetsEncrypt-type comprehensive mission, it's out of the question. And, since Azure 'Entra' is a Microsoft profit center, no easy to use tool will be in their interest.
jameskilton 2y ago
Full disclosure: I work at WorkOS (https://workos.com/ 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 unfortunately SSO isn't free. Someone is paying for it somewhere, be that implementation, outsourcing to a service, and/or maintenance and customer support for the live of the product. That said there are a lot more services and libraries out today that try to make this easier such as https://www.passportjs.org/ https://www.passportjs.org/ (which WorkOS sponsors).
- ArchOversight 2y ago
  SMB's are the customers of products that offer SSO but only at the enterprise level. CISA is arguing that the enterprise level of the software SMB's need to operate is too expensive and thus SMB's don't end up buying a license tier that includes the ability to hook into their already existing SSO (likely Azure Entra ID or Google Workspaces, sometimes Okta). The SMB's already have SSO, they just don't enable it for the SaaS products they buy because of the price.
- Dachande663 2y ago
  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 :(
  - tatersolid 2y ago
    Same here. As a SaaS provider to SMB, all the major auth vendors (Okta, Ping, WorkOS, etc.) are ludicrously overpriced and would require us to double our own pricing. Except Entra ID for customers, which is fairly priced and has a magic “just works automatically for any M365 customer” feature. It is quite stupid and confusing in many other ways but at least it makes fiscal sense.
jauntywundrkind 2y ago
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 https://yunohost.org/en/users
jeffdubin 2y ago
The org I work for recently signed a small (5-user) enterprise agreement with a popular web-based form solution provider for $5k. When I asked them to enable SSO, they asked for an additional $2.5k, which I felt was ridiculous. This is why we didn't do SSO.
delfinom 2y ago
>Why SMBs Don’t Deploy Single Sign On (SSO) Bullshit article. The reason SMBs don't deploy SSO is because SaaS and other tooling puts SSO integration behind very high tier paywalls. I'm talking pricing schemes where sure, you can sign up for a 20 person team on a service because that's the only expected user base in house, but the moment you ask for SSO they demand you license your entire employee headcount. Among many ridiculous schemes I've dealt with.
hluska 2y ago
One of my friends from high school has a dad with a business. I still live in the same city where I went to high school so I occasionally get called to do some tech support for my friend’s dad. Last summer, he ended up in SSO hell and so I got loaded on muscle relaxants and went to help him. He’s an excellent guy with a great attitude and a genuine love for what he does. He’s infectious and when I get to see him, I usually laugh so hard I damned near hyperventilate. His SSO issue was so severe that all that good humour and attitude was totally absent. It took a couple of days, but we got him going. I’m a big fan of democratizing tech, especially security tech. But SSO is quite complicated at the best of times. When it goes wrong, it’s like troubleshooting a plate of spaghetti where half the noodles try to bite you. In the case of SMB, when it goes wrong their businesses mostly grind to a halt. They often don’t have dedicated IT staff - the model of a son’s friend who comes in to help because he didn’t move away is quite common in SMB. It’s a good idea, but in practice until we can get it to be completely turnkey, I don’t believe that many SSO providers could even afford to provide support for SMBs.
fmajid 2y ago
SSO is not the silver bullet they seem to think it is. You are delegating your security to an org that may not be as secure as they claim, e.g. Okta: https://arstechnica.com/information-technology/2023/11/no-okta-senior-management-not-an-errant-employee-caused-you-to-get-hacked/ https://arstechnica.com/information-technology/2023/11/no-ok...
- ndriscoll 2y ago
  SSO doesn't have to mean you delegate anything. You can run e.g. a saml identity provider on-prem with no public Internet access. The browser--being on the vpn--can reach both the identity provider and the application, and can pass along the necessary assertion even if the application cannot talk to the identity server. The application itself may or may not be on-prem as well. I worked on this exact setup for some SaaS software for banks. Our applications were in AWS and we never had any ability to reach the bank identity servers.

38 points by kl4m 2y ago

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

revicon 2y ago
Forced two factor auth can often solve this kind of thing though.
- hananova 2y ago
  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.
  - scott_w 2y ago
    1Password and LastPass both offer this feature, too. Don’t use LastPass though.
  - plorkyeran 2y ago
    Or more primitively than that, I've seen small offices have an old shared phone with a bulging battery that's used for 2fa (or even just having it attached to someone's personal phone and just asking them for the code when you need to log in).
  - neilv 2y ago
    Impressive. Is the reason for this "2FA server" to circumvent per-seat licensing, or some other reason?
    - scott_w 2y ago
      It’s also because there might only be one super admin account allowed, which also needs to be the most secure. But you don’t want the person with the 2FA codes to wander off with them one day!
- modo_ 2y ago
  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
  - noprocrasted 2y ago
    I've set up multiple times a phone-to-Slack proxy for this exact reason. In my case it was a VoIP number, but if that's blocked, Android has many SMS-to-webhook apps and even entry-level industrial LTE routers generally have this feature so you can use a real SIM card.

dswalter 2y ago

I'm largely in favor of SSO, but it's not without its downsides, going beyond capital costs: SSO can also be implemented in a way that introduces an onerous latency tax when using services.

dijit 2y ago
Because of proxying? SSO (SAML/OAUTH2) are usually implemented with a token, like normal auth. There should be no penalty aside from login.
scott_w 2y ago
I’m not sure about that beyond login. That said, Okta has gotten reasonably good when you have a Yubikey, so I’ve stopped complaining about it.
justin_oaks 2y ago
> SSO can also be implemented in a way Unless you're more specific, I'm going to assume that that "way" is the wrong way. Initial login shouldn't add more latency than a couple web redirects. The authentication token/assertion should be validated only once and not be needed until it expires or the user logs out.

sloankev 2y ago

https://sso.tax https://sso.tax

smitty1e 2y ago
> 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.
- scott_w 2y ago
  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. But this is also why those features are so pricey: enterprise organisations derive the most benefit from it, and have a team dedicated to its maintenance.
  - ArchOversight 2y ago
    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 for users, but the cost is prohibitive for most products to get the upgrade to get access to SAML or OIDC for SSO.
    - scott_w 2y ago
      I address this here https://news.ycombinator.com/item?id=40752797 https://news.ycombinator.com/item?id=40752797

scott_w 2y ago

As someone who works on our SSO implementation, the reason for the SSO tax is twofold: - Positioning: it’s seen as an enterprise product so attracts enterprise pricing - Support: it’s genuinely a high touch feature which lots of customers fuck up all the time in the same way and always needs support and engineering help. Documentation for those issues? We have it, it doesn’t stop the support requests coming in. I was looking at a request this morning where the error message is coming from Azure itself and clearly says “this is not configured correctly.” The request hasn’t even reached our systems yet! Until SSO is as plug n play for users as Google Sign-in, SSO will continue to attract a high price point. And I’ll continue to push back on attempts internally to democratise it.

ArchOversight 2y ago
I feel like a lot of the issues are also due to Azure making it vastly more difficult than necessary to configure OIDC/SAML and get the right information over to the SP.
- scott_w 2y ago
  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.
  - ArchOversight 2y ago
    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.
    - scott_w 2y ago
      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.

daft_pink 2y ago

I don’t want to bother with vendor lock in and an additional single point of failure. That’s why I don’t use sso

dijit 2y ago
SAML and OAUTH2 are open standards, and single-point of failure generally means a single server or host- but I take the point that having a centralised service becoming unavailable would affect new logins. However, you're rather naive if you think this is what would keep you locked in, changing authentication host (usually tied to mail, calendars, chat) is... difficult, and changing the SSO stuff is one of the easiest parts of the migration speaking from experience. SSO is quite useful when you have onboarding and offboarding, remembering every place a person had an account with access to critical company data is horrible and trying to convince people to not share passwords between them is horrible too- a breach in one, in those cases, is a breach in all.

tqwhite 2y ago

I've implemented SSO in a small business context. It's insanely hard. Absolutely not worth it. Until Apple and Microsoft find a way to a LetsEncrypt-type comprehensive mission, it's out of the question. And, since Azure 'Entra' is a Microsoft profit center, no easy to use tool will be in their interest.

jameskilton 2y ago

Full disclosure: I work at WorkOS (https://workos.com/ 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 unfortunately SSO isn't free. Someone is paying for it somewhere, be that implementation, outsourcing to a service, and/or maintenance and customer support for the live of the product. That said there are a lot more services and libraries out today that try to make this easier such as https://www.passportjs.org/ https://www.passportjs.org/ (which WorkOS sponsors).

ArchOversight 2y ago
SMB's are the customers of products that offer SSO but only at the enterprise level. CISA is arguing that the enterprise level of the software SMB's need to operate is too expensive and thus SMB's don't end up buying a license tier that includes the ability to hook into their already existing SSO (likely Azure Entra ID or Google Workspaces, sometimes Okta). The SMB's already have SSO, they just don't enable it for the SaaS products they buy because of the price.
Dachande663 2y ago
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 :(
- tatersolid 2y ago
  Same here. As a SaaS provider to SMB, all the major auth vendors (Okta, Ping, WorkOS, etc.) are ludicrously overpriced and would require us to double our own pricing. Except Entra ID for customers, which is fairly priced and has a magic “just works automatically for any M365 customer” feature. It is quite stupid and confusing in many other ways but at least it makes fiscal sense.

jauntywundrkind 2y ago

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 https://yunohost.org/en/users

jeffdubin 2y ago

The org I work for recently signed a small (5-user) enterprise agreement with a popular web-based form solution provider for $5k. When I asked them to enable SSO, they asked for an additional $2.5k, which I felt was ridiculous. This is why we didn't do SSO.

delfinom 2y ago

>Why SMBs Don’t Deploy Single Sign On (SSO) Bullshit article. The reason SMBs don't deploy SSO is because SaaS and other tooling puts SSO integration behind very high tier paywalls. I'm talking pricing schemes where sure, you can sign up for a 20 person team on a service because that's the only expected user base in house, but the moment you ask for SSO they demand you license your entire employee headcount. Among many ridiculous schemes I've dealt with.

hluska 2y ago

One of my friends from high school has a dad with a business. I still live in the same city where I went to high school so I occasionally get called to do some tech support for my friend’s dad. Last summer, he ended up in SSO hell and so I got loaded on muscle relaxants and went to help him. He’s an excellent guy with a great attitude and a genuine love for what he does. He’s infectious and when I get to see him, I usually laugh so hard I damned near hyperventilate. His SSO issue was so severe that all that good humour and attitude was totally absent. It took a couple of days, but we got him going. I’m a big fan of democratizing tech, especially security tech. But SSO is quite complicated at the best of times. When it goes wrong, it’s like troubleshooting a plate of spaghetti where half the noodles try to bite you. In the case of SMB, when it goes wrong their businesses mostly grind to a halt. They often don’t have dedicated IT staff - the model of a son’s friend who comes in to help because he didn’t move away is quite common in SMB. It’s a good idea, but in practice until we can get it to be completely turnkey, I don’t believe that many SSO providers could even afford to provide support for SMBs.

fmajid 2y ago

SSO is not the silver bullet they seem to think it is. You are delegating your security to an org that may not be as secure as they claim, e.g. Okta: https://arstechnica.com/information-technology/2023/11/no-okta-senior-management-not-an-errant-employee-caused-you-to-get-hacked/ https://arstechnica.com/information-technology/2023/11/no-ok...

ndriscoll 2y ago
SSO doesn't have to mean you delegate anything. You can run e.g. a saml identity provider on-prem with no public Internet access. The browser--being on the vpn--can reach both the identity provider and the application, and can pass along the necessary assertion even if the application cannot talk to the identity server. The application itself may or may not be on-prem as well. I worked on this exact setup for some SaaS software for banks. Our applications were in AWS and we never had any ability to reach the bank identity servers.