GitHub Enterprise Server での SCIM を使用したユーザー プロビジョニングについて

お使いの GitHub Enterprise Server インスタンスで SCIM を使用してユーザー アカウントのライフサイクルを管理する方法について説明します。

この記事で

GitHub Enterprise Server のユーザー プロビジョニングに関する情報

お使いの GitHub Enterprise Server インスタンスに SAML シングル サインオン (SSO) を使用する場合は、IDP でアプリケーションを割り当てるか割り当て解除するときに、ユーザー アカウントを自動的に作成または中断し、インスタンスへのアクセスを許可するように SCIM を構成できます。 SCIM の詳細については、IETF の Web サイトの「クロスドメインの ID 管理用システム: プロトコル (RFC 7644)」を参照してください。

SCIM を使用してユーザー プロビジョニングを構成しない場合、アプリケーションをユーザーに割り当てたり割り当てを解除したりしても、IdP は自動的に GitHub Enterprise Server と通信しません。 SCIM がない場合、 GitHub Enterprise Server は SAML Just-in-Time (JIT) プロビジョニングを使用してユーザー アカウントを作成し、ユーザーが初めて GitHub Enterprise Server に移動し、IdP を介して認証してサインインします。

企業のプロビジョニングを構成するには、 GitHub Enterprise Serverでプロビジョニングを有効にしてから、IdP にプロビジョニング アプリケーションをインストールして構成するか、SCIM 用に GitHubの REST API エンドポイントを使用して SCIM プロビジョニングを手動で構成する必要があります。

サポートされているアイデンティティプロバイダ

GitHub は、ID 管理システムの一部の開発者と提携し、GitHub Enterprise Server との「舗装されたパス」統合を提供します。 構成を簡略化して完全なサポートを確保するため、認証とプロビジョニングの両方に単一のパートナー IdP を使用します。

パートナー ID プロバイダー

次の IdP はパートナー IdP です。 SAML 認証と SCIM プロビジョニングの両方の構成に使用できるアプリケーションが用意されています。

  • Microsoft Entra ID
  • Okta
  • PingFederate (パブリック プレビュー)

認証とプロビジョニングの両方に 1 つのパートナー IdP を使用する場合、 GitHub はパートナー IdP 上のアプリケーションと IdP と GitHub の統合をサポートします。 SAML 認証と SCIM プロビジョニングの両方に同じアプリケーションを使用する必要があります。 PingFederate のサポートは パブリック プレビュー にあります。

Azure Governmentに Entra ID を使用する場合、サポートされているパートナー アプリケーションはありません。

他の ID 管理システム

認証とプロビジョニングの両方に 1 つのパートナー IdP を使用できない場合、別の ID 管理システムまたはシステムの組み合わせを使用できます。 システムは次を実行する必要があります。

SCIM を使用したユーザー ライフサイクルの管理方法

SCIM を使用すると、IdP からユーザー アカウントのライフサイクルを管理できます。

  • 新しいユーザーをプロビジョニングすると、IdP はお使いの GitHub Enterprise Server インスタンスアカウントを作成し、オンボードメールをユーザーに送信するように求められます。 IdP 内のアプリケーションにグループを割り当てると、IdP はグループのすべてのメンバーのアカウントをプロビジョニングします。
  • IdP でユーザーの ID に関連付けられている情報を更新すると、IdP は GitHubでユーザーのアカウントを更新します。
  • IdP アプリケーションからユーザーの割り当てを解除するか、IdP でユーザーのアカウントを非アクティブ化すると、IdP は GitHub と通信してセッションを無効にし、メンバーのアカウントを無効にします。 無効なアカウントの情報が維持され、ユーザー名が元のユーザー名のハッシュに変更され。
  • ユーザーを IdP アプリケーションに再割り当てするか、IdP で自分のアカウントを再アクティブ化すると、ユーザー アカウントが再アクティブ化され、ユーザー名が復元されます。

チームと組織のメンバーシップ、リポジトリへのアクセス、アクセス許可を構成するには、IdP でグループを使用できます。 詳しくは、「ID プロバイダー グループを使用したチーム メンバーシップの管理」をご覧ください。

SCIM が有効になっていると、SCIM でプロビジョニングされたユーザーを GitHub Enterprise Serverで直接削除、中断、昇格することはできなくなります。 これらのプロセスは IdP から管理する必要があります。 IdP で問題が発生し、ユーザーを直接管理する必要がある場合は、SCIM REST API を使用してアプライアンス上のユーザー ID を管理する必要があります ( REST API を使用した SCIM でユーザーとグループのプロビジョニング を参照)。

