複数組織アーキテクチャ

複数の Auth0 Organizations 向けのアプリケーションインスタンスに対応する必要がある複数組織アーキテクチャのための連携ガイド。

あなたが提供するサービスに登録しているサードパーティ組織にユーザーが所属する、というユースケースは複数あります。こうしたユーザーは、サードパーティ組織の従業員である場合もあれば、顧客である場合もあり、あるいはその両方であることもあります。どのようなケースであっても、このガイドでは、マルチテナント アプリケーションにおける一般的なユースケースを大まかに紹介します。

B2B アプリケーションでは、サービスを利用する企業の従業員や顧客にとって快適なユーザー体験を提供することが重視されます。そのため、B2B 環境のサービス提供者は、そのサービスを利用する各組織ごとにブランディングを追加できるようにしていることがよくあります。たとえば、あなたが AwesomeSaaS (SaaS ソフトウェア企業) で働いていて、会社では福利厚生やその他の人事業務を管理するための人事アプリケーション Human0 を利用しているとします。人事アプリにアクセスしてログインすると、ログイン画面は AwesomeSaaS のロゴが表示され、AwesomeSaaS のカラーが使われるようにカスタマイズされています。

Auth0 との連携を設計する B2B サービス提供者としては、顧客 (つまりサードパーティ組織) が、他の組織のユーザーによる自社のアプリケーションインスタンスへのログインを許可するかどうか、また、それらのユーザーを組織間で共有すべきか、それとも単一の組織に分離すべきかを検討する必要があります。

まずは、さまざまなユースケースを示すためのサンプルアプリケーションをいくつか紹介しましょう。Travel0 は、オンライン旅行代理店サービスを提供する架空の企業です。Travel0 には複数のアプリケーションがありますが、この説明では、組織に直接販売されている 2 つのアプリケーションに焦点を当てます。

• Travel0 Corporate Booking: 従業員がログインして業務に関連する出張を予約できるオンラインアプリケーションを組織向けに提供します。このアプリケーションの顧客である組織には、次のようなものがあります。

  • Hoekstra & Associates: 少人数の従業員しかいない小規模な法律事務所です。IT 部門がなく、企業向け IDプロバイダー (IdP) の設定方法を学ぶ時間も余力もありません。
  • Gupta & Smith Law: より大規模な法律事務所ですが、やはり IT 部門がなく、企業向け IdP の設定方法を学ぶ時間も余力もありません。
  • MetaHexa Bank: 大規模な金融機関です。銀行業務と保険サービスを提供しており、独自の IdP を持っています。
  • Many Student University (MSU): 複数のキャンパスを持つ大規模な大学で、各キャンパスがそれぞれ独自の IdP を持っています。

• Travel0 Adventure Management: ホワイトウォーターラフティングのようなアドベンチャーを組織が企画し、販売できるようにします。ガイド (フリーランス、または何らかのサードパーティの旅行・イベント組織の従業員) は、このアプリケーションを使ってアカウントを作成し、アドベンチャーを案内するためのスケジュール管理を行えます。このアプリケーションの顧客である組織には、次のようなものがあります。

  • AdventureZ: 大規模なツアー・イベント運営会社です。従業員向けに独自の IdP を使っています。所属ガイドの数が十分で、その一部は繁忙期にのみ働くため、フリーランサーを必要とすることはめったにありません。また、自社のガイドが他社向けにフリーランスの仕事をできるようにもしています。
  • Rocky Mountain High Adventures: 初めて市場に参入する新しいグループです。共同創業者たちがツアーを運営しており、繁忙期にはフリーランサーに支援を依頼します。
  • Suzie’s Rafting and Ziplines: 長年続いている会社です。ほとんどのイベントは自社のガイドスタッフが対応しますが、繁忙時にはフリーランサーも雇います。

​

用語

ここで示すガイダンスで使われる語の多くは、文脈によって意味が異なります。例を読む際に誰がどの役割を担っているのかが分かるよう、まずはそれぞれの定義に目を通してください。

• Auth0 テナント (認可サーバーとも呼ばれます) : Auth0 で作成するテナントです。これは認可サーバーのインスタンスであり、1 つ以上のユーザードメインを表します。
• Auth0 Organizations: 組織をサポートするために設計された Auth0 テナントの機能を指します。Auth0 Organization のインスタンスは、通常、あなたの特定の顧客を表します。
• Employee: あなたの会社で働く人です。通常は IDプロバイダー (IdP) にアカウントを持ち、1 つ以上の Organization Tenant インスタンスへの管理者アクセスが必要になる場合があります。ここで Employee という用語は、あなたの会社の従業員だけを指すために使用します。顧客の Organizations に属するユーザーについては、Organization User を参照してください。
• Identity Provider (IdP): Auth0 のようにユーザーの認証を管理し、必要に応じてユーザープロファイル情報や資格情報の管理を提供するサービスです。また、サードパーティの IdP (Azure AD、Google、Facebook など) を使用して、資格情報の検証やプロファイル管理の委譲を行う場合もあります。
• Organization: あなたの顧客の 1 つであるサードパーティ企業です。アプリケーション用に作成された 組織 インスタンスを tenant と呼ぶこともありますが、Auth0 テナントとの混同を避けるため、ここでは Organization Tenant と呼びます。
• Organization Tenant: アプリケーションのサブスクリプション/プロビジョニングの一環として、顧客向けに作成されたテナントを指します。これは Auth0 テナントとは異なります。
• Organization User: Organization のメンバーとしてアプリケーションにログインする人です。これは (Organization の) 従業員の場合もあれば、顧客の場合もあります。組織コンテキストで参照されるユーザーは、すべて Organization User と見なせます。

