単一の Identity Provider: プロビジョニング

マルチテナント アーキテクチャ向けに Organizations をプロビジョニングする方法について説明します。

Auth0 Organizations 機能を使用すると、単一の Auth0 テナントを本番環境へのデプロイ向けにプロビジョニングできます。最も複雑なアーキテクチャ シナリオを除き、Single Sign-On (SSO) やユーザーの Profile Management などとの統合や利用が容易になるため、本番環境で使用する Auth0 テナントは 1 つにすることを推奨します。実装によっては、Auth0 テナントの設定や、それに対応する統合に関して、追加で検討すべき項目がいくつかあります。

組織に関連付けられたブランディングは非常に重要です。ブランド アセットを活用することで、ユーザーにとって見慣れた信頼できる環境を提供できるためです。また、認知されたブランド アセットを使用することで、ユーザーが提供する情報 (たとえば認証情報) が安全かつ確実に取り扱われるという安心感も高まります。したがって、Auth0 のデフォルトのブランディングは置き換えるべきです。詳しくは、Branding を参照してください。

​

組織

サポートする各組織ごとに、独立した Auth0 Organization を作成する必要があります。この例では、Hoekstra & Associates を表す hoekstra 組織と、MetaHexa Bank を表す metahexa 組織を作成します。組織は、組織を作成する を Auth0 Dashboard で手動作成することも、Auth0 の Management API を使ってプログラムから作成することもできます。

​

アプリケーション

Organizationテナントの実装方法によっては、Auth0テナント内でアプリケーション定義を作成する際に、いくつかの選択肢があります。どの方法を選んでも、Organizationの動作はアプリケーション レベルで定義されます。

顧客ごとに個別のOrganizationテナントをプロビジョニングする場合は、通常、それぞれに対応する独立したアプリケーション定義をAuth0で作成する必要があります。この構成では通常、アプリケーション固有のclient_idパラメーターと、使用するAuth0 Organizationを識別するorganizationパラメーターの両方を、/authorizeエンドポイントの呼び出し時に送信することになります。詳しくは、Authenticationを参照してください。

ベストプラクティス

設定を簡単にし、セキュリティ分離を最大限に高めるため、Auth0ではアプリケーションを個別に定義してください。これにより、許可するコールバックURLなどをそれぞれ個別に設定できるほか、最小権限の原則に従って、Client IDやClient Secretの情報が露出する可能性を最小限に抑えられます。

また、Auth0で単一のアプリケーション定義を使用することもできます。この場合、ユーザーは第1要素認証の一環として、必要なorganizationを指定するよう求められます。通常は共通のアプリケーションclient_idを使用することになりますが、/authorizeエンドポイントの呼び出しではorganizationパラメーターは省略されます。

​

Connections

次に、ユーザーの認証に使用するConnectionsを定義します。ここでは、Hoekstra & Associates に関連するユーザー向けに データベース接続 を、MetaHexa Bank に関連するユーザー向けに エンタープライズ接続 を定義します。

ベストプラクティス

単一の Identity Provider (IdP) Organization では、さまざまなユースケースに柔軟に対応できるよう、定義した Organization ごとに 1 つの Connection を作成してください。たとえば、Organization ごとに 1 つの Database or Custom Database Connection を用意しておくと、廃止された Organization に関連するユーザーを簡単に削除できるほか、パスワードの複雑さに関する要件が異なる Organization にも最大限柔軟に対応できます。

Connection を定義したら、Auth0 Dashboard または Auth0 Management API を使用して、適切な Auth0 Organization にプロビジョニングできます。詳しくは、Enable Organization Connections を参照してください。

​

Users

Database または Custom Database Connections 以外の Connections 経由で認証されるユーザーは、Auth0 とは独立して、通常どおり外部の Identity Provider (IdP) にプロビジョニングされます。一方、Database または Custom Database Connections 経由で認証されるユーザーは、いくつかの異なる方法でプロビジョニングできます。Auth0 Dashboard と Auth0 Management API を使用して、Auth0 Tenant にユーザーを直接作成できます。また、Automatic Migration と Bulk Migration もサポートしています。

Management API または Dashboard 経由でユーザーをプロビジョニングするには、少なくとも 1 つの アプリケーション に対して Database または Custom Database Connection を直接有効にする必要があります。Organization に対してのみ Database または Custom Database Connection を有効にしても十分ではありません。

