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

Why Single Sign on Sucks

goteleport.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Why Single Sign on Sucks

#111

Post by xg15 »

Reminds me of the "create an account or login with Facebook/Google/etc" UX you see on many sites.

The promise was that services could outsource their account management to e.g. Facebook, users wouldn't have to deal with dozens of accounts and Facebook gets some more juicy user data to analyse. Win-win-win, right?

Except of course sites don't want to outsource their account management to anyone. User accounts are valuable, so every company who can manage to do so in any way pushes their users to make an account. They also want to keep maximum control over those accounts.

However, what sites would like very much is to have their user accounts associated with a Facebook or Google identity.

So what happens in the end is that the buttons really mean "login with Facebook and create an account" - which means for UX and privacy of users, it's the worst of both worlds combined.

Re: Why Single Sign on Sucks

#112

Post by prepend »

adontz wrote: post #58

GitHub's SSO if it's not Enterprise managed accounts sucks. Thus the example is extremely unlucky. Industry standard is that service provider gets identity from identity provider and provisions an account with that identity. So that if I log in to Jira as john.smith@example.com I'll have john.smith@example.com username. What GitHub does is it links enterprise identity to personal account. So I have to log in twice (a…

This is a frustrating limitation of GitHub’s setup and is hard to find out who people are. As an admin, I can theoretically search the org membership for HugeDick53 and see that it’s associated with John.smith@example.com, b it regular users in the org are at a loss.

We have a loose convention that everyone update their profile with their name. But this is visible publicly, so if an employee doesn’t want their name public they are hosed.

I wish there was an option for an “enterprise” account that would stay hidden to everyone except org members.

But I do applaud GitHub for sticking with the idea that dev identities belong to individuals, not their orgs. So when someone leaves a company they can keep their profile.

I use a single GitHub account with activity for years and link and unlink it to orgs as necessary. Since I also do dev work, I worry that if someone compromises my account or gets a token, they will be able to wreak havoc on multiple orgs and repos where I have access.

Re: Why Single Sign on Sucks

#113

Post by prepend »

seiferteric wrote: post #40

Maybe someone can answer this, why are client certificates not more popular instead of something like VPN for work? I suppose even with client cert, you would still need to login, though if your computers login is already managed through AD/ldap or something and you enforce timeout logout policies you could argue that if you are logged into your machine that is good enough. Even if not, then a client cert plus a SSO…

I’ve used client certs for maybe 25 years. They are hard to configure. Most devs can’t get them working.

They also used to be expensive but I expect that’s dropped.

I’ve seen many “client certificate” solutions over the year that end up trying to do client management and crap out in many situations that are hard to fix (eg, user changes their environment and the cert is gone, now they can’t log in).

To make it easy enough to use, it ends up having all the flaws of our current sso environment. My friend had a company he was trying to start where he would automatically create and revoke client certificates for every device and session. But they were so ephemeral, they may as well have been cookies and it ended up being really cumbersome to try to keep track of certs on client devices.

Re: Why Single Sign on Sucks

#114

Post by jeroenhd »

Sebb767 wrote: post #98
jeroenhd wrote: post #82

Earlier quoted context omitted.

I think it's because A) developers don't know about it, B) users don't understand it and C) the UI for it is quite terrible. Implementing it requires some uncommon TLS configuration and a little cert work. Using it prompts uncommon native popups, slowing people down. Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't…

> Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't replace that. That's not true. nginx, for example, let's you return a custom response, which can easily be a 302 to the login page. But I agree with all other points. On a sidenote, there's also the great option of using a CA for your client certificates while still…

> Unfortunately, hardly any tutorials pointed this out and used their own CA for everything instead.

I think this is one of the reasons so few people consider using TLS auth. There aren't many guides out there, and many of the ones that are easily accessible use a custom CA deployment that's an absolute pain to manage (custom TLS certs on websites with a custom ACME server or manual certificate generation, and so on).

Sometimes I feel like writing my own guide, but I'm not 100% confident that I'd get everything right.

Re: Why Single Sign on Sucks

#115

Post by larrybud »

prepend wrote: post #112
adontz wrote: post #58

GitHub's SSO if it's not Enterprise managed accounts sucks. Thus the example is extremely unlucky. Industry standard is that service provider gets identity from identity provider and provisions an account with that identity. So that if I log in to Jira as john.smith@example.com I'll have john.smith@example.com username. What GitHub does is it links enterprise identity to personal account. So I have to log in twice (a…

