With Enterprise Managed Users, you manage the lifecycle and authentication of your users on GitHub from an external identity management system, or IdP:
- Your IdP provisions new user accounts on GitHub, with access to your enterprise.
- Users must authenticate on your IdP to access your enterprise's resources on GitHub.
- You control usernames, profile data, organization membership, and repository access from your IdP.
- If your enterprise uses OIDC SSO, GitHub will validate access to your enterprise and its resources using your IdP's Conditional Access Policy (CAP). See "About support for your IdP's Conditional Access Policy."
- Managed user accounts cannot create public content or collaborate outside your enterprise. See "Abilities and restrictions of managed user accounts."
Note
Enterprise Managed Users is not the best solution for every customer. To determine whether it's right for your enterprise, see "Choosing an enterprise type for GitHub Enterprise Cloud."
Identity management systems
GitHub partners with some developers of identity management systems to provide a "paved-path" integration with Enterprise Managed Users. To simplify your configuration and ensure full support, use a single partner IdP for both authentication and provisioning.
Partner identity providers
Partner IdPs provide authentication using SAML or OIDC, and provide provisioning with System for Cross-domain Identity Management (SCIM).
| Partner IdP | SAML | OIDC | SCIM |
|---|---|---|---|
| Entra ID | |||
| Okta | |||
| PingFederate |
When you use a single partner IdP for both authentication and provisioning, GitHub provides support for the application on the partner IdP and the IdP's integration with GitHub.
Other identity management systems
If you cannot use a single partner IdP for both authentication and provisioning, you can use another identity management system or combination of systems. The system must:
- Adhere to GitHub's integration guidelines
- Provide authentication using SAML, adhering to SAML 2.0 specification
- Provide user lifecycle management using SCIM, adhering to the SCIM 2.0 specification and communicating with GitHub's REST API (see "Provisioning users and groups with SCIM using the REST API")
Note
Provisioning users with GitHub's public SCIM schema is in public beta and subject to change.
GitHub does not expressly support mixing and matching partner IdPs for authentication and provisioning and does not test all identity management systems. GitHub's support team may not be able to assist you with issues related to mixed or untested systems. If you need help, you must consult the system's documentation, support team, or other resources.
Usernames and profile information
GitHub automatically creates a username for each developer by normalizing an identifier provided by your IdP. If the unique parts of the identifier are removed during normalization, a conflict may occur. See "Username considerations for external authentication."
The profile name and email address of a managed user account is provided by the IdP:
- Managed user accounts cannot change their profile name or email address on GitHub.
- The IdP can only provide one email address.
- Changing a user's email address in your IdP will delink the user from the contribution history associated with the old email address.
Managing roles and access
In your IdP, you can give each managed user account a role in your enterprise, such as member, owner, or guest collaborator. See "Roles in an enterprise."
Organization memberships (and repository access) can be managed manually, or you can update memberships automatically using IdP groups. See "Managing team memberships with identity provider groups."
Authentication for managed user accounts
The locations where managed user accounts can authenticate to GitHub depends on how you configure authentication (SAML or OIDC). See "Authenticating with Enterprise Managed Users."
By default, when an unauthenticated user attempts to access your enterprise, GitHub displays a 404 error. You can optionally enable automatic redirects to single sign-on (SSO) instead. See "Enforcing policies for security settings in your enterprise."