At Formula5, we recognize that the process of implementing a new tool involves more than just familiarizing the team with its practices and features. For many organizations, it is essential to ensure secure access to source code repositories and manage developer accounts efficiently. Our GitHub Enterprise Adoption Framework offers a valuable solution in this regard, providing guidance to organizations on identity management options available when using the GitHub Enterprise platform.

In this blog, we will be focusing on one aspect of the framework, Identity and Access Management, which is part of the Enterprise Configuration phase:

To gain a deeper understanding of the complete process or to see the relationship of Enterprise Configuration to the broader framework, you may refer to our GitHub Enterprise Adoption Framework page. Let’s begin.

GitHub Enterprise Cloud with GitHub accounts

Once GitHub Enterprise is configured, developers can create and manage their accounts to access source code repositories owned by our organization, provided they have received an invitation. In this scenario, all accounts are managed by GitHub, so there is no need for additional configuration of identity providers. One of the most significant advantages of this approach is that developers can use their existing GitHub accounts to join our organization and work on the code. Additionally, we can invite external collaborators to our GitHub organization. An outside collaborator is someone who is not a member of our organization but has access to one or more of our organization’s repositories. We can choose the level of access to grant each outside collaborator.

However, this approach also has its downsides. Many organizations have already configured identity providers to manage employee identities, such as Azure Active Directory. In this case, the preferred solution is to create developer accounts in the identity provider and then grant access to the GitHub platform. Let’s dive into this scenario.

GitHub Enterprise Cloud with Identity provider

It’s important to note that GitHub accounts are still required, as they are mapped with the accounts from the identity provider. Outside collaborators with standard GitHub accounts can also be added to our organization on GitHub, but this can be a bit tricky to understand. So let me expand on this. First, this approach is called Single Sign-On (SSO). For GitHub, SSO can be enabled using SAML, which is an authentication protocol.

When using an external identity provider, such as Azure Active Directory or Okta, to manage user accounts on GitHub, there are two possible configuration paths:

1. We can enable integration with the identity provider on the GitHub Enterprise Account level. In this case, authentication with an account registered in the identity provider is enforced for all organizations owned by our GitHub Enterprise Account.
2. We can enable integration with the identity provider on the specific GitHub organization level. In this case, authentication with an account registered in the identity provider is enforced only for selected GitHub organizations.

It’s worth noting that SAML authentication is not required for outside collaborators.

However, this approach has one significant downside that should be considered before making a final decision on how user accounts will be managed in our organization on GitHub. Enabling SSO with an external identity provider does not replace the normal sign-in process for GitHub. Unless we use Enterprise Managed Users (which I’ll explain below), members will continue to sign in using their accounts on GitHub.com, and each personal account will be linked to their identity in the external identity provider. This means that we end up with two user identities – one in the external identity provider and one linked to it on GitHub. This is why it’s worth considering the Enterprise Managed Users option, which I’ll describe below.

GitHub Enterprise Cloud with Enterprise Managed Users

Enterprise Managed Users is a feature that enables us to control the user accounts of our GitHub Enterprise members through our identity provider, such as Azure Active Directory or Okta. When we assign users to the GitHub Enterprise Managed User application in our organization’s identity provider, they are provisioned as new user accounts on GitHub and added to our enterprise automatically. There is still a mapping between GitHub accounts and identity provider accounts, but in this model, GitHub accounts are provisioned automatically using SCIM (System for Cross-domain Identity Management). We have control over usernames, profile data, team membership, and repository access for the user accounts from our organization’s identity provider. To sum up, user lifecycle management and team member syncing are done automatically using SCIM.

However, there is one significant difference between Enterprise Managed Users and the standard SSO approach described above. In this model, there is no outside collaborators GitHub feature available. All accounts are managed by the organization’s identity provider, and SSO is enabled at the Enterprise Account level, with no option to enable it on the Organization level. Furthermore, managed user accounts cannot create public repositories, gists of any visibility, or GitHub Pages sites that are visible outside the enterprise. Developers are also unable to contribute to external repositories outside of our enterprise.

GitHub AE with isolated user accounts

With GitHub AE, all developer accounts are fully isolated from other services, including products from GitHub.com. Users are solely managed by the organization’s identity provider. GitHub AE uses SAML SSO for authentication, and enterprise owners must configure SAML SSO with a SAML identity provider during the initialization of the GitHub AE instance. Like Enterprise Managed Users, user lifecycle management and team member syncing are done automatically using SCIM (System for Cross-domain Identity Management). There is no outside collaborators GitHub feature available in this model, and developers cannot contribute to external repositories outside of our enterprise.

GitHub AE can be an excellent option for customers with stringent security and compliance requirements. It’s worth noting that GitHub AE is deployed to the Microsoft Azure cloud region, which means that it’s a fully managed service, hosted in a high-availability architecture, but with restrictions and more control over the product.

Summary

In conclusion, identity management for GitHub Enterprise users plays a crucial role in adopting the tool. This article examined four available options for managing user identities: GitHub Enterprise Cloud with GitHub accounts, GitHub Enterprise Cloud with an identity provider, GitHub Enterprise Cloud with Enterprise Managed Users, and GitHub AE with isolated user accounts. Each option offers unique benefits and drawbacks and is suited to meet specific organizational requirements.

GitHub Enterprise Cloud with GitHub accounts is the standard approach, where all user accounts are managed by GitHub, with no external identity management solution used. GitHub Enterprise Cloud with an identity provider can be a good option when we want to centrally manage users with an identity provider while also providing access to external collaborators who use standard GitHub.com accounts. This approach is also flexible, as we can decide which GitHub organizations we want to secure access with an identity provider and which can be accessed with standard GitHub.com accounts. If our goal is to increase isolation levels and we do not need external users to access repositories in our organization, GitHub Enterprise Cloud with Enterprise Managed Users can be a good choice. With this approach, we centrally manage users with an identity provider, and access with standard GitHub.com accounts is disabled. In case we have stringent security and compliance requirements, we can use GitHub AE with isolated user accounts. These are centrally managed by our organization’s identity provider, with external GitHub.com accounts isolated and unavailable, so the external collaborators feature does not exist.

It’s important to note that the options presented in this article are just a small part of the larger Enterprise Adoption Framework. As the Formula5 team, we are always happy to help you make the right decision at any level of your GitHub adoption journey.