アイデンティティ管理とアクセス管理

多くの場合、マルチテナントアーキテクチャへの移行はアイデンティティから開始されます。アプリケーションにアクセスする各ユーザーはテナントに接続する必要があります。このユーザー ID からテナントへのバインディングは、非公式に SaaS アイデンティティと呼ばれます。SaaS アイデンティティのキー属性は、テナントコンテキストを最優先される構造に引き上げ、SaaS アプリケーションの認証と承認モデル全体に直接接続します。

このアプローチにより、テナントコンテキストはユーザー ID の伝達とアクセスに使用されるアーキテクチャ構造と同じ構造を使用して、アーキテクチャのすべてのレイヤーを経由できます。例えば、アプリケーションに 100 のマイクロサービスがある場合、これらの各サービスが別のサービスにラウンドトリップしないで、テナントコンテキストを取得して適用できる必要があります。別のサービスを介してこのコンテキストを管理するとレイテンシーが増加し、多くの場合、アーキテクチャにボトルネックが生じます。

テナントコンテキストは、複数のパターンを使用してアイデンティティに挿入できます。アプリケーションに選択した ID プロバイダーとテクノロジーによって、このコンテキストをエクスペリエンスに組み込むために最終的に適用するアプローチと戦略が直接形成されます。このツールは変わる場合もありますが、基本的に必要なのは、ユーザーがアプリケーションに入る際にテナンシーが挿入される環境の全体的な認証エクスペリエンスにテナンシーを導入することです。

図 15 は、AWS のサービスを使用してこれを実現する一般的な方法の例を示しています。この例には SaaS 環境へのテナントコンテキストの挿入に使用される一般的なコンポーネントとテクノロジーが含まれています。これについては図の左側で示します。ここでは、テナントがサインアップフォームに入力し、アプリケーションの登録サービスに対する呼び出しをトリガーします。

図 15: テナントコンテンツの挿入

この登録サービスはテナントを作成してから Amazon Cognito でユーザーを作成します。このプロセスの一環として、ユーザーのテナントとの関係に関する情報が保持されるカスタムクレームをユーザーの属性に導入します。これらのカスタムクレームは、ユーザー ID 署名の一部となり、最優先される構造としてテナントに直接接続されます。

オンボーディングが完了した後、ユーザーのログイン時にこれらのユーザー属性とテナント属性が適用される方法を確認できます (図の右側)。ここでは、ユーザーが Amazon Cognito に対して認証し、そのプロセスの一部として、オンボーディングプロセス中に作成されたカスタムクレームを含む JSON Web トークン (JWT) を返すことがわかります。

これで、テナントコンテキストをマルチテナントアプリケーションサービスとの対話に挿入する際に必要なすべての情報を含むトークンを使用できるようになります。この例では、Product マイクロサービスに対する各リクエストのヘッダーでベアラートークンとして渡される JWT を示します。このサービスは、別のサービスを呼び出さなくても、このトークンからコンテキストを取得して適用できるようになりました。

最後に、この Product マイクロサービスは Order マイクロサービスを呼び出し、リクエストのヘッダーで JWT を渡します。これは、ルックアップやレイテンシーを増やさずに、すべてのマイクロサービスの呼び出しをテナントコンテキストがどのように経由するのかを示しています。

この例では、Amazon Cognito を使用してユーザー ID とテナント ID を接続しています。ただし、これと同じモデルは他の ID プロバイダーや代替認証スキームでも実装できます。ここで重要なのは、テナントとユーザーを接続する表現を生成できる認証エクスペリエンスを構築していることです。この表現は、ソリューションのすべてのレイヤーで使用できる必要があります。