SCIM を使用したユーザーのプロビジョニング解除と復帰

お使いの GitHub Enterprise Server インスタンスで SCIM を有効にしている場合、SCIM を使用して次の操作を行います。

ユーザーとグループのプロビジョニングを解除して、アクセスできないようにします。
以前にプロビジョニング解除されたユーザーを、再プロビジョニングします。

ユーザーのプロビジョニングを解除する前に、プロビジョニング解除の効果を理解することが重要です。これは、ID プロバイダーから受け取****GitHubによって異なります。

重要

以降を読む前に、ご自分の Enterprise で SCIM がどのように実装されているかを理解しておく必要があります。 GitHub では、認証とプロビジョニングの両方にサポートされている ID プロバイダー (IdP) を使用する場合は、"paved-path" アプリケーションが提供されます。円滑パスアプリケーションをお使いでない場合は、REST API を使って SCIM の要求を行います。 GitHub Enterprise Server での SCIM を使用したユーザープロビジョニングについてを参照してください。

ユーザーのプロビジョニング解除の種類

ユーザーがプロビジョニング解除されると、 GitHub アカウントは 一時停止されます。つまり、ユーザーは企業にアクセスできません。どのプロビジョニング解除の種類でも、プロビジョニング解除されたアカウントが Enterprise から削除されることはありません。

GitHub が ID プロバイダから受け取るデプロビジョニング呼び出しの種類によって、デプロビジョニングされたユーザーの停止解除（復元）が可能かどうかが左右されます。

論理的なプロビジョニング解除: 特定のシナリオでは、SCIM 統合を通じてユーザーの一時停止を解除することができます。
物理的なプロビジョニング解除: ユーザーの一時停止を解除することはできません。ユーザーが再びアクセスする必要がある場合は、新しいアカウントをプロビジョニングする必要があります。

ユーザーのプロビジョニング解除の影響

IdP または REST API を使用してユーザーアカウントのプロビジョニングを解除すると、 GitHub はユーザーアカウントに変更を加えます。

ソフト・プロビジョニング解除の影響

ユーザーは一時停止されて、Enterprise とプライベートリソースにアクセスできなくなります。
一時停止されたユーザーアカウントは、Enterprise の設定の [People] セクションで、[Members] ページではなく [Suspended members] ページに表示されます。
ユーザーのユーザー名は、元のユーザー名をハッシュ化した値に置き換えられます上の企業向け）。
Entra ID では、ユーザーのメールアドレスは同じままです。それ以外のすべての場合、ユーザーのメールアドレスは難読化されます。
ユーザーの SCIM ID は、 GitHubのユーザーアカウントにリンクされたままです。 Entra ID では、格納されているリンクされた SCIM ID の active 属性の値が、True から False に更新されます。
ユーザーがプライベートリポジトリまたは内部リポジトリのフォークを持っている場合、フォークは 24 時間以内に削除されます。ユーザーが 90 日以内に一時停止解除された場合、フォークは復元されます。
SCIM でプロビジョニングされた IdP グループのメンバーであるユーザーは、これらのグループから隠蔽され、これらのグループにマップされているチームから削除されます。 IdP 側ではユーザーがまだグループのメンバーである場合でもこのようになることに注意してください。
Organization のメンバーシップが IdP グループによって管理されている場合、それらの IdP グループから削除されたユーザー、または IdP グループにマップされている organization 内のすべてのチームから削除されたユーザーは、organization から削除されます。
Organization のメンバーシップが直接管理されている場合、ユーザーは、手動で削除されるまで、organization のアクセス権を持たない "一時停止されたメンバー" として残ります。

ハード・デプロビジョニングの影響

ユーザーは一時停止されて、Enterprise とプライベートリソースにアクセスできなくなります。
一時停止されたユーザーアカウントは、Enterprise の設定の [People] セクションで、[Members] ページではなく [Suspended members] ページに表示されます。
ユーザーのユーザー名は、元のユーザー名をハッシュ化した値に難読化されますが続きます。
ユーザーのメールアドレスは難読化されます。
ユーザーの表示名は空の文字列に設定されます。
ユーザーのリンクされた SCIM ID は、ユーザーのすべての SCIM 属性も含めて、削除されます。
ユーザーの personal access tokens、 fine-grained personal access tokens、SSH キー、GPG キー、アプリケーション承認が削除されます。キーの削除は、コミットの検証に影響する可能性があります。「コミット署名の検証について」を参照してください。
ユーザーが所有するリポジトリは削除されます。
ユーザーによって作成されたリソース (コメントなど) は、保持されます。
SCIM でプロビジョニングされた IdP グループのメンバーであるユーザーは、これらのグループから隠蔽され、これらのグループにマップされているチームから削除されます。 IdP 側ではユーザーがまだグループのメンバーである場合でもこのようになることに注意してください。
Organization のメンバーシップが IdP グループによって管理されている場合、それらの IdP グループから削除されたユーザー、または IdP グループにマップされている organization 内のすべてのチームから削除されたユーザーは、organization から削除されます。
Organization のメンバーシップが直接管理されている場合、ユーザーは、手動で削除されるまで、organization のアクセス権を持たない "一時停止されたメンバー" として残ります。

