複数組織アーキテクチャ

複数の Auth0 組織向けのアプリケーションインスタンスに対応する必要があるマルチテナントアーキテクチャの統合ガイドです。

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

B2B アプリケーションでは、提供先企業の従業員や顧客にとって快適なユーザー体験を実現することが重視されます。そのため、B2B 環境のサービスプロバイダーは、自社サービスを利用する各組織ごとにブランディングを追加できるようにすることがよくあります。たとえば、あなたが AwesomeSaaS (SaaS 企業) で働いていて、勤務先で福利厚生やその他の人事業務を管理する HR アプリケーション Human0 を利用しているとします。HR アプリにアクセスしてログインすると、ログイン画面には 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 つであるサードパーティ企業です。アプリケーション用に作成された組織インスタンスをテナントと呼ぶこともありますが、Auth0 テナント との混同を避けるため、ここでは Organization Tenant と呼びます。
• Organization Tenant: アプリケーションのサブスクリプションやプロビジョニングの一環として、顧客向けに作成されたテナントを指します。これは Auth0 テナント とは異なります。
• Organization User: 組織のメンバーとしてアプリケーションにログインする人です。これはその組織の従業員である場合もあれば、顧客である場合もあります。組織の文脈で参照されるユーザーは、いずれも Organization User と見なせます。

​

ユーザーの分離

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

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

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

​

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

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

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

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

一方、Pat は典型的ではないユーザーです。Pat はフリーランスのパラリーガルで、Hoekstra & Associates と Gupta & Smith Law の両方で働いているため、それぞれの Travel0 Corporate Booking インスタンスに別々のユーザーアイデンティティでアクセスします。このアプローチの大きな利点の 1 つは、Pat に 2 つの別個のペルソナ (法律事務所ごとに 1 つ) を作成させることで、ミスの可能性を抑えられる点です。Pat が出張を予約する際は、予約を行うために対象の組織インスタンスに個別にログインする必要があります。

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

​

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

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

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

最初の 2 種類の組織については、解決策は比較的明快です。これらの組織は単一 IdP の組織と見なされ、アプローチもほぼ共通です。詳細については、単一のIDプロバイダーの組織 を参照してください。

組織に複数の IdP がある場合は、より複雑になる傾向がありますが、複雑さを最小限に抑えるためのアプローチがいくつかあります。詳細については、複数のIDプロバイダーの組織 を参照してください。

​

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

ユーザーは複数の組織に所属することがあります。その場合、組織間を移動するたびに別々のアイデンティティやアカウントを持たなくて済むほうが便利です。こうした場合でも、各組織は引き続き独自の IdP を使用できます。

このシナリオでは、ユーザーは所属先またはアクセス権を持つ組織に直接ひも付くものではなくなります。ユーザーのログイン方法には 2 つの選択肢があります。A) 組織ごとに Auth0 テナント内で個別に割り当てられた IDストアではなく、共通にプロビジョニングされた アイデンティティストア (つまり、Auth0 テナント内の単一の UserID/Password データベース接続) に認証情報を作成する、または B) 自分の組織の IdP を使ってログインする、のいずれかです。ユーザーがひとたびアイデンティティを持てば、その後はアクセスを許可される各組織へのアクセス権が付与されます。アクセス先が 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 に保存されます (ユーザーアイデンティティを自社で管理するかどうかによって異なります) 。

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

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

​

組織に対する管理アクセス

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

推奨事項

Auth0 Dashboard 経由でアクセス権を付与される Auth0 テナント 管理者には、必ず MFA を有効にしてください。Auth0 テナント 自体に MFA を有効にする場合とは異なる手順で、Auth0 テナント 管理者に対して MFA を有効にする必要がある点に注意してください。Auth0 テナント 管理者に MFA を有効にする方法については、MFA を使用した Dashboard アクセスの管理を参照してください。

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

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

​

詳細情報

• 単一のIDプロバイダーの組織
• 複数のIDプロバイダーの組織