Enterprise Managed Users, can I have one of those?

GitHub shipped Enterprise Managed Users (EMU) in September 2021. There are many reasons why enterprise customer should consider switching to EMUs. However, there are also many reasons why they shouldn’t. The purpose of this page is to explain what EMU is as well as to provide pros and cons.

A note here, while this list of pros and cons will be my personal view, many of those (if not all) will be aligned with GitHub’s position.

14 Mar 2024 update: GitHub updated the docs with a bit more info on classic vs EMU topic.

Some background

Before I go into EMUs I need to go through a few relevant areas of GitHub.

GitHub’s flavour of SAML SSO

Firstly, I need to explain how SAML SSO works on github.com. There is a more detailed explanation, but here’s my version.

All user accounts on github.com are personal user accounts. While some companies request users to create a separate GitHub account “for business use” (false sense of security), the individual users completely own their GitHub accounts, can set any settings on their user account and no any other party can control or enforce that.

When a company configures SAML SSO on github.com , all they do is set up an additional “gate” in front of their organisation or enterprise account. A GitHub user can login with GitHub’s account, go to any of their personal private repos, visit other organisations they have access to, but as soon as the user tries to access any organisation with SAML SSO set up, the user will be presented with a login window in a relevant identity provider (IdP). If the user provides correct credentials, they will be able to access the repositories in that organisation. Otherwise the access will be denied. In any case, the user will need to log into github.com first before authenticating against organisation’s IdP; i.e. all users will always be required to have their personal GitHub user account, irrespective whether SAML SSO is configured or not.

The authentication sequence is something like:

1. Login into github.com with a personal username and password. If configured, provide 2FA
2. When trying to access an organisation with SAML SSO enabled, authenticate against that IdP. If required by IdP - provide 2FA
3. Get access to resources in that organisation
4. When trying to access another organisation configured with different SAML provider - repeat steps #2 and #3.

This is somewhat different from other implementation of SSO where the expectation is that all user information, including username, will come from the IdP and no other account will need to be created. While it’s possible to configure user provisioning in GitHub from the IdP, it really only adds an existing individual GitHub user into the organisation and prompts the user to create an individual GitHub user account first if it the person doesn’t have one yet.

Enterprise Account

Often customers get confused when GitHub staff talks about Enterprise Accounts. This may sound like a type of a plan or a customer. Like “I have an Enterprise Account of GitHub with all Enterprise features”. Or as in “this customer’s account is classified as Enterprise in our Salesforce”.

Enterprise Account is actually a feature. Not a plan name or a customer classification. Think of Enterprise Account as a container for organisations. When you are on Free or Team plans, all you have is one organisation. Until 2023, if you purchased Enterprise plan by providing your credit card details on GitHub website, you also only had one organisation. However, if you purchased your GitHub Enterprise plan through your account manager you would get an Enterprise Account with an ability to create multiple organisations. And from 2023 all customers purchasing Enterprise plan would get an Enterprise Account.

In addition to creating multiple organisations, Enterprise Account also provides a number of cool features, mostly about the ability to centrally manage various settings and policies.

GitHub plans

As of 1 Nov 2024 GitHub has three plans: Free, Team and Enterprise. One of the main benefits of the Enterprise plan is the ability to manage user authentication in your GitHub organisation through SAML as well as to provision and (what usually is more valuable) to de-provision users through SCIM. Enterprise plan customers have an option to either have their code hosted on github.com (we usually refer to it as GitHub Enterprise Cloud) or in a self-hosted environment (GitHub Enterprise Server).

So what is this EMU thing

The standard SAML SSO implementation on GitHub doesn’t always sit well with some companies. Some customers prefer to be able to own all user accounts and be able to completely control those. They want to be able to provide employees with a GitHub username when they start their employment (as oppose to “create your personal GitHub username”), they want to be able to enforce the settings on those accounts, they want to be able to reset the password and to take over that user account when the employee resigns. This is exactly the problem EMU solves.

Unlike the login experience on standard GitHub Enterprise Cloud explained above, logging into EMU instance will bypass GitHub’s authentication and the request will go straight to your SAML provider. The username will be dictated by your IdP and the password will be your user’s password in your IdP. The username will always be in a format <username_dictated_by_IdP>_<enterprise_identifier> where <enterprise_identifier> will be chosen by the company when EMU instance is created (also known as a shortcode). For example, johnsmith_microsoft.

EMU is only applicable to GitHub Enterprise Cloud; EMU is not applicable to Free, Team or self-hosted Enterprise Server plans. It is also not available to self-served GitHub Enterprise Cloud customers; to get EMU you will need to contact your account manager.

What are the gotchas