​

ユーザーの分離

組織ごとのユーザー分離を検討する際は、提供するアプリケーションの種類を見極めることが重要です。これらのユーザーをどのように、どこに保存するかについては、基本的に 2 つのアプローチがあります。組織 ごとに分離されたユーザー と、複数の組織間で共有されるユーザー です。

上のフロー図は、意思決定のプロセスを示しています。また、組織 インスタンスに対して 管理者向けのアクセス が必要かどうかも検討する必要があります。たとえば、1 つ以上の組織で管理者として機能する自社の従業員や、ヘルプデスクサービスなどを提供する第三者が該当します。

以下のセクションでは、組織ごとのユーザー分離における各アプローチについて詳しく説明します。特に、それぞれに関連する非典型的なシナリオ (つまり、ユーザーが複数の組織にアクセスする必要がある場合) に注意してください。こうしたユースケースが、どのアプローチが要件により適しているかを左右することが多いためです。

​

組織ごとに分離されたユーザー

各組織はそれぞれ独自のユーザー群を持ち、ユーザーは他の組織にアクセスできず、またアクセスできるべきでもありません。アクセスを試みた場合は、権限なしとして拒否されるべきです。必要に応じて、ユーザーが所属する組織ごとに個別のアカウントを作成させることもできます。その場合、同一人物であっても、2 人以上の別々のユーザーとして扱われます。

このシナリオでは、ユーザーは、自分が所属している、またはアクセス権を持つ組織に直接ひも付けられます。ユーザーのログイン方法には 2 つの選択肢があります。A) 適切な組織向けに用意された ID ストア (つまり、お使いの Auth0 テナント内の UserID/Password データベース接続) に資格情報を作成する、または B) そのユーザー自身の組織の IdP を使ってログインする、のいずれかです。このユースケースでは、1 人のユーザーが複数の組織に属していても意味がなく、組織ごとに別々の ID を作成するほうが適切です。Travel0 Corporate Booking を例にすると、以下の図はこの構成を示しています。

Sally は典型的なユーザーです。彼女は MetaHexa Bank の従業員であり、MetaHexa Bank の Travel0 Corporate Booking インスタンスにしかアクセスできません。

一方、Pat は典型的ではないユーザーです。Pat はフリーランスのパラリーガルで、Hoekstra & Associates と Gupta & Smith Law の両方で働いているため、それぞれの Travel0 Corporate Booking インスタンスに別々のユーザー ID を使ってアクセスします。この方法の大きな利点の 1 つは、Pat に 2 つの別個のペルソナ (それぞれの法律事務所に 1 つずつ) を持たせることで、ミスの可能性を抑えられることです。Pat が出張を予約する際には、予約を行うために、対象となる特定の組織のインスタンスへその都度ログインしなければなりません。

Pat のようなケースは、おそらくまれなユースケースです。しかし、これはユーザー分離の要件を決める際に、何を考慮する必要があるかを示しています。ユーザーを、そのユーザーが関連付けられている組織ごとに分離したい場合は、別々のユーザー ID を作成する必要があります。この場合、Pat には Hoekstra & Associates の Travel0 Corporate Booking インスタンスにアクセスするための ID が 1 つあり、Gupta & Smith Law の Travel0 Corporate Booking インスタンスにアクセスするための別の ID があります。

​

組織 ごとに分離する場合のユースケース

組織ごとにユーザーを分離するアプリケーションでは、通常、3 つの異なるユースケースがあります。この節の例では、導入部で説明した Travel0 Corporate Booking アプリケーションのシナリオを使用します。Travel0 は Auth0 の顧客です。

• 独自の IdP を持っていない 組織、またはその使い方がわからない 組織。こうした 組織 は、通常、比較的小規模で、組織の IDプロバイダー (IdP) と シングルサインオン (SSO) を構成できる IT 部門がないか、あるいはその用途に適した組織の IdP を持っていない傾向があります。Travel0 Corporate Booking の例では、Hoekstra & Associates がこのような 組織 に当たります。
• 従業員があなたのアプリケーション用に新たな資格情報を作成しなくて済むよう、独自の IdP を構成したい 組織。ほとんどの 組織 はこのカテゴリに当てはまります。Travel0 Corporate Booking の例では、MetaHexa Bank がこのような 組織 に当たります。
• 複数の認証オプションを必要とする 組織。この種の 組織 の例としては、新しい会社を頻繁に買収する 組織、学校のように職員と保護者が同じアプリケーションにログインできる 組織、または自社のアプリケーションインスタンスにパートナーや顧客を招待してログインさせる 組織 (つまり、B2B2C 組織) などがあります。例では、Many Student University (MSU) がこのような 組織 に当たります。