This is a frustrating limitation of GitHub’s setup and is hard to find out who people are. As an admin, I can theoretically search the org membership for HugeDick53 and see that it’s associated with John.smith@example.com, b it regular users in the org are at a loss. We have a loose convention that everyone update their profile with their name. But this is visible publicly, so if an employee doesn’t want their name p…

> I wish there was an option for an “enterprise” account that would stay hidden to everyone except org members

There is: Take a look at Enterprise Managed Users https://docs.github.com/en/enterprise-cloud@latest/admin/ide...

Re: Why Single Sign on Sucks

#116

Post by Anunayj »

gonehome wrote: post #62
paxys wrote: post #54

The author's complaint is really against authentication in general rather than SSO. Different sites and services have always and will always use their own authn/authz methods, simply because it isn't a generic problem that can be abstracted away. You can outsource parts of it (show the user a username/password form, validate credentials, verify email, check 2FA) which is what all these SSO providers aim to do. Also t…

I think it could be a generic problem that's abstracted away, but you have to absorb identity into the stack at the OS level. For a centralized authoritarian example of this you can consider WeChat. Unified API and auth layer that supports lots of different applications from one auth service that's used for basically everything. In the decentralized world there have been attempts to do this as hacks on the existing w…

I agree, honestly something like public key auth built into the browser seems great to me! I use a single ssh key to login into multiple servers, I don't have to rely on a central authority to identify me and anyone can remove my access by just removing my public key.

Re: Why Single Sign on Sucks

#117

Post by xmodem »

prepend wrote: post #112
adontz wrote: post #58

GitHub's SSO if it's not Enterprise managed accounts sucks. Thus the example is extremely unlucky. Industry standard is that service provider gets identity from identity provider and provisions an account with that identity. So that if I log in to Jira as john.smith@example.com I'll have john.smith@example.com username. What GitHub does is it links enterprise identity to personal account. So I have to log in twice (a…

This is a frustrating limitation of GitHub’s setup and is hard to find out who people are. As an admin, I can theoretically search the org membership for HugeDick53 and see that it’s associated with John.smith@example.com, b it regular users in the org are at a loss. We have a loose convention that everyone update their profile with their name. But this is visible publicly, so if an employee doesn’t want their name p…

We used to use terraform to invite people to our github org, along with a file in a repo to map company emails to github usernames. When a new starter joins, their manager submits a PR to add their username.

It was a huge mess - it would fail to apply if you looked at it funny, and it had no controls against someone typo-ing a username and inviting a random person to the org. But it solved this case at least.

Re: Why Single Sign on Sucks

#118

Post by grogers »

throwawayboise wrote: post #10
csben wrote: post #4

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

Honestly I don't mind this too much as long as it's yubikey only, that literally is just reach up, tap, hit enter: 1-2 seconds if you know it's coming. If they require to reenter a password it's more like 10-30 seconds depending on if I mistype anything. That's just setting the wrong incentive to have a weak password that is easy to type.

Re: Why Single Sign on Sucks

#119

Post by r00fus »

thwarted wrote: post #94
Bellend wrote: post #73

Earlier quoted context omitted.

If that was the goal, wouldn't you do that in advance anyway before any suggestion you were bailing?

Sure, but it doesn't always happen like that. You're in sales at a company in a highly competitive space and are exited. You're not the kind of person to premeditate taking anything with you, perhaps you left on good terms. You join another company and someone there asks you for the book of business or sales leads you were working on that the previous company. Oh look, your login to the CRM system is still working, a…

Absolutely not only is immediately removing the terminated employee’s access critical but setting up SSO and auto-provisioning/de-provisioning so straightforward and effortless with many SSO products that it’s essentially malpractice to not do so.

Re: Why Single Sign on Sucks

#120

Post by throwra620 »

adontz wrote: post #58

GitHub's SSO if it's not Enterprise managed accounts sucks. Thus the example is extremely unlucky. Industry standard is that service provider gets identity from identity provider and provisions an account with that identity. So that if I log in to Jira as john.smith@example.com I'll have john.smith@example.com username. What GitHub does is it links enterprise identity to personal account. So I have to log in twice (a…

No post body was provided.
Post reply on HN