Okta でのプロビジョニングについて
IdP として Okta を使用する場合は、Okta のアプリケーションを使用して、ユーザー アカウントのプロビジョニング、エンタープライズ メンバーシップの管理、およびエンタープライズ内の組織のチーム メンバーシップの管理ができます。 Okta はパートナー IdP であるため、okta アプリケーション 」を参照してください。では、SAML シングル サインオンと、 GitHub Enterprise Serverでの SCIM プロビジョニングの両方を管理できます。
または、SAML 認証にのみ Okta を使用し、プロビジョニングに別の IdP を使用する場合は、 GitHubの SCIM 用 REST API と統合できます。 詳しくは、「REST API を使用した SCIM でユーザーとグループのプロビジョニング」をご覧ください。
サポートされている機能
GitHub Enterprise Server
では、Okta の次のプロビジョニング機能がサポートされています。
| 機能 | 説明 |
|---|---|
| 新規ユーザーへのプッシュ通知 | Okta の GitHub のアプリケーションに割り当てられているユーザーは、GitHub 上のエンタープライズ内で自動的に作成されます。 |
| プロファイルの更新をプッシュする | Okta でユーザーのプロファイルに対して行われた更新は、 GitHubにプッシュされます。 |
| プッシュ グループ | プッシュ グループとしてGitHub アプリケーションに割り当てられている Okta のグループは、GitHub上の企業で自動的に作成されます。 |
| ユーザ無効化のプッシュ | |
| GitHub アプリケーションからユーザーの割り当てを解除すると、GitHub 上でそのユーザーが利用できなくなります。 ユーザーはサインインできませんが、ユーザーの情報は保持されます。 | |
| ユーザの再アクティブ化 | Okta において、Okta アカウントが再有効化され、GitHub のアプリケーションに再度割り当てられたユーザーは、利用可能になります。 |
前提条件
GitHub Enterprise Serverで SCIM を使用するための一般的な前提条件が適用されます。 「エンタープライズ マネージド ユーザー」の「前提条件」セクションをご覧ください。
さらに:
-
SCIM を構成するには、「AUTOTITLE」のステップ 1 から 4 を完了している必要があります。
- Okta からの要求を認証するには、セットアップ ユーザー用に作成された personal access token (classic) が必要です。
-
認証とプロビジョニングの両方に Okta のアプリケーションを使用する必要があります。
-
Okta 製品は、クロスドメイン ID 管理 (SCIM) 用のシステムをサポートしている必要があります。 詳細については、Okta のドキュメンテーションを確認するか、Okta のサポート チームにお問い合わせください。
1. SAML を構成する
このセクションを始める前に、「AUTOTITLE」のステップ 1 と 2 が済んでいることを確認します。
Okta では
-
Okta の GitHub Enterprise Server アプリケーションに移動します。
-
[統合の追加] をクリックします。
-
一般設定のベース URL に、 GitHub Enterprise Server ホスト URL (
https://HOSTNAME.com) を入力します。 -
[サインオン] タブをクリックします。
-
[認証情報の詳細] が次の内容と一致していることを確認します。
- "アプリケーション ユーザー名の形式": Okta ユーザー名
- "Update application username on (アプリケーション ユーザー名の更新)": 作成と更新
- "パスワードの表示": 選択解除
-
[SAML 署名証明書] セクションで、[アクション] を選択し、[証明書のダウンロード] をクリックして、自身の証明書をダウンロードします。
-
ページの右側にある [SAML セットアップ手順の表示] をクリックします。
-
[サインオン URL] と [発行者] URL のメモを取ります。
GitHub Enterprise Server 上
- 管理コンソールにアクセスできるユーザーとして お使いの GitHub Enterprise Server インスタンス にサインインします。
- 収集した情報を使用して SAML を構成します。 「Enterprise 向けの SAML シングルサインオンを設定する」を参照してください。
2. SCIMを構成する
SAML 設定を構成したら、プロビジョニング設定の構成に進むことができます。
このセクションを始める前に、「AUTOTITLE」のステップ 1 から 4 が済んでいることを確認します。
-
Okta の GitHub Enterprise Managed User アプリケーションに移動します。
-
[プロビジョニング****] タブをクリックします。
-
[設定] メニューで、 [統合] をクリックします。
-
変更するには、 [編集] をクリックします。
-
[API 統合の構成] をクリックします。
-
[API トークン] フィールドに、セットアップ ユーザーに属する personal access token (classic) を入力します。
メモ
[グループのインポート] は、GitHub ではサポートされていません。 チェックボックスを選択または選択解除しても、構成には影響しません。
-
[Test API Credentials](API 資格情報のテスト) をクリックします。 テストが成功すると、確認メッセージが画面の上部に表示されます。
-
トークンを保存するには、 [保存] をクリックします。
-
[設定] メニューで To App をクリックします。
-
Provisioning to App の右側で、変更を許可するには、 [編集] をクリックします。
-
[ユーザーの作成] 、 [ユーザー属性の更新] 、 [ユーザーの非アクティブ化] の右にある [有効にする] を選びます。
-
プロビジョニングの構成を完了するには、 [保存] をクリックします。
SCIM の構成が完了したら、構成プロセスで有効にしたいくつかの SAML 設定を無効にすることができます。 「エンタープライズ マネージド ユーザー」を参照してください。
ユーザーとグループの割り当て方法
認証とプロビジョニングを構成設定した後、ユーザーまたはグループを IdP の関連アプリケーションに割り当てることで、GitHub Enterprise Managed User で新しいユーザーをプロビジョニングできます。
メモ
サイト管理者がインスタンスで API レート制限を有効にしている可能性があります。 これらのしきい値を超えると、ユーザーをプロビジョニングしようとすると、"レート制限" エラーが発生して失敗する可能性があります。 試した SCIM プロビジョニングまたはプッシュ操作がレート制限エラーに起因して失敗したかは IdP ログで確認できます。 プロビジョニング失敗に対する反応は IdP によって異なります。 詳細については、 AUTOTITLE を参照してください。
また、Okta の [プッシュ グループ] タブにグループを追加することで、Organization のメンバーシップを自動的に管理することもできます。 グループが正常にプロビジョニングされると、エンタープライズの組織のチームに接続できるようになります。 チームの管理について詳しくは、「ID プロバイダー グループを使用したチーム メンバーシップの管理」をご覧ください。
ユーザーを割り当てるときは、IdP 上のアプリケーションで "Roles" 属性を使って、Enterprise 内でのユーザーのロールを設定できます。 割り当てることができるロールの詳細については、「企業における役割の能力」を参照してください。
メモ
"ロール" 属性はグループではなく、個別のユーザーにのみ設定できます。 Okta のアプリケーションに割り当てられているグループの全員にロールを設定する場合、グループ メンバー別に "ロール" 属性を使う必要があります。
ユーザーとグループのプロビジョニング解除方法
GitHubからユーザーまたはグループを削除するには、Okta の [割り当て] タブと [プッシュ グループ] タブの両方からユーザーまたはグループを削除します。 ユーザーの場合は、[プッシュ グループ] タブのすべてのグループからユーザーが削除されていることを確認してください。