私の質問は主に、Spring アプリケーションで同じユーザーに提示される、別々の真の認証ソースを持つ 2 つのログイン フォームを持つことが可能かどうかに関するものです。
UATまたはProductionのどちらのプロファイルが選択されているかに応じて、異なるセキュリティ構成クラス (またはstatic 内部構成クラスを持つ同じクラス) を Maven ビルドに追加したいと考えています。または、デプロイメント環境でこれを制御します (フレームについては以下を参照してください)。
どちらの場合でも、アプリケーションには「特権」アクセス (管理ページなど) 用の独自の認証プロンプトが必要であり、このためのアプリのログイン ページを表示したいと考えています。
ただし、UATプロファイルの場合、ユーザーがページを表示する前に追加のログイン ページと、それらの保護されたページにアクセスした場合の管理機能のログイン ページを確認したいと考えています。
アイデアは、本番環境で動作するのとまったく同じように UAT でアプリケーションを表示することです。
どんなアイデアでも喜んで検討しますが、私の理想的なケースは、個別の Spring Security 構成セットでこれを許可することです。
私が試したこと/考えたこと
動的フィルター リクエストをキャッチし、別のログイン ページの表示と外部認証の処理を唯一の目的とするサーブレットに転送する動的フィルターを登録することで、このアイデアを実装することができました。 UAT のビルド時間)、しかしそれは Spring アプリではなく、ディスパッチ サーブレットはそのアプローチを無効にするだろうと私は信じています。
フレーム (app-ception) 独自のセキュリティを持つ外側の「UAT ビューアー」アプリのフレーム内にアプリを表示するというアイデアを検討し、Spring セキュリティの懸念を理論的にセグメント化しました。しかし、それが外側のアプリと内側のアプリに異なる Cookie を作成するかどうかはわかりません (セキュリティ上の理由からフレームを考慮することはめったにありません)。理想的には、クリックジャッキングを防ぐために x-frame-options ヘッダーのすべてのフレーミングを拒否したいのですが、このアプローチが可能であれば、フレーム ポリシーを同じオリジンに変更するだけで十分です。
最初にフレーム アプローチを試して、また報告しようと思います。
このことを考えてみると、フレーム内に表示される内部アプリは、クライアントがロードできるように外部からアクセスできる必要があります。そのため、このアプローチは、コードへの影響を最小限に抑えて内部アプリケーションを分離するという目的を無効にします。