コンテンツにスキップ
Authrim

マルチテナンシーアーキテクチャ

環境はデプロイと運用の単位、テナントはその中の ID・認可の境界、クライアントはテナントに属するアプリです。テナントとデータベースは同じものではありません。複数テナントが共有容量を使う構成も、Control Plane のポリシーでテナント専用に配置する構成もあります。

環境・テナント・クライアント

Section titled “環境・テナント・クライアント”
対象役割
環境Setup が管理するデプロイ、リソース設定、鍵、リリース状態。本番と評価用のリソースは分離
テナントアカウント、クライアント、ポリシー、実行時コンテキストのスコープ
クライアントプロトコル設定、リダイレクト URI、認証方式を持つ登録済みアプリ
組織メンバーシップや認可に使う対象。すべての組織が独立した環境・テナントになるわけではありません

アプリは対象のテナントに登録します。アプリ間や環境間でのシークレット共有は境界を弱めます。また、設定ファイルのコピーだけでは環境移行の計画にはなりません。

テナントの解決

Section titled “テナントの解決”

リクエスト処理では、ホストとリクエストの種類を解決してからテナントのコンテキストを検証します。設定済みのドメイン解析と、登録された独自ドメインの解決経路があります。プラットフォーム管理、テナント管理、Discovery・UI、プロトコルのリクエストでは、必要なコンテキストが異なります。

tenant_hint は画面誘導のヒントであり、別のテナントのデータを選ぶ権限ではありません。転送されたホストや管理用のテナント指定にも、それぞれ検証があります。任意のヘッダーを追加しても、テナントを越えたアクセス権は得られません。

ドメインと issuer

Section titled “ドメインと issuer”

BASE_DOMAIN、既定・プライマリのテナント、ドメイン解析、issuer の設定を組み合わせて解決します。単純なサブドメイン構成では acme.auth.example.com のような URL を使えますが、実際には設定されたマッピングに従います。ホストのラベルが常に canonical なテナント ID と同じとは限りません。

裸のドメインの受付と issuer URL の生成は関連しますが、別の処理です。NAKED_DOMAIN_AS_ISSUER は issuer の生成に影響します。また、登録済みの独自ドメインには専用のリゾルバーがあるため、「BASE_DOMAIN 配下以外は必ず拒否する」という説明も正確ではありません。

Setup が生成した URL と、テナントの Discovery 文書を使用してください。不正・未登録のホストでテナント検証を回避することはできません。DNS の変更だけではテナントを作成できず、issuer やアプリ側の信頼設定を安全に変更することもできません。

データの配置

Section titled “データの配置”

Control は共有プールとテナント専用の配置を管理します。署名付きのランタイムレジストリが実際の保存先とルートの世代を記録します。テナントのメタデータとアカウントの Core・PII は異なる保存先になる場合があり、アカウントの場所は Lookup が解決します。

DB の解決ではテナント、役割、バインディング、シャード、データ所在地の区分、世代を検証します。テナント専用配置でも、テナントを限定するアクセス検証は必要です。逆に、論理的に分離されていても、必ず一テナント一 DB というわけではありません。

テナントを追加する

Section titled “テナントを追加する”
  1. 必要な管理権限でテナント管理機能を使います。古い /admin/tenants の例は使用しません。
  2. 対応する配置とドメイン設定を選び、リソースの準備とレジストリへの反映を完了させます。
  3. テナントが利用可能であること、DNS、Discovery の issuer を確認します。
  4. 対象テナントにクライアントと ID プロバイダーを登録します。
  5. 認証・トークン検証と、別テナントへのアクセスが拒否されることを確認します。

リクエスト形式と権限は現在の Admin APIを参照してください。テナントの行が作成されたことだけでは、経路や DB がすべて準備済みとは判断できません。

複数テナントの運用

Section titled “複数テナントの運用”

管理権限、トークンの issuer・audience、セッション、キャッシュ、DB アクセスを適切なコンテキストに限定します。実装にはテナント対応のヘルパーがありますが、独自 SQL や連携コードでも正しく使う必要があります。DB アダプターがすべてのクエリへ自動でテナント条件を追加するわけではありません。

外部 ID 連携やトークン交換には、明示的な信頼設定が必要です。それらがテナントの境界をなくしたり、任意のテナントのデータへのアクセスを許可したりするわけではありません。

構成やデータ配置を変更する際は、対応する Setup・Control の操作を使い、完了を確認します。BASE_DOMAIN を設定するだけでは、既存データは新しいマルチテナント構成へ移行しません。

アーキテクチャ、PII 分離、インストールも参照してください。