モダンなアプリケーションでOIDCの利用が増えているとはいえ、SAML 2.0はエンタープライズおよび公共部門のアイデンティティ統合において依然として重要な標準です。多くの組織は、AD FS、Entra ID、Okta、Ping、Auth0、またはフェデレーションゲートウェイの背後にある既存のディレクトリをSAML経由で運用しています。公共部門側でも、国家アイデンティティフェデレーションとそれに接続するSaaSサービスはしばしばSAML 2.0の上に構築されています。
そのため、新規または近代化されたアプリケーションにとって正しいアプローチは、別個のユーザーデータベースを作ることではありません。アプリケーションは、組織がすでに信頼しているアイデンティティプロバイダーに接続すべきです。そのためには、アクセスレイヤーがSAML 2.0サービスプロバイダーとして振る舞う必要があります：ユーザーを正しいIdPへリダイレクトし、受信したSAML応答を検証し、アイデンティティを安全に抽出し、アプリケーションが利用できるセッションに変換しなければなりません。
しかしSAML統合は単に「XMLを受け取り、ユーザーを読み、サインインさせる」作業ではありません。誤って実装すると深刻なセキュリティの穴を生みます。SAML応答内の署名を正しく検証すること、どの要素が実際に署名されているかを確認すること、署名除去や偽アサーション挿入のような攻撃を防ぐことが必要です。有効期間、audience制約、issuer情報、NameID形式、属性マッピングは単に読まれるだけでなく、厳格に適用されなければなりません。
運用面も同様に重要です。IdPメタデータの更新、証明書および署名キーのローテーション、テナントごとに異なるIdPルーティング、異なるアプリケーション向けの異なるマッピングルール、Single Logoutフローは、後から付け足す細部ではありません。これらはSAMLフェデレーションが安全かつ持続可能に機能するための基本部品です。
最も一般的な誤りの一つは、各アプリケーションに個別のSAMLライブラリを埋め込むことです。このアプローチはアイデンティティの責任を各バックエンドに分散させます。単一のIdP変更が多数のアプリケーションで個別の更新を必要とします。MFA、条件付きアクセス、デバイストラスト、ログアウト挙動、監査記録がアプリケーションごとに再び解決されようとします。結果は中央集権的なアイデンティティではなく、分散したアイデンティティの混乱です。
正しい場所はアクセスエッジです。SAMLは単一ポイントで終端され、認証、MFA、条件付きアクセス、デバイストラスト、Backend SSOと同じレイヤーで管理されるべきです。これによりアプリケーションはフェデレーションプロトコルの複雑さを抱えず、検証済みでクリーンかつ信頼できるアイデンティティのみを受け取ります。
SAMLを正しく管理するとは、単にIdPに接続することではありません。組織のアイデンティティ信頼を単一ポイントで検証し、監査し、アプリケーションへ安全に運ぶことです。
単一のAAMゲートウェイがエッジでSAMLを正しく終端します；アクセスエンジンの残りはその上に重なります。
送信時の署名付きAuthnRequest、受信時の完全なアサーション検証 — 署名、audience、有効期間、AudienceRestriction、NameID形式。HTTP-RedirectとHTTP-POSTの両バインディングがサポートされます。署名処理は、既知のSAML攻撃を阻止するために存在するSAML 2.0適合ルールに従います。
単一のAAMゲートウェイは、異なるアプリケーションを異なるIdPへ、また同一アプリケーションの異なるテナントを異なるIdPへ、同時にルーティングできます。IdPの選択は、アプリケーションのコンテキストからリクエストごとに行われます — IdPごとの別ゲートウェイなし、ユーザー向けの手動ログインページセレクターなし。
IdPごとのマッピングルールが、SAMLアサーションのNameIDと属性ステートメントを、AAMの残りが使う正規のフィールド — ユーザー名、メール、グループ、表示名、カスタム属性 — に変換します。同じマッピングがMFAゲーティング、条件付きアクセスの式、監査ログ、Backend SSO注入を供給します。
SAML認証は単独では機能しません — エッジのMFA（IdPがステップアップを適用しなかった場合）、条件付きアクセスの式、継続的トラスト評価、バックエンドへのBackend SSO注入とともに組み立てられます。SAMLアサーションはAAMセッションへの一入力となります；セッション全体にはなりません。
標準準拠のSAML 2.0 SP、加えてフェデレーションを大規模に安全かつ管理可能にする運用機能。
ユーザーがアプリケーションに到来し、AAMが署名付きSAML AuthnRequestとともに構成済みのIdPへリダイレクトし、ユーザーはIdPでサインインし、IdPは署名付きアサーションをAAMのAssertion Consumer Serviceエンドポイントへ返します。送信リクエストにはHTTP-Redirect、受信アサーションにはHTTP-POSTの両バインディングがサポートされます。
ユーザーの起点がIdPであるデプロイメント向け — IdP上のポータルのランチパッド、アプリケーションカタログ、公共部門アイデンティティポータル — IdP-Initiated SSOが受け入れられます。RelayStateは目的のアプリケーション到達先を運びます；これにより、アサーション消費後にユーザーは正しいページで開きます。
アサーションの署名は構成済みのIdP署名証明書に対して検証されます；audienceは構成済みのAAM SP識別子と一致します；NotBeforeとNotOnOrAfterが有効期間を定めます；AudienceRestrictionが適用されます。既知のSAML攻撃（signature wrapping、signature stripping、NotBefore drift）は黙って許容されるのではなく、明示的に阻止されます。
IdPがアサーションを暗号化する場合（xmlenc）、AAMは検証の前に構成済みのSP秘密鍵でアサーションを復号します。暗号化アサーションは、国家アイデンティティフェデレーション向けや、アサーション内容をバインディングレイヤーで可読にしたくないIdP向けに一般的です。暗号化キーは構成ストアに暗号化して保存され、決してログに出力されません。
各IdPは、優先するNameID形式（persistent、transient、email-address、unspecified）と、SAML属性名からAAMセッションフィールドへのマッピングとともに構成できます。異なるIdPはアイデンティティを異なる形で提示しえます — 国民ID番号、メール、一意の不透明な識別子 — それでも同じ正規のAAMセッション形式を生成できます。
多数のテナントを前面で受け持つ単一のAAMゲートウェイは、各テナントを自身のIdPへルーティングできます。選択はリクエスト時にアプリケーションまたはテナントのコンテキストから行われます — IdPごとの別ゲートウェイなし、ユーザーごとのセレクターなし。同じゲートウェイが、あるテナントには国家アイデンティティフェデレーションを、別のテナントにはカスタムのエンタープライズIdPを、同時に運べます。
IdPがログアウトを開始すると、AAMはSAML LogoutRequestを受け入れ、AAMセッションを終了し、Backend SSO注入を受けるバックエンドにシグナルを送ります。アプリケーションがログアウトを開始すると、AAMはIdPへ署名付きLogoutRequestを送り、セッション終了を宣言する前にLogoutResponseを待ちます。フロントチャネルSLOがサポートされます。
バックチャネルSOAPベースのSingle Logout、非ブラウザクライアント向けのSAML ECP（Enhanced Client/Proxy）プロファイル、高セキュリティ統合向けのholder-of-key subject confirmationがロードマップにあります。構成オブジェクトとSPパイプラインの残りはすでにこれらに対応しています；欠けているのはプロトコル固有のコードです。
SAMLフェデレーションを安全、最新、観測可能に保つメカニクス。
IdPメタデータは、IdPが提供するメタデータXMLをアップロードすることで、AAMが取得しキャッシュするメタデータURLを構成することで、またはエンドポイントと証明書を手動入力することで読み込めます。手動構成は、標準準拠のメタデータを公開しないIdP向けの現実的な選択肢です；機能する場合は他の2つの方式が優先されます。
AAMは自身のSPメタデータドキュメントを安定したURLで公開します；これにより、IdPオペレーターはエンドポイントと証明書を手動で移すのではなく、それをIdPのトラストストアに取り込めます。メタデータは稼働中のSP構成を反映します — 現在のACS URL、現在の署名証明書、現在のSLOエンドポイント。
SP署名キーと証明書には寿命があります。AAMはオーバーラップによるキーローテーションをサポートします — ロールオーバーウィンドウの間、新旧両方のキーがIdPのキャッシュ済みメタデータに対して検証されます。オペレーターはローテーションを事前に計画します；ランタイムはオーバーラップ期間中に両方を受け入れ、ローテーションはクリーンに切り替わります。
アサーションはNotBeforeとNotOnOrAfterのタイムスタンプを持ちます。実際のクロックはずれます；AAMは構成可能な許容ウィンドウを適用します；これにより小さなずれが有効なアサーションを拒否せず、大きなずれ（設定ミスやリプレイの兆候）は引き続き拒否されます。許容はIdPごとです；よく同期されたIdPは狭いウィンドウを、問題のあるIdPは文書化された猶予を得ます。
各SAMLイベント — 送信AuthnRequest、受信アサーション、署名検証の結果、SLO LogoutRequest、LogoutResponse — が、AAMセッション、その背後のバックエンド、ユーザーアイデンティティに紐づく相関IDとともに記録されます。「誰がどのIdP経由でいつサインインしたか」は単一のクエリで答えられます。
構成済みURLからのIdPメタデータの定期的な自動更新、差分検出、署名証明書変更時のオペレーターへのアラートがロードマップにあります。ローテーションテレメトリー — キー経過メトリクス、有効期限までの残日数アラート、自動ロールオーバーのスケジューリング — も計画されています。
国家アイデンティティフェデレーションIdPを受け入れる必要があるアプリケーション — 公共部門デプロイメント、規制対象セクター、公共部門の調達者へ契約されたSaaSサービスに典型的です。AAMはSAMLフェデレーションをエッジで終端し、その背後のアプリケーションにクリーンで検証済みのアイデンティティを提示します。
ワークフォースに対してすでに権威となっている既存のエンタープライズIdP。AAMは、IdPチームに何かを変更させることなく、SAML SPとして接続します。新しいアプリケーションは、各コードベースに新しいSAMLライブラリを追加するのではなく、AAMに登録を追加することでフェデレーションに参加します。
各顧客が自身のIdPを持ち込むSaaSアプリケーション。単一のAAMゲートウェイがすべてのテナントを前面で受け持ちます；各テナントのトラフィックはそのテナントのIdPへルーティングされます。テナントを追加することは、デプロイではなく、構成ストアにIdP登録を追加することです。
一部のIdPは認証はしますが、ステップアップMFAや条件付きアクセスを適用しません — 特に古いフェデレーションゲートウェイ。AAMはIdPの認証を受け入れ、その後アプリケーションへのアクセスを許可する前に、独自のMFA、条件付きアクセスの式、継続的トラスト評価をその上に重ねます。
AAMをあなたのIdP — エンタープライズまたは国家アイデンティティフェデレーション — に接続し、アクセスエンジンの残りをMFA、条件付きアクセス、デバイストラスト、Backend SSOとともにアサーションの上に重ねましょう。