エンタープライズ内で稼働する多くのアプリケーション — 内部ポータル、請求システム、運用コンソール、ベンダー提供の管理パネル、レガシーの基幹業務ツール — はSAMLやOIDCが主流になる前に構築されました。これらは通常、モダンなトークンではなく、HTTPヘッダー、Basic-Auth資格情報、またはすでに信頼しているセッションCookieでユーザーを認識します。
これらのアプリをモダンなSSOへ移行することは理論的には単純に聞こえます。バックエンドの認証パスを書き直し、SAML/OIDCサポートを追加し、中央アイデンティティプロバイダーへ接続するだけです。しかし実際にはほとんど行われません。ソースが古い可能性があり、アプリがベンダー所有の場合があり、変更が規制対象のワークフローを壊す可能性があり、または機能している内部ツールのためにコストが正当化されない場合があります。
組織は2つの悪い選択肢の間で立ち往生します。レガシーアプリをモダンなアイデンティティペリメーターの外に置くか、それぞれのために個別の脆弱な統合を構築するかです。最終的にはフラクチャーされたユーザー体験、分散したアクセス制御、各バックエンド独自のレガシーモデルに散らばったアイデンティティロジックになります。
正しいアプローチはモダンなアクセスレイヤーをアプリの前に配置することです。ユーザーはまず中央アイデンティティ、MFA、条件付きアクセス、デバイス信頼チェックを通過し、認証済みアイデンティティはバックエンドがすでに理解できる形式に変換されます。アプリはコード変更なしでモダンなSSO体験を得ます。
しかしこの移行は慎重に行う必要があります。ユーザーからのなりすましアイデンティティヘッダーをストリップせずにバックエンドへ転送すると、誰もが自分のリクエストにX-Auth-Userヘッダーを追加して別のユーザーになりすますことができます。ゲートウェイは信頼されていないインバウンド値を削除し、自身が生成した信頼できるアイデンティティのみを注入し、これをルートごとに厳密にスコープする必要があります。
ログアウト、セッション喪失、バックエンド主導のアイデンティティ状態も同じエンジンを通じて流れる必要があります。そうでなければ、ユーザーがポータルでログアウトしているように見えてバックエンドセッションが生き続けたり、バックエンドセッションがドロップしてもアクセスレイヤーが気づかなかったりする場合があります。
バックエンドSSOはレガシーアプリを強制的に書き直すことではありません — アプリの前にモダンなアイデンティティ制御を置き、認証済みユーザーアイデンティティをバックエンドがすでに受け入れる言語へ安全に変換することです。
バックエンドごとに1つの設定オブジェクト、5つの注入形式、残りのアクセスエンジンと連携。
すべての注入ルールは最初にターゲットヘッダー、Cookie、またはAuthorization値の受信コピーをストリップし、次に認証済みセッションから派生したバージョンを注入します。独自の"X-Auth-User"を送信するユーザーは他人になりすますことができません — ゲートウェイが信頼できるものを追加する前に、そのヘッダーは削除されます。
カスタムヘッダー（X-Auth-User、X-Forwarded-User、バックエンドが期待する任意のもの）、ユーザー名:パスワードペアを必要とするアプリ向けのAuthorization Basic、トークン対応バックエンド向けのAuthorization Bearer、名前付きCookieを読み取るアプリ向けのCookie値マージ、署名済みSAMLアサーションを期待するバックエンド向けのSAML-SP。各注入には独自の設定があり、1つのバックエンドで複数の形式を同時に使用できます。
各注入ルールは独自の条件式を持ちます — 管理パスのみに適用、特定のセッション属性が存在する場合のみ適用、1つのテナントのみに適用。同一バックエンドが特権ルートではより豊かなアイデンティティを、公開ルートでは最小限のサブセットを受け取ることができます。
バックエンドがユーザーのセッションが消滅したと報告した場合（サービスごとの既知のレスポンス形式）、またはバックエンド自体がユーザーをログアウトした場合、AMMはシグナルを検出し、ゲートウェイ側のセッションをクリーンアップし、設定されたポリシーに従ってリダイレクトします。ログアウト優先の優先順位により、クリーンアップは常に追加の注入より前に実行されます。
5つのリリース済み注入形式、それらを安全にする入力ストリップの規律、および高レベルプロトコル注入のロードマップ。
最もシンプルで一般的な形式です。ヘッダー名（X-Auth-User、X-Forwarded-User、REMOTE_USER、バックエンドが読み取る任意のもの）と値を生成するスマート変数（ユーザー名、メール、グループリスト、表示名）を設定します。ヘッダーはインバウンドリクエストからストリップされ、リクエストがバックエンドに到達する前に認証済みセッションから再追加されます。
HTTP Basicで認証するレガシーアプリに対して、ゲートウェイはユーザー名スマート変数と保存された資格情報から派生したAuthorization: Basic
すでにBearerトークンを使用するバックエンド（内部API、マイクロサービス、モダンなイントラネットアプリ）に対して、AMMはAuthorization: Bearer
名前付きCookieからアイデンティティを読み取るアプリにはCookie値注入で対応します。ゲートウェイは注入するname=valueペアを他のCookieを上書きせずにリクエストのCookieヘッダーへマージします — 4つのヘッダースタイル形式の中で最もエラーが発生しやすく、単純な上書きではなく明示的なマージロジックで処理されます。
すべてのリクエストで署名済みSAMLアサーションを期待するバックエンドに対して、ゲートウェイは認証済みセッションからSAML 2.0アサーションを生成し、AMMのSAML署名キーで署名し、設定されたヘッダーでバックエンドへ転送します。公共部門のアイデンティティフェデレーション統合とエンタープライズSaaSバックエンドに典型的です。ユーザーはモダンなIdPでサインインし、バックエンドはすべてのリクエストで新鮮でスコープされたSAMLアサーションを受け取ります。
すべての注入は同一ターゲットのインバウンドストリップと対になっています。独自のリクエストでX-Auth-Userを設定したユーザー、改ざんされたアイデンティティ値を持つCookieを送信したユーザー、または他の場所からAuthorizationヘッダーを再生したユーザーは、ゲートウェイを通過させることができません。スロットがクリアされた後にのみ注入が実行されます。
各注入ルールは条件を付加できます — 条件付きアクセスポリシーと同じ式言語。管理パスのみに注入、ユーザーが特定のグループに属する場合のみ注入、属性が存在する場合のみ特権バリアントを注入。条件はACL優先順位安全な方法でコンパイルされ、1つのバックエンド上の複数のルールが正しく組み合わされます。
すべての注入は認証済み状態の後にゲートされます — リクエストが有効なAMMセッションを持つ場合のみ実行されます。設定ミスのあるルートで認証を回避したユーザーが誤って注入されたバックエンド資格情報を受け取ることはありません。匿名リクエストは常に注入なしでバックエンドに到達します。
高レベルプロトコル注入形式 — サービスチケットを必要とするバックエンド向けのKerberosの制約付き委任、古いWindows環境向けのNTLM — はロードマップにあります。設定オブジェクトと条件的な配管はすでに対応しており、残っているのはプロトコル固有のランタイムです。
アクセスエッジでヘッダーグレードの注入を安全にするメカニクス。
注入ごとの条件は、ゲートウェイの他のACL駆動の決定（認証状態、アクセスポリシー、バックエンド選択）と組み合わされます。条件コンパイラーはextra-entriesパターンを使用するため、注入条件は常に認証とポリシーの後に評価され、注入ルールが誤って高優先順位のポリシー決定の結果を逆転させることはありません。
注入がセッションバッグにない値を必要とする場合（リクエストごとのフェッチから派生した値、グループ展開、属性ルックアップ）、ディスパッチャーは注入の条件が一致する場合にのみ実行される条件付きフェッチを発行します。注入を受け取らないバックエンドは値のフェッチコストを支払いません。
各サービスは「セッションが消滅した」ことを意味するレスポンスシグネチャを宣言できます — 特定のステータスコード、特定のレスポンスヘッダー、ボディマーカー。ゲートウェイがそのシグネチャを見ると、セッション喪失フラグを設定し、ゲートウェイ側のセッションをクリーンアップし、設定されたポリシーに従ってリダイレクトします。
バックエンド自体がユーザーをログアウトした場合（通常、既知のログアウトシグネチャでレスポンスすることで）、ゲートウェイは3ステップのクリーンアップを実行します。ゲートウェイ側のCookieをクリア、セッションレコードを削除、設定されたターゲット経由でリダイレクト。ログアウト優先の優先順位により、このパスは実行中の注入より先に来ます。
注入で使用される資格情報とトークンは設定ストアで暗号化して保存され、アクセスログに平文で書き込まれることはありません。監査エントリは注入がリクエストで実行されたことを記録しますが、どの値を持っていたかは記録しません。オペレーターはポリシーを見ます。ワイヤーペイロードはワイヤー上に留まります。
ユーザーをログインページへ送り返すことなくバックエンドセッションを再確立するための、AMMデーモンへの302を使用したサイレント再認証フローはロードマップにあります。AAM主導のログアウト伝播 — 注入されたアイデンティティを受け取ったすべてのバックエンドへログアウトシグナルをプッシュすること — もロードマップにあります。
10年間X-Remote-Userを信頼してきた内部ポータルはX-Remote-Userを読み続けます。ゲートウェイはエッジでモダンなSAML/OIDCを実行し、ポータルが常に見ていた同じヘッダーを注入します。バックエンドのデプロイなし、移行のカットオーバーなし。
内部マイクロサービスのクラスターはBearer-token認証を必要としますが、サービスごとにアイデンティティフローを実行したくありません。ゲートウェイはリクエストごとに署名済みトークンを発行して注入し、各サービスはゲートウェイのキーに対してトークンを検証します。
マルチアプリのデプロイメントに、Basic Authを必要とするアプリ、カスタムヘッダーを必要とするアプリ、Cookieを必要とするアプリが含まれています。1つのAMMゲートウェイが一度ログインを処理し、各バックエンドは期待する形式を同時に、ルートごとの条件で受け取ります。
明確なアイデンティティチェーンを必要とするコンプライアンス体制 — 「このリクエストがバックエンドに到達した時に誰が認証されていたか」 — はゲートウェイの監査ストリームから生成されるそのチェーンを取得します。ヘッダー値、注入条件、認証済みサブジェクトが一緒に記録されます。
実際のアプリケーションにバックエンドSSOをデプロイします — 既存の信頼モデルを維持し、ユーザーの手から資格情報を取り除き、すべてのリクエストに監査グレードのアイデンティティチェーンを生成します。