メインコンテンツまでスキップ
に最終更新

Oktaを設定して、ID管理を自動化する

このページでは、自動ID管理を使用して、Oktaを構成し、Databricksアカウントにユーザーとグループをプロビジョニングする方法について説明します。

始める前に​

  • Databricksのアカウント管理者である必要があります。
  • Oktaの管理者権限が必要です。
  • Databricksアカウント用にOkta SSOを構成する必要があります。

自動ID管理をセットアップする​

Oktaアプリケーションを設定する​

  1. Okta管理コンソールで、 [アプリケーションとリソース] > [アプリケーション] に移動します。

  2. 「 Create App Integration 」をクリックし、「 Classic experience 」と「 API Services 」を選択して、「 Next 」をクリックします。

  3. 「Databricks AIM」などのアプリ統合の名前を入力し、 Use Okta-generated client ID を選択して、 Save をクリックします。

  4. General tabの Public keys セクションで、「Add」をクリックして新しい公開鍵を追加します。

  5. [新しいキーを生成] をクリックします。

  6. Private key – Copy this! の下で、完全な JSON の値をコピーして安全に保管します。この値は、Databricks で Okta を設定するときに使用します。公開鍵や PEM 値はコピーしないでください。

  7. Save をクリックして署名キーを有効にします。

  8. 署名キーがアクティブになったら、[ 全般 ] tabで [ クライアント資格情報 ] セクションに移動します。[ クライアント認証 ] で、[ クライアント シークレット ] を [ 公開鍵 / 秘密鍵 ] に変更します。

  9. 「 General 」tabの「 全般設定 」セクションで、「 所有権証明 」の下にある「 DPoPヘッダーを必須にする 」のチェックを外し、「 保存 」をクリックします。

  10. On the Okta API Scopes tab, grant the following scopes:

    • okta.groups.read
    • okta.users.read

  11. Admin Roles タブで、 Read-only Administrator ロールをアプリに割り当てます。

Databricks で Okta を構成する​

  1. アカウント管理者として、アカウントコンソールにログインします。

  2. サイドバーで 「セキュリティ」 をクリックします。

  3. [ID プロバイダーのセットアップ] tab で、 [ID 管理] の横にある [自動 ID 管理] の横にある [構成] をクリックします。

  4. 以下の値を入力してください。

    • Okta org URL : Okta 組織の URL（例: https://your-org.okta.com）。管理コンソール URLではなく、組織 URL を使用してください。URL に -admin を含めないでください。
    • クライアントID ：作成したOktaアプリのクライアントID
    • Client Private key : Oktaアプリケーションの設定時に生成およびコピーした、完全なプライベートキーのJSON値。

  5. 接続テスト をクリックして、統合が成功したことを確認してください。

  6. 接続が成功したら、 「AIMを有効にする」 をクリックしてください。

接続のトラブルシューティング​

無効なJSON

Client Private key フィールドには、完全なプライベート JWK を JSON 形式で指定する必要があります。Okta の Private key – Copy this! > JSON の下にある値全体をコピーします。公開鍵、PEM 値、または JSON オブジェクトの一部のみを貼り付けないでください。

302 Found

Okta組織URL に管理コンソールURLではなくOkta組織URLが含まれていることを確認してください。ホスト名から -admin を削除します。たとえば、 https://your-org-admin.okta.com ではなく https://your-org.okta.com を使用します。

403 からの応答 /api/v1/users

Okta アプリの Okta API Scopes tab で、アプリに okta.users.read スコープがあることを確認します。

403 からの応答 /api/v1/groups

Oktaアプリに okta.groups.read スコープと Read-only Administrator ロールが付与されていることを確認します。

既知の問題点と制限事項​

自動ID管理を有効にする際は、以下の動作と制限事項に注意してください。

自動ID管理を有効にした後に重複するIDが生成される​

Databricks は、既存のユーザーおよびグループの externalId フィールドと Okta のユーザー ID またはグループ ID を比較して、ID を照合します。既存のIDの externalId に Okta ID がない場合、プロビジョニングによって重複エントリが作成されます。どちらのエントリも、既存の権限で引き続き使用できます。

以前に Okta Databricks OIN アプリと同期していた場合、通常、ユーザーの externalId の値は入力されますが、グループの値は入力されません。重複を解決するには、アカウント ユーザー、アカウント Service Principal、またはアカウント グループ API を使用して、各オブジェクトの externalId を一致する Okta ユーザー ID またはグループ ID に設定します。

統合ログイン​

Databricksでは、アカウントとすべてのワークスペース間でSSOが一貫するように、統合ログインを強く推奨しています。これを行わない場合、アカウントレベルとワークスペースレベルのSSOで同じIDプロバイダーを使用し、同じフィールドをDatabricksのユーザー名にマッピングしている場合にのみ、自動ID管理が機能します。アカウントSSOがユーザー名をマッピングし、ワークスペースSSOがEメールをマッピングしている場合で、ユーザーのユーザー名とEメールが異なるときは、ログイン時に既存のユーザーと一致させずに2番目のユーザーが作成されます。

また、Okta SSO アプリでグループ クレームを設定し、グループ メンバーシップが OIDC トークンに含まれるようにします。

Okta での電子メールまたはユーザー名の変更​

プロビジョニングにより、ログイン時の SSO ユーザー名クレームから各 Databricks ユーザーが作成されます。（たとえば、Okta でユーザーのEメールが変更された場合や、管理者が SSO のユーザー名クレームのフィールドマッピングを更新した場合など）そのクレームが変更されると、既存のユーザーを更新する代わりに新しいユーザーが作成されます。Databricks サポートに連絡して、Databricks ユーザー名と更新されたクレームを再調整するユーザー名の移行を実行します。

オンボーディング前にDatabricksユーザー名の一意性を確認してください。​

Databricksは、OktaのログインフィールドとEメールの両方と比較して、ユーザー名でIDを照合します。Oktaは、Eメールではなく、ログインフィールドのユニーク性のみを保証します。複数のOktaユーザーがEメールを共有している場合、またはユーザーのEメールが別のユーザーのログインフィールドと一致する場合、プロビジョニングでは正しいユーザーを確実に特定できません。自動ID管理を有効にする前に、各Databricksのユーザー名がテナント全体の単一のOktaユーザーにマップされていることを確認してください。

外部 ID は、プロビジョニングされた後にのみ表示されます​

ID プロバイダーからのユーザーとグループは、自動 ID 管理によって Databricks にプロビジョニングされるまで、アカウント コンソールの [ユーザー管理] ページには表示されません。ID がプロビジョニングされる前に検索するには、その ID を検索します。検索では、まだプロビジョニングされていない ID を含め、ID プロバイダーから一致する ID が返されます。

このページの見出し