日本語

マルチテナンシー
SaaS
組織
コラボレーション
アイデンティティ
アクセスコントロール

Logtoのマルチテナンシーモデルの説明

Logtoのマルチテナンシーモデルの設計方法と、それがSaaSアプリにどのような利点をもたらすかを見てみましょう。

Gao

Founder

11/29/2023

ユーザー認証に何週間も費やすのはもうやめましょう

Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。

始めましょう

混乱

"マルチテナンシー" という用語をアイデンティティの分離を表現するために使用するいくつかのプロダクトを耳にしたことがあるかもしれません: 各テナントは独自のユーザー、役割、権限、データを持っています。

直感に反するように思えるかもしれませんが、実際には"マルチテナンシー"はその逆を意味します: 複数のテナントが単一のインスタンスでリソースを共有しているのです。ユーザーにとっては、アプリ内のアイデンティティは運転免許証のようなものです。例えば、一つの運転免許証でさまざまな州で運転できる（複数の組織に対して一つのアイデンティティ）、各州に新しい運転免許証を申請する代わりに。

Logtoのモデル

Logtoでは、設計の初期段階でこの混乱に気づき、アプリとユーザーに正しく適用することを努めました。私たちの設計は次のとおりです:

テナントは、それ自体が独自のユーザー、権限、データを持つ単一のLogtoインスタンスと見なすことができます。
テナント内には、複数の組織が存在することがあります。ユーザーは複数の組織のメンバーになることができます。
各組織には、ロールベースアクセスコントロール (RBAC) パターンを採用し、同じ組織ロールと組織権限のセットを使用します。このセットを組織テンプレートと呼びます。
組織ロールと組織権限は、組織のコンテキストにおいてのみ有効です。
- 例えば、あるユーザーは一つの組織で「管理者」（ロール）ですが、他の組織では「メンバー」（ロール）かもしれません。
- 組織のコンテキストがなければ、組織ロールと組織権限は無意味です。
組織のロールではなく、組織権限を使用して組織内のアクセスを制御します。

このモデルは、特にSaaSアプリのアイデンティティ管理に柔軟性と再利用性を提供します。人気のあるSaaSアプリを見てみると、このモデルに全て一致することがわかります。アプリによって「組織」という用語が異なるかもしれませんが、例えば「ワークスペース」や「チーム」など、それでもコンセプトは同じです。

たとえば、Notion（人気のあるコラボレーションツール）では:

一つのアカウントで複数のワークスペースを作成し参加でき、新しいアカウントを各ワークスペースごとにサインアップする必要がありません。
各ワークスペースでは、Notionは「ワークスペースオーナー」や「メンバー」などの同じセットのアクセスレベルを定義しており、各ワークスペースに異なるアクセスレベルを期待することがあります。

したがって、ユーザーはアカウントを切り替えたり再度サインインすることなく、ワークスペース間を簡単に切り替えることができ、ワークスペース間の分離も維持されます。これをLogtoのモデルに翻訳すると、次のようになります:

組織テンプレートは「オーナー」と「メンバー」の2つのロールを定義します。
ユーザーがワークスペースに参加した場合、そのユーザーは組織のメンバーであり、その組織内で「メンバー」ロールを持っています。
ユーザーがワークスペースを作成した場合、そのユーザーは組織のメンバーであり、その組織で「オーナー」ロールを持っています。

異なるロールに応じて、ユーザーは異なるワークスペース（組織）で異なる権限を持つことができます。

利点

ユーザー体験

ユーザーにとって、真のシングルサインオン体験を楽しむことができます。組織間の切り替えは、タブ間の切り替えと同じくらい簡単です。

再利用性

SaaSアプリの一つの利点は、それが標準化されており、スケーラブルであるということです。たとえば、Notionで新しいワークスペースを数クリックで作成し、すぐに使用可能にすることができます。

アプリが成長するにつれて、各組織にさらに多くのロールと権限を追加したいと思うかもしれません。たとえば、新しいロール「ゲスト」や新しい権限「招待:ゲスト」。すべての既存組織を一つずつ更新しなければならない場合は、悪夢になる可能性があります。

Logtoを使用すると、組織テンプレートを更新することで、すべての既存組織が自動的に更新されます。

一つのアクセスコントロールモデル、複数のユースケース

Logtoでは、組織とAPIリソースの両方に同じアクセスコントロールモデル (RBAC) を使用しています。つまり、RBACに慣れていれば、新しいアクセスコントロールモデルを学ぶ必要がないということです。同時に、それらは互いに分離されているため、異なるユースケースに使用できます。

最もエキサイティングな部分は、それらを同時に使用できることです。Notionの例を拡張しましょう:

ワークスペースにアクセスする場合、Logto組織RBACを使用できます。
アカウントレベルのリソース（たとえばプロファイルや請求情報）にアクセスして更新する場合は、Logto APIリソースRBACを使用できます。

ほとんどのLogto SDKは両方の種類のRBACをサポートしています。

違い

組織RBACとAPIリソースRBACは次の点で異なります:

組織RBACは組織のコンテキストを必要としますが、APIリソースRBACは必要ありません。
組織RBACは組織内のアクセスを制御するために使用され、APIリソースRBACはAPIリソースへのアクセスを制御するために使用されます。
ユーザーは異なる組織で異なる組織ロールを持つことができますが、APIリソースのロールはテナント内で普遍的です。
これら二つのRBACのロールと権限は分離されています。

結論

SaaSアプリを構築するのは難しく、Logtoがあなたのコアビジネスに集中できるように支援できることを願っています。もし質問や提案があれば、遠慮なく私たちにフィードバックしてください。

Logto Cloud を無料で試す

混乱#

Logtoのモデル#

利点#

ユーザー体験#

再利用性#

一つのアクセスコントロールモデル、複数のユースケース#

結論#

混乱#

Logtoのモデル#

利点#

ユーザー体験#

再利用性#

一つのアクセスコントロールモデル、複数のユースケース#

結論#

混乱

Logtoのモデル

利点

ユーザー体験

再利用性

一つのアクセスコントロールモデル、複数のユースケース

結論

混乱

Logtoのモデル

利点

ユーザー体験

再利用性

一つのアクセスコントロールモデル、複数のユースケース

結論