Skip to main content

現在、GitHub AE は限定的リリースです。

Enterprise 用の SCIM を使用したユーザーのプロビジョニングを構成する

GitHub AE 用のクロスドメイン ID 管理システム (SCIM) を構成できます。これにより、GitHub AE用のアプリケーションを ID プロバイダー (IdP) のユーザーに割り当てる場合、ユーザー アカウントが自動的にプロビジョニングされます。

この機能を使用できるユーザー

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."

Prerequisites

  • 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 "Managing your personal access tokens."

    Notes:

    • 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 Enterprise Server, click your profile photo, then click Enterprise settings.

    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