プロビジョニング解除をトリガーするアクション

論理的プロビジョニング解除と物理的プロビジョニング解除ではそれをトリガーするアクションが異なり、トリガーは SCIM 統合によって異なります。一般に、「paved-path」IdP アプリケーションで実行するほとんどのアクションは、一部の例外を除き、ソフトディプロビジョニングのみをトリガーします。

ソフトデプロビジョニングのトリガー

SCIM 統合	ソフトデプロビジョニングのトリガー
REST API
`PUT` または `PATCH` 要求が `/scim/v2/Users/{scim_user_id}` に送信されて、ユーザーの `active` フィールドが `false` に更新されます。
保守する	ユーザーが Entra ID で無効にされるか、アプリケーションから割り当てを解除されるか、割り当てられているすべてのグループから削除されるか、管理者によってテナントから論理的に削除されます。詳しくは、Microsoft のドキュメントの「論理的な削除」をご覧ください。
Okta	ユーザーがアプリケーションから割り当てを解除されるか、割り当てられているすべてのグループから削除されるか、[Deactivate] ボタンで非アクティブ化されます。 [中断] ボタンは、 GitHubに要求を送信しないことに注意してください。 Okta では、ソフトデプロビジョニングの呼び出しのみが送信されます。
PingFederate	ユーザーが、プロビジョニング元によってターゲットにされているユーザーストアから一時停止、無効化、または削除されます。

完全プロビジョニング解除のトリガー

SCIM 統合	完全プロビジョニング解除のトリガー
REST API
`DELETE` 要求が `/scim/v2/Users/{scim_user_id}` に送信されます。
保守する	Microsoft のドキュメントの「物理的な削除」で説明されているような、Entra ID ユーザーアカウントの物理的な削除。論理的に削除された Entra ID ユーザー (Entra ID 管理ポータルの [ユーザー] > [削除済みのユーザー] ページに表示されます) は、論理的に削除されてから 30 日後に Entra ID によって自動的に物理的に削除されます。
Okta	該当なし。 Okta では、物理的プロビジョニング解除の呼び出しは送信されません。
PingFederate	構成ミスの結果として [Remove User Action] の設定が [Disable] ではなく [Delete] に設定されている場合、このアクションでは物理的プロビジョニング解除の呼び出しが送信されます。
PingIdentity のドキュメントを参照してください。

仮のプロビジョニング解除されたユーザーアカウントの回復

同じ IdP ユーザーアカウントである場合に限り、ソフトデプロビジョニングされたユーザーのアカウントを再プロビジョニングして、そのユーザーのアクセスとアカウントの詳細を復元できます。 IdPユーザーアカウントは同じである必要があります。なぜなら、ソフトプロビジョニング解除されたユーザーアカウントは、SCIMのexternal ID（IdPユーザーオブジェクトID）とSCIMのUser IDに基づいて、この外部IDにまだリンクされているからです。個別にソフトデプロビジョニングされたユーザーアカウントにリンクされている外部 ID（アイデンティティ）は変更できません。

再プロビジョニングの影響

ユーザーは一時停止を解除されて、Enterprise に再びアクセスできるようになります。
ユーザーのユーザー名とメールアドレスが復元されます。
Organization 内のチームにマップされている、SCIM によってプロビジョニングされた IdP グループのメンバーであるユーザーは、ユーザーアカウントが再プロビジョニングされた直後に organization に追加されます。以前に organization のメンバーであったユーザーのメンバーシップは、削除されてから 90 日以内であれば復帰されます。「組織の以前のメンバーの復帰」を参照してください。
ユーザーが組織内のチームにマップされている SCIM プロビジョニング IdP グループのメンバーでない場合、 GitHub 組織の所有者は、再プロビジョニング後にユーザーアカウントを手動で組織に追加する必要があります。
削除されたフォークは、一時停止から 90 日以内にユーザーが一時停止解除された場合は復元されます。
次のようなユーザーに関連付けられている項目は復元されます。
- GitHub Apps、 OAuth apps、アプリの承認
- Personal access tokens
- SSH キー
- トークンとキーの認可
- ユーザー所有のリポジトリ

