Дескриптор развертывания web.xml является наиболее важной частью конфигурации Java EE веб-приложений Java EE. Конфигурация безопасности в этом дескрипторе управляет семантикой и работой безопасности веб-контейнера. Следовательно, очень важно, чтобы веб-разработчики и администраторы понимали различные комбинации, возможные в конфигурации безопасности в этом дескрипторе.
Ограничения безопасности
Ограничения безопасности менее всего понятны веб-разработчикам, даже если они критически важны для безопасности веб-приложений Java EE. Указание комбинации шаблонов URL, методов HTTP, ролей и транспортных ограничений может быть затруднительным для программиста или администратора. Важно понимать, что любая комбинация, которая была предназначена для обеспечения безопасности, но не была указана с помощью ограничений безопасности, будет означать, что веб-контейнер будет разрешать эти запросы. Ограничения безопасности состоят из коллекций веб-ресурсов (шаблоны URL, методы HTTP), ограничения авторизации (имена ролей) и ограничений пользовательских данных (необходимость получения веб-запроса через защищенный транспорт, такой как TLS).
В этом разделе мы рассмотрим определение ограничений безопасности для нескольких вариантов использования.
Вариант использования : мы хотели бы определить набор веб-ресурсов, доступ к которым не будет проверяться . Мы добьемся этого, исключив ограничения авторизации (элемент auth-constraint).
<security-constraint> <web-resource-collection> <web-resource-name>All Access</web-resource-name> <url-pattern>/unchecked/*</url-pattern> <http-method>DELETE</http-method> <http-method>PUT</http-method> <http-method>HEAD</http-method> <http-method>OPTIONS</http-method> <http-method>TRACE</http-method> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint></security-constraint>
Вариант использования : операция HTTP GET для набора веб-ресурсов должна быть доступна только пользователю с ролью «Сотрудник». Мы добьемся этого с помощью спецификации авторизационных ограничений ( элемент auth-constraint с элементом role-name ).
<security-constraint> <display-name>Restricted GET To Employees</display-name> <web-resource-collection> <web-resource-name>Restricted Access - Get Only</web-resource-name> <url-pattern>/restricted/employee/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>Employee</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint></security-constraint>
ВНИМАНИЕ : Помните, что в этом примере вы указали http-метод GET. Это подразумевает, что ограничение безопасности применяется к GET. Все остальные методы http (POST, PUT, TRACE, HEAD и т. Д.) Открыты. Если вы не хотите использовать уязвимость, не указывайте метод http.
Вариант использования : мы хотели бы исключить набор веб-ресурсов из любого доступа. Это может произойти, когда определенная часть веб-приложения нуждается в какой-либо форме обслуживания или неприменима для конкретного физического развертывания типового веб-приложения. Мы добьемся этого с помощью ограничений авторизации, которые не определяют роли.
<security-constraint> <display-name>excluded</display-name> <web-resource-collection> <web-resource-name>No Access</web-resource-name> <url-pattern>/excluded/*</url-pattern> <url-pattern>/restricted/employee/excluded/*</url-pattern> <url-pattern>/restricted/partners/excluded/*</url-pattern> </web-resource-collection> <web-resource-collection> <web-resource-name>No Access</web-resource-name> <url-pattern>/restricted/*</url-pattern> <http-method>DELETE</http-method> <http-method>PUT</http-method> <http-method>HEAD</http-method> <http-method>OPTIONS</http-method> <http-method>TRACE</http-method> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint /> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint></security-constraint>
Аутентификация
Веб-контейнер может аутентифицировать веб-клиента / пользователя с использованием схем аутентификации HTTP BASIC, HTTP DIGEST, HTTPS CLIENT или FORM.
Вариант использования : Мы хотели бы использовать механизм аутентификации браузера, BASIC HTTP, как определено в спецификации HTTP 1.0.
Элемент login-config.xml в web.xml будет выглядеть следующим образом:
<login-config> <auth-method>BASIC</auth-method> <realm-name>default</realm-name></login-config>
Вариант использования : Мы хотели бы использовать механизм аутентификации клиента HTTPS , основанный на цифровых сертификатах. Аутентификация основана на сертификате пользователя X509.
Элемент login-config.xml в web.xml будет выглядеть следующим образом:
<login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>JMX Console</realm-name></login-config>
Вариант использования : мы хотели бы использовать механизм аутентификации на основе FORM .
Механизм на основе FORM обеспечивает гибкость в определении настраиваемой страницы jsp / html для входа в систему и другой страницы для направления ошибок во время входа в систему.
Элемент xml login-config в web.xml будет выглядеть следующим образом:
<login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/login.html</form-login-page> <form-error-page>/error.html</form-error-page> </form-login-config></login-config>
В этом случае html-страница для входа в систему — это login.html, и при возникновении каких-либо ошибок (включая неудачный вход в систему) пользователь перенаправляется на error.html.
Ссылка
Об авторе : Анил Салдхана — ведущий архитектор безопасности в JBoss. Он ведет блог на http://anil-identity.blogspot.com