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

71–80 of 124 posts

Re: Why Single Sign on Sucks

#71

Post by evouga »

I feel like authentication these days has veered way too much towards the extreme of security over usability.

My primary email account, bank accounts, medical records, etc. absolutely should be protected with MFA (and ironically often are not).

But why do I need to do to a 2FA song-and-dance to access a random Zoom meeting? Each of a dozen different Slack workspaces? Why is my GitHub personal project with 2 stars and zero collaborators locked behind a convoluted system of tokens I've been repeatedly asked to regenerate?

The thing is, well north of 90% of my daily logins are to services where it would be annoying, but not life-changing, if I got hacked. I'd rather accept the possibility and consequences of such a black swan event than pay the constant premiums on my time and focus required by today's authentication patterns.

Re: Why Single Sign on Sucks

#72

Post by seiferteric »

benarent wrote: post #66
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…

OP here: We are cooking up something cool at Teleport, drop me an email ben@goteleport.com and I'll invite you to the preview.

Oh, I didn't make it to the bottom of the article lol, I see that is what this is about.... cool!

Re: Why Single Sign on Sucks

#73

Post by Bellend »

IncRnd wrote: post #50
feoren wrote: post #44

Earlier quoted context omitted.

> Employers also see trusted employees smile and leave for competitors even after signing that they would not do that. Employers who ask their employees to sign immoral and usually illegal non-compete clauses deserve whatever they get, honestly. Employers should expect their employees to go work for competitors when they leave. Where else are they going to go work, but companies with similar operations? An ecology ma…

> Employers who ask their employees to sign immoral and usually illegal non-compete clauses deserve whatever they get, honestly. Employers should expect their employees to go work for competitors when they leave. That's my point as to why employers want to immediately stop access to employees who leave for competitors. > An ecology management company fires and ecologist and they clutch their pearls when that ecologis…

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

Re: Why Single Sign on Sucks

#75

Post by rectang »

zrail wrote: post #61
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…

I make a new GitHub account with work email on day one. My personal GitHub account never touches my work machines and the only personal thing my work accounts touch is my dotfiles.

Creating separate Github accounts for each employer/organization is crucial to avoid creating a personal access token for one organization which has global permissions across all repositories your account has access to. This has been a problem for many years.

Note that Github only allows one free account, so the business needs to pay for each one if its dev accounts.

Re: Why Single Sign on Sucks

#76

Post by jrockway »

EGreg wrote: post #14

Why don't people just use webauthn?

I went this route. I really like the design of Google's Identity-Aware Proxy. You host your apps behind it, the proxy authenticates users and passes a JWT to the application that contains additional metadata. The app can choose to care or not care about the JWT. This is nice for read-only things that aren't particularly important (something like jaeger-ui). Or the app can choose to care, and do one cryptographic operation to get a trustworthy username and group membership list. This is so much easier from an operations and implementation perspective than integrating something like OIDC. I wish more applications supported this, and didn't force me to hack OIDC into this flow.

As for WebAuthn, yes, that's what you should be using these days. People are terrible at choosing passwords, so why make them?

I wrote an authenticating proxy that maintains username -> WebAuthn credentials, and use it for my personal projects. I wouldn't recommend that someone else use it (incomplete featureset, not security reviewed), but it's totally open source so you can steal the bits you like: https://github.com/jrockway/jsso2

The end result is that I can open up Grafana on my phone and sign in with FaceID. Or if my face falls off, I can scan my YubiKey with NFC. All given to you for free for using WebAuthn. And it costs $0/month, which is much less than the Oktas of the world charge for a more

Re: Why Single Sign on Sucks

#77

Post by wyattpeak »

derekp7 wrote: post #46
throwawayboise wrote: post #10

Earlier quoted context omitted.

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 see this in situations similar to sudo where you need to make sure it is the same user that signed on when elevating privileges, vs letting in anyone who sits down at an unlocked user's terminal.

If I had to wait for several hundred network requests to complete and one or two pages to render every time I sudo'ed I'd complain about that too.

Re: Why Single Sign on Sucks

#78

Post by jodrellblank »

throwawayboise wrote: post #7
deergomoo wrote: post #3

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

Single Sign On works beautifully in the Windows environment. Logon to one workstation, access any server's file or print shares, SQL server, IIS websites, and tons of third party software without any logon prompts but still with granular permissions.

One of those things people who say "I don't understand why anyone uses Windows" don't understand. Something so pervasive and convenient that "we" the industry have given up in moving everything to the web, along with standard menus, ubiquitous keyboard accelerators for menus and dialog boxes, scripting with the likes of COM, ActiveX, AppleScript, or embedded Python/Lua, local snapshots or volume shadow copy, tools like DNSpy and AutoHotkey and SysExporter able to introspect into running programs and their windows and system controls (and they generally weren't obfuscated javascript inside), being able to see different programs in task switchers without them all being wrapped in a web browser.

It was a different and in many ways better world 10-15 years ago.

Re: Why Single Sign on Sucks

#79

Post by cletus »

Weird timing. I was just dealing with an issue related to this.

I had a work a phone. I restored an image to my personal iPhone and just today tried to sign on to Youtube. It redirected me to the SSO page for my former employer's page. Why? I guessed I'd signed on to my corp Google account on my phone at some point and it remembered. Googling didn't find an easy answer. There was no opt out button (on the login screen or on YT) and no clear way to bypass it. After some googling I ended up just deleting every Google related cookie on my phone and that seemed to clear it up.

This is a terrible user experience.

But even when you are signed in to more than one account it's terrible. You get a link to a Google doc, click on it and it says "you don't have permission". More often than not Google has decided to try as your personal Google account not your corp account. But I bet there is a ton of confused people who click "Request Access" and are confused why it doesn't work.

I haven't experienced the author's issue of 43 sign-ons a day. Sounds like a bad enterprise setup.

I'm not sure what the solution to this is but my first thought is resource ownership should be clear from the URL eg it should use a domain name other than google.com. There are probably problems with that. Whatever the case, currently it's terrible.

More often than not I find myself segragating Google accounts by browser (or browser profile). That's a pretty clear sign the product experience, well, sucks.

Re: Why Single Sign on Sucks

#80

Post by jordanbeiber »

hinkley wrote: post #18
deergomoo wrote: post #3

I 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…

It’s just bad practice having accounts scattered through bunches of systems that shouldn’t be used anymore.

It’s often a licensing issue, and definitely a security issue.

Either you maintain this manually - proper time consuming chore at larger companies with many systems and applications.

Or write automations to manage it. Better, but still a lot of work and not always technically possible.

Or you hook as many of these systems as possible up to an SSO solution backed by some kind of identity provider.

This grants many benefits for everyone during the lifecycle of systems and its users - sysadmins, it-support, infosec but perhaps most of all the end-users.

As a manager myself I first and foremost think about how the on-boarding works: is it smooth, and are new hires gaining access to the systems they need without 15 calls to the service desk.

Post reply on HN