モダンな組織のアイデンティティアーキテクチャは均質ではありません。あるチームが中央ディレクトリを使用する一方で、別の事業部門は RADIUS ベースの古い検証システムを、外部ユーザーグループはソーシャルアイデンティティを、市民向けサービスを提供するアプリケーションは national eID を必要とすることがあります。フィンテック、ヘルスケア、公共プロジェクトではカスタム REST アイデンティティサービスもよく見られます。
従来のアクセスプラットフォームは、多くの場合この多様性を個別に扱います。各プロバイダーに異なる統合、異なる監査証跡、異なるエラー動作、異なる MFA フローが生じます。結果としてセキュリティポリシーは断片化します;オペレーターは同じユーザーを異なるシステムで異なる形で管理しなければなりません。
レガシーシステムは別の問題です。何年も稼働している RADIUS や web フォームベースの検証基盤を置き換えることは高価でリスクも伴います。しかしこれらのシステムの前面に MFA、条件付きアクセス、lockout、IP 制御、監査層を追加せずに、モダンな zero-trust レベルに到達することは不可能です。
カスタムアイデンティティ API も同じギャップを示します。組織が独自の顧客検証、OTP、またはモバイルアイデンティティシステムを HTTP エンドポイントとして提供しているなら、アクセスプラットフォームはそれをアイデンティティプロバイダーとして使用できなければなりません。さもなければ、各アプリケーションが独自の統合を書かなければなりません。
TR7 AAM は、異なるアイデンティティプロバイダーモデルを単一の authentication provider 層にまとめます;RADIUS、OAuth2、HTTP API、Web Form、LocalDB、Portal の各プロバイダーを同じアクセス、MFA、監査エンジンに接続します。
TR7 AAM は、異なるアイデンティティソースを単一プロバイダーモデルの下で動作させ、各検証結果を同じアクセス判断チェーンに運びます。
RADIUS、OAuth2、HTTP API、Web Form、LocalDB、Portal の各プロバイダーは同じプロバイダーオブジェクトとして定義されます。フローエンジンは各プロバイダーを成功、エラー、lockout、MFA の遷移とともに同じ形で処理します。
PAP と CHAP のサポートにより既存の RADIUS backend を AAM の背後に置けます。既存の検証システムは保たれます;その上に MFA、条件付きアクセス、lockout、監査が追加されます。
組み込みの OAuth2 プロバイダーとカスタム OAuth2 構成を AAM に接続できます。Google Workspace ドメイン制限や national eID のアイデンティティ属性マッピングのようなシナリオが単一のアクセスエンジンに組み込まれます。
組織独自の REST アイデンティティサービス、OTP システム、または顧客検証エンドポイントを AAM プロバイダーとして使用できます。method、header、body、成功条件を構成することで、追加開発の必要性が軽減されます。
追加アイデンティティプロバイダー統合は、レガシー検証システムからカスタム REST API まで、異なるアイデンティティソースを AAM の共通セキュリティモデルに運びます。
TR7 AAM は RADIUS 側で PAP と CHAP の検証タイプをサポートします。PAP はよりシンプルなレガシー互換を提供します;CHAP は challenge ベースの検証動作を提供します。既存の RADIUS 基盤を変更することなく AAM の前面に置けます。これは telco、NAC、古い VPN、エンタープライズアクセスシステムにとって実用的なモダナイズ経路です。
各 RADIUS backend に個別の共有シークレットキーを定義できます。これにより AAM と RADIUS サーバー間の検証関係がプロバイダー単位で分離されます。複数の RADIUS 環境で各統合が独自のセキュリティ境界を持ちます。運用上の変更は単一の中央構成で管理されます。
一つの provider 配下に複数の RADIUS サーバーを定義できます。プライマリサーバーが応答しない場合、セカンダリサーバーが起動できます。この構造は UDP ベースの RADIUS の性質に合った短い timeout と迅速な切り替え動作で動作します。レガシーアイデンティティシステムが高可用性モデルにより近づきます。
Google OAuth2 プロバイダーは特定の Workspace ドメインに限定できます。これにより組織所属のドメインユーザーのみがログインできるようになります。access type と prompt の動作は OAuth2 フローに応じて構成できます。外部ソーシャルアイデンティティがエンタープライズアクセスポリシーで制御されるようになります。
national eID OAuth2 プロバイダーは、公共アイデンティティのシナリオ向けに組み込みの属性マッピングで動作します。識別番号、姓、名、メール、電話、生年月日などの属性を AAM ユーザーオブジェクトに運べます。PKCE 対応フローが認証セキュリティを高めます。市民向けサービスを提供するアプリケーションで、市民アイデンティティが AAM アクセスチェーンに接続されます。
Custom OAuth2 モードでは authorization URL、token URL、userinfo URL、logout URL、revocation URL を個別に定義できます。Client ID、secret、scope、response type、grant type、PKCE の動作を構成できます。これにより標準 OAuth2 を話すカスタムエンタープライズアイデンティティシステムを AAM に組み込めます。統合は単一プロバイダーモデル内で管理されます。
一部の古いアプリケーションは標準プロトコルを提供せず、web ログインフォームしかありません。TR7 AAM は web form provider で login URL、フォームフィールド、成功条件を定義できます。成功は redirect、cookie、または status code の動作で判定できます。これにより古いアプリケーションのログイン画面を AAM 制御チェーンに取り込めます。
HTTP API provider は任意の REST エンドポイントを認証ソースに変換します。GET、POST、PUT の method;JSON、multipart、URL-encoded、raw body のタイプを使用できます。成功条件は status code、cookie の有無、redirect URL で評価できます。バンキング OTP、顧客認証、カスタムモバイル検証システムをこのモデルで接続できます。
LocalDB provider は AAM 内で管理されるローカルユーザーストアを使用します。インターネット接続のない環境、テストシステム、外部パートナーアカウント、または中央アイデンティティストアから独立したアクセスに適しています。パスワード履歴などの基本的なセキュリティ制御を適用できます。これは独立した self-hosted の利用シナリオを容易にします。
Portal provider は別の AAM portal gateway を認証ソースとして使用できます。この構造は複数ポータルや異なるアクセスゲート間の SSO ライクな移行シナリオをサポートします。ユーザーは単一の AAM チェーンで検証され、他のアクセスポイントに運べます。大規模なエンタープライズ展開でポータルアーキテクチャをシンプルにします。
各プロバイダーは異なる属性名を返すことがあります。TR7 userMapping で source attribute の値を AAM 標準属性にマッピングします。例えば識別番号、メール、グループ、電話、display name が共通ユーザーオブジェクトに運ばれます。MFA、条件付きアクセス、backend SSO 注入はこの標準オブジェクトの上で動作します。
各 authentication provider は独自の lockout 動作を継承、拡張、または override できます。これにより RADIUS、HTTP API、LocalDB などのプロバイダーが異なる失敗ログインしきい値を持てます。Brute force 保護は単一のグローバル設定に縛られません。アイデンティティプロバイダーのリスクプロファイルに応じてポリシーが定められます。
追加アイデンティティプロバイダーは、プロトコル動作、ネットワークアクセス、ユーザーマッピング、失敗ログイン管理、監査証跡とともに設計されなければなりません。
RADIUS は UDP ベースで動作します;クラシックな TCP 接続プールのロジックを持ちません。Timeout 値は短く、failover 動作は迅速に計画されなければなりません。複数の RADIUS サーバーを定義する場合、応答時間と順序を慎重に選ぶべきです。
OAuth2 フローにおいて state と PKCE は CSRF とリプレイのリスクを軽減します。公共またはモバイル中心のシナリオでは PKCE の動作が特に重要です。Provider 構成時には安全な前提を保つべきです。
HTTP API provider は status code だけを見る必要はありません。Cookie の有無や redirect URL などの追加成功条件を使用できます。これはカスタムアイデンティティサービスの異なる成功動作への適応を可能にします。
HTTP path、body、header、Web Form フィールドでユーザー入力や AAM 変数を使用できます。ユーザー名、OTP、その他の入力フィールドを動的にアイデンティティリクエストに追加できます。この動作は慎重なバリデーションとともに使用すべきです。
一部の provider タイプは外部アイデンティティプロバイダーにアクセスするため、正しいネットワークゾーンから出る必要があります。OAuth2、OIDC、Web Form プロバイダーは異なる route table を必要とすることがあります。プロバイダー単位のネットワーク選択は統合の成功にとって重要です。
各 provider の試行は成功、失敗、またはロックされた結果とともに監査ログに書き込まれるべきです。プロバイダータイプ、ユーザー、ソース IP、結果情報を SIEM にエクスポートできます。これは断片的なアイデンティティ基盤において統合された監査を提供します。
Telco または ISP 環境で稼働する古い RADIUS 検証システムが保たれます。TR7 AAM を前面に置くことで MFA、条件付きアクセス、中央監査が追加されます。
自治体または公共ポータルが市民ログインを national eID OAuth2 で行えます。アイデンティティ属性が AAM セッションに運ばれ、サービスアクセスが条件付きアクセスルールで管理されます。
異なる地域やチームが異なるアイデンティティシステムを使用することがあります。TR7 AAM はこれらのプロバイダーを単一の gateway と単一の監査モデルの下に統合します。
銀行の顧客検証または OTP サービスが REST API を提供しているなら、AAM はそれを HTTP provider として呼び出せます。成功は status code、cookie、または redirect 条件で検証されます。
中央エンタープライズディレクトリに登録しないパートナーアカウントを AAM LocalDB 上で管理できます。これらのアカウントには個別の MFA、lockout、アクセスポリシーが適用されます。
RADIUS、OAuth2、HTTP API、ローカルユーザーデータベースを同じ条件付きアクセス、MFA、監査のフローで動作させます。お客様の環境でのライブセットアップでご案内します。