[adontz]

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 [e-mail] I'll have [e-mail] username.

What GitHub does is it links enterprise identity to personal account. So I have to log in twice (and honestly it's already not an SSO at this stage) first time I log in with enterprise identity and then I log in with personal account. So I log in as [e-mail], then login as HugeDick53 and then I'm visible as HugeDick53 and [e-mail] identity vanishes from view.

GitHub's justification is that contributions on enterprise projects should be visible on personal accounts. However, from administrator's point of view entire system + UI issues make this type of so called SSO completely unusable. Nobody in company has any idea who is HugeDick53.

On the other hand Atlassian products provide true SSO. Not the most sophisticated one, but at least it's SSO.

[zrail]

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.

[rectang]

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.

[stormbrew]

Honestly, at the risk of committing No True Scotsman, I feel like the flow demonstrated in this blog post just.. isn't SSO to begin with, actually. It may be using SSO infrastructure, but if you have to login twice, use 2fa twice, to log in to one thing, then it's Two Sign On or something.

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.

[prepend]

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 [e-mail], 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.

[larrybud]

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

[xmodem]

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.