一時停止されたメンバーを表示するには、[Enterprise] 設定の [一時停止メンバー] タブに移動します。 このページは、 GitHub Enterprise Serverで SCIM が有効になっている場合に表示されます。

  1. GitHub Enterprise Server の右上隅にあるプロフィール画像をクリックしてから、[Enterprise settings] をクリックします。
  2. ページ上部で、 People をクリックします。
  3. [一時停止メンバー] をクリックします。

SCIM を有効にするとどうなりますか?

現在 SAML SSO を使用していて、SCIM を有効にしている場合は、SCIM が有効になると、 GitHub Enterprise Server の既存のユーザー アカウントに対して何が起こるかを認識する必要があります。

  • SAML マッピングを持つ既存のユーザーは、自身の ID が SCIM によってプロビジョニングされるまで、サインインすることはできません。
  • 組み込み認証で作成された既存のユーザーは、組み込み認証がまだ有効になっている場合にのみサインインできます。
  • GitHub Enterprise Server では、ユーザーの SAML マッピングは格納されなくなります。 代わりに、ユーザーのプロビジョニング時に SCIM ID がユーザーに対して格納されます。
  • ユーザーの https://HOSTNAME/users/USER/security サイト管理者ページに [SAML 認証] セクションが表示されなくなります。 このセクションで以前に表示されていた SAML NameID マッピングを表示または更新することはできません。これらの保存された SAML マッピングは、SCIM が有効になっていると SAML 認証時に評価されなくなるためです。
  • インスタンスが SCIM 要求を受信すると、SCIM userName属性値と GitHub Enterprise Server ユーザー名を比較することで、SCIM ID が既存のユーザーと照合されます。 つまり、既存の GitHub Enterprise Server ユーザー アカウントは、最初にローカル ユーザー アカウントとして作成されたものであるか、SAML JIT プロビジョニングを介して作成されたかに関係なく、これら 2 つの値が一致する場合、SCIM にリンクされたユーザー アカウントに変換できます。
    • ユーザー名が一致するユーザー アカウントが存在する場合、 GitHub Enterprise Server は SCIM ID をこのユーザー アカウントにリンクします。
    • 一致するユーザー名を持つユーザー アカウントが存在しない場合、 GitHub Enterprise Server は新しいユーザー アカウントを作成し、この SCIM ID にリンクします。
  • GitHub既存のユーザー アカウントで SAML 経由で認証しているユーザーと正常に一致するが、メール アドレス、名、姓などのアカウントの詳細が一致しない場合、インスタンスは IdP の値で詳細を上書きします。 SCIM によってプロビジョニングされたプライマリ メール以外のメール アドレスも、ユーザー アカウントから削除されます。
  • CLI アクセス権を持つ Enterprise 管理者は、ghe-scim-identities-csv ツールを使用して、SCIM でプロビジョニングされたユーザー ID の完全な CSV をエクスポートできます。

SAML 認証中は何が起こりますか?

IdP 管理者がユーザーに お使いの GitHub Enterprise Server インスタンス へのアクセスを許可した後、ユーザーは IdP を介して認証し、SAML SSO を使用して GitHub Enterprise Server にアクセスできます。

  • ユーザーが SAML を使用して認証を行い、ユーザーを SAML ID に関連付ける場合、 GitHub は、正規化された NameID 要求を IdP (または構成した別の値) からアカウントのユーザー名と比較します。 正規化の詳細については、「AUTOTITLE」を参照してください。
  • インスタンスに一致するユーザー名を持つアカウントがない場合、ユーザーはログインに失敗します。
    • この一致を行うために、 GitHub Enterprise Server は、IDP からの SAML NameId 要求を、インスタンス上の SCIM によってプロビジョニングされた各ユーザー アカウントの SCIM userName 属性と比較します。
    • さらに、Entra IDの場合、GitHub Enterprise Serverは SAML 要求のオブジェクト識別子を既存の SCIM 外部 ID と比較します。
  • 環境でユーザーの一意的な識別に NameID を使用しない場合は、サイト管理者がインスタンスのカスタム ユーザー属性を構成できます。 GitHub Enterprise Server は、SCIM が設定されている場合、このマッピングに従います。 ユーザー属性のマッピング詳細については、「AUTOTITLE」を参照してください。

SCIM を無効にする方法

SCIM を無効にするさまざまな方法の詳細については、「AUTOTITLE」を参照してください。

概要

SCIM の使用を開始するには、次の作業を行います:

  1. 使用する IdP に関係なく、「AUTOTITLE」で、必要な初期設定を完了します。
  2. IdP で設定を構成します。
    • 認証とプロビジョニングにパートナー IdP を使用している場合は、IdP のガイドに従います。
    • それ以外の場合は、「AUTOTITLE」で説明されているように、REST API との SCIM 統合を設定します。