关于企业身份验证
GitHub Enterprise Cloud 上的企业所有者可以控制对企业资源的身份验证和访问权限的要求。
可以选择允许成员创建和管理用户帐户，或者企业可以使用 Enterprise Managed Users 为成员创建和管理帐户。 如果你允许成员管理自己的帐户，还可以配置 SAML 身份验证，以提高团队使用的 Web 应用程序的安全性并集中管理标识和访问权限。
详细了解这些选项后，要确定哪种方法最适合企业，请参阅“确定企业的最佳身份验证方法”。
GitHub Enterprise Cloud 的身份验证方法
以下选项可用于在 GitHub Enterprise Cloud 上进行帐户管理和身份验证。
通过 GitHub.com 进行身份验证
默认情况下，每个成员必须在 GitHub.com 上创建个人帐户。 你授予对企业的访问权限，成员在 GitHub.com 上登录帐户后方可访问企业资源。 成员管理帐户，并且可以为 GitHub.com 上的其他企业、组织和存储库做出贡献。
通过 GitHub.com 进行身份验证，并具有其他 SAML 访问限制
如果配置其他 SAML 访问限制，每个成员就必须在 GitHub.com 上创建和管理个人帐户。 你授予对企业的访问权限，成员在 GitHub.com 上登录帐户并成功通过 SAML 标识提供者 (IdP) 进行身份验证后，方可访问企业资源。 成员可以使用其个人帐户为 GitHub.com 上的其他企业、组织和存储库做出贡献。 有关要求对所有企业资源访问进行 SAML 身份验证的详细信息，请参阅“关于企业 IAM 的 SAML”。
可选择在企业级别配置 SAML（将同一 SAML 配置应用于企业中的所有组织），或者为单个组织单独配置 SAML。 有关详细信息，请参阅“决定是在企业级别还是组织级别配置 SAML”。
使用 Enterprise Managed Users 和联合方法进行身份验证
如果需要对 GitHub.com 上的企业成员的帐户进行更多控制，可以使用 Enterprise Managed Users。 使用 Enterprise Managed Users 时，可以使用 IdP 在 GitHub.com 上为企业成员预配和管理帐户。 每个成员会登录到你创建的帐户，由企业管理该帐户。 对 GitHub.com 的其余部分的贡献受到限制。 有关详细信息，请参阅“关于 Enterprise Managed Users”。
确定企业的最佳身份验证方法
SAML SSO 和 Enterprise Managed Users 都可增强企业资源的安全性。 Enterprise Managed Users 还可用于控制企业成员的用户帐户并限制帐户可以执行的操作。 但如果这些限制阻碍了开发人员的工作流，这些限制可能得不到企业的承认。
要确定企业是更多地受益于 SAML SSO 还是 Enterprise Managed Users，请考虑以下问题。
是否希望控制用户的用户帐户？
如果你不希望企业成员在 GitHub.com 上使用其自己的个人帐户来访问企业资源，则 Enterprise Managed Users 可能适合你的企业。
借助 SAML SSO，开发人员可以创建和管理其自己的个人帐户，并且每个帐户都链接到 IdP 中的 SAML 标识。 Enterprise Managed Users 的功能更像其他熟悉的 SSO 解决方案，因为你可以为用户预配帐户。 还可通过控制与帐户关联的用户名和电子邮件地址，确保用户帐户符合公司标识。
如果你当前要求用户在 GitHub.com 上创建新帐户以仅在你的企业中使用，则 Enterprise Managed Users 可能更适合你。 但是，如果将 IdP 用作用户和访问管理的真相源，则 SAML SSO 可能是更好的选择，因为它可以显著降低复杂性。 例如，也许你的企业没有在 IdP 中加入新用户的既定流程。
企业使用的标识提供者是什么？
Enterprise Managed Users 支持有限数量的 IdP，并且需要 SCIM，而 SAML SSO 充分支持大量 IdP，并对所有实施 SAML 2.0 标准的 IdP 提供有限支持，并且不需要 SCIM。 有关每个选项支持的 IdP 列表，请参阅“关于 Enterprise Managed Users”和“关于企业 IAM 的 SAML”。
仅当将不受支持的 IdP 联合到受支持的 IdP 以用作集成点时，才能将 Enterprise Managed Users 与不受支持的 IdP 一起使用。 如果想要避免这种额外的复杂性，SAML SSO 可能是更好的解决方案。
开发人员是在公共存储库、Gist 还是在 GitHub Pages 站点上工作？
为防止企业成员在 GitHub.com 上意外将企业拥有的内容泄露给公众，Enterprise Managed Users 对用户可执行的操作施加了严格的限制。 例如，托管用户帐户 无法创建公共存储库、任何可见性的 Gist 或在企业外部可见的 GitHub Pages 站点。 有关限制的完整列表，请参阅“关于 Enterprise Managed Users”。
某些企业可能无法接受这些限制。 要确定 Enterprise Managed Users 是否适合你，请与你的开发人员一起查看限制，并确认任何限制是否会阻碍你现有的工作流。 如果会，SAML SSO 可能是企业更好的选择。
开发人员是否依赖于企业外部的协作？
托管用户帐户 仅适用于企业内的存储库。 如果开发人员必须参与企业内外的存储库（包括专用存储库），则 Enterprise Managed Users 可能不适合你的企业。 SAML SSO 可能是更好的解决方案。
某些公司在 GitHub.com 上使用 SAML SSO 维护现有企业中的存储库，还会创建 具有托管用户的企业。 从单个工作站参与两个企业拥有的存储库的开发人员必须在单个浏览器中，在 GitHub.com 上的帐户之间切换，或者为每个帐户使用不同的浏览器。 开发人员可能还需要自定义工作站的 Git 配置，以适应这两个帐户。 此工作流的复杂性可能会增加错误地将内部代码泄露给公众的风险。
如果你决定创建 具有托管用户的企业，但要求开发人员从单个工作站参与企业外部的资源，可以在开发人员的本地 Git 配置中为帐户之间的切换提供支持。 有关详细信息，请参阅“关于 Enterprise Managed Users”。
企业是否依赖于外部协作者？
借助 SAML SSO，可使用外部协作者角色向非 IdP 目录成员的人员授予对特定存储库的访问权限。 这对于企业外部的合作者（如承包商）尤其有用。 有关详细信息，请参阅“添加外部协作者到组织的仓库”。
使用 Enterprise Managed Users 时，不存在外部协作者角色。 企业资源只能被 托管用户帐户 访问，后者始终由 IdP 预配。 要让外部合作者访问你的企业，必须在 IdP 中使用来宾帐户。 如果你对 Enterprise Managed Users 感兴趣，请与开发人员确认这是否会妨碍其任何现有工作流。 如果会，SAML SSO 可能是更好的解决方案。
企业能否容忍迁移成本？
如果企业不熟悉 GitHub.com，SAML SSO 和 Enterprise Managed Users 同样易于采用。
如果已与管理其自己的用户帐户的开发人员一起使用 GitHub.com，则采用 Enterprise Managed Users 时需要迁移到新的企业帐户。 有关详细信息，请参阅“关于 Enterprise Managed Users”。
虽然 Enterprise Managed Users 是免费的，但迁移过程可能需要团队付出时间或成本。 确认你的企业和开发人员可以接受此迁移过程。 如果无法接受，SAML SSO 可能是更好的选择。
决定是在企业级别还是组织级别配置 SAML
如果决定使用 SAML 而不是 Enterprise Managed Users，则必须决定是在企业级别还是组织级别配置 SAML。
如果企业中的一些组必须使用不同的 SAML 身份验证提供程序来授予对 GitHub.com 上资源的访问权限，请为独立组织配置 SAML。 通过允许用户使用 SAML 逐步进行身份验证，可以为组织逐步实现 SAML。 或者，可以在特定日期前要求进行 SAML 身份验证。 在此日期前未使用 SAML 进行身份验证的组织成员将被删除。 有关组织级别 SAML 的详细信息，请参阅“关于使用 SAML 单一登录进行的标识和访问管理”。
如果在组织级别配置 SAML，则成员无需通过 SAML 进行身份验证即可访问内部存储库。 有关内部存储库的详细信息，请参阅“关于仓库”。
如果需要为企业中的每个组织保护内部存储库或强制实施一致的身份验证体验，可转而为企业帐户配置 SAML 身份验证。 企业的 SAML 配置优先于单个组织的任何 SAML 配置，组织配置不能优先于企业配置。 为企业配置 SAML 后，组织成员必须先使用 SAML 进行身份验证，然后才能访问组织资源（包括内部存储库）。
SCIM 不适用于企业帐户，并且团队同步仅适用于企业级别的 SAML（如果使用 Azure AD 作为 IdP）。 有关详细信息，请参阅“管理企业中组织的团队同步”。
无论选择哪种 SAML 实现方式，都不能将外部协作者添加到组织或团队。 只能将外部协作者添加到单个存储库中。