There are a few and these are the main reason why any time any of my customer is asking for an EMU instance I require a 30mins call, to make sure the customer understands what will happen should they switch to EMU as a wrong choice here will be very costly (read: another migration, yay!).

EMU is a new Enterprise Account

Often customers incorrectly assume that EMU is a type of GitHub user account and they will be able to “mix and match”, i.e. let some users to bring their personal username and provide EMU username for others. Instead, EMU is a type of Enterprise Account (remember, the Enterprise Account feature explained earlier?) and ALL users under such Enterprise Account will come from company’s IdP.

Migration!

Yes, whether you are on or not on GitHub, you will need to do a migration. EMU is not a “switch” on your existing Enterprise Account; instead it’s a brand new Enterprise Account and while it is possible to transfer an organisation between Enterprise Accounts, that only works in non-EMU environment.

If you want to move from non-EMU to EMU - you will need to migrate the code. GitHub made it easier with tools like GitHub Enterprise Importer and you can always migrate (code only, no metadata) with git clone, git push, but it’s still a migration. If you are coming to GitHub from another code versioning platform you will need to migrate anyway, so that wouldn’t be much of a difference.

However, making a wrong choice here will cost you a migration later. I had customers choosing to go with EMUs only to come back six months later with the decision to switch back to a standard enterprise account (and yes, to do the migration). So if not sure - talk to your accountant/financial advisor/lawyer friendly GitHub’s solution engineer!

Limitations

Please please please look through the list of EMU limitations. In a nutshell, you can’t create anything public (repos, gists), forking is restricted, no outside collaborators (at least in traditional definition as all EMU users should have identity in your IdP), whatever you create in an EMU instance - stays in EMU instance. The picture I usually paint is EMU is a castle in github.com kingdom with tall stone walls without gates: it’s the same soil as everywhere else and you can grow the same crops just like anybody else in the kingdom, but nobody outside those wall can see what you are growing or what happens inside the castle and the castle residents cannot take anything with them outside those walls; well, they can’t even leave as username will stay in that EMU account!

The users in an EMU instance technically don’t exist on broader github.com so you can’t contribute to any public repositories (or to anything really outside of EMU enterprise account). If any of your users need to commit to repositories outside of your EMU account, they would have to log out from your EMU instance, log into github.com with their personal username and then contribute to public or private repositories. And they’ll need to log out and log into your EMU instance to continue working on your code. GitHub is making it easier with multi-account support, but a switch between user account still will be required.

If you have any public repositories to share your code or collaborate on with the public - you will need to set up a separate non-EMU organisation for that and depending on your requirements it might be an additional cost.

GitHub user profiles

Many developers start using GitHub in universities (if not earlier!) to work on school projects. Once they finish uni, they look for jobs and their GitHub profile serves as part of their resume. Think LinkedIn for developers! Potential employees can visit a candidate’s GitHub profile and examine the code they wrote in public repositories. They can also see how active a developer is from their contribution graph. While working for a company (assuming the company uses GitHub), all contributions to any company code will be reflected in employee’s contribution graph. When this developer is looking for another job a few years later, they can send their GitHub profile to the next potential employer who can also review the quality of any code that developer contributed to public repositories. So in a nutshell, developers treat their GitHub profile as part of their resume. Or to just show off: there’s even an option to 3D-print your contribution graph!

If a developer starts at a company that uses EMUs, no contributions will be reflected on the employee’s personal contribution graph and since there are no public repositories in EMU enterprise, it won’t be possible to show developer’s contributions to any public code unless they switched to their personal account.

Should I or shouldn’t I?

So with all above, why would you want to go EMU? Or why should you stay on standard GitHub?

Consider EMU if

• You have a requirement to own and be able to take over user accounts
• You want to reduce the risk of accidental code leakage to public repositories
• You need to use OIDC SSO through EntraID and enable support for your IdP’s Conditional Access Policy

Consider standard GitHub if

• You value developer’s ability to use their profile as a resume
• You have a strong open source presence, maintain a number of open source projects or encourage your developers to contribute to open source
• Your IdP is not Okta, AzureAD/EntraID or Ping Federate (14 Mar 2024 update: GitHub beta-released REST APIs for SCIM and the ability to use non-partner IdPs for SAML which would allow customers to connect to IdPs other than Okta/Entra/Ping, but a custom development would be required for that, and don’t forget that it’s still in beta and might change or even never go GA)
• You need to provide contractors with access to some of your repos without creating identity in your IdP (using outside collaborator feature).

Over my 4+ year career at GitHub I met with many customers who were interested in EMUs. About half of them eventually, after discussing pros and cons, decided not to go ahead with it. The decision is not about whether EMU option is better or worse, the decision is whether EMU is the right choice for your company. Make sure to involve various teams in that decision when evaluating your options, especially your security and development teams, and don’t hesitate to involve your solution engineer.