[deleted]
Why Single Sign on Sucks
21–30 of 124 posts
Re: Why Single Sign on Sucks
#22I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.
That's centralized identity management, not single-sign-on. Single-sign-on is/was supposed to mean you sign on once. I've never seen it actually work.
SSO is the source of truth, and centralized identity is the system of record. They go hand in glove. It's not a non-sequitur so much as a tangent.
Re: Why Single Sign on Sucks
#23SSO sucks nothing in compare with TOTP-incompatible "please scan QR" mobile auth. With uniq app per service.
Re: Why Single Sign on Sucks
#24My experience is completely opposite of the author's. I sign on once a day when I access a service that uses my firm's SSO solution. I'm then automatically signed in to all other services as I use them. It's quite seamless. I have no complaints about the SSO setup in my firm.
So your company doesn't have certain functions where someone has said "this is really critical so we'll force a sign-in even if the SSO token is already there" because that happens to me 10 times a day at my work.
I would say that's not really a SSO issue so much as it's an obnoxious session duration policy.
Re: Why Single Sign on Sucks
#25I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.
I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time. On the one hand, Precautionary Principle. The costs of being wrong - and having to explain it to the Board - are just unimaginable. So sure, if you want IT to have a way to push a button and block someone out of the ent…
I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time.
Proper offboarding protects you too, not just the company. If you leave the company and someone compromises one of the 27 hard-coded credentials left behind on various machines and services, then it puts you under suspicion.
In companies where I do have hard coded creds (including shared passwords), when leaving a company, I compile a list of all of them and send it to my manager and tell them to make sure they are all disabled.
Re: Why Single Sign on Sucks
#26I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it's going to be much less of a headache than managing n sets of user credentials.
That's centralized identity management, not single-sign-on. Single-sign-on is/was supposed to mean you sign on once. I've never seen it actually work.
SSO can be both Single Sign-On, or Same Sign-On.
The latter is the LDAP integrated thing - (re)using the same credentials for multiple/disparate services, controlled centrally.
The former ("true" single sign-on) is logging in once and accessing everything from there.
FWIW there are single sign-on services out there. Okta is used by my current employer, I log into the Okta portal and it has links out to all of the services it supports from there.
Re: Why Single Sign on Sucks
#27SSO sucks nothing in compare with TOTP-incompatible "please scan QR" mobile auth. With uniq app per service.
Sendgrid does something similar. You can't use TOTP, you have use Authy specifically for their special 7 digit code. It's infuriating and they don't care.
Re: Why Single Sign on Sucks
#28I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut. But Github recently rolled out a default 2FA that uses their app on my phone instead of the 2FA code. Luckily they support switching back to TOTPs for now. But now that passwordless is the new sign-in meme, i can look forward to having to migrate everythi…
I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut.
Doesn't that dilute the value of MFA and essentially make it SFA? If someone compromises your 1Password app or password, then they get both factors of authentication.
what if an employee leaves their laptop unattended
I think that's what automatic screen locks are supposed to protect from, my company enforces a 5 minute screen lock. I used to use a bluetooth screen lock that would lock my screen immediately if I stopped away from the computer, but the company now won't let me use that app because it has the capability to automatically unlock when I come back (though I don't use that part).
Re: Why Single Sign on Sucks
#29Earlier quoted context omitted.
That's centralized identity management, not single-sign-on. Single-sign-on is/was supposed to mean you sign on once. I've never seen it actually work.
SSO is the source of truth, and centralized identity is the system of record. They go hand in glove. It's not a non-sequitur so much as a tangent.
for the benefit of others (I had to search it): https://www.linkedin.com/pulse/difference-between-system-rec...
Re: Why Single Sign on Sucks
#30This is how I login to SSO today at work: Login username is cached in browser. Password is auto-filled-in by my password manager, which is in turn unlocked for a period of time when I am logged into my desktop. I hit "Log In" button. Backend does magic. An app pops up on my phone. I supply my fingerprint. Authentication is approved, and my browser is now logged in. Same pattern works for logging into AWS from the con…
As an enterprise cloud software business, I will not allow my systems to handle user-chosen long-lived credentials like the passwords you describe. Sorry, it's too much of liability. Got any other ideas? (sincerely curious)
At some point, your user also has right to make their own policies. Imagine your banker requiring you to take a drug test before they let you do any action, would that be fine by you?
If you were talking about your employees, of course, it's less of an issues, but you are still open to them misusing other solutions: in the end, invasive security policies in a business where people can also use service accounts is a recipe to have people build backdoors in their own security. Good security is only as secure as it is convenient for users.
When I was working in banking, people had physical card readers that would identify them. Of course, some people still forgot them sometimes, but it was also necessary to get out of the desks.