Skip to main content

利用可否は Auth0 のプランによって異なります

この機能が利用可能かどうかは、ログイン実装の詳細と、Auth0 のプランまたはカスタム契約の両方によって異なります。詳しくは、Pricing をご覧ください。

​
ビジネスケース

Auth0 Organizations 機能は、エンドユーザーがアクセスするアプリケーションを持つ企業間取引 (B2B) の実装に特に適しています。
B2B Organizations のビジネスケース図
B2B 実装によく見られる特徴は次のとおりです。
  • 他社の従業員による利用を目的としてライセンス提供される製品であること。
  • 各 組織 で、認証エクスペリエンスに対して独自のフェデレーションと軽微な branding が必要になること。
  • アプリケーション内のアクセスレベルを、各 組織 のメンバーに割り当てる roles で表現できること。
Organizations がどのように役立つのかを示すために、いくつかのビジネスケースの例を見ていきましょう。

​
サンプルシナリオ

Travel0 はオンライン旅行サービスを提供する架空の企業で、Auth0 テナントを設定しています。Travel0 には複数のアプリケーションがありますが、ここでは Organizations を活用することでメリットが得られる 1 つのアプリケーションに注目します。 Travel0 Adventure Management: 顧客が急流ラフティング、乗馬、ジップラインなどのアドベンチャーを企画・販売できるオンラインアプリケーションです。各アドベンチャーにはガイドが付き、ガイドはこのアプリケーションを使って登録やスケジュール管理を行えます。ガイドは顧客に直接雇用されている場合もあれば、フリーランスの場合もあります。 このアプリケーションの顧客には、次のような企業があります。
  • Granite Outpost Rafting and Ziplines: 大勢のガイドスタッフを直接雇用している老舗企業ですが、ときどきフリーランスのガイドにも声をかけています。従業員向けに独自の を利用しています。
  • AdventureZ: 多数のガイドを直接雇用している大規模なイベント会社ですが、頻度は低いもののフリーランスも活用しています。また、ガイドを必要としている他社向けに、自社の従業員がフリーランスとして働けるようにもしています。従業員向けに独自の IdP を利用しています。
  • Rocky Mountain High Adventures: 市場に参入したばかりの新しい会社です。共同創業者がツアーの大半を運営しており、繁忙期にはフリーランスにサポートを依頼しています。IT スタッフはおらず、独自のアイデンティティプロバイダー (IdP) を設定する時間も、その意向もありません。AdventureZ と契約を結んでおり、AdventureZ の従業員であれば誰でも同社のためにフリーランスとして働けます。

​
計画時の考慮事項

組織を設定する際は、次の点を考慮してください。
  • ログイン体験: ユーザーはログイン時に組織を選択する必要がありますか？ ユーザーには、アプリケーションのデフォルトのログインページが表示されますか、それとも組織向けにカスタマイズされたログインページが表示されますか？
  • 接続モデル: 組織間で共有されるユーザーはいますか？ ユーザーは、組織独自の内部アイデンティティプロバイダーを使用してログインできる必要がありますか？
  • ロール: アプリケーションでは、ユーザーに各組織内で特定のロールが割り当てられている必要がありますか？ 割り当てられたロールを使用して、管理者が自分の組織をセルフサービスで管理できるカスタムダッシュボードを構築する予定はありますか？

​
ログイン体験

まず、ユーザーが組織にログインする際にどのような体験にするかを決める必要があります。エンドユーザーをAuth0内の特定の組織のログインプロンプトに直接送ることも、ログインしたい組織の名前を入力できるプロンプトに送ることもできます。 さらに、アプリケーション用に設定されたデフォルトのページを使用するか、ページテンプレートを使って組織ごとに専用のログインページをカスタマイズするかを選ぶ必要があります。詳しくは、Create Your First Organizationを参照してください。

​
接続モデル

通常、各 組織 はビジネス上の顧客やパートナーのいずれか 1 つに直接対応しますが、ユーザーは複数の組織のメンバーになることができます。ユーザーが顧客の組織にどのように対応づけられるかを理解することで、組織と接続をどのようにモデル化すべきか判断しやすくなります。ユーザーのシナリオは 2 つあります。
  • ユーザーが 1 つの 組織 に限定される場合: すべてのユーザーは、必ず 1 つの 組織 のみに所属します。ユーザーが複数の 組織 に所属する必要がまったくない場合や、組織 ごとに別の ID を作成したほうが適切な場合です。
  • ユーザーが複数の 組織 間で共有される場合: どのユーザーも複数の 組織 に所属でき、同じ ID を使って 組織 間を移動できる必要があります。
