Skip to main content
설명서에 자주 업데이트를 게시하며 이 페이지의 번역이 계속 진행 중일 수 있습니다. 최신 정보는 영어 설명서를 참조하세요.
GitHub AE는 현재 제한된 릴리스에 있습니다.

엔터프라이즈용 SCIM을 사용하여 사용자 프로비저닝 구성

GitHub AE에 대해 SCIM(도메인 간 ID 관리)을 구성할 수 있습니다. GitHub AE에 대한 애플리케이션을 IdP(ID 공급자)의 사용자에게 할당할 때 사용자 계정을 자동으로 프로비전합니다.

이 기능을 사용할 수 있는 사용자

Enterprise owners can configure user provisioning for an enterprise on GitHub AE.

About user provisioning for GitHub AE

GitHub AE uses SAML SSO for user authentication. You can centrally manage access to GitHub AE from an IdP that supports the SAML 2.0 standard. For more information, see "Configuring SAML single sign-on for your enterprise."

You can configure SCIM to automatically create or suspend user accounts and grant access for GitHub AE when you assign or unassign the application on your IdP. For more information about SCIM, see System for Cross-domain Identity Management: Protocol (RFC 7644) on the IETF website.

If you do not configure user provisioning with SCIM, your IdP will not communicate with GitHub AE automatically when you assign or unassign the application to a user. Without SCIM, GitHub AE creates a user account using SAML Just-in-Time (JIT) provisioning the first time someone navigates to GitHub AE and signs in by authenticating through your IdP.

Configuring provisioning allows your IdP to communicate with your enterprise when you assign or unassign the application for GitHub AE to a user on your IdP. When you assign the application, your IdP will prompt your enterprise to create an account and send an onboarding email to the user. When you unassign the application, your IdP will communicate with GitHub AE to invalidate any SAML sessions and disable the member's account.

To configure provisioning for your enterprise, you must enable provisioning on GitHub AE, then install and configure a provisioning application on your IdP.

About identities and claims

After an IdP administrator grants a person access to your enterprise, the user can authenticate through the IdP to access GitHub AE using SAML SSO.

During authentication, GitHub AE attempts to associate the user with a SAML identity. By default, GitHub AE compares the NameID claim from the IdP to the account's username. GitHub AE normalizes the value of NameID for the comparison. For more information about username normalization, see "Username considerations for external authentication."

If there is no existing account with a matching username on the instance, the user will fail to sign in.

If GitHub AE successfully identifies a user from the IdP, but account details such as email address, first name, or last name don't match, the instance overwrites the details with values from the IdP. Any email addresses other than the primary email provisioned by SCIM will also be deleted from the user account.

Supported identity providers

The following IdPs support user provisioning with SCIM for GitHub AE.

Note: GitHub AE single sign-on (SSO) support for Okta is currently in beta.

IdPSAMLUser provisioningTeam mapping
Azure Active Directory (Azure AD)
Okta Beta Beta Beta

For IdPs that support team mapping, you can assign or unassign the application for GitHub AE to groups of users in your IdP. These groups are then available to organization owners and team maintainers in your enterprise to map to GitHub AE teams. For more information, see "Mapping Okta groups to teams."


  • You must configure SAML SSO when you initialize GitHub AE. For more information, see "Initializing GitHub AE."
  • You must have administrative access on your IdP to configure the application for user provisioning for GitHub AE.

Enabling user provisioning for your enterprise

  1. While signed into your enterprise as an enterprise owner, create a personal access token with admin:enterprise scope. For more information, see "Creating a personal access token."


    • To create the personal access token, we recommend using the account for the first enterprise owner that you created during initialization. For more information, see "Initializing GitHub AE."
    • You'll need this personal access token to configure the application for SCIM on your IdP. Store the token securely in a password manager until you need the token again later in these instructions.

    Warning: If the user account for the enterprise owner who creates the personal access token is deactivated or deprovisioned, your IdP will no longer provision and deprovision user accounts for your enterprise automatically. Another enterprise owner must create a new personal access token and reconfigure provisioning on the IdP.

  2. In the top-right corner of GitHub AE, click your profile photo, then click Enterprise settings.

    A screenshot of the drop-down menu that appears when you click the profile photo on GitHub Enterprise Server. The "Enterprise settings" option is highlighted in a dark orange outline.

  3. In the enterprise account sidebar, click Settings.

  4. Under Settings, click Authentication security.

  5. Under "SCIM User Provisioning", select Require SCIM user provisioning.

  6. Click Save.

  7. Configure user provisioning in the application for GitHub AE on your IdP.

    The following IdPs provide documentation about configuring provisioning for GitHub AE. If your IdP isn't listed, please contact your IdP to request support for GitHub AE.

    IdPMore information
    Azure ADTutorial: Configure GitHub AE for automatic user provisioning in the Microsoft Docs. To configure Azure AD for GitHub AE, see "Configuring authentication and provisioning for your enterprise using Azure AD."
    Okta(beta) To configure Okta for GitHub AE, see "Configuring authentication and provisioning for your enterprise using Okta."

    The application on your IdP requires two values to provision or deprovision user accounts on your enterprise.

    ValueOther namesDescriptionExample
    URLTenant URLURL to the SCIM provisioning API for your enterprise on GitHub AEhttps://HOSTNAME/api/v3/scim/v2
    Shared secretPersonal access token, secret tokenToken for application on your IdP to perform provisioning tasks on behalf of an enterprise ownerPersonal access token you created in step 1