Okta でのプロビジョニングについて
IdP として Okta を使用する場合は、Okta のアプリケーションを使用して、ユーザー アカウントのプロビジョニング、エンタープライズ メンバーシップの管理、およびエンタープライズ内の組織のチーム メンバーシップの管理ができます。 Okta はパートナー IdP であるため、okta アプリケーション for Enterprise Managed Usersを使用することで、認証とプロビジョニングの構成を簡略化できます。 詳細については、「 Enterprise Managed Users の概要.
または、SAML 認証にのみ Okta を使用し、プロビジョニングに別の IdP を使用する場合は、 GitHubの SCIM 用 REST API と統合できます。 詳しくは、「REST API を使用した SCIM でユーザーとグループのプロビジョニング」をご覧ください。
サポートされている機能
Enterprise Managed Users
では、Okta の次のプロビジョニング機能がサポートされています。
| 機能 | 説明 |
|---|---|
| 新規ユーザーへのプッシュ通知 | Okta の GitHub Enterprise Managed Userに割り当てられているユーザーは、GitHub 上のエンタープライズ内で自動的に作成されます。 |
| プロファイルの更新をプッシュする | Okta でユーザーのプロファイルに対して行われた更新は、 GitHubにプッシュされます。 |
| プッシュ グループ | プッシュ グループとしてGitHub Enterprise Managed User アプリケーションに割り当てられている Okta のグループは、GitHub上の企業で自動的に作成されます。 |
| ユーザ無効化のプッシュ | |
| Okta の GitHub Enterprise Managed Userからユーザーの割り当てを解除すると、GitHub 上でそのユーザーが利用できなくなります。 ユーザーはサインインできませんが、ユーザーの情報は保持されます。 | |
| ユーザの再アクティブ化 | Okta において、Okta アカウントが再有効化され、Okta 上の GitHub Enterprise Managed Userに再度割り当てられたユーザーは、利用可能になります。 |
メモ
Enterprise Managed Users では、ユーザー名の変更はサポートされていません。
前提条件
新しい企業に対して SCIM プロビジョニングを構成する場合は、最初の構成プロセスでこれまでの全手順を完了してください。 「Enterprise Managed Users を使ってみる」を参照してください。
さらに:
- 認証とプロビジョニングの両方に Okta のアプリケーションを使用する必要があります。
- Okta 製品は、クロスドメイン ID 管理 (SCIM) 用のシステムをサポートしている必要があります。 詳細については、Okta のドキュメンテーションを確認するか、Okta のサポート チームにお問い合わせください。
SCIM を構成する
Okta アプリで SAML 設定を構成したら、プロビジョニング設定の構成に進むことができます。 SAML の設定をまだ構成していない場合は、「エンタープライズ マネージド ユーザーの Okta を使った SAML シングル サインオンの構成」をご覧ください。
プロビジョニングを構成するには、ユーザー名が@_adminであるセットアップユーザーが、personal access token (classic) スコープを指定した を提供する必要があります。 「Enterprise Managed Users を使ってみる」を参照してください。
-
Okta の GitHub Enterprise Managed User アプリケーションに移動します。
-
[プロビジョニング****] タブをクリックします。
-
[設定] メニューで、 [統合] をクリックします。
-
変更するには、 [編集] をクリックします。
-
[API 統合の構成] をクリックします。
-
[API トークン] フィールドに、セットアップ ユーザーに属する personal access token (classic) を入力します。
メモ
[グループのインポート] は、GitHub ではサポートされていません。 チェックボックスを選択または選択解除しても、構成には影響しません。
重要
データ所在地付き GitHub Enterprise Cloud (GHE.com) の企業の場合は、[ベース URL] フィールドに次の URL を入力してください:https://api.{subdomain}.ghe.com/scim/v2/enterprises/{subdomain} ({subdomain}を企業のサブドメインに置き換えます)。
>
>
たとえば、エンタープライズのサブドメインが acmeされている場合、ベース URL は https://api.acme.ghe.com/scim/v2/enterprises/acmeされます。
- [Test API Credentials](API 資格情報のテスト) をクリックします。 テストが成功すると、確認メッセージが画面の上部に表示されます。
- トークンを保存するには、 [保存] をクリックします。
- [設定] メニューで To App をクリックします。
- Provisioning to App の右側で、変更を許可するには、 [編集] をクリックします。
- [ユーザーの作成] 、 [ユーザー属性の更新] 、 [ユーザーの非アクティブ化] の右にある [有効にする] を選びます。
- プロビジョニングの構成を完了するには、 [保存] をクリックします。
ユーザーとグループの割り当て方法
認証とプロビジョニングを構成設定した後、ユーザーまたはグループを GitHub アプリケーションに割り当てることで、GitHub Enterprise Managed User で新しいユーザーをプロビジョニングできます。
メモ
GitHub のレート制限を超えないようにするには、IdP の SCIM 統合に 1 時間あたり 1,000 人を超えるユーザーを割り当てないでください。 グループを使って IdP アプリケーションにユーザーを割り当てる場合、1 時間あたり 1,000 人を超えるユーザーを各グループに追加しないでください。 これらのしきい値を超えると、ユーザーをプロビジョニングしようとすると、"レート制限" エラーが発生して失敗する可能性があります。 試した SCIM プロビジョニングまたはプッシュ操作がレート制限エラーに起因して失敗したかは IdP ログで確認できます。 プロビジョニング失敗に対する反応は IdP によって異なります。 詳細については、 AUTOTITLE を参照してください。
また、Okta の [プッシュ グループ] タブにグループを追加することで、Organization のメンバーシップを自動的に管理することもできます。 グループが正常にプロビジョニングされると、エンタープライズの組織のチームに接続できるようになります。 チームの管理について詳しくは、「ID プロバイダー グループを使用したチーム メンバーシップの管理」をご覧ください。
ユーザーを割り当てるときは、IdP 上のアプリケーションで "Roles" 属性を使って、Enterprise 内でのユーザーのロールを設定できます。 割り当てることができるロールの詳細については、「企業における役割の能力」を参照してください。
メモ
"ロール" 属性はグループではなく、個別のユーザーにのみ設定できます。 Okta のアプリケーションに割り当てられているグループの全員にロールを設定する場合、グループ メンバー別に "ロール" 属性を使う必要があります。
ユーザーとグループのプロビジョニング解除方法
GitHubからユーザーまたはグループを削除するには、Okta の [割り当て] タブと [プッシュ グループ] タブの両方からユーザーまたはグループを削除します。 ユーザーの場合は、[プッシュ グループ] タブのすべてのグループからユーザーが削除されていることを確認してください。