アイデンティティハブ
Authrim は、複数のログイン方法や外部 ID プロバイダーをアカウントに結び付け、そのアカウントをアプリの認証とポリシー評価に使います。「アイデンティティハブ」はこの役割を表す言葉です。同じメールアドレスの ID をすべて自動で統合する、という意味ではありません。
ID の提供元とアカウント
Section titled “ID の提供元とアカウント”外部 OIDC/OAuth プロバイダーは Bridge が扱い、SAML には IdP・SP の機能があります。ローカルのログイン方法にはパスキーやメールコードがあります。canonical モデルでは、すべてを一つのユーザー行に詰め込まず、主体、アカウント、関連、プロフィール、機微な値を分けています。
例えば、企業の SSO とローカルログインを同じアプリで提供できます。ただし、既存アカウントでログインするか新規作成するかは、プロバイダー設定、テナント、連携ルール、アプリのポリシーによって決まります。
アカウントの紐付け
Section titled “アカウントの紐付け”Bridge の identity stitching は、明示的な連携や既存の外部 ID を確認します。メールによる自動連携には、次の条件も必要です。
- identity stitching が有効であること。
- プロバイダーの
autoLinkEmailが有効であること。 - 外部プロバイダー側でメールが検証済みであること。
- 一致したローカルアカウントのメールも検証済みであること。
- 外部 ID が別のアカウントと競合していないこと。
同じメールのアカウントがあっても連携条件を満たさない場合は、既存の認証方法でログインしてから連携するよう求めます。文字列の一致だけでは十分ではありません。また、これは Bridge の処理の説明であり、すべての連携プロトコルが同一の紐付け処理を使うという意味ではありません。
初回ログイン時の作成（JIT）
Section titled “初回ログイン時の作成（JIT）”一致するアカウントがない場合、JIT 設定に応じて最初の連携ログイン時にアカウントを作成できます。作成の許可、検証済みメールの要否、属性のマッピングはプロバイダーと JIT の設定で決まります。外部のクレームがそのままローカル権限になると考えず、ロール・グループのマッピングを明示的に設定してください。
認証の強さと属性の証明
Section titled “認証の強さと属性の証明”パスキー、メール検証、外部 SSO、本人確認書類は、それぞれ証明する内容が異なります。以前の説明にあった「Level 0〜4」は、Authrim 共通の保証レベルとして定義されたものではありません。パスキーは認証を保護しますが、それだけで法的な本人性を確認するわけではありません。必要な保証は、対象のフローとポリシーで評価します。
ar-vc には /vci/credential、/vp/authorize、/vp/response などの発行・提示経路と、属性検証の経路があります。それぞれ設定、信頼する発行者、受け付ける形式、検証ルールが必要です。すべてのウォレットやクレデンシャル形式・属性を、主たるログイン方法としてそのまま使えるという意味ではありません。
| モデル | 主に使う情報 |
|---|---|
| RBAC | ロールと割り当てられた権限 |
| ABAC | 主体・リソース・環境の属性 |
| ReBAC | 主体、組織、リソース間の関係 |
アプリは、設定したトークンのクレームや実行時のポリシー評価を使えます。トークンの情報は発行時点のもので、後から変わった権限が自動反映されるわけではありません。操作に応じてオンラインの判定やトークンの有効期間を選びます。すべてのポリシー結果が、すべての ID トークン・アクセストークンに含まれるとは限りません。
個人情報の境界
Section titled “個人情報の境界”Core はアカウントの状態と参照を、PII は機微な値や連携した識別子を保存します。Core に直接残る値は、フィールドの分類と呼び出し経路によります。Lookup はアカウントの実際の保存先を解決します。分離の範囲と削除処理は PII 分離で説明しています。