Некоторые web-приложения включают сервлеты, которые не должны вызываться непосредственно пользователями, поскольку они обрабатывают важные данные или имеют специальное назначение (например, администрирование сервера или web-приложения). К примеру, вы разработали панель администратора. Как защитить подобные сервлеты от непосредственного вызова неавторизованных пользователей?


Для решения этой проблем, в дескрипторе развертывания web.xml существует элемент security-constraint, но чтобы его использовать, необходимо сначала завести имя пользователя и пароль в XML-документе, находящемся по адресу <инсталляционный-каталог-Tomcat>/conf/tomcat-users.xml. Этот файл предназначен для хранения имен и паролей пользователей. Выглядит он так:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
 
  <role rolename="tomcat"/>
  <role rolename="role1"/>
  <user username="tomcat" password="tomcat" roles="tomcat"/>
  <user username="both" password="tomcat" roles="tomcat,role1"/>
  <user username="role1" password="tomcat" roles="role1"/>
 
</tomcat-users>

Показанный фрагмент XML включает корневой элемент tomcat-users, содержащий один или несколько элементов role (роль), и user (пользователь), в зависимости от числа пользователей web-приложений на сервере Tomcat. Этот файл конфигурации доступен всем web-приложениям сервера.

Далее, в дескрипторе развертывания приложения (web.xml), необходимо создать элементы security-constraint, login-config и security-role.

Элемент security-constraint выглядит так, как показано в следующем листинге:

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Weather</web-resource-name>
            <url-pattern>/weather</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>Этот сервлет доступен только для роли role1</description>
            <role-name>role1</role-name>
        </auth-constraint>
        <user-data-constraint>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

Элемент security-constraint должен содержать один или более элементов web-resource-collection. Элемент web-resource-collection описывает, какие ресурсы web-приложения защищаются указанным ограничением безопасности. Другими словами, запрос web-ресурса через Интернет (например, сервлета) активизирует каждое из ограничений безопасности, относящихся к этому ресурсу. В рассматриваемом примере, ограничения безопасности распространяются на любой запрос, удовлетворяющий шаблону URL /weather.

Элементы http-method задают методы HTTP, на которые действуют данные ограничения безопасности. В этом примере GET и POST с запросом к /weather активизируют механизм безопасности. Если в элементы security-constraint не включено никаких элементов http-method, ограничения будут применяться ко всем методам HTTP (таким, как PUT и DELETE, в дополнение к GET и POST).

Элемент auth-constraint предназначен для описания ролей безопасности, которым разрешен доступ к web-компоненту. Роль безопасности – это имя, представляющее пользователю или группе пользователей полномочия доступа к определенному ресурсу, например сервлету. Роли назначаются пользователям в файле tomcat-users.xml. В приведенном в примере элементе security-constraint доступ к Weather открыт только для пользователей, котрым в файле tomcat-users.xml назначена роль role1.

Как web-приложение аутентифицирует пользователя? Как, например, web-приложение находит имя и пароль обращающегося с запросом пользователя? При безопасности, управляемой контейнером, для этого предназначен элемент login-config.

    <login-config>
        <auth-method>BASIC</auth-method>
    </login-config>
 
    <security-role>
        <role-name>role1</role-name>
    </security-role>

Элемент login-config задает способ, используемый для аутентификации любого пользователя, запрашивающего защищаемый web-ресурс. Защищаемыми являются web-ресурсы, указанные в элементе web-resource-collection, внутри элемента security-constraint. В приведенном примере для любого запроса, соответствующего шаблону URL /weather используется способ аутентификации BASIC – знакомая всем форма web-аутентификации, при которой браузер открывает перед пользователями диалоговое окно для ввода имени и пароля пользователя. Tomcat сравнивает имя и пароль с информацией о пользователях, заданных в файле tomcat-users.xml, и затем, используя настройку ограничений для web-приложения из соответствующего элемента security-constraint, определяет, имеет ли данный пользователь право доступа к защищаемому ресурсу.

Дочерний для login-config элемент auth-method также может принимать значения FORM, CLIENT-CERT или DIGEST.

Для завершенности этой конфигурации безопасности требуется еще один ингредиент: элемент security-role (роль безопасности). В нашем примере создается роль безопасности role1. Значение role1 также присутствует в дочернем элементе auth-constraint элемента security-constraint. Это означает, что пользователи, которым назначена роль безопасности role1, имеют доступ к web-ресурсам, защищенным данными ограничениями (то есть ресурсам, перечисленным в элементе web-resource-collection, дочернем по отношению к security-constraint). Иными словами, описываемый способ аутентификации состоит из двух шагов.

  1. Проверка корректности получаемых имени и пароля пользователя.
  2. Определение, присвоена ли этому пользователю требуемая роль безопасности. К примеру, пользователь может ввести корректные имя и пароль, однако требуемая ему роль безопасности не присвоена. В этом случае он не допускается к использованию запрошенного web-ресурса.

На сервере Tomcat присвоение пользователям ролей безопасности производится с помощью файла tomcat-user.xml.

<username="dmitrii" password="dmitr2i" roles="role1" />

В этом посте было описано, как ограничить запросы к определенным сервлетам.