メインコンテンツへスキップ
ユーザーがサードパーティーの組織に属していて、指定のサービスでサインアップしなければならないユースケースはいくつかあります。そのようなユーザーは、サードパーティー組織の従業員や顧客、またはその両方であるかもしれません。状況にかかわらず、このガイドでは複数テナントのアプリケーションについて、一般的なユースケースの技術的な概要を説明します。 B2Bアプリケーションは、サービスを提供する企業の社員や顧客を対象に、快適なユーザーエクスペリエンスの作成を目指しています。これを達成するために、B2B環境のサービスプロバイダーは通常、利用者である各組織のサービスにブランディングを追加できるようにします。たとえば、勤めているAwesomeSaaS（SaaSソフトウェア企業）にHuman0という人事アプリケーションがあり、福利厚生や他の人事業務を管理しているとします。人事アプリにアクセスして、ログインするときには、ログインエクスペリエンスが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のインスタンスは通常、貴社の特定の顧客を意味します。
  • 従業員： 貴社で働いている人のことです。通常は、貴社のIDプロバイダー（）にアカウントを持ちます。1つまたは複数の組織テナントのインスタンスへの管理者アクセスを必要とする場合があります。「従業員」は、貴社の従業員のみを指します。貴社の顧客の組織に属するユーザーについては「組織ユーザー」を参照してください。
  • IDプロバイダー（IdP）： Auth0など、ユーザーの認証を管理するサービスです。ユーザープロファイル情報や資格情報を管理することもあります。サードパーティーIdP（Azure AD・Google・Facebookなど）を使用して資格情報検証やプロファイル管理の委任を可能にすることもあります。
  • 組織： 貴社の顧客の1つであるサードパーティー企業です。アプリケーションのために作成する組織インスタンスをテナントと呼ぶこともありますが、当社では、Auth0テナントとの混乱を避けるために、組織テナント と呼びます。
  • 組織テナント： 貴社のアプリケーションのサブスクリプションやプロビジョニングの一部として、貴社の顧客のために作成したテナントのことです。Auth0テナントとは異なります。
  • 組織ユーザー： 組織のメンバーとしてアプリケーションにログインする人のことです。顧客や（組織の）社員であるかもしれません。組織のコンテキストで言及される「ユーザー」は、組織ユーザーと考えることができます。

​
ユーザーの分離

組織ユーザーを分離する場合には、アプリケーションの種類を決めることが重要です。それぞれのユーザーを分離する場所と方法については、基本的に組織でユーザーを分離する方法と組織間でユーザーを共有する方法の2つがあります。
Architecture Scenarios - Multitenancy - Diagram - Multiple organizations shared decision
上のフロー図は、意思決定のプロセスを表します。また、組織インスタンスに管理者タイプのアクセスが必要かどうかも検討しなければなりません。これは、1つ以上の組織の管理者である貴社組織の社員や、ヘルプデスクサービスなどを提供する何らかのサードパーティーに必要かもしれません。 以下のセクションでは、ユーザーを分離するそれぞれの方法について詳しく説明します。（ユーザーに複数組織へのアクセスが必要になる）変則的なシナリオをよく理解してください。そのようなユースケースによって、貴社の要件に合致した方法が分かることがよくあります。

​
組織別に分離するユーザー

組織には、それぞれ独自のユーザーセットがあり、ユーザーが他組織にアクセスできないようにする必要があります。アクセスしようとした場合には、不正として拒否されなければなりません。必要であれば、ユーザーがそれぞれの所属組織で個別のアカウントを作成するように強制できます。その場合には、1人でも、ユーザーとしては異なる2人以上の人だと見なされます。 このシナリオでは、所属する組織またはアクセス権のある組織にユーザーを直接結びつけます。どのようにログインするかについて、ユーザーには以下の2つのオプションがあります：Ａ）適切な組織にプロビジョニングされたIDストレージで資格情報を作成する（Auth0テナントにあるユーザーIDとパスワードのデータベース接続）か、B）ユーザーが自身の組織のIdPでログインする。このユースケースでは、ユーザーが複数組織に属することは理にかないません。それぞれの組織に個別のIDを作成する方が便利です。Travel0 Corporate Bookingを例にすると、下の図のようになります。
Architecture Scenarios - Multitenancy - Diagram - Isolated users
Sallyは、典型的なユーザーです。MetaHexa Bankの社員で、MetaHexa BankのTravel0 Corporate Bookingインスタンスにのみアクセスできます。 そして、Patは特殊なユーザーです。Patは、フリーランスのパラリーガルとしてHoekstra & AssociatesとGupta & Smith Lawの両方から仕事を受けているため、個別のユーザーIDを使ってそれぞれの組織のTravel0 Corporate Bookingインスタンスにアクセスします。この方法での利点の1つは、Patに法律事務所でそれぞれ個別にペルソナの作成を強制すると、エラー発生の可能性を制限できることです。Patは、出張関連の予約を行うときに、該当する組織のインスタンスに個別にログインしなければなりません。 Patの状況はおそらく稀なユースケースですが、ユーザーの分離要件を決めるときに考慮するべき事柄がはっきりと分かります。ユーザーを関連する組織で分離したい場合には、個別のユーザーIDを作成する必要があります。Patには、Hoekstra & AssociatesのTravel0 Corporate BookingインスタンスにアクセスするためのIDと、Gupta & Smith LawのTravel0 Corporate BookingインスタンスにアクセスするためのIDがあります。

