У меня есть приложение Spring MVC, защищенное с помощью Spring Security. Большинство приложений использует простой HTTP для экономии ресурсов, но небольшая часть обрабатывает более конфиденциальную информацию и требует HTTPS-канала.
Извлечь из security-config.xml
:
<sec:http authentication-manager-ref="authenticationManager" ... >
...
<sec:intercept-url pattern="/sec/**" requires-channel="https"/>
<sec:intercept-url pattern="/**" requires-channel="http"/>
</sec:http>
Все работало нормально, пока мы не решили перенести его на основной сервер, где серверы приложений работают за обратными прокси-серверами. И поскольку теперь HTTPS обрабатывается обратными прокси-серверами, сервер приложений видит только HTTP-запросы и запрещает доступ к иерархии /sec/**
.
После некоторых исследований я обнаружил, что прокси-серверы добавляют заголовок X-Forwarded-Proto: https
(*) но в Spring Security HttpServletRequest.isSecure()
используется для определения предлагаемой безопасности канала (извлечение из javadoc SecureChannelProcessor
).
Как я могу сообщить Spring Security, что для защищенного запроса достаточно заголовка X-Forwarded-Proto: https
?
Я знаю, что мог бы сообщить об этой части о конфигурации прокси, но администратору прокси действительно не нравится это решение, потому что за прокси есть много приложений, и конфигурация может вырасти до неуправляемого состояния.
В настоящее время я использую Spring Security 3.2 с XML-конфигурацией, но я готов принять ответы на основе Java-конфигурации и/или более поздней версии.
(*) Конечно, прокси удаляют заголовок, если он присутствовал во входящем запросе, поэтому приложение может быть в этом уверено.