Auth0 Organizationsの仕組みを理解する

Auth0 Organizations機能は、エンドユーザーがアクセスするアプリケーションについて企業間（B2B）の実装に最適なサポートを提供します。

一般的なB2Bの統合には以下のような特徴があります。

• 従業員が別の企業にライセンスされた製品を使用する

• 認証エクスペリエンスについて、各組織が独自のフェデレーションやちょっとしたブランディングを必要としている

• アプリケーションでのアクセスレベルを、各組織のメンバーに割り当てられたロールで表すことができる

Organizationsが企業での統合に役立つことを顕著に示す例を見ていきましょう。

オンラインの旅行代理店サービスを提供する架空の会社、Travel0が、Auth0テナントをセットアップしています。Travel0にはいくつかのアプリケーションがありますが、Organizationsが特に役立つあるアプリケーションに焦点を当ててみます。

Travel0 Adventure Management：顧客が渓流下りや乗馬、ジップラインなどのアドベンチャーを企画して販売できるオンラインアプリケーションです。各アドベンチャーにはガイドが同行し、このアプリケーションを使ってサインアップやスケジュールを管理します。ガイドは顧客に正規雇用されている場合も、フリーランスの場合もあります。

このアプリケーションは以下のような顧客によって利用されています。

• Granite Outpost Rafting and Ziplines：定評のある企業で、多くのガイドを正規雇用しているが、時々フリーランスのガイドを雇うこともある。社員のための専有のIdPがある。

• AdventureZ：大手のイベント企業で、多数のガイドを正規雇用しているが、ごくたまにフリーランスを雇うこともある。正規の社員がフリーランスのガイドとして他の企業の仕事を受けられるようにもしている。社員のための専有のIdPがある。

• Rocky Mountain High Adventures：新たに市場に参入してきた新企業。共同創立者らが自らほとんどのツアーを運営し、繁忙期にはフリーランスの手を借りている。IT担当者はおらず、独自のIDプロバイダー（IdP）をセットアップする時間も意欲もない。AdventureZとの契約で、AdventureZの社員をフリーランスとして雇うことができる。

組織を設定する際には、以下を検討します。

• ログインエクスペリエンス：ユーザーがログインする際に組織を選択する必要があるのか。ユーザーが使用するのは、アプリケーションのデフォルトのログインページか、それとも組織ごとにカスタマイズされたログインページなのか。

• 接続モデル：ユーザーが組織間で共有されるのか。ユーザーは組織独自の内部のIDプロバイダーを使ってログインする必要があるのか。

• ロール：アプリケーションは組織内でユーザーに割り当てられた特定のロールを必要とするのか。カスタムダッシュボートを作成して、管理者が割り当てられたロールを使って独自に組織を管理できるようにするのか。

まず、ユーザーが組織にログインする際にどのような体験をするのか決めなければなりません。Auth0でエンドユーザーを特定の組織のログイン画面へ直接送るのか、ログインしたい組織の名前を入力できる画面へ送るのかを選択できます。

次に、アプリケーションのために構成されたデフォルトのユニバーサルログインを使用するのか、それともページテンプレートを使って各組織に特化したログインページにカスタマイズするのかを決めなければなりません。詳細については、「初めて組織を作成する」を参照してください。

各組織は通常、1つの企業顧客やパートナーと直接マッピングされますが、ユーザーは複数の組織のメンバーになり得ます。ユーザーがどのようにして顧客の組織にマッピングされるかを理解すると、組織や接続をどのようにモデル化すればよいのかを決定しやすくなります。ユーザーのシナリオとしては次の2つがあります。

• ユーザーを1つの組織に分離する：ユーザーはそれぞれ1つの組織にしか所属しない。ユーザーが複数の組織に属する必要がない場合か、ユーザーが各組織で別のIDを使った方が理にかなっている場合。

• ユーザーを組織間で共有する：ユーザーは複数の組織に所属し、同じIDを使って組織間を移動することができる。

Travel0 Adventure Managementの例を使って、以下のユーザーを想定してみましょう。

• ジョンノ：Rocky Mountain High Adventuresの正規社員で、Rocky Mountainの組織にのみログインできなければならない。Rocky MountainにはIdPがないため、ジョンノの資格情報はTravel0のデータベース接続に保管され、ジョンノにはRocky Mountain組織のメンバーシップが割り当てられている。

