So while I don't think the thrust of the post is wrong in general, it's an odd example.

> GitHub's justification is that contributions on enterprise projects should be visible on personal accounts.

Really the thing that sucks here is something that hasn't really been well solved and is only tangentially related to SSO: Multiple linked identities under one or more logical accounts. No site does this well, and SSO is an insufficient tool to help - the entire mechanism of identity on the web is working against it.

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.

The example from the article looks terrible and should not be seen as representative for how SSO can work.

That said, it’s still not the sign on nirvana we all want to have, browsers and OS still have a lot of areas for improvement here.

From the author’s gifs, it looks like their SSO is setup incorrectly AND being incorrectly used. The 1st gif is really bad, the subsequent ones are more typical SSO setups.

Also, this blog article is an ad for Teleport. Given their flawed premise, … yeah.

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 web (stuff like open id), but they can't really succeed on the current stack. The Urbit OS is an attempt to solve these types of issues by boiling the ocean and in doing so this is one of the issues that gets fixed.

However, it is not really safe to expose it publicly, so it is stuck to intranet only. Random services can ask the user for a ticket (domain does not have to match the realm!), so in your browser you need to whitelist hosts that are allowed to ask for SPNEGO. It does not help that both mobile platforms and macOS insist on using MDM to join the domain.

So if you manage to skip all the hurdles, you can use SSO like Keycloak that does accept SPNEGO for the user login and use it for SAML2/OIDC for all the other services. This way, your ad-joined-desktop/gnome-online-accounts/nomad.app login can work in the brave new world of web apps and apis outside your intranet.

If not careful, set it up once, in one place (ie email), and you’ll get logged into that account for every single Google app on your iPhone.

No, Google, I don’t want to use Google Maps with some random account some client set up for me. I just want to get their emails. Nothing more.

Then, of course, there’s trying to join a Google Meet meeting, and having to play around with the Google account selection.

But the funniest was when I had my own GSuite org, with almost every service turned off.

I’d get redirected to the admin panel, but then switching to the client’s org’s account would redirect to their admin panel, to which I didn’t have access.

And getting back to the initial app (drive or meet), would bring me back into the account linked to my org, thus the admin panel… After a couple times, I ended up systematically opening those links in a private browsing window.

AWS takes the cake - you can enable a youbikey, or other TFA, but only one. So I get locked out if my device ever dies.

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

I'd actually say it's the other way around. One of my favorite quote related to that is "security at the expense of usability is at the expense of security". If you force users to rotate passwords, they'll use some form of continuous passwords and/or stick them with notes to their monitors. If you'd need to sign in all the time, users will be less careful and choose easier passwords. If it takes 20 seconds to authenticate at the front door, it will only take a few days until someone puts a brick there to keep it open. To improve security, you'll absolutely need to consider the UX; improving the UX while not caring about security, OTOH, works quite well in my experience (until it blows up in your face, which might be years away or even a moral hazard).

Because employers see how some employees act as they depart, even though they don't act similarly around their coworkers. Employers also see trusted employees smile and leave for competitors even after signing that they would not do that. Employers are right to suspect departing employees, because some steal information or otherwise cause issues before they leave.

> So it troubles me a bit how quickly the C Suite prioritizes having a giant switch to lock people out.

I've seen dozens of systems that had to be accounted for when an employee left. Almost all of those systems required separate action to remove the departing employee, plus follow-up checks that sometimes had to be from humans.

It only makes sense to have your employee separation procedure get automated, and during automation it makes sense to communicate with one system instead of communicating with 30 systems that each respond in different ways - some of which require human intervention.

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.

When you have thousands of accounts and dozens to hundreds of services, manual management just stops being practical.

Most large orgs are subject to one form of compliance or another, and it's inevitable that at some point you have to prove to an auditor that you have onboarding / offboarding processes for everything as that's in their checklist.

This is difficult to prove "at scale" and removing tons of per-service UAR processes is the main value. Each service is an opportunity to screw up - forget to document the process, forget to execute the process, (my favourite) forget to record that you executed the process, or execute the process wrong.

The alternative to automation in a big company is that accounts get left dormant for years.

The risk does not come primarily from disgruntled employees doing bad things—there's already a huge legal deterrent to that since they know exactly who you are. The bigger risk is what can happen when credentials are stolen by actual criminals. This is context dependent, but scales with the number of employees times the number of accounts, the latter of which has trended up dramatically as cheap B2B SaaS has proliferated.

What happens when a laptop is lost? What happens if a DB is hacked and users had reused passwords? How do we know who even has access to what when teams self-administer access control? These start to become real security problems at relatively modest scale even if we assume every employee is a saint.

Even leaving security aside, the management of accounts starts to become a significant pain point in the low hundreds of employees and so it will typically be the IT team that pushes for SSO first well before compliance comes into the picture.

People suck at remembering passwords, and even if you go and give them Password Manager tools like 1Password/Lastpass/whatever, they'll still tend to re-use the same password they use for their personal email, and that random service that recently got pwned.

It's worse when they have credentials like AWS IAM Keys that are while not difficult, are inconvenient to rotate. Those are likely to just sit around on someone's machine and get leaked inadvertently in logs or test code.

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.

Most SSO integrations have very bad Single-Sign-Out design, if any at all. So as long as the token in your session has not expired yet, you have full access to resources, even if account is blocked in the Id Provider.

No more chasing around for each service figuring out who is the admin for what.

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.

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.

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 using a normal CA for your https certificate - you don't have the worry of installing a root certificate on all clients and still have a nice, valid https connection in the browser. Unfortunately, hardly any tutorials pointed this out and used their own CA for everything instead.

SSO without central identify management would be weird but also very possible.

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.