最初の 2 種類の 組織 については、解決策は比較的単純になる傾向があります。これらの 組織 は Single IdP 組織 と見なされ、アプローチもほぼ常に同じです。詳しくは、Single Identity Provider Organizations を参照してください。

組織に複数の IdP がある 組織 は、より複雑になりがちですが、複雑さを最小限に抑えられるアプローチがいくつかあります。詳しくは、Multiple Identity Provider Organizations を参照してください。

​

組織 間で共有されるユーザー

ユーザーは複数の 組織 に所属できるため、1 つの 組織 から別の 組織 へ移るたびに別の ID やアカウントを使い分ける必要がないほうが便利です。そのような場合でも、組織 はそれぞれ独自の IdP を使用できます。

このシナリオでは、ユーザーは所属先の 組織 やアクセス権を持つ 組織 に直接ひも付けられなくなります。ユーザーのログイン方法には 2 つの選択肢があります。A) 組織 用に Auth0 テナント内で個別に割り当てられた ID ストアではなく、共通にプロビジョニングされた ID ストレージ (つまり、Auth0 テナント内の単一の UserID/Password データベース接続) に資格情報を作成する、または B) 自分の 組織 の IdP を使ってログインする、のいずれかです。ユーザーが ID を持つと、アクセスが必要な各 組織 へのアクセス権が付与されます。アクセス先が 1 つの 組織 のみの場合もあれば、複数の 組織 にアクセスできる場合もあります。ユーザーは、ログインを求められた際に、同じ資格情報を使って各 組織 のインスタンスにアクセスできることを理解しておく必要があります。Travel0 Adventure Management を例にすると、上の図はこの構成を示しています。

Jonno は典型的なユーザーです。Jonno は Suzie’s Rafting and Ziplines の従業員です。Jonno がログインできるのは、Suzie’s Rafting and Ziplines 向けにプロビジョニングされた Travel0 Adventure Management のインスタンスだけで、そこでアドベンチャーを作成し、ガイドします。Jonno の資格情報は、Travel0 の Auth0 テナントに関連付けられたデータベース接続、または Suzie’s Zipline and Rafting の IdP のいずれかに保存されます (ユーザー ID を自社で管理するかどうかによります) 。

Sumana はやや特殊なユーザーです。Sumana は AdventureZ の従業員ですが、AdventureZ は繁忙期に小規模なガイド会社向けのフリーランス業務も調整しているため、Sumana はフリーランサーとして Rocky Mountain High Adventures に招待されています。Sumana は、AdventureZ と Rocky Mountain の両方の Travel0 Adventure Management のインスタンスにログインする権限を持っています。ただし、Suzie’s Rafting and Ziplines にはガイドとして招待されたことがないため、そのインスタンスへのアクセス権はありません。

Sumana は両方の 組織 で同じ ID を持つ必要があります。というのも、ガイド業務では評価システムが使われ、Sumana の評価は、彼女が働く 組織 をまたいで引き継がれ、統合される必要があるからです。Jonno と同様に、Sumana の資格情報は、Travel0 の Auth0 テナントに関連付けられたデータベース接続、または AdventureZ の IdP のいずれかに保存されます (AdventureZ がユーザー ID を管理するかどうかによります) 。資格情報がどこに保存されているかは、彼女がアクセスできる 組織 のインスタンスには影響しません。

​

組織 への管理アクセス

組織 全体にわたる管理アクセスを提供する必要があるケースがあります。通常、これはユーザーのプロファイル/アカウント管理 (プロファイル管理 で説明しているとおり) 以外の管理タスクを想定したもので、従業員だけでなく第三者にもアクセスを提供する必要が生じる場合があります。

ベストプラクティス

Auth0 Dashboard 経由でアクセスを付与する Auth0 テナント管理者には、必ず多要素認証 (MFA) を有効にしてください。Auth0 テナント管理者に MFA を有効にする手順は、Auth0 テナント自体に MFA を有効にする手順とは異なる点に注意してください。Auth0 テナント管理者に MFA を有効にする方法については、Manage Dashboard Access with Multi-factor Authentication を参照してください。

Auth0 Dashboard は ロールベースのアクセス制御 で設定でき、これにより Auth0 テナントのデプロイ全体を通じて、従業員向けの特定のロールを定義できます。さらに、独自の企業向け IdP を活用して、従業員向けに Auth0 テナント管理者の認証を提供したり、信頼できる第三者に拡張されたテナント管理者アクセスを提供したりすることもできます。

その他の管理アクセスについては、通常、独自の API やアプリケーションを構築し、それを Auth0 の Management API と組み合わせて使用することになります。幅広いユーザーに対して Auth0 Dashboard 経由で Auth0 テナントへの管理アクセスを提供することは推奨されません。このようなアプリケーション/API の構築は本ドキュメントの対象外ですが、そのような取り組みを始める前に、Auth0 Professional Services に支援を求めることをお勧めします。

​

詳しくはこちら

• 単一 IDプロバイダー Organizations
• 複数 IDプロバイダー Organizations