• ひろこ：Granite Outpost Rafting and Ziplinesの正規社員で、Granite Outpostの組織にのみログインできなければならない。Granite Outpostには独自のIdPがあるため、ひろこの資格情報はTravel0のデータベース接続か、Granite OutpostがIdPとしてセットアップしたエンタープライズ接続に保管できる。ひろこにはGranite Outpost組織のメンバーシップが割り当てられなければならない。Granite OutpostのIdPを使用する場合には、エンタープライズ接続が組織に有効でなければならない。

• エミリオ：Rocky Mountain High AdventuresとGranite Outpost Rafting and Ziplinesの両社でフリーランスとしてガイドを務めている。両社の組織にログインできなければならない。エミリオが両社の組織に同じIDを使えるようにしたい場合、エミリオの資格情報はTravel0のデータベース接続に保管され、エミリオにはRocky MountainとGranite Outpost両組織のメンバーシップが割り当てられる必要がある。一方、両社で別のIDを使用する場合、エミリオはRocky Mountain High Adventures用の1セットの資格情報をTravel0のデータベース接続でセットアップし、Rocky Mountain High Adventures組織のメンバーシップが割り当てられ、次にGranite Outpost用の別のセットの資格情報をTravel0のデータベース接続またはGranite Outpostのエンタープライズ接続でセットアップして、Granite Outpost組織のメンバーシップが割り当てられる必要がある。Granite OutpostのIdPを使用する場合には、エンタープライズ接続がGranite Outpost組織に有効でなければならない。

• スマナ：AdventureZに正規雇用されているガイドだが、Rocky Mountain High AdventuresとAdventureZ間の契約に基づき、時々フリーランスとしてRocky Mountainで働く。AdventureZとRocky Mountainにはガイドの評価システムがあり、スマナの評価はAdventureZからRocky Mountainへ引き継がれ、組織間で結合される必要がある。スマナの資格情報はTravel0のデータベース接続に保管され、Rocky MountainとAdventureZ両組織からメンバーシップを割り当てられる。あるいは、AdventureZが独自のIdPの共有を望む場合には、スマナの資格情報はAdventureZがIdPとしてセットアップしたエンタープライズ接続に保管され、Rocky MountainとAdventureZ両組織に対してエンタープライズ接続の有効化が必須となる。スマナがGranite Outpost Rafting and Ziplinesにもフリーランスとして雇われた場合、スマナの資格情報はTravel0のデータベース接続に保管されるか、Granite OutpostのIdPに追加され、Granite Outpost組織のメンバーシップが割り当てられる必要がある。

いくつの組織を所有し、どのような接続モデルになるべきかを決定したら、データベース、ソーシャル、またはエンタープライズ接続をセットアップする、組織を作成する、組織メンバーシップを構成する、または組織接続を有効にすることができます。

組織のメンバーにはロールを割り当てることができます。それらのロールは、アプリケーションへのアクセス制御を定義するのに使用します。たとえば、ユーザーのためにAPIやSDKを使ってダッシュボートを作成したら、特定のメンバーに管理者のロールを割り当てて、ダッシュボートで組織を自己管理できるようにすることができます。

Auth0 Organizations機能には以下の制限があります。

• この機能が利用できるかどうかは、ご利用のAuth0サブスクリプションプランによります。詳細については、「Auth0の価格設定」をお読みください。

• ユニバーサルログインにのみ対応しています（従来型のログインやLock.jsには対応していません）。

• 組織対応型のアプリケーションは、以下の付与とプロトコルとは互換性がありません。リソース所有者パスワード、デバイス認証フロー、WS-Fed（IdPとしてのAuth0）。

• 以下には対応していません。

  • 組織ごとのカスタムドメイン（たとえば、サンプルのシナリオで説明すると、Rocky Mountain High AdventuresとGranite Outpost Rafting and Ziplining両社が、login.travel0.comをログインドメインとして使用すると、Organizationsが役立ちます。あるいは、Rocky Mountain High Adventuresがlogin.rockymountain.com 、Granite Outpostがlogin.graniteoutpost.comをそれぞれ使用したい場合は、複数のAuth0テナントを使用する必要があります。

  • Delegated Administration Extension（委任管理拡張機能）での統合

  • Authorization Extension（認可拡張機能）での統合

  • サードパーティ製アプリケーションでの統合

• 最初の組織を作成する
• 組織のカスタム開発
• トークンとOrganizations（組織）を使用する
• Organizationsの構成
• エンティティ制限ポリシー