Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why SMBs Don't Deploy SSO

cisa.gov

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Why SMBs Don't Deploy SSO

#51

Post by scott_w »

lelanthran wrote: post #48
scott_w wrote: post #45

Earlier quoted context omitted.

The issue isn’t writing the code. It’s everything that comes after in terms of user support. The systems are relatively easy to integrate with libraries or products like Auth0.

> It’s everything that comes after in terms of user support. That's the detail that I need, actually

In which case, I’d look at the documentation that companies put out for SSO to get a feel for the types of issues your customers will face. Make sure your system logs everything (or pay Auth0) and provide this as a feature. It’ll cut down a lot of support calls.

Budget in time for your engineers to sit on support calls and directly work through them with customers. Document every issue you see for your support team. If you can, hire a semi technical person to do this support (especially if you want to scale up). It’ll take a load off your engineers.

If your permission system allows it, enable IDP-initiated login as a must have.

Have a strategy for if a customer locks themselves out with a bad configuration. You’ll need either to force they have a password account or a way to reach out to Support to turn it off for them to try again.

After that, honestly, the issues will be a grab bag of things. They’re generally one-off issues per customer but they can take time while you resolve them.

Finally, most customers are great and get it. Some are great and don’t get it. The last group think they know more than you and clearly don’t. They’ll eat up most of your time.

Re: Why SMBs Don't Deploy SSO

#52

Post by scott_w »

neilv wrote: post #36
hananova wrote: post #24

Earlier quoted context omitted.

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.

Impressive. Is the reason for this "2FA server" to circumvent per-seat licensing, or some other reason?

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!

Re: Why SMBs Don't Deploy SSO

#53

Post by slooonz »

scott_w wrote: post #23
ArchOversight wrote: post #20

Earlier quoted context omitted.

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.

"Your issue is coming from a misconfigured SSO. We disabled SSO on your account, you can login with the standard password reset flow. You can reenable SSO once you have fixed the issue."

Re: Why SMBs Don't Deploy SSO

#54

Post by scott_w »

slooonz wrote: post #53
scott_w wrote: post #23

Earlier quoted context omitted.

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.

"Your issue is coming from a misconfigured SSO. We disabled SSO on your account, you can login with the standard password reset flow. You can reenable SSO once you have fixed the issue."

And when you have to unlock it for the fifth time? This is looking like a shit product and shit customer support.

Re: Why SMBs Don't Deploy SSO

#55

Post by noprocrasted »

modo_ wrote: post #27
revicon wrote: post #3

Earlier quoted context omitted.

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

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.

Re: Why SMBs Don't Deploy SSO

#56

Post by cratermoon »

ArchOversight wrote: post #13
scott_w wrote: post #6

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…

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.

Azure AD or whatever they are calling is now isn't even fully SAML 2.0 compliant, so of course it generates support calls. Then the answer from MS support is "use this workaround" and now your implementation is locked into Microsoft's implementation.

Sound familiar?

Re: Why SMBs Don't Deploy SSO

#57

Post by cratermoon »

justin_oaks wrote: post #42
scott_w wrote: post #6

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…

> Until SSO is as plug n play for users as Google Sign-in I noticed that Slack offers "OAuth with Google" for their Pro plan (lowest paid tier) but SAML SSO requires the more expensive Business+ plan. Would it make sense to allow everyone to use the "easy" SSO and require higher payment for stuff that's complicated and easy to screw up?

SAML is way more of a beast to configure and maintain compared to any oauth-based flow. One reason is just that SAML is more complex, because it does a great many different things for many different use cases. The other reason is that setting up SAML requires humans to coordinate the trust setup and key exchange between the IDP and Relying Party. For typical setups, oauth is pretty much self-serve, but where I worked setting up a new SAML customer required a senior engineer to personally handle it every time.

Re: Why SMBs Don't Deploy SSO

#58

Post by ndriscoll »

fmajid wrote: post #49

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

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.

Re: Why SMBs Don't Deploy SSO

#59

Post by phantompeace »

scott_w wrote: post #54
slooonz wrote: post #53

Earlier quoted context omitted.

"Your issue is coming from a misconfigured SSO. We disabled SSO on your account, you can login with the standard password reset flow. You can reenable SSO once you have fixed the issue."

And when you have to unlock it for the fifth time? This is looking like a shit product and shit customer support.

The customer misconfigured their SSO 5 separate times? Sounds like you don’t want that kind of customer in the first place to be honest.
Post reply on HN