Spring SecurityがHttpSessionSecurityContextRepositoryを利用していることは理解していますHttpSession。
さらに、CloudFoundry などの PaaS は、スケーラビリティーのためにセッションのレプリケーションを回避しようとしていると読みました。
アプリケーションをCloudFoundry PaaSにデプロイするつもりです。
HttpSessionSecurityContextRepositoryCFでの使用に問題はありますか?
CloudFoundry のドキュメントには、HTTP セッションはデフォルトではインスタンス間で複製されないと単純に書かれています。つまり、複数のインスタンスにデプロイされたアプリケーションは、デフォルトではいかなる種類の HTTP セッション クラスタリングも使用できなくなります。HTTP セッションはスティッキーになります。つまり、同じセッション内のすべての HTTP リクエストは、リクエストのセッションが存在するインスタンスにルーティングされます。インスタンスに障害が発生した場合、そのインスタンスでアクティブなセッションを行っていたユーザーは他のインスタンスに移行されますが、セッション情報が失われるため、再度ログインする必要があります。
これは、そのような環境で Spring Security を使用することが安全でないという意味ではありません。Spring Security を使用したセマンティクスは、Spring Security を使用しない場合と同じになります。ユーザーがログインすると、セッションが作成された CloudFoundry インスタンスに引き続きアクセスします。そのインスタンスがクラッシュした場合、別のインスタンスに自動的に移植されますが、再度ログインする必要があります。
デフォルトの設定 (セッション レプリケーションなし) が問題になる場合は、インスタンス間でセッションを共有することは確かに可能です。CloudFoundry フォーラムでは、Redis 経由とJDBC を使用してこれを実現する 2 つの方法がリストされています。CloudFoundry サービスの 1 つを使用して、独自のソリューションを実装することもできます。