本当にあなたのアイデンティティシステムを管理するために複数のテナントが必要ですか?
'テナント'という概念は多くのユーザーにとってあまり馴染みがないかもしれませんが、アイデンティティモデルを構築する際には特に重要です。この記事では、例を通じて、どのようなアイデンティティモデルがあなたのビジネスに適しているかを理解する手助けをします。
現在、ローコードツールとクラウドサービスの成熟度が増し、AIのツール化が進む中で、アプリを開発するためのハードルが大幅に下がっており、市場にはますます多くのアプリが登場しています。
複雑なものからシンプルなものまで、多くのアプリはユーザー登録とログインのシナリオを含んでおり、ユーザーがより安定した安全でカスタマイズされたサービスを受けられるようにしています。そして、ユーザーのログインと登録の問題を解決するための第一歩は、アイデンティティシステムを構築することです。
多くの消費者向けアプリでは、アイデンティティモデルが比較的単純であることが多く、メールアドレスとパスワードだけで十分なこともあります。新しいユーザーを引き付けるために急成長している段階のアプリにとってはこれで十分かもしれませんが、アプリが独自のビジネスモデルを持つようになると、最も単純な場合でも、たとえば広告を提供するためには、一般ユーザーアカウントと広告主アカウントを区別する必要があります。広告主アカウントは広告配信の規模や内容などをカスタマイズできますが、一般ユーザーは一部の無料コンテンツと広告を閲覧することしかできません。
Logtoはクラウドベースのアイデンティティソリューションであり、同じカーネルを持つオープンソースソフトウェア(OSS)ソリューションも提供しており、特別なニーズを持つユーザーはカスタマイズを行うことができます。Logtoのサービスは多テナントシステムに基づいて構築されてお り、各Logtoユーザーは自分のアカウントを作成し、その中で複数のテナントを管理できます。他の様々なアイデンティティクラウドサービスも類似のアーキテクチャを持っており、各クラウドサービスはそれぞれ「テナント」の定義を持っているため、本記事で議論するテナントモデルはLogtoのシナリオに限定されており、他のベンダーには他の対応する概念があるかもしれません。
注目すべきこととして、Logtoの多テナントモデルでは、テナント間のデータ(エンドユーザーのすべての情報)は分離されています。したがって、Logtoユーザーは自身のビジネスニーズに応じたエンドユーザーのアカウントデータを1つのLogtoアカウント内で管理することができます。多くの他のアイデンティティクラウドサービスは、アカウントごとに1つのテナントしかサポートできず、同時に複数のテナントを管理する必要があるユーザーが頻繁にアカウントを切り替える必要があり、これは悪い体験をもたらします。
以上のことを踏まえ、あなたのアプリに適したアカウントモデルはどのように選ぶべきでしょうか?ここでは、3つのケースを見てみましょう。
ケース1: アプリがエンドユーザーに直接サービスを提供する場合
このようなアプリのアイデンティティモデ ルは非常に単純です。例えば、音楽ストリーミングアプリを例に挙げましょう。管理者(このケースではLogtoユーザー「foo」であり、テナントオーナーであるため、管理者アクセス権を持ちます)以外にはエンドユーザーしかいません。
このシナリオでは、エンドユーザーは3つのタイプに分けられます:
- 無料プランユーザー: 無料の音楽しか再生できません
- 有料プランユーザー: 無料の音楽を再生し、自分のプレイリストを作成できます
- プレミアムユーザー: 無料の音楽とプレイリストに加え、HiFi音楽も再生できます
上記のアプリケーションシナリオにおいては、異なる権限が割り当てられた3つのロール(無料、有料、プレミアム)だけが必要です。したがってエンドユーザーがログインした後、Logtoは彼の持つロールに基づいて特定のサービス(例えばHiFi音楽へのアクセス)を提供するかどうかを決定できます。この時点で、必要要件を満たすには1つのテナントだけで十分です。
ケース2: e コマースプラットフォームアプリ
サードパーティのサービスプロバイダーとエンドユーザーを結びつけるプラットフォームで、これは現在非常に一般的な 2C ビジネスモデルです。考慮すべきユーザーグループは 2 つあります -e コマースアプリを例にとると、彼らは商人(サービスプロバ イダー)とバイヤー(エンドユーザー)です。
ここで、アイデンティティモデルを構築する方法は 2 つあります:
- バイヤーと商人のユーザーグループを同じテナントに入れる。
- バイヤーと商人をそれぞれ異なるテナントに分ける。
例をより理解しやすくするために、バイヤーは注文を行うか製品説明を閲覧でき、商人は製品の価格を変更し、製品説明を変更し、製品在庫を閲覧できることを前提とします。商人は製品情報を見つけて更新するために、製品説明を閲覧します。
アイデンティティモデル 1 では、アプリは 1 つだけあります。登録したすべてのユーザーはバイヤーになります。何かを販売する必要がある人は、自分の商品を追加して販売できるため、そのようなエンドユーザーはバイヤーの権限に加えて商人権限を取得し、自分の商品を管理します。
アイデンティティモデル 2 では、各テナントは独自のユニークなアイデンティティ情報と独自の承認ゲートウェイを持つ必要があるため、各テナントは独自のアプリを持つ必要があります。この例では、バイヤーアプリと商人アプリがあります。バイヤーアカウントは商人になることができず、商人アカウントもバイヤーになることができませ ん。商人がモデル 1 のようにバイヤーの視点から自分の製品説明をチェックしたい場合は、商人アプリで同じ機能を再実装するか、バイヤーアプリのアカウントを登録して閲覧する必要があります。これは多くの複雑さを追加しますが、その利点はバイヤーと商人のアイデンティティが完全に分離されていることです。
商人が管理すべき製品が多い場合は、アイデンティティモデル 2 を使用し、より専門的な商人アプリを開発する方が良い選択であるべきです。モデル1は、eBayのように商人が多くの製品を持たず、過度に複雑な製品管理機能を必要としないプラットフォームにより適しています。
ケース3: ITコンサルティング企業によって作られたアプリ
IT技術コンサルティング会社があり、クライアントが自分のITシステムを開発する機能を持っていないため、この会社から技術サービスを求める必要があると仮定します。
この会社に2つのクライアントがいるとし、一つは書店のための内部書籍管理システムで、もう一つのクライアントはホテルの予約システムです。
書店のオーナーの視点から見れば、ホテルの宿泊客が勝手に私の書籍管理システムにログインできるようにはしたくありません。それは非常に危険です。したがって、プライバシーを守る観点から、各クライアントに別々のテナントを設定し、テナント情報分離メカニズムを利用して、顧客のデータが他の顧客に見えないようにする必要があります。
前述のように、たとえ複数のテナントを作成する必要があっても、Logtoは1つのアカウントで複数のテナントを管理するのを支援でき、複数のアカウントを自分で作成して管理する必要がある他のいくつかのサービスよりも便利で安全です。
上記の例を通じて、複数のテナントを作成する必要があるとき、どのシナリオでは単一のテナントまたは複数のテナントを持つことができるかを理解し、あなた自身のビジネスニーズに応じて、最も適したアイデンティティモデルソリューションを選択することができます。
Logtoチームは「複数のテナントを作成すべきかどうか」という質問がビジネスの阻害要因にならないようにすることを目指しています。あなたのビジネスシナリオが単一のテナントで実現できるかどうか不確かである場合は、Logtoコミュニティに参加してご相談ください。あなたの質問は他の誰かの質問でもあるかもしれませんので、直面した課題を私たちと共有して、Logtoのプロダクトの拡張性を向上させる手助けをしてください。
アプリのアイデンティティフレームワークを選択する際には、Logtoを試してみる価値があります。小規模企業から大規模アプリケーションに至るさまざまなビジネスシナリオに適した即時使用可能なソリューションを提供します!