GitHub Enterprise-IdP連携の「これやったらどうなる？」「そもそもこれできる？」を色々試してみたので備忘のため書いておきます。
※記事中ではOktaで記載していますが、Entra IDでも同様でした。
ユーザープロビジョニングのみを無効にしたらどうなるか？
OktaのGitHub Enterprise Managed Userのアプリケーションの「プロビジョニング」で
- ユーザーを作成
- ユーザーの非アクティブ化
を無効にして保存します。
ユーザーはそのまま残る
IdP連携を切る（SAML連携をOFFにするとどうなるか）
GitHub Enterpriseの管理画面 > Identity providerに移動し、SAML-single sign onをOFFにする
ユーザーはそのまま残るとのこと
削除中であることが表示される。
Peopleを見てみるとSetup user以外全員消える。will not removeって書いてあったじゃん！
ちなみに以前プロビジョニングされていたEnterprise ownerのアカウントでも認証できなくなる。
しかしこれは正しい挙動です。
以下のGitHub docsを見ると以下のように記載があり、IdP連携を切ると、IdPによってプロビジョニングされたユーザーは休眠状態に入るということがわかります。
GitHub Enterprise 設定で認証を無効にすると、GitHub により、Enterprise 内のすべての マネージド ユーザー アカウント (セットアップ ユーザー アカウントを除く) は一時停止されます。 Enterprise のメンバーの一時停止は、GitHub で検証できます。
ではこの「一時停止」状態のユーザーはGitHub側でどのように確認するのか？
GitHub Enterpriseの管理画面でPeople>Suspendedに移動すると、休眠状態のユーザーが表示されます。
つまり、IdP連携を切った場合の挙動をまとめると以下のようになります。
- IdPの連携がないので、SAMLによるGitHubへのSSO認証も停止
- ゆえに、setupユーザー以外はGitHub Entepriseの環境にアクセスすらできなくなる
- それらのユーザーは休眠ユーザーとして残る
別のIdPに移行する場合
あまりおすすめはしませんが、「最初はEntra IDだったけどOktaにしないといけなくなった」「EntraIDは使い続けるけど、別のEntra IDのテナントに引っ越すことになった」という場合もあるかと思います。
GitHub EnterpriseのEMUにおいては連携IdPの移行はできるのか？Yes。できます。
こちらのdocsに移行する場合の方法がstep by stepで記載されています。
EMU環境の引っ越しは必要か？
Noです。連携しているIdPのみを変更する場合は環境の引っ越し、すなわち移行先の新しい環境を作りなおすということは不要です。
EMUの環境作成時に、連携先IdPをEntra IDに指定しました。別のIdPに連携しなおすことは可能でしょうか？
Yes。できました。
GiHub Enterpriseの利用を開始する際、以下のトライアル開始ページで環境を作成します。
EMUの場合はトライアルの設定画面でどのIdPを使うかを選択できます。
ここで最初にEntra IDを選んでしばらく運用したのち、Oktaに連携先を変更するを試してみたところ、ちゃんと連携IdPをOktaに変更してSAML構成→ユーザープロビジョニングまでできました。
ただ、移行時の注意点があります。
最初に既存のIdP連携を切ること
最初に既存のIdPの連携を切ります。上述のように、IdPの連携を停止するとSetupユーザー以外のすべてのユーザーが休眠ユーザーとなり、アクセスできなくなります。
この時点ではIdP連携がされていない環境にアクセスできる人はsetupユーザーのみです。そしてsetupユーザーは最初に設定したパスワード or 付与されたリカバリーコードでアクセスすることになります。
連携IdPを切る前に、Setupユーザーが作業ができるように（＝IdPに依存する認証なしGitHub Enterpriseにアクセスできるように）しておいてください。
再びIdPと連携する際、usernameは移行元・移行先で一致するように。
シームレスな移行を行う場合、新しい SCIM プロバイダーの SCIM userName 属性が、古い SCIM プロバイダーの属性と一致することを確認します。
SCIMのusernameはIdP側で確認することができます。この値が移行先、移行元と一致するようにしてください。
最も安全なのはusernameに全く同じ値を設定していることですが、正規化されてもこの値が移行先、移行元で完全に変わる場合（yuriemori@XXX.com→yuriemori@XXX.corp.com, yuriemori@XXX.com→yuriemori_new@XXX.comのように）は新しいEnterpriseアカウントのプロビジョニングが必要となります。
正規化された SCIM userName 値が変わる場合は、GitHub で移行用に新しい Enterprise アカウントをプロビジョニングする必要があります。 サポートについては、営業チームにお問い合わせください。
再びプロビジョニングする際は再度scim:enterpriseのPATを設定すること
移行元IdPから新しいIdPに移行する際には最初にセットアップしたときにユーザープロビジョニングに使ったPATの有効期限はさすがに切れていると思いますが、（←デフォルトだとプロビジョニングのために生成するPATの生成はNo expirationで無期限になっている）一度IdPとの連携を切って再度新しいIdPでユーザープロビジョニングをする際はenterprise:scimの権限を持つPATも新たに発行してください。
（一度切って忘れてて普通に既存のPATが設定されたままでプロビジョニングしようとしたら普通にエラーになりました）
PATを再度設定する場合は、GitHubの画面右上のプロフィールアイコンを押下してSettingsを選択して、
開いた画面の左メニューのDeveloper settingsをさらに選択
Personal access token > Token(classic)を選択し、Generate new tokenを押下
Generate new token(classic)を選択
noteに何のためのPATか記載をして、
※有効期限はNo expirationで（突然プロビジョニングができなくなってしまわないように）
アクセススコープはscim:entepriseを選択して保存。
Discussion