再プロビジョニングをトリガーするアクション

ユーザーを再プロビジョニングする方法は、SCIM 統合と、ソフト・デプロビジョニングをトリガーしたアクションによって異なります。

SCIM の実装	ユーザーを再プロビジョニングするためのアクション
保守する	無効にされたアカウントを再び有効にするか、ユーザーを直接または割り当てられたグループを介してアプリケーションに再度割り当てます。変更が処理されるまで 40 分待つか、[Provision on Demand] ボタンを使ってすぐに処理します。
Okta	アカウントを再びアクティブにするか、ユーザーを直接またはグループを介してアプリケーションに再度割り当てます。
PingFederate	ユーザーストアでユーザーを一時停止解除または再有効化するか、プロビジョニング元によってターゲットにされているデータストアグループまたはフィルターにユーザーを追加し直します。
REST API
`PUT` または `PATCH` 要求を `/scim/v2/Users/{scim_user_id}` に送信して、ユーザーの `active` フィールドを `true` に更新します。

ハードプロビジョニング解除されたユーザーアカウントの回復

SCIM 経由でハードプロビジョニング解除された**** ユーザーアカウントを復元GitHub。代わりに、ユーザーの新しい GitHub アカウントをプロビジョニングする必要があります。

新しいアカウントをプロビジョニングするときは、物理的にプロビジョニング解除されたユーザーのユーザー名を再利用できます。ただし、ハードプロビジョニング解除されたユーザーアカウントを、 GitHubの新しいユーザーアカウントとマージすることはできません。

ハードプロビジョニング解除されたユーザーのメールアドレスと新しいユーザーが一致する場合、 GitHub は、メールアドレスに関連付けられている既存の Git コミットを新しいユーザーに属性付けします。
元のユーザーによって作成された既存のリソースとコメントが、新しいユーザーに関連付けられることはありません。

監査ログイベント

エンタープライズの監査ログには、エンタープライズでのアクティビティに関する詳細が表示されます。監査ログを使用して、SCIM の構成をサポートできます。詳しくは、「企業の監査ログ」をご覧ください。

重要

Enterprise 所有者には、監査ログストリーミング、ソース IP 開示、API 要求をストリーミングするオプションなどの Enterprise 監査ログ機能を有効にすることを強くお勧めします。これらのイベントをストリーミングすると、管理者は、ビジネスのニーズに合ったログアイテム保持ポリシーを設定し、好みのツールを使ってこれらのログのクエリを実行できます。

緩やかなプロビジョニング解除に関するイベント

ユーザーをソフト解除すると、external_identity.update イベントは監査ログに表示されません。次のイベントは監査ログに表示されます。

user.suspend
user.remove_email
user.rename
external_identity.deprovision
この要求が成功した場合、external_identity.scim_api_success
要求が失敗した場合、external_identity.scim_api_failure
team.remove_member: ユーザーがチームにマップされている IdP グループのメンバーである場合
org.remove_member: Organization でのユーザーのメンバーシップが IdP によって管理されていて、organization 内の IdP グループにマップされているすべてのチームから削除された場合

ハードディプロビジョニングに関するイベント

external_identity.deprovision
user.remove_email
この要求が成功した場合、external_identity.scim_api_success
要求が失敗した場合、external_identity.scim_api_failure
team.remove_member: ユーザーがチームにマップされている IdP グループのメンバーである場合
org.remove_member: Organization でのユーザーのメンバーシップが IdP によって管理されていて、organization 内の IdP グループにマップされているすべてのチームから削除された場合

再プロビジョニングに関するイベント

ユーザーを再度有効にすると、external_identity.update イベントは監査ログに表示されません。次のイベントは監査ログに表示されます。

user.unsuspend
user.remove_email
user.rename
external_identity.provision
この要求が成功した場合、external_identity.scim_api_success
要求が失敗した場合、external_identity.scim_api_failure
org.add_member: ユーザーが SCIM によってプロビジョニングされた IdP グループのメンバーであり、このグループが organization 内のチームにマップされている場合

参考資料

REST API を使用した SCIM でユーザーとグループのプロビジョニング