​
組織別に分離するユースケース

ユーザーを組織別に分離したアプリケーションは、通常、3つのユースケースをサポートします。このセクションでは、上記で説明したTravel0 Corporate Bookingアプリケーションのシナリオを例として使用します。Auth0の顧客は、Travel0です。
  • 専有のIdPがないか、使い方を知らない組織 。これが該当するのは小規模企業であることが多く、組織の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プロバイダー組織」をお読みください。

​
組織間で共有するユーザー

複数の組織に所属するユーザーでも、個別のID/アカウントを持たずに組織間を移動できれば便利です。そのような場合でも組織は専有のIdPを使用できます。
Architecture Scenarios - Multitenancy - Diagram - Shared users
このシナリオでは、ユーザーは、所属する組織、またはアクセス権のある組織に直接結びつけられません。どのようにログインするかについて、ユーザーには以下の2つのオプションがあります：Ａ）組織のAuth0テナントで特別に割り当てられたIDストアではなく、一般にプロビジョニングされたIDストレージで資格情報を作成する（Auth0テナントにある1つのユーザーIDとパスワードのデータベース接続）か、B）ユーザーが自身の組織のIdPでログインする。IDが作成されると、ユーザーに、各団体へのアクセス権限が与えられます。人によって、1組織だけにアクセスする場合もあれば、複数の組織にアクセスする場合もあります。ユーザーは、ログインが要求されたときに同じ資格情報でどの組織のインスタンスにもアクセスできることを理解する必要があります。Travel0 Adventure Managementを例にすると、上の図のようになります。 典型的なユーザーであるJonnnoは、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は、AdventureZの社員ですが、AdventureZは小規模のガイド企業が多忙な時期にフリーランスも提供するため、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に保管されます（同社がユーザーIDを社内で管理したいかどうかによる）。Sumanaの資格情報がどこに保管されるかは、どの組織のインスタンスにアクセスできるかとは関係がありません。

​
組織への管理者アクセス

貴社にある複数の組織に対して、管理者アクセスの提供が必要となるシナリオがあります。これは通常、ユーザーのプロファイルやアカウントの管理（「プロファイル管理」を参照）以外の管理タスクを行うためで、貴社の社員とサードパーティーの両方にアクセスの提供が必要な場合があります。
ベストプラクティスAuth0 Dashboardを介したアクセス権限が与えられているAuth0テナント管理者に対しては、必ず多要素認証（MFA）を有効にします。Auth0テナント管理者に対してMFAを有効化するプロセスは、Auth0テナント自体に対してMFAを有効化するプロセスとは異なるので注意が必要です。Auth0のテナント管理者に対してMFAを有効化する方法については、「多要素認証でDashboardへのアクセスを管理する」を参照してください。
はロールベースのアクセス制御を通して構成できるため、Auth0テナントのデプロイメント全体に対して、貴社の社員に特定のロールを定義することができます。会社の専有IdPを活用すれば、従業員にAuth0テナントの管理者認証を提供するだけでなく、信頼できるサードパーティにもテナント管理者アクセスを提供することができます。 管理者アクセスでは通常、独自のAPIやアプリケーションを構築して、Auth0 と併用することになります。Auth0 Dashboardを介してAuth0テナントへの管理者アクセスを広範囲のユーザーに提供することはお勧めできません。そのようなアプリケーションやAPIの構築は、このドキュメントが扱うものではないため、作業を進める前にAuth0プロフェッショナルサービスに助言を求めることをお勧めします。

​
もっと詳しく