About user provisioning with SCIM on GitHub Enterprise Server

GitHub Enterprise Server のユーザープロビジョニングについて

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

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

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

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

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

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

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

Microsoft Entra ID
Okta
PingFederate (ベータ)

認証とプロビジョニングの両方に 1 つのパートナー IdP を使用するとき、GitHub は、パートナー IdP でアプリケーションにサポートに加え、GitHub で IdP の統合を提供します。 PingFederate のサポートは、パブリックプレビューにあります。

他の ID 管理システム

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

GitHub の統合ガイドラインに従う
SAML 2.0 仕様に従って SAML を使用した認証を提供する
SCIM を使用したユーザーライフサイクル管理を提供し、SCIM 2.0 仕様に準拠して、GitHub の REST API と通信する (「REST API を使用した SCIM でユーザーとグループのプロビジョニング」を参照)

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

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

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

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

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

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

の右上で、ご自分のプロフィールフォトをクリックしてから、 [Enterprise 設定] をクリックします。
ページの上部にある [ People] をクリックします。
[Suspended Members] をクリックします。

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

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

SAML マッピングを持つ既存のユーザーは、自身の ID が SCIM によってプロビジョニングされるまで、サインインすることはできません。
組み込み認証で作成された既存のユーザーは、組み込み認証がまだ有効になっている場合にのみサインインできます。
GitHub Enterprise Server は、ユーザーの SAML マッピングを格納しなくなります。代わりに、ユーザーのプロビジョニング時に SCIM ID がユーザーに対して格納されます。
ユーザーの https://HOSTNAME/users/USER/security サイト管理者ページに [SAML authentication] セクションが表示されなくなります。このセクションで以前に表示されていた 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 にリンクします。
既存のユーザーアカウントで SAML を介して認証されたユーザーが GitHub による照合に成功しても、メールアドレスや姓名などのアカウントの詳しい内容が一致しない場合は、インスタンスによって、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 は、IdP (または構成した別の値) からの正規化された NameID 要求をアカウントのユーザー名と比較します。正規化について詳しくは、「外部認証のユーザー名に関する考慮事項」をご覧ください。
インスタンスに一致するユーザー名を持つアカウントがない場合、ユーザーはログインに失敗します。
- この照合を行うために、GitHub Enterprise Server により、IdP からの SAML NameId 要求と、インスタンス上の SCIM によってプロビジョニングされた各ユーザーアカウントの SCIM userName 属性が比較されます。
- さらに、Entra ID の場合、GitHub Enterprise Server により、SAML 要求のオブジェクト識別子が既存の SCIM 外部 ID と比較されます。
環境でユーザーを一意的に識別するために NameID を使用しない場合は、サイト管理者がインスタンスのカスタムユーザー属性を構成できます。 SCIM の構成時には、GitHub Enterprise Server によってこのマッピングが考慮されます。ユーザー属性のマッピングについて詳しくは、「Enterprise 向けの SAML シングルサインオンを設定する」をご覧ください。

SCIM を無効にする方法

SCIM を無効にするさまざまな方法の詳細については、「ユーザーに対する SCIM プロビジョニングの無効化」を参照してください。

概要

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

「About user provisioning with SCIM on GitHub Enterprise Server」で、使用する IdP に関係なく、必要な初期セットアップを完了します。
IdP で設定を構成します。
- 認証とプロビジョニングにパートナー IdP を使用している場合は、IdP のガイドに従います。
- それ以外の場合は、「REST API を使用した SCIM でユーザーとグループのプロビジョニング」で説明されているように、REST API との SCIM 統合を設定します。

About user provisioning with SCIM on GitHub Enterprise Server

この記事の内容