Travel0 Adventure Management の例で、次のユーザーを想定してみましょう。
  • Jonno: Rocky Mountain High Adventures に直接雇用されているガイドで、Rocky Mountain の 組織 にのみログインできる必要があります。 Rocky Mountain には独自の IdP がないため、Jonno の資格情報は Travel0 のデータベース接続に保存され、Jonno には Rocky Mountain 組織 のメンバーシップが割り当てられます。
  • Hiroko: Granite Outpost Rafting and Ziplines に直接雇用されているガイドで、Granite Outpost の 組織 にのみログインできる必要があります。 Granite Outpost には独自の IdP があるため、Hiroko の資格情報は Travel0 のデータベース接続、または Granite Outpost が自社の IdP を表すために設定したエンタープライズ接続のいずれかに保存できます。そのうえで、Hiroko には Granite Outpost 組織 のメンバーシップも割り当てる必要があります。Granite Outpost の IdP を使用する場合は、そのエンタープライズ接続もその 組織 に対して有効化されていなければなりません。
  • Emilio: Rocky Mountain High Adventures と Granite Outpost Rafting and Ziplines の両方でフリーランスとして働くガイドで、両方の 組織 にログインできる必要があります。 Emilio が両方の 組織 で同じ資格情報を使えるようにしたい場合は、Emilio の資格情報を Travel0 のデータベース接続に保存し、Emilio には Rocky Mountain 組織 と Granite Outpost 組織 の両方のメンバーシップを割り当てる必要があります。 そうでない場合、Emilio は Rocky Mountain High Adventures 用に Travel0 のデータベース接続で 1 組の資格情報を設定し、Rocky Mountain High 組織 のメンバーシップを割り当てられる必要があります。そのうえで、Travel0 のデータベース接続または Granite Outpost のエンタープライズ接続のいずれかで別の 1 組の資格情報を設定し、Granite Outpost 組織 のメンバーシップを割り当てられる必要があります。最後に、Granite Outpost の IdP を使用する場合は、設定済みのエンタープライズ接続を Granite Outpost 組織 に対して有効化する必要があります。
  • Sumana: AdventureZ に直接雇用されているガイドですが、AdventureZ と Rocky Mountain の契約のもと、ときどき Rocky Mountain High Adventures でもフリーランスとして働きます。AdventureZ と Rocky Mountain にはガイドの評価システムがあり、Sumana の評価は AdventureZ から Rocky Mountain に引き継がれ、組織 間で統合される必要があります。 Sumana の資格情報を Travel0 のデータベース接続に保存し、Rocky Mountain 組織 と AdventureZ 組織 の両方にメンバーシップを割り当てることもできます。あるいは、AdventureZ が自社の IdP を共有したい場合は、Sumana の資格情報を AdventureZ が自社の IdP を表すために設定したエンタープライズ接続に保存し、そのエンタープライズ接続を Rocky Mountain 組織 と AdventureZ 組織 の両方に対して有効化する必要があります。 さらに Sumana が Granite Outpost Rafting and Ziplines でもフリーランスをするよう招待された場合、彼女の資格情報は Travel0 のデータベース接続に保存することも、Granite Outpost の IdP に追加することもでき、Granite Outpost 組織 のメンバーシップを割り当てる必要があります。
いくつの組織を持つか、また接続モデルをどのような形にするかを決定したら、データベース、ソーシャル、または エンタープライズ 接続を設定し、組織を作成 し、組織のメンバーシップを設定 するか、組織の接続を有効化 できます。

​
アプリケーションのアクセスモデル

デフォルトでは、Organizations が有効でアクティブな接続が設定されているすべてのアプリケーションに、組織のメンバーがアクセスできます。これが暗黙的なアクセスモデルです。 アプリケーションごとのアクセスを使用すると、個々の組織を明示的なアクセスモデルに切り替えられます。組織で有効にすると、明示的なグラントがないファーストパーティアプリケーションはブロックされます。明示的なグラントがないサードパーティアプリケーションは、引き続きその組織の Third-Party Application Access ポリシーに従います。テナント内の他の組織には影響しません。 次のような場合は、明示的なモデルを使用してください。
  • 特定の顧客組織が購入した製品へのアクセスを制限する。
  • 組織にプロビジョニングされていないアプリケーションにメンバーがアクセスできないようにする。
  • カスタム Actions や app_metadata による回避策を使わずに、アプリケーションの利用権限を管理する。
はじめに、組織へのアプリケーションアクセスの付与を参照してください。

​
ロール

組織のメンバーには、ロールを割り当てることができます。これらのロールを使って、アプリケーションのアクセス制御を定義できます。たとえば、API と SDK を使用してユーザー向けのダッシュボードを構築した場合、特定のメンバーに管理者ロールを割り当て、ダッシュボードを通じて自分たちの組織を管理できるようにすることができます。
Management API には、confidential クライアントからのみアクセスする必要があります。その利用には、Auth0 Management API のレート制限が適用されます。

​
制限事項

Auth0 Organizations 機能には、次の制限事項があります。
  • この機能を利用できるかどうかは、ご利用の Auth0 のサブスクリプションプランによって異なります。詳しくは、Auth0 Pricingをご覧ください。
  • Universal Login でのみサポートされます (クラシックログインおよび Lock.js はサポート対象外です) 。
  • Organizations が有効化されたアプリケーションは、次のグラントおよびプロトコルと互換性がありません: パスワード、Device 、 (Auth0 を IdP として使用する場合) 。
  • サポートしていないもの:
    • 組織 ごとのカスタムドメイン (たとえば、サンプルシナリオのように 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 でサポートされています。組織でサードパーティアプリケーションを有効にする方法については、組織のサードパーティアプリケーションアクセスを有効にするをご覧ください。

​
詳しくはこちら