Enterprise Managed Users をお使いの場合は、SCIM を使って次のことを行います。
- ユーザーとグループのプロビジョニングを解除して、アクセスできないようにします。
- 以前にプロビジョニング解除されたユーザーを、再プロビジョニングします。
ユーザーのプロビジョニングを解除する前に、プロビジョニング解除の影響を理解しておくことが重要です。これは、GitHub が ID プロバイダーから受け取るプロビジョニング解除 API 呼び出しの種類によって異なります。
重要
以降を読む前に、ご自分の Enterprise で SCIM がどのように実装されているかを理解しておく必要があります。 認証とプロビジョニングの両方にサポートされている ID プロバイダー (IdP) をお使いの場合、GitHub では "円滑パス" アプリケーションが提供されます。 円滑パス アプリケーションをお使いでない場合は、REST API を使って SCIM の要求を行います。 「Enterprise Managed Users について」をご覧ください。
ユーザーのプロビジョニング解除の種類
ユーザーをプロビジョニング解除すると、GitHub アカウントが一時停止され、ユーザーは Enterprise にアクセスできなくなります。 どのプロビジョニング解除の種類でも、プロビジョニング解除されたアカウントが Enterprise から削除されることはありません。
GitHub が ID プロバイダーから受け取るプロビジョニング解除呼び出しの種類によって、プロビジョニング解除されたユーザーの一時停止を解除 (復帰) できるかどうかが決まります。
- 論理的なプロビジョニング解除: 特定のシナリオでは、SCIM 統合を介してユーザーの一時停止を解除できます。
- 物理的なプロビジョニング解除: ユーザーの一時停止を解除することはできません。 ユーザーが再びアクセスする必要がある場合は、新しいアカウントをプロビジョニングする必要があります。
ユーザーのプロビジョニング解除の影響
IdP または REST API を使ってユーザー アカウントのプロビジョニングを解除すると、GitHub によってユーザー アカウントの変更が行われます。
論理的プロビジョニング解除の影響
- ユーザーは一時停止されて、Enterprise とプライベート リソースにアクセスできなくなります。
- 一時停止されたユーザー アカウントは、Enterprise の設定の [People] セクションで、[Members] ページではなく [Suspended members] ページに表示されます。
- ユーザーのユーザー名は難読化されて、元のユーザー名の後に GitHub.com での Enterprise の
_SHORTCODEを付加したもののハッシュになります。 - 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 とプライベート リソースにアクセスできなくなります。
- 一時停止されたユーザー アカウントは、Enterprise の設定の [People] セクションで、[Members] ページではなく [Suspended members] ページに表示されます。
- ユーザーのユーザー名は難読化されて、元のユーザー名の後に GitHub.com での Enterprise の
_SHORTCODEを付加したもののハッシュになります。 - ユーザーのメール アドレスは難読化されます。
- ユーザーの表示名は空の文字列に設定されます。
- ユーザーのリンクされた 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 統合によって異なります。 一般に、"円滑パス" IdP アプリケーションで実行するほとんどのアクションでは、一部の例外を除き、論理的プロビジョニング解除のみがトリガーされます。
論理的プロビジョニング解除のトリガー
| SCIM 統合 | 論理的プロビジョニング解除のトリガー |
|---|---|
| REST API | PUT または PATCH 要求が /scim/v2/enterprises/{enterprise}/Users/{scim_user_id} に送信されて、ユーザーの active フィールドが false に更新されます。 |
| Entra ID | ユーザーが Entra ID で無効にされるか、アプリケーションから割り当てを解除されるか、割り当てられているすべてのグループから削除されるか、管理者によってテナントから論理的に削除されます。詳しくは、Microsoft のドキュメントの「論理的な削除」をご覧ください。 |
| Okta | ユーザーがアプリケーションから割り当てを解除されるか、割り当てられているすべてのグループから削除されるか、[Deactivate] ボタンで非アクティブ化されます。 [Suspend] ボタンでは GitHub に要求が送信されないことに注意してください。 Okta では、論理的プロビジョニング解除の呼び出しのみが送信されます。 |
| PingFederate | ユーザーが、プロビジョニング元によってターゲットにされているユーザー ストアから一時停止、無効化、または削除されます。 |
物理的プロビジョニング解除のトリガー
| SCIM 統合 | 物理的プロビジョニング解除のトリガー |
|---|---|
| REST API | DELETE 要求が /scim/v2/enterprises/{enterprise}/Users/{scim_user_id} に送信されます。 |
| Entra ID | Microsoft のドキュメントの「物理的な削除」で説明されているような、Entra ID ユーザー アカウントの物理的な削除。 論理的に削除された Entra ID ユーザー (Entra ID 管理ポータルの [ユーザー] > [削除済みのユーザー] ページに表示されます) は、論理的に削除されてから 30 日後に Entra ID によって自動的に物理的に削除されます。 |
| Okta | 該当なし。 Okta では、物理的プロビジョニング解除の呼び出しは送信されません。 |
| PingFederate | 構成ミスの結果として [Remove User Action] の設定が [Disable] ではなく [Delete] に設定されている場合、このアクションでは物理的プロビジョニング解除の呼び出しが送信されます。 PingIdentity のドキュメントを参照してください。 |
論理的にプロビジョニング解除されたユーザー アカウントの復帰
IdP ユーザー アカウントが同じである場合に限り、論理的にプロビジョニング解除されたユーザーのアカウントを再プロビジョニングして、ユーザーのアクセスとアカウントの詳細を復元できます。 論理的にプロビジョニング解除されたユーザー アカウントは、SCIM の external ID (IdP ユーザー オブジェクト ID) と SCIM の User ID に基づいて、この外部 ID にまだリンクされているため、IdP ユーザー アカウントが同じである必要があります。 論理的にプロビジョニング解除された個々のユーザー アカウントにリンクされている外部 ID は変更できません。
再プロビジョニングの影響
- ユーザーは一時停止を解除されて、Enterprise に再びアクセスできるようになります。
- ユーザーのユーザー名とメール アドレスが復元されます。
- Organization 内のチームにマップされている、SCIM によってプロビジョニングされた IdP グループのメンバーであるユーザーは、ユーザー アカウントが再プロビジョニングされた直後に organization に追加されます。 以前に organization のメンバーであったユーザーのメンバーシップは、削除されてから 90 日以内であれば復帰されます。 「組織の以前のメンバーの回復」を参照してください。
- ユーザーが organization 内のチームにマップされている SCIM でプロビジョニングされた IdP グループのメンバーでない場合は、GitHub organization の所有者が、再プロビジョニング後にユーザー アカウントを手動で organization に追加する必要があります。
- 削除されたフォークは、一時停止から 90 日以内にユーザーが一時停止解除された場合は復元されます。
- 次のようなユーザーに関連付けられている項目は復元されます。
- GitHub Apps、OAuth apps、アプリの認可
- Personal access tokens
- SSH キー
- トークンとキーの認可
- ユーザー所有のリポジトリ
再プロビジョニングをトリガーするアクション
ユーザーを再プロビジョニングする方法は、SCIM の統合と、論理的プロビジョニング解除をトリガーしたアクションによって異なります。
| SCIM の実装 | ユーザーを再プロビジョニングするアクション |
|---|---|
| Entra ID | 無効にされたアカウントを再び有効にするか、ユーザーを直接または割り当てられたグループを介してアプリケーションに再度割り当てます。 変更が処理されるまで 40 分待つか、[Provision on Demand] ボタンを使ってすぐに処理します。 |
| Okta | アカウントを再びアクティブにするか、ユーザーを直接またはグループを介してアプリケーションに再度割り当てます。 |
| PingFederate | ユーザー ストアでユーザーを一時停止解除または再有効化するか、プロビジョニング元によってターゲットにされているデータストア グループまたはフィルターにユーザーを追加し直します。 |
| REST API | PUT または PATCH 要求を /scim/v2/enterprises/{enterprise}/Users/{scim_user_id} に送信して、ユーザーの active フィールドを true に更新します。 |
物理的にプロビジョニング解除されたユーザー アカウントの復帰
SCIM 経由で物理的にプロビジョニング解除された GitHub ユーザー アカウントを復元することはできません。 代わりに、ユーザーの新しい GitHub アカウントをプロビジョニングする必要があります。
新しいアカウントをプロビジョニングするときは、物理的にプロビジョニング解除されたユーザーのユーザー名を再利用できます。 ただし、GitHub で物理的にプロビジョニング解除されたユーザー アカウントと新しいユーザー アカウントをマージすることはできません。
- ハードウェア上でプロビジョニング解除されたユーザーと新しいユーザーのメール アドレスが一致する場合、GitHub により、メール アドレスに関連付けられた既存の Git コミットが新しいユーザーに関連付けられます。
- 元のユーザーによって作成された既存のリソースとコメントが、新しいユーザーに関連付けられることはありません。
監査ログのイベント
エンタープライズの監査ログには、エンタープライズでのアクティビティに関する詳細が表示されます。 監査ログを使用して、SCIM の構成をサポートできます。 詳しくは、「企業の監査ログについて」をご覧ください。
重要
Enterprise 所有者には、監査ログ ストリーミング、ソース IP 開示、API 要求をストリーミングするオプションなどの Enterprise 監査ログ機能を有効にすることを強くお勧めします。 これらのイベントをストリーミングすると、管理者は、ビジネスのニーズに合ったログ アイテム保持ポリシーを設定し、好みのツールを使ってこれらのログのクエリを実行できます。
論理的プロビジョニング解除に関するイベント
ユーザーを論理的にプロビジョニング解除すると、external_identity.update イベントは監査ログに表示されません。 次のイベントは監査ログに表示されます。
user.suspenduser.remove_emailuser.renameexternal_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.deprovisionuser.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.unsuspenduser.remove_emailuser.renameexternal_identity.provision- この要求が成功した場合、
external_identity.scim_api_success - 要求が失敗した場合、
external_identity.scim_api_failure org.add_member: ユーザーが SCIM によってプロビジョニングされた IdP グループのメンバーであり、このグループが organization 内のチームにマップされている場合