Skip to content

Commit

Permalink
Make "Choosing an enterprise type for GitHub Enterprise Cloud" scanna…
Browse files Browse the repository at this point in the history
…ble (#50951)

Co-authored-by: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com>
  • Loading branch information
2 people authored and pull[bot] committed Jun 25, 2024
1 parent 17f99cc commit 39773e0
Showing 1 changed file with 42 additions and 29 deletions.
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Choosing an enterprise type for GitHub Enterprise Cloud
shortTitle: Choosing an enterprise type
intro: "To decide how people will access your company's resources on {% data variables.product.product_name %}, ask yourself some questions about the needs and workflows of your company, administrators, and users."
intro: "Decide whether {% data variables.product.prodname_emus %} is right for your enterprise by asking yourself some questions."
versions:
ghec: '*'
type: overview
Expand All @@ -16,60 +16,73 @@ redirect_from:
- /admin/identity-and-access-management/managing-iam-for-your-enterprise/identifying-the-best-authentication-method-for-your-enterprise
---

## About types of enterprises
**Before** you create your enterprise account, you must choose an enterprise type:

Before you start using {% data variables.product.product_name %}, you must decide how members of your enterprise will access your company's data, such as organizations, repositories, issues, and pull requests.
- Enterprise with personal accounts
- Enterprise with managed users

On {% data variables.product.product_name %}, your enterprise account is a central place for your users to collaborate. An enterprise account is also where you secure, administer, and govern access to your company's data. For more information, see "[AUTOTITLE](/admin/managing-your-enterprise-account/about-enterprise-accounts)."
To decide which is best for your enterprise, ask yourself the following questions.

The features and functionality available to your users depend on which type of enterprise you create. You can choose one of the two following types of enterprises:
## Do you want to control users' accounts?

| Type of enterprise | User identity | Authentication | Provisioning |
| :- | :- | :- | :- |
| Enterprise with personal accounts on {% data variables.product.prodname_dotcom_the_website %} | Existing personal account on {% data variables.product.prodname_dotcom_the_website %} | <ul><li>Username and password for {% data variables.product.prodname_dotcom_the_website %}</li><li>Optionally, additional Security Assertion Markup Language (SAML) authentication through your external identity management system</li></ul> | <ul><li>None; users own accounts, and enterprise and organization owners grant membership manually</li><li>Optionally, use System for Cross-domain Identity Management (SCIM) from your identity management system to provision access to individual organizations that use SAML authentication</li></ul> |
| Enterprise with managed users | Managed by your external identity management system | <ul><li>SAML</li><li>OpenID Connect (OIDC), if you use Microsoft Entra ID (previously known as Azure AD)</li></ul> | <ul><li>SCIM from your identity management system</li></ul> |
{% data variables.product.prodname_emus %} may be right for your enterprise if you **don't want enterprise members to use their own personal accounts** to access your enterprise's resources.

If your company is new to {% data variables.product.product_name %}, enterprises with personal accounts and {% data variables.product.prodname_emus %} are equally easy to adopt.
### Managed users

To maintain a presence in the open source community while practicing innersource in a managed environment, some companies maintain repositories within an existing enterprise with personal accounts on {% data variables.location.product_location %}, and also create a separate {% data variables.enterprise.prodname_emu_enterprise %}.
{% data variables.product.prodname_emus %} provides a true SSO experience for users:
- You provision the accounts for your users.
- You ensure that user accounts conform with your company identity, by controlling usernames and email addresses.
- Users must authenticate with your identity management system, using SAML or OIDC.

To choose the type of enterprise that will best serve you and your users, ask yourself the following questions.
If you currently require your users to create a new personal account on {% data variables.product.prodname_dotcom_the_website %} to contribute to your company's resources, {% data variables.product.prodname_emus %} might be a better alternative.

## Do you want to control the user accounts for your users?
### Personal accounts

{% data variables.product.prodname_emus %} may be right for your enterprise if you don't want enterprise members to use their own personal accounts on {% data variables.product.prodname_dotcom_the_website %} to access your enterprise's resources.
If you do not choose {% data variables.product.prodname_emus %}:
- Each user must create, manage, and sign in to a **personal account** on {% data variables.product.prodname_dotcom_the_website %}.
- You can configure SAML authentication so that users must **also** authenticate to your external identity management system. {% data variables.product.prodname_dotcom %} links the user's personal account to an external identity on the identity management system.
- User provisioning is not available. You can use System for Cross-domain Identity Management (SCIM) to provision **access** to individual organizations.

{% data variables.product.prodname_emus %} provides a true SSO experience for users. If you choose {% data variables.product.prodname_emus %}, you will provision the accounts for your users, and users will not need to sign into a separate user account. You can also ensure that these user accounts conform with your company identity by controlling usernames and the email addresses associated with the accounts.
Consider personal accounts if using your external identity management system as the source of truth for user and access management would add too much complexity. For example, you do not have an established process for onboarding new users in the system.

If you do not choose {% data variables.product.prodname_emus %}, each user must create, manage, and sign in to a personal account on {% data variables.product.prodname_dotcom_the_website %}. You can configure SAML authentication so that users must authenticate to your external identity management system in addition to signing in to a personal account. After successful SAML authentication, {% data variables.product.prodname_dotcom %} links the user's personal account to an external identity on the identity management system.
## Is your external identity management system supported?

If you currently require your users to create a new personal account on {% data variables.product.prodname_dotcom_the_website %} to contribute to your company's resources, {% data variables.product.prodname_emus %} might be a better alternative. If using your external identity management system as the source of truth for your user and access management would add too much complexity, creating an enterprise that allows you to configure additional SAML access control for existing personal accounts on {% data variables.product.prodname_dotcom_the_website %} may be a better option. For example, perhaps your enterprise does not have an established process for onboarding new users in your identity management system.
Consider whether you already use, or can adopt, a supported identity management system.

## Is your external identity management system supported?
### Managed users

{% data variables.product.company_short %} partners with some developers of identity management systems to provide a "paved-path" integration with {% data variables.product.prodname_emus %}, which includes both authentication and provisioning.

If you cannot use a paved-path integration, you can use another identity management system that **meets our guidelines**.

For full details, see "[AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/about-enterprise-managed-users#identity-management-systems)."

### Personal accounts

{% data reusables.enterprise_user_management.ghec-supported-idps %}
You can use any external identity management system that adheres to the **SAML 2.0** standard.

## Do your users work in public repositories, gists, or {% data variables.product.prodname_pages %} sites?
{% data variables.product.company_short %} officially supports and tests some systems. See "[AUTOTITLE](/admin/identity-and-access-management/using-saml-for-enterprise-iam/configuring-saml-single-sign-on-for-your-enterprise#supported-identity-providers)."

To prevent enterprise members from accidentally leaking corporate-owned content to the public on {% data variables.product.prodname_dotcom_the_website %}, {% data variables.product.prodname_emus %} imposes strong restrictions on what users can do. For example, {% data variables.enterprise.prodname_managed_users %} cannot create public repositories, gists of any visibility, or {% data variables.product.prodname_pages %} sites that are visible outside the enterprise. For a full list of restrictions, see "[AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/abilities-and-restrictions-of-managed-user-accounts)."
## Do you need public repositories, gists, or {% data variables.product.prodname_pages %} sites?

These restrictions are unacceptable for some enterprises. To determine whether {% data variables.product.prodname_emus %} will work for you, review the restrictions with your users, and confirm whether any of the restrictions will hinder your existing workflows. If so, an enterprise with personal accounts may be a better choice for your enterprise.
To prevent enterprise members from accidentally leaking corporate-owned content to the public, {% data variables.product.prodname_emus %} imposes **strong restrictions** on what users can do.
- {% data variables.enterprise.prodname_managed_users_caps %} cannot create public repositories, gists of any visibility, or {% data variables.product.prodname_pages %} sites that are visible outside the enterprise.
- For a full list of restrictions, see "[AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/abilities-and-restrictions-of-managed-user-accounts)."

## Do your users rely on collaboration outside of your enterprise?
Review the restrictions with your users, and confirm whether they will hinder your existing workflows. If so, an enterprise with personal accounts may be a better choice.

{% data variables.enterprise.prodname_managed_users_caps %} can only contribute to repositories within your enterprise. If your developers must contribute to repositories both within and outside of your enterprise, including private repositories, {% data variables.product.prodname_emus %} may not be right for your enterprise. An enterprise with personal accounts may be a better solution.
## Do you require collaboration outside of your enterprise?

If your company maintains repositories within an existing enterprise with personal accounts on {% data variables.location.product_location %}, and also creates a separate {% data variables.enterprise.prodname_emu_enterprise %}, users who contribute to repositories owned by both enterprises from a single workstation must switch between the accounts on {% data variables.location.product_location %} within their browser. The user may also need to customize the workstation's Git configuration to accommodate the two accounts. The complexity of this workflow can increase the risk of mistakenly leaking internal code to the public.
{% data variables.enterprise.prodname_managed_users_caps %} can only contribute to repositories within your enterprise. If your developers must contribute to repositories outside of your enterprise (including private repositories), {% data variables.product.prodname_emus %} may not be right for you.

If you choose {% data variables.product.prodname_emus %} but require that users contribute to resources outside of the enterprise from a single workstation, you can provide support for switching between the accounts in a user's local Git configuration. For more information, see "[AUTOTITLE](/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/about-enterprise-managed-users#supporting-developers-with-multiple-user-accounts-on-githubcom)."
For a managed user to collaborate outside your enterprise, they must also maintain a separate, personal account. The complexity of regularly switching between accounts can increase the risk of mistakenly leaking internal code to the public. For details of the required workflow, see "[AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/getting-started-with-enterprise-managed-users#support-developers-with-multiple-user-accounts)."

## Can your enterprise tolerate migration costs?

If you already have an enterprise that uses personal accounts on {% data variables.product.prodname_dotcom_the_website %}, adoption of {% data variables.product.prodname_emus %} requires migration to a new enterprise account. For more information, see "[AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/getting-started-with-enterprise-managed-users)."
If you already have an enterprise that uses personal accounts on {% data variables.product.prodname_dotcom_the_website %}, adoption of {% data variables.product.prodname_emus %} requires **migration to a new enterprise account**. To discuss this process, contact [{% data variables.product.prodname_dotcom %}'s Sales team](https://enterprise.github.com/contact).

Although {% data variables.product.prodname_emus %} does not differ in cost from an enterprise that uses personal accounts, the migration process may require time or cost from your team. Confirm that this migration process is acceptable to your business and your users. If not, an enterprise with personal accounts may be the better choice for you.
The migration process may require time or cost from your team. Confirm that this migration process is acceptable to your business and your users. If not, an enterprise with personal accounts may be the better choice.

## Further reading

- "[AUTOTITLE](/admin/identity-and-access-management/understanding-iam-for-enterprises/about-identity-and-access-management)"
- "[AUTOTITLE](/admin/identity-and-access-management/using-saml-for-enterprise-iam/deciding-whether-to-configure-saml-for-your-enterprise-or-your-organizations)"

0 comments on commit 39773e0

Please sign in to comment.