Tomcat: ограничение доступа с помощью файла web.xml

Автор: | 13/12/2013
1 комментарий
 

apache-tomcat-7-logoФайл web.xml, называемый “дескриптор развёртывания” (приложения) – одна из наиболее важных частей Java EE web-приложений.

Настройки безопасности, осуществляемые с помощью этого файла, полностью регулируют поведение веб-контейнера, для которого он назначен. Потому, понимание его основ и главных принципов построения такой защиты необходимое условие для корректной и безопасной работы как самого сервера Tomcat, так и веб-приложений в нём.

Security Constraints (ограничения безопасности), описываемые в этом файле очень гибкие, и имеют множество вариантов настроек. Далее мы рассмотрим основные элементы конструкции <security-constraint>.

Для примера – возьмём такой вариант:

<security-constraint>
<web-resource-collection>
<web-resource-name>All Access</web-resource-name>
<url-pattern>/unchecked/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
...

Основной элемент, который управляет ограничениям – <security-constraint>. Внутри него описываются остальные необходимые элементы, управляющие ограничениями веб-приложения.

<web-resource-collection> – внутри элемента описывается ресурс, к которому будут применены ограничения, его имя, расположение, тип аутентификации и/или ограничений доступа.

<web-resource-name> – имя защищаемого ресурса, не учитывается сервером во время работы, но полезен для удобства настройки и управления, обязательный элемент;

<description> – необязательный элемент, в котором можно добавить более полное описание ресурса;

<url-pattern> – путь от корня приложения к файлу и/или каталогу, к которому будут применяться ограничения; можно использовать шаблоны – например, *.jsp, /unchecked/* – все URL-ы, начинающиеся с /unchecked, /Page – шаблон, срабатывающий только для URL-а /Page и т.д.

<http-method> – необязательный элемент, описывающий для каких типов запросов будет применяться ограничение. Допустимые значения: DELETE, PUT, HEAD, GET, POST и т.д. Важно – если указан только один тип запросов – это значит, что для всех остальных ограничение применяться не будет. Если не указан ни один – ограничение применяется ко всем типам.

Пример:

<security-constraint>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTAL</transport-quarantee>
    </user-data-constraint>
</security-constraint>

Рассмотрим другой пример:

<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>

<display-name> – отображаемое имя для защищаемого ресурса, не работает в Tomcat 4 и 5, необязательный элемент;
<auth-constraint> – список ролей, пользователи которых будут иметь доступ к ресурсу; если оставить пустым – доступ будет закрыт для всех ( <auth-constraint /> ); роли обязательно должны быть перечислены в элементе <security-role>;

<role-name> – по одной роли в каждом элементе;

<security-role> – список ролей пользователей, которые будут использоваться приложением для аутентификации; должен в себе содержать элементы <role-name>:

<security-role>
<role-name>Employee</role-name>
</security-role>

<user-data-constraint> – описывается уровень уровень защиты для ресурса; должен содержать элемент <transport-guarantee>;

<transport-guarantee> – содержит указание уровня защиты передачи данных между клиентом и сервером; допустимые значения:

  • NONE – значение по-умолчанию – никаких ограничений;
  • INTEGRAL – данные должны передаваться способом, который гарантирует, что они не могут быть изменены в процессе передачи, например – с использованием контрольных сумм;
  • CONFIDENTIAL – данные должны передаваться способом, который гарантирует, что они не могут быть рассмотрены и/или изменены в процессе передачи (например – SSL);

Пример:

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

<login-config> – элемент описывает способы авторизации, а так же – необходимые атрибуты для форм авторизации BASIC и FORM-based; может содержать такие элементы внутри: <auth-method>, <form-login-config>, <form-login-page>, <form-error-page>, <realm-name>.

<auth-method> – описывает тип авторизации, допустимые типы:

  • BASIC – базовая атворизация, через всплывающее окно браузера, авторизация осуществляется через механизм, заданный в элементе <realm-name>;
  • DIGEST – тоже, что и BASIC, но данные хешируются на стороне клиента; используемый Realm должен быть сконфигурирован с поддержкой алогиртма шифрования MD5, пароли должны хранится в виде хешей;
  • FORM – форма авторизации, через заданную в элементе <form-login-page> страницу, в случае неудачноя авторизхации – пользователь перенаправляется на страницу, заданную в элементе <form-error-page>;
  • CLIENT_CERT – авторизация клиента по SSL-сертифкату.

Примеры:

<login-config>
<auth-method>BASIC</auth-method>
<realm-name>JDBCRealm</realm-name>
</login-config>
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
<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>

Ссылки по теме:

http://java.dzone.com
http://java.dzone.com
http://wiki.metawerx.net
http://twoguysarguing.wordpress.com