UIAM統合アイデンティティ・認証基盤
人・サービスアカウント・AI エージェントのための統合アイデンティティ制御面。Kotlin、Spring Boot 4、Spring Security 7 で構築し、OAuth2 認可サーバーを内蔵。16 のデータドメイン、56 のテーブル、77 のコントローラがテナント分離からエージェントのツール認可までの全経路をカバーし、MySQL と PostgreSQL で同型に動作します。
アイデンティティカーネルはログインの殻ではありません。テナント絞り込みは jOOQ の VisitListener がクエリ層で強制し、エージェントの委任チェーンは RFC 8693 の Token Exchange を通り、ツール呼び出しはツール単位の認可を通過します。
各業務システムに散在するアカウント・権限・監査を、統治可能なひとつのアイデンティティカーネルに収束させます。
実際に何を解決するのか
4つの主要機能が、4つの実在する業務ニーズに対応します。
アイデンティティ情報と権益体系を統合し、プラットフォームごとに分断されたユーザーの孤島を繋ぎます。SMS 認証コード、ソーシャルログイン、招待登録、オープンプラットフォーム認可を、ひとつのユーザーライフサイクルサービスにまとめました。
企業内のアイデンティティ中核です。組織・役職・権限を一元管理し、社内 SSO を提供、入社・異動・退職までのライフサイクルを自動化します。
ひとつのプラットフォームで社内社員と外部ユーザーの両方を収容し、内と外でアイデンティティの統治ドメインを分けながら、統一ポリシーエンジンとセキュリティ基準を共有します。
自律的に動く AI エージェントにアイデンティティ・資格情報・スコープ・呼び出しクォータを発行します。すべての行為は追跡可能で、即時失効できます。
能力一覧
- OAuth 2.1 / OIDC 認可サーバー内蔵：認可コード、クライアントクレデンシャル、リフレッシュトークン、Token Exchange に対応
- マルチテナント + マルチスペース（tenant / space）の強い分離。JWT の tenant_id が唯一の信頼源
- きめ細かな RBAC：機能権限とデータ権限の二本立てで、権限変更は即時反映
- WebAuthn / パスキー、マジックリンク、TOTP MFA、デバイス管理、IP ルール、NG ワードポリシー
- Agent IAM の4本柱：マシン主体 → 委任チェーン → マルチホップ伝播 → MCP ツール認可
- コネクタエコシステム：WeCom、WeChat オープンプラットフォーム、ミニプログラム、GitHub、Google を標準対応
スライドの中にある製品ではない
以下の数字は uiam-coplit リポジトリの実際のコードから読み出したものです。モジュール、テーブル、エンドポイント、機能項目。
技術スタック
機能一覧
6 の業務ドメイン、43 項目の具体的な機能。どれもコード上に実在する実装に対応します。
マルチテナントとスペース分離
uiam-core · 01-tenant · 02-spaceテナント境界はセキュリティ境界です。フィルタはクエリ層で強制され、WHERE の書き忘れに頼りません。
- テナント管理：テナント CRUD、テナント設定、テナントクォータ、テナントオプション、テナントディスカバリー
- スペース管理：テナント配下の複数スペース、スペースメンバー、スペースセキュリティ設定、公開スペース
- TenantScopedTables レジストリが 45 のテーブルをテナントスコープ対象として一元的に宣言
- TenantScopeVisitListener が jOOQ クエリ層でテナント述語の欠落を検出。DETECT_LOG / DETECT_THROW を切り替え可能
- JWT の tenant_id が唯一の信頼源。ヘッダー宣言と一致しない場合は TenantMismatchException (403) を即座に返す
- UserContext の ThreadLocal はリクエストごとにクリアし、リクエスト間の漏洩を防ぐ
- runAsSystem / runWithoutTenantFilter は明示的なバイパス経路で、バイパス行為自体も監査に記録
認証と資格情報
uiam-authn · uiam-protocolパスワードからパスキー、パスワードレスまで、複数の強度の資格情報が一条の経路に共存します。
- ユーザー名・パスワードログイン：パスワードポリシー、パスワード履歴、アカウントロック、パスワードリセット
- OAuth 2.1 の全グラント種別：認可コード、クライアントクレデンシャル、リフレッシュトークン、トークン失効
- OIDC 標準エンドポイント：Discovery、JWKS、認可、同意画面、トークン、イントロスペクション
- WebAuthn / パスキーによるパスワードレス認証。デバイス管理とデバイスポリシーと連携
- マジックリンクによるメールパスワードレスログイン。認証コードとボット判定つき
- TOTP MFA の登録・検証・バックアップコード。MFA enrollment フローは外部システムと接続可能
- アプリケーションキーと JWT の受け渡し。サーバー間呼び出しに利用
- 個人 API キーとユーザーレベル API キーの管理。introspect による検証に対応
認可と権限
uiam-authz · 07-authzRBAC を土台に、データ権限が補完し、Token Exchange が権限を絞り込みます。
- ロール管理と権限管理。ロール-権限、ユーザー-ロールの関連を管理
- データ権限：Sys データ権限サービスがスコープに応じて可視データを計算
- テナントレベルとスペースレベルの権限を階層化。ユーザーリソースとユーザー権限ビュー
- Token Exchange（RFC 8693）：impersonation と delegation の両モード
- 委任時は「アプリ権限 ∩ ユーザー権限」の積集合を取り、maxPermissionLevel で上限を絞り込み
- act claim が「誰が誰の代理か」を表現し、マルチホップの入れ子委任チェーンに対応
- メニューとアプリグループ：アプリグループ、ユーザーアプリ、アプリ-スペースバインディング
Agent アイデンティティとツール認可
uiam-agent · 16-agentAI エージェントは一等の主体であり、人間のトークンを盗んで動く存在ではありません。
- MACHINE subject_type：サービスアカウントと Agent は USER になりすまらず、トークンは principal_type=machine を持つ
- マシン主体には直接ロールを割り当て可能。assignToMachine / batchAssignToMachines で一括付与
- MCP Server エンドポイント：Agent は標準 MCP プロトコルで接続し、資格情報とスコープは UIAM が発行
- agent_tools ツールレジストリ。ツール呼び出し前に呼び出し元のツール権限を検証
- @RequiresToolPermission アノテーションがツール単位の認可をコードに書き込む。ドキュメントには書かない
- Agent の呼び出しクォータとレート制限。超過時は即座に失敗
- 全経路監査：誰が誰に委任し、どのツールを呼び、どの権限を使ったかを完全に再生可能
アイデンティティソースとソーシャル接続
uiam-connector · 10-connector国内 IM エコシステムも国際的なソーシャルアカウントも、同じコネクタ抽象で扱います。
- WeCom コネクタ：QR コードログインとアドレス帳アイデンティティソース
- WeChat オープンプラットフォームコネクタ：WeChat ログインとユーザー情報取得
- WeChat ミニプログラムコネクタ：ミニプログラムのログイン状態を統合アイデンティティに交換
- GitHub / Google の OAuth2 ソーシャルログイン
- コネクタ統合管理画面：設定、有効化 / 無効化、コールバック統治
- アイデンティティソース抽象。外部アイデンティティをローカルアイデンティティとタグにマッピング
監査・統治・運用
uiam-audit · uiam-serverすべての行為が記録に残り、運用画面はそのままプラットフォーム運営に使えます。
- 監査ログ：構造化されたイベント記録。主体・テナント・時間での検索に対応
- セキュリティアラート：異常ログインやテナント越権などのリスクイベントを SECURITY / FAILURE として区分記録
- システムログとログイン履歴。ユーザー自身が自分のログイン履歴を確認できます
- システム初期化とシステム設定：初回インストールガイドとランタイムスイッチ
- 通知テンプレートと Webhook：イベント駆動の外部配信
- 辞書・メニュー・お知らせ：バックオフィス運用に必要なメタデータ管理
- クォータと使用量：テナントクォータ、ユーザークォータ、利用統計
- NG ワードと IP ルール：コンテンツコンプライアンスとアクセス元の制御
API コントラクト
12 の代表的エンドポイント。ここに列挙するのは公開契約の骨格であり、完全な定義は導入時に提供します。
/oauth2/tokenトークンエンドポイント：認可コード、クライアントクレデンシャル、リフレッシュトークン、Token Exchange が共用
/oauth2/authorize認可エンドポイント：ログイン、MFA 二次検証、認可同意を担う
/.well-known/openid-configurationOIDC Discovery：クライアントがエンドポイントと能力を自動発見
/oauth2/jwks公開鍵セット：業務側でローカル検証。オリジンへの往復は不要
/oauth2/introspectトークンイントロスペクション：オフライン検証できない場面で使用
/oauth2/revokeトークン失効：ログアウト、リスク管理、資格情報ローテーションで発火
/api/v1/authn/passkey/registerWebAuthn / パスキーの登録と資格情報の紐付け
/api/v1/authz/token-exchangeRFC 8693 の委任と代理（impersonation）。権限は積集合で絞り込み
/api/v1/agents/{id}/tools/{tool}/invokeAgent ツール呼び出しの入口。@RequiresToolPermission で検証
/api/v1/tenants/{code}/spacesテナント配下のスペース一覧。クエリは自動でテナント述語を伴う
/api/v1/audit/events監査イベントの検索：主体・テナント・時間の軸で
/api/v1/connectors/{kind}/callbackアイデンティティソースコネクタのコールバック統一入口
実際の呼び出し
エンドポイントがどのようなものかは、一覧よりも雄弁です。
01$ curl -X POST https://id.zhenbei.tech/oauth2/token \02 -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \03 -d subject_token=$USER_TOKEN \04 -d actor_token=$AGENT_TOKEN \05 -d audience=uniscrm-api0607{ "access_token": "eyJhbGciOiJSUzI1NiIs...",08 "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",09 "expires_in": 900,10 "act": { "sub": "agent:sales-copilot", "principal_type": "machine" } }契約の規律
インターフェースは約束であり、実装詳細の晒しではありません。この3つの規則を守り続けています。
破壊的変更はメジャーバージョンで行い、1リリース前に告知します。公開済みのエンドポイントが内部リファクタリングで意味を変えることはありません。
エラーコードは曖昧な 500 ではなく意味を持たせ、呼び出し側（AI Agent を含む）がリトライか断念かを判断できます。
人間向けのテキストではなく、既定で構造化データを返します。AI が直接読め、人がスクリーンショットで中継する必要はありません。
モジュール
5 グループ・14 のコードモジュール。すべて uiam-coplit リポジトリの実際のディレクトリ構造に基づきます。
uiam-server-kotlin/主体のモデリング、組織構造、ユーザーライフサイクル。
uiam-core共通カーネル：テナントコンテキスト、リクエストコンテキスト、テナントスコープテーブルの登録とクエリヘルパー
uiam-core/{api,biz}uiam-dept組織と部署：ツリー組織、役職アカウント、所属関係、社員と組織の関連
uiam-dept/{api,biz}03-identity / 04-organizationアイデンティティと組織のデータドメイン：ユーザープロフィール、アイデンティティタグ、外部メンバー、組織関係
db/changelog/migrations/「誰がアクセスしているか」を証明する部分のすべて。
uiam-authn認証：パスワードログイン、認証コード、マジックリンク、パスキー、セッションとログイン履歴
uiam-authn/{api,biz}uiam-protocol-oidcOIDC プロトコル：Discovery、JWKS、認可エンドポイント、同意画面、トークン発行と失効
uiam-protocol/uiam-protocol-oidcuiam-protocol-coreプロトコルカーネル：クライアント登録、認可同意、スコープとトークンモデル
uiam-protocol/uiam-protocol-coreuiam-connector-*アイデンティティソースコネクタ：wecom / weoa / weopen / weapp / github / google
uiam-connector/「何ができるか」と「どんな条件では許されないか」を決める部分。
uiam-authz認可：ロール、権限、データ権限、Token Exchange、権限積集合による絞り込み
uiam-authz/{api,biz}uiam-audit監査：構造化イベントストリーム、システムログ、セキュリティアラート、コンプライアンス保持
uiam-audit/{api,biz}13-security-ext / 14-sensitive / 15-ip-ruleセキュリティ拡張：パスワード履歴、NG ワード、IP ルール、デバイスポリシー、クォータ
db/changelog/migrations/IAM の境界を「人」から「AI エージェント」へ拡張します。
uiam-agentAgent プリンシパル、MCP エンドポイント、agent_tools レジストリと ToolExecutionService
uiam-agent/{api,biz}16-agentAgent データドメイン：マシン主体、委任チェーン、ツール認可関連のテーブル
db/changelog/migrations/16-agent/マルチテナント SaaS の運用面。
uiam-serverアセンブリ層：テナントとスペースの統治、システム初期化、システム設定、辞書、メニュー、お知らせ、Webhook
uiam-server/uiam-jooqコード生成：Liquibase changelog から Tables / Record 型を生成
uiam-jooq/レイヤー設計
アクセスからランタイムまで、各層の責務と実装技術。
OAuth 2.1 / OIDC / Token Exchange (RFC 8693) / JWKS / Discovery / WebAuthn
ユーザー・組織・サービスアカウント・Agent の 4 種類の主体を統合モデリングし、subject_type で USER / MACHINE を区別
RBAC + データ権限。権限はテナント / スペースの二重で分離され、Token Exchange は積集合で絞り込みます
jOOQ の TenantScopeVisitListener がクエリレベルでテナント述語を強制し、45 のテナントテーブルを一元登録
MFA、パスキー、デバイスポリシー、IP ルール、パスワード履歴、リスクアラート、システム JWT 鍵のローテーション
構造化された監査イベントストリーム。テナント違反は SECURITY / FAILURE レベルで記録
Kotlin 2.2 · Spring Boot 4 · Spring Security 7 · jOOQ · Liquibase · 仮想スレッド
主要フロー
最も重要ないくつかの経路を、ステップごとに分解して見ていきます。
標準的な OIDC 認可コードログイン
業務システムはユーザーを UIAM に預け、ユーザーテーブルのコピーではなく検証可能なトークンを受け取ります。
- 1
業務アプリが client_id・scope・redirect_uri を付けて /oauth2/authorize へリダイレクト
- 2
UIAM が現在のセッションを判定。未ログインならログイン画面を表示（パスワード / 認証コード / パスキー / ソーシャル）
- 3
MFA やデバイスポリシーに該当する場合は二次検証を挿入し、通過して初めて認証完了
- 4
認可同意画面に戻り、ユーザーが認可スコープを確認
- 5
認可コードを発行 → access_token / refresh_token / id_token と交換
- 6
業務側は JWKS でトークンをローカル検証。P99 以内に完了し、オリジンへの往復は不要
Agent 委任チェーン（Token Exchange）
Agent がユーザーの代理で働くとき、トークンには「誰が誰の代理か」を書き込み、権限は和集合ではなく積集合を取ります。
- 1
Agent は自身の MACHINE アイデンティティで主体トークンを取得。principal_type=machine
- 2
ユーザートークンを添えて urn:ietf:params:oauth:grant-type:token-exchange リクエストを送信
- 3
TokenExchangeServiceImpl が「アプリ権限 ∩ ユーザー権限」を計算し、maxPermissionLevel で絞り込む
- 4
新しいトークンには act claim を書き込み、委任者を記録。マルチホップでは act が入れ子になる
- 5
Agent は新しいトークンで業務 API を呼び出し。リソース側は permissions claim で実際の認可を行う
- 6
チェーン全体を監査に記録。委任関係、ツール、権限のスナップショットを含む
テナント分離の強制検証
テナント境界はレビューではなく、クエリ層のリスナーが守ります。
- 1
リクエストが到着すると TenantContextFilter が JWT から tenant_id を解析してコンテキストに書き込む
- 2
ヘッダーで宣言されたテナントが JWT と一致しない場合、TenantMismatchException (403) を即座に投げる
- 3
jOOQ 実行時、TenantScopeVisitListener が SQL がテナントスコープテーブルに触れるか検査
- 4
テナント述語の欠けたクエリは、設定に応じてセキュリティログに記録するか即座にエラー
- 5
本当にテナントをまたぐシステム操作は runAsSystem の明示バイパスを使い、監査を残す
- 6
リクエスト終了時に UserContext をクリアし、スレッドプール再利用による漏洩を防ぐ
技術スタック
性能と規模
これらの数字は推定ではなく、コードと実行構成から読み出したものです。宣伝文句と誤解されないよう、各項目に実際の意味を注記しています。
uiam-coplitJWKS でローカル検証。業務サービスはアイデンティティセンターへの往復が不要
一元登録 + クエリ層リスナー。述語の欠落は設定で即エラーにできる
MySQL 8 と PostgreSQL が同一コード。マイグレーションは方言ごとに管理
Liquibase でバージョン管理。再実行でも結果は同一、失敗時はロールバック可能
act claim の入れ子でマルチホップ委任を表現。権限はホップごとに和集合ではなく積集合
WeCom / WeChat オープンプラットフォーム / ミニプログラム / WeCom OA / GitHub / Google
リポジトリで数えられる事実
以下の各項目は uiam-coplit で照合できます。モジュール、テーブル、エンドポイント、機能項目。「完了したか」の判断は、これらの数字が動いたかどうかで行います。
セキュリティとコンプライアンスの実装ポイント
UIAM がセキュリティとして具体的に何をし、境界をどこに引いたか。各項目に実装箇所を明記し、検証できるようにしています。
ヘッダーで宣言されたテナントが JWT と一致しなければ即 403。テナント横断の操作は明示的なバイパス経路を使う必要があり、バイパス自体も監査に入ります。
TenantMismatchException · runAsSystemパスワードポリシー、パスワード履歴、アカウントロック、TOTP MFA、パスキー、マジックリンクをテナントと場面ごとに組み合わせられます。
uiam-authn · 13-security-extデバイス管理、デバイスポリシー、IP ルール、NG ワードポリシーが、ログインとコンテンツの二層防御を構成します。
15-ip-rule · 14-sensitiveシステム JWT 署名鍵はローテーション可能。旧トークンは有効期限内は検証でき、ローテーションは無停止です。
uiam-protocol-core監査イベントは主体・テナント・時間で構造化保存され、セキュリティイベントはレベルを分けて記録。コンプライアンスの証拠取得に応えます。
uiam-auditAgent の資格情報は人間と独立。ツール呼び出しは毎回権限とクォータを検証し、全認可を即時失効できます。
uiam-agent · agent_toolsデータがどこで止まるか
データ境界は製品の形で決まり、気軽に切り替えられるスイッチではありません。これは4つの事業ラインに共通する判断です。
端末製品の最小境界です。この層のデータは設計上、アップロード経路を持ちません。スイッチで切っているわけではありません。
- legdger のすべての記帳データ：端末内で暗号化保存し、クラウドには暗号文のみ
- legdger の端末内 AI 集計と Q&A：推論はデバイス内で完結
- NewTool のデスクトップと wasm 形態：アルゴリズムカーネルに IO がなく、データはプロセスから出ない
- pxc のキャプチャトラフィック：カーネルは端末上で動作し、第三者サービスを経由しない
プライベート導入の境界です。モデル、ベクトル、業務データ、監査記録のすべてが顧客自身のネットワーク内に配備されます。
- Uniclaw の記憶と知識ベクトル：Milvus を自社構築し、社内網から出ない
- Uniclaw のモデルサービス：プライベート配備の互換プロトコルサービスに接続可能
- UIAM のアイデンティティと監査データ：全体が顧客のネットワーク境界内に配備され、完全なオフライン稼働も可能
- Uniscrm の素材とメディア：オブジェクトストレージは顧客自身の OSS に接続可能
- Unilearning の教材と学習記録：単一コンテナで提供し、データは顧客が掌握
外部ネットワークを必要とするのは同期と外部チャネルのみで、流れる内容は暗号文か、すでに匿名化されたメッセージです。
- legdger のデバイス間同期：最新の暗号文のみを送信し、サーバーは履歴を蓄積しない
- Uniscrm の WeCom チャネル：WeCom 公式インターフェースと通信し、公式のアーカイブ機能を利用
- Uniclaw のチャネル：Feishu / DingTalk の push API。内容はテナント単位で分離
- NewTool のリモート呼び出し：MCP 経由で伝送し、アルゴリズムカーネル自体はネットワーク要求を発行しない
会社レベルのセキュリティ原則
どの事業ラインにおいても、この6つは共通の譲れない一線です。
コンパイラ、フレームワーク、クエリ層に埋め込める制約は、ドキュメントに書いて人に覚えさせません。テナント分離はクエリ層のリスナーが強制し、ドメイン境界は Go の internal 機構がコンパイル時に拒否します。
jOOQ TenantScopeVisitListener · Go internal 墙機密データは既定でユーザーの端末、または顧客ネットワーク内に留まります。4 つの事業ラインすべてがプライベート導入に対応し、端末製品 legdger は AI 分析すらデバイスから出しません。
legdger 端侧 AI · Uniclaw 自建 Milvus · Unilearning 单容器エージェントが人間の資格情報を共有することはなく、サーバーは長期鍵をハードコードせず、端末からの接続は失効可能なトークンを使います。どの資格情報も、他の主体に影響を与えず単独で失効できます。
UIAM MACHINE 主体 · OSS STS AssumeRole · ledger-cli 令牌認証、認可、ツール呼び出し、キャプチャデバッグのすべてが構造化記録を生みます。コンプライアンスのためではなく、事故のときに再生できるようにするためです。
uiam-audit · collaboration-logger · pxc 会话记录委任関係は act claim で「誰が誰を代表するか」を表現し、権限はホップごとに積集合を取ります。監査では、どのユーザーがどのエージェントを認可し、どのツールを呼び、どの権限を使ったかまで答えられます。
RFC 8693 Token Exchange · agent_tools 注册表データベースの変更はバージョン管理されたマイグレーションで行い、再実行しても結果は同一です。アプリのリリースは単一イメージの差し替えで、ロールバックは前のイメージに戻すだけです。
Liquibase · 各域方言迁移 · Docker 单镜像デプロイと連携
すべてのプロダクトラインがプライベート導入に対応します。具体的な形態は製品ごとに異なります。
既定の提供形態：アイデンティティカーネル全体を顧客自身のネットワーク境界内に配備します。
- Spring Boot サービス 1 セット + MySQL / PostgreSQL + Redis
- Liquibase によるバージョン管理マイグレーション。冪等なアップグレードとロールバック
- 外部 SaaS 依存なし、完全なオフライン稼働が可能
同一コードが MySQL と PostgreSQL の両方で動作し、方言差は jOOQ とマイグレーションファイルが吸収します。
- application-mysql.yml / application-pg.yml の 2 プロファイル
- マイグレーションは方言ごとにディレクトリを分け、リリース後の履歴改変はしない
- jOOQ コード生成が changelog から型安全なデータアクセス層を直接生成
業務システムは自前のユーザー体系を変える必要がなく、UIAM が発行したトークンを信頼するだけです。
- OIDC / OAuth2.1：標準クライアントライブラリで直接接続
- JWKS でトークンをローカル検証。都度のオリジン往復は不要
- API Key / Application Key：サーバー間呼び出し向け
- MCP：AI エージェント向け
API ゲートウェイと組み合わせ、認証をトラフィックの入口へ前倒しできます。
- Higress 統合レシピ（docs/integration/higress）
- トークン検証はゲートウェイ層で完了し、業務サービスは認可後のアイデンティティのみ扱う
- Uniclaw・Unilearning の各製品ラインと接続済み
比較
同じことを、異なるやり方で。左欄が私たちの選択、右欄は一般的な代替案です。違いは通常機能表ではなく、境界をどこに引くかにあります。
誰が変化を感じるか
機能一覧では人は動きません。ロール視点が動かします。以下は、4種類のロールが接続前後で感じた実際の違いです。
業務システムごとにアカウント体系を維持し、権限の基準が揃わない。新システムを接続するたびにログインの調整がやり直しになる
標準 OIDC で一度の接続で済みます。トークンと権限モデルは全体で統一され、新システムはクライアントを 1 つ登録するだけ
「誰が、いつ、どんなアイデンティティで、何にアクセスしたか」に答えられない。越権は事後発見しかない
構造化監査イベントストリームは SIEM に接続でき、テナント越権は SECURITY / FAILURE レベルで直接記録
ログインロジックが各サービスで重複実装され、パスワードポリシーの 1 回の変更に N リポジトリを触る
認証と認可はアイデンティティカーネルに収束。業務サービスはトークンの claims を読むだけ
退職後の権限残留。回収はシステムごとの手作業で、必ず取りこぼしが出る
退職で全権限回収が発火し、リアルタイムで反映。システムごとの操作は不要
バージョンとロードマップ
リリース済みは何を納品したか、開発中は何を進めているか、計画中は何をする予定かを明記します。リリース済みの項目が覆ることはありません。
v1.0リリース済み基本カーネル- アイデンティティカーネルとマルチテナント分離
- OAuth 2.1 / OIDC 認可サーバー
- RBAC によるロールと権限管理
- MySQL / PostgreSQL 双方言
v1.2リリース済みAgent IAM- MACHINE 主体のモデリングとサービスアカウント
- RFC 8693 の委任チェーンとマルチホップ伝播
- MCP エンドポイントとツール単位の認可
- Agent 呼び出しクォータとレート制限
v1.4開発中統治強化- 権限変更のリアルタイム配信（次のログインを待たない）
- 監査イベントストリームの SIEM 接続
- システム JWT 鍵の無停止ローテーション
- ポリシーエンジンのプログラマブル化
v2.0計画中フェデレーションとポリシー- テナント横断のフェデレーテッドアイデンティティ
- ABAC ポリシー言語
- アイデンティティデータの越境コンプライアンスポリシー
- サードパーティアプリマーケット
連携と接続対象
UIAM がどの相手と、どの方式で接続するか。
QR コードログインとアドレス帳同期。組織構造がそのままアイデンティティソースになる
WeChat ログインとユーザー情報取得。To C 会員体系を支える
ミニプログラムのログイン状態を統合アイデンティティに交換。マルチ端末の会員を一元化
国際的なソーシャルアカウントの OAuth2 ログイン。社内ツールと外部協業に利用
認証をトラフィックの入口へ前倒し。ゲートウェイ層でトークン検証を完了し、認証済みのアイデンティティを後段へ渡す
3 つの業務ラインが同じアイデンティティカーネルを共有。Agent の資格情報とツール認可は UIAM が発行
導入シーン
これらが実際の業務でどう使われるのか。
ひとつのグループ傘下の複数子会社・複数システムが、同じアイデンティティカーネルを共有しながらデータは相互不可視です。
- 子会社はテナントで、業務システムはスペースで分離
- 社員は一度のログインで全社内システムへ
- 退職時に全権限を即時回収。リアルタイムで反映
複数のアプリ・ミニプログラム・Web が、ひとつの会員アイデンティティとログイン方式を共有します。
- SMS 認証コード + WeChat + ソーシャルログインをひとつに収束
- 会員タグとアイデンティティタグを一元管理
- オープンプラットフォームでサードパーティアプリに認可
Agent は注文を読み、メッセージを送る。ただし開発者の資格情報で好き勝手はさせません。
- Agent は自身の MACHINE アイデンティティと失効可能な資格情報を持つ
- 委任チェーンで「どのユーザーがどのエージェントを認可したか」を追跡
- ツール単位の認可で、Agent が呼べるインターフェースを決める
金融・官公庁では、誰の・どのアクセスも説明できなければなりません。
- 構造化監査イベントストリームは SIEM に接続可能
- NG ワード・IP ルール・デバイスポリシーの多層防御
- システム JWT 鍵は停止なしでローテーション可能
よくある質問
必要です。LDAP はディレクトリ保存を担い、UIAM は現代的なプロトコル（OIDC / OAuth2.1）での統合認証・きめ細かな認可・マルチテナント分離・Agent アイデンティティを担います。外部アイデンティティソースの上位制御面にもなれます。
アイデンティティ・エージェント・プライベートドメインの複雑さを、統治可能なひとつのカーネルへ
既存の IAM の置き換え、エージェント基盤の構築、あるいはプライベートドメイン運用の本格化——まずは 30 分のアーキテクチャ相談から始めましょう。私たちが得意とする種類の問題かを先に判断し、適さない場合は率直にお伝えします。