その後、ユーザーはメンバーシップを割り当てることで Auth0 Organization に関連付けられます。また、Auth0 Organization は、ユーザーの メンバーシップ を自動的に割り当てる ようにすることも、手動で割り当てる ようにすることもできます。

ユーザーに organization への メンバーシップ を手動で割り当てるには、そのユーザーの User Profile が Auth0 にすでに存在している必要があります。メンバーシップ を手動で割り当てる には、Auth0 Tenant Dashboard または Auth0 Management API のいずれかを使用できます。

​

招待

Auth0 Organization 機能では、メンバー招待も利用できます。メンバー招待のワークフローでは、ユーザーをアプリケーションに招待すると、そのユーザーは自動的にプロビジョニングされ、メンバーシップも自動的に作成されます。

​

データベース接続

Hoekstra & Associates の例を使って、ユーザー招待の一部としてデータベース接続を使用する場合に、この実装がどのような流れになるかを見てみましょう。ここで説明するワークフローの大部分は通常、使用している技術スタックに対応する Auth0 SDK またはライブラリによって処理されます。

1. Hoekstra & Associates の Jennifer は、Hoekstra & Associates の Travel0 Corporate Booking インスタンスに代わって Travel0 の Auth0 テナントから送信されたメールを受信します。

   1. メールは、組織メンバーを招待するで説明されているとおりに送信されたもので、Auth0 Dashboard または Auth0 Management API を使用してトリガーされた可能性があります。

2. Jenniferはメールを開き、その中のリンクをクリックします。すると、ブラウザーはHoekstra & AssociatesのTravel0 Corporate Bookingインスタンスへ移動します。リンクで使用されるベースURLはApplication Login URIとして指定されており、これはTravel0 Auth0テナント内のHoekstra & AssociatesのTravel0 Corporate Bookingアプリケーション定義の一部です。

   1. リンクには organization と organization_name パラメーターが含まれています。organization パラメーターには、Auth0テナント内の対応する Auth0 Organization 定義の ID が設定されています。これはステップ 3 の一部として Auth0テナントに渡されます。
   2. リンクには invitation パラメーターも含まれており、これもステップ 3 の一部として渡されます。

3. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは、/authorize エンドポイントを呼び出して以下のようなパラメータを渡すことで、認可コードフロー (PKCE の有無を問わず) を使用し、Travel0 Auth0テナントにリダイレクトします。通常、これは Auth0 SDK またはサードパーティ製ライブラリを使用して行われます。

   1. redirect_uri: https://hoekstra.corp.travel0.net/login/callback
   2. response_type: code
   3. state: このセッションで生成された一意のstate
   4. scope: openid profile …
   5. ユーザーについて必要な情報に応じて、追加で必要なOIDC スコープ。
   6. client_id: Hoekstra & Associates’ の Travel0 Corporate Booking インスタンス向けに、Travel0 Auth0 テナントで作成した Application に関連付けられた Client ID。
   7. organization: 招待元の組織の ID。通常はステップ 2 で説明したメール内のリンクから取得します。organization=organization_id の形式で指定します。ここで、organization_id には、Auth0 テナント内の対応する Auth0 Organization 定義に関連付けられた識別子を設定します。
   8. invitation: ステップ 2 で説明したとおり、メール内のリンクに関連付けられた追加の invitation パラメーター。

4. Travel0 Auth0テナントは、ユーザーのパスワード認証情報を取得するために /signup/invitation にリダイレクトします。

   1. Branding で説明されているように、組織ごとのブランド要素を表示するように設定された Universal Login Page が表示されます。

      Auth0 Organizations 機能に関連する招待ワークフローでは、Auth0 で保持されている SSO セッションは考慮されません。ユーザーがサインアップに招待されていて、すでにサインイン済みの場合でも、メール内のリンクをクリックすると、関連する Universal Login Page が常に表示されます。

5. ユーザーはパスワード (およびユーザー名などの追加認証情報) を入力し、[続行] をクリックします。ユーザー ID にはそのユーザーに紐付けられたメールアドレスが設定されており、変更できません。

6. Travel0 Auth0テナントが認証情報を確認します。有効であれば、ユーザーがプロビジョニングされ、Auth0 Organization Membership が設定されます。ユーザーは暗黙的に認証され、Rules パイプラインが実行されます。Authorization で説明されているように、Rules はアクセス制御の処理に使用できます。

   1. ユーザーの認証情報が無効な場合は、再入力を求められます。

7. 認証情報の確認と Rules の実行が正常に完了すると、ユーザーはステップ 3 で渡された state と code を伴って、redirect_uri (https://hoekstra.corp.travel0.net/login/callback) にリダイレクトされます。

8. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは state を検証した後、https://auth.travel0.net/oauth/token の Travel0 Auth0 テナントを呼び出し、code、client id、および client secret を渡して ID Token を取得します。続いて、その ID トークンを使用して https://hoekstra.corp.travel0.net のセッションを生成します。

9. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは、ユーザーに適切なページを表示します。

​

エンタープライズ接続

MetaHexa Bank の例を使って、ユーザー招待の一部として Enterprise Connection を使用する場合に、この実装がどのように進むかを見ていきましょう。ここでも、説明するワークフローの大半は通常、利用している技術スタックに対応する Auth0 SDK またはライブラリによって処理されます。

1. MetaHexa Bank の Amintha は、MetaHexa Bank 向けの Travel0 Corporate Booking インスタンスの代理で、Travel0 の Auth0テナントから送信されたメールを受け取ります。

   1. このメールは Invite Organization Members で説明されている方法で送信されており、Auth0 Dashboard または Auth0 Management API のいずれかによってトリガーされた可能性があります。

2. Amintha はメールを開き、その中のリンクをクリックします。すると、ブラウザーは MetaHexa Bank 向けの Travel0 Corporate Booking インスタンスに移動します。リンクで使用されるベース URL は Application Login URI として指定されており、Travel0 の Auth0テナントにある MetaHexa Bank 向け Travel0 Corporate Booking アプリケーション定義の一部を構成します。

   1. リンクには organization および organization_name パラメーターが含まれます。organization パラメーターには、Auth0テナント内の対応する Auth0 Organization 定義の ID が設定されています。これはステップ 3 の一部として Auth0テナントに転送されます。
   2. リンクには invitation パラメーターも含まれており、これもステップ 3 の一部として転送されます。

3. MetaHexa Bank 向けの Travel0 Corporate Booking インスタンスは、通常 Auth0 SDK またはサードパーティのライブラリを使用して /authorize エンドポイントを呼び出し、次のようなパラメーターを渡すことで、Authorization Code Flow (PKCE あり／なし) を使って Travel0 の Auth0テナントにリダイレクトします。

   1. redirect_uri: https://metahexa.corp.travel0.net/login/callback
   2. response_type: code
   3. state: このセッションで生成された一意の state
   4. scope: openid profile …
   5. ユーザーについて必要な情報に応じて、必要な追加の OIDC Scopes
   6. client_id: MetaHexa Bank 向け Travel0 Corporate Booking インスタンス用に Travel0 の Auth0テナントで作成された アプリケーション に関連付けられた Client ID。
   7. organization: 通常はステップ 2 で説明したメール内のリンクから取得する、招待元 organization の ID。organization=organization_id の形式で指定し、organization_id には Auth0テナント内の対応する Auth0 Organization 定義に関連付けられた識別子を設定します。
   8. invitation: ステップ 2 で説明したとおり、メール内のリンクに関連付けられた追加の invitation パラメーター。

4. Travel0 の Auth0テナントは /invitation にリダイレクトし、そこで Amintha に、まず第 1 要素の認証情報を認証するため MetaHexa IdP にリダイレクトされることが通知されます。

   1. ユーザーが確認すると、
   2. Auth0 は MetaHexa Bank の IdP インスタンスにリダイレクトし、
   3. ログインページが表示され、ユーザーは認証情報を入力して login をクリックします。

5. 成功すると、Auth0 Organization メンバーシップ が設定され、ユーザーは暗黙的に認証され、Rules パイプラインが実行されます。Rules は、Authorization で説明されているように、アクセス制御の処理に使用できます。

ステップ 6 から 8 は データベース接続 のシナリオで説明されているものと同じですが、ユーザーは Jennifer ではなく Amintha であり、Hoekstra & Associates の代わりに MetaHexa Bank (metahexa.corp.travel0.net) が使用されます。

​

ソーシャル接続

ソーシャル接続経由の招待は、エンタープライズ接続 の場合と同様のパターンに従いますが、上流の IdP は特定の組織ではなく、ソーシャルプロバイダーに関連付けられます。ソーシャル接続の使用に関するその他の考慮事項については、Authentication を参照してください。