Система единого входа с Apache Tomcat

1. Обзор

В этой статье мы узнаем об основах сервера Tomcat, о том, как он работает, и о том, как включить функцию единого входа ( SSO ) Tomcat. Мы рассмотрим сервер Tomcat и необходимые конфигурации веб-приложения.

2. Архитектура Томкэт

Основными частями, составляющими контейнер сервлетов Catalina, являются сервер, содержащий службы, которые будут определять коннекторы, и механизм, построенный из хостов, и, наконец, эти хосты будут содержать контексты или веб-приложения.

Соединители слушают запросы клиента и отправляют ответы. В Tomcat 10 мы можем найти коннекторы для следующих протоколов: HTTP/1.1 , HTTP/2 и AJP .

Механизм будет обрабатывать запросы, полученные коннекторами, и выдавать результат. Он будет содержать конвейер обработки , представляющий собой цепочку процессов, которые будут выполняться для каждого запроса для получения ответа. Эти процессы являются клапанами Tomcat . Например, SSO на Tomcat реализован в виде клапана.

После этого находим хосты, которые будут определять виртуальные хосты, связывающие сетевое имя с сервером. Это уровень, на котором будет определен клапан SSO, поэтому все контексты хоста будут находиться под SSO.

И, наконец, у нас будут элементы контекста, связанные с хостами. Эти контексты представляют собой веб-приложения, которые будут работать на сервере. Контексты должны соответствовать спецификации сервлета 2.3 или более поздней версии.

3. Единый вход на Tomcat

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

Клапан SSO должен соответствовать следующим требованиям :

• Realm или « база данных пользователей» должны совместно использоваться всеми веб-приложениями на виртуальном хосте.
• Механизм аутентификации веб-приложений должен быть одним из стандартных аутентификаторов: Basic , Digest , Form , SSL или SPNEGO .
• Когда клиент запрашивает защищенный ресурс, сервер запускает механизм аутентификации веб-приложения.
• Сервер будет использовать роли аутентифицированного пользователя для доступа к защищенным ресурсам веб-приложений на виртуальном хосте без повторного входа в систему.
• Когда пользователь выходит из веб-приложения, сервер аннулирует сеанс пользователя во всех веб-приложениях.
• Клиент должен принимать файлы cookie. Файлы cookie хранят токен, который связывает запросы с учетными данными пользователя.

3.1. Конфигурации сервера Tomcat

На стороне сервера нам нужно настроить клапан SingleSignOn и Realm или «базу данных пользователей» . Эти конфигурации находятся внутри файла server.xml в папке conf установки Tomcat. Чтобы добавить клапан SSO, нам нужно раскомментировать следующую строку:

<Valve className="org.apache.catalina.authenticator.SingleSignOn" />

Для примера в статье мы будем полагаться на Realm, настроенный по умолчанию, и нам нужно будет только добавить пользователей в базу данных . Определение Царства выглядит так:

<Realm
  className="org.apache.catalina.realm.UserDatabaseRealm"
  resourceName="UserDatabase"/>

Эта конфигурация использует глобальный ресурс JNDI для определения источника пользовательской базы данных:

<Resource name="UserDatabase" auth="Container"
  type="org.apache.catalina.UserDatabase"
  description="User database that can be updated and saved"
  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
  pathname="conf/tomcat-users.xml" />

Ресурс создаст экземпляр объекта типа org.apache.catalina.UserDatabase и заполнит его из файла tomcat-users.xml с помощью фабричного класса org.apache.catalina.users.MemoryUserDatabaseFactory .

Наконец, здесь мы видим, как добавить пользователя с ролью администратора, необходимой на примере статьи. Нам нужно изменить файл tomcat-users.xml:

<tomcat-users xmlns="http://tomcat.apache.org/xml"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
  version="1.0">
    <role rolename="admin"/>
    <user username="demo" password="demo" roles="admin"/>
</tomcat-users>

3.2. Конфигурация веб-приложений

После того, как мы настроили сервер, давайте настроим сервлеты с помощью файла конфигурации web.xml, который находится в папке WEB-INF каждого сервлета.

Все веб-приложения, требующие SSO, должны иметь защищенные ресурсы и использовать один из методов аутентификации Tomcat . Как определено в спецификации Servlet API 2.3, механизм аутентификации веб-приложений определяется в элементе login-config внутри элемента веб -приложения . Этот элемент будет содержать форму метода аутентификации, которая должна использовать одно из следующих значений: BASIC, DIGEST, FORM или CLIENT-CERT. Каждый метод аутентификации будет иметь свою конфигурацию, но мы обсудим только методы аутентификации DIGEST и FORM в разделе Конфигурация веб-приложений Tomcat .

Чтобы завершить настройку веб-приложения, нам нужно настроить защищенные области . Внутри файла web.xml под элементом web-app мы можем добавить столько элементов ограничения безопасности, сколько необходимо. Каждое ограничение безопасности определяет шаблон URL для защищенных ресурсов и устанавливает разрешенные роли. Кроме того, нам нужно определить элементы security-role со всеми ролями, и они должны соответствовать определениям в файле tomcat-users.xml. Мы увидим пример в следующем разделе.

4. Примеры механизмов аутентификации

Теперь, когда мы знаем, как настраивать веб-приложения, давайте рассмотрим два примера: Ping и Pong. Мы выбрали разные механизмы аутентификации, чтобы показать, что SSO хорошо работает с разными механизмами .

4.1. Механизм аутентификации Ping

В веб-приложении ping мы используем метод аутентификации FORM. Для метода аутентификации FORM требуется форма входа, а вход на веб-страницу завершился неудачно . Например, этот метод будет полезен, когда мы хотим настроить страницу входа в систему так, чтобы она выглядела как веб-приложение, и конфигурация будет выглядеть так:

<login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/logging.html</form-login-page>
        <form-error-page>/logging_error.html</form-error-page>       
    </form-login-config>
</login-config>

Страница входа должна следовать некоторым строгим правилам, определенным в примечаниях к форме входа спецификации сервлета 2.3 , потому что мы не можем выбирать ни имена формы, ни поля ввода. Это должны быть j_security_check , j_username и j_password . Это делается для того, чтобы форма входа работала со всеми видами ресурсов, и для устранения необходимости настраивать поле действия исходящей формы на сервере. Здесь мы можем увидеть пример того, как это должно выглядеть:

<!DOCTYPE html>
<html>
<head>
    <title>Ping - Login</title>
</head>
<body>
    <form method="post" action="j_security_check">
        <table >
            <tr>
                <td>User name: </td>
                <td><input type="text" name="j_username" size="20"/></td>
            </tr>
            <tr>
                <td>Password: </td>
                <td><input type="password" name="j_password" size="20"/></td>
            </tr>
        </table>
        <p></p>
        <input type="submit" value="Submit"/>
         
        <input type="reset" value="Reset"/>
    </form>
</body>
</html>

Чтобы понять, что произойдет на сервере, когда он получит запрос от защищенного ресурса веб-приложения, прошедшего проверку подлинности FORM, давайте обобщим поток этого механизма проверки подлинности.

В первую очередь клиент запрашивает защищенный ресурс. Если сервер не содержит действительного идентификатора сеанса единого входа, сервер перенаправит клиента к форме ведения журнала. После того, как пользователь заполнит форму и отправит свои учетные данные на сервер, запустится механизм аутентификации.

После успешной аутентификации пользователя сервер проверит роли пользователя, и если ограничение безопасности разрешает хотя бы одну из них, сервер перенаправит клиента на запрошенный URL-адрес. В другом случае сервер перенаправит клиента на страницу ошибки.

4.2. Механизм аутентификации Pong

В веб-приложении Pong мы используем механизм аутентификации DIGEST, и конфигурация будет выглядеть так:

<login-config>
    <auth-method>DIGEST</auth-method>
</login-config>

Поток механизма аутентификации DIGEST аналогичен аутентификации BASIC: когда клиент запрашивает защищенный ресурс, сервер возвращает диалоговое окно для запроса учетных данных пользователя. Если аутентификация прошла успешно, сервер возвращает запрошенный ресурс, но в другом случае сервер снова отправляет диалоговое окно аутентификации.

Хотя методы аутентификации DIGEST и BASIC похожи, есть важное отличие: пароль остается на сервере.

4.3. Конфигурация ограничений безопасности веб-приложений

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

<security-constraint>
    <display-name>Ping Login Auth</display-name>
    <web-resource-collection>
        <web-resource-name>PingRestrictedAccess</web-resource-name>
        <url-pattern>/private/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>admin</role-name>
    </auth-constraint>
    <user-data-constraint>
        <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>
</security-constraint>

Ограничение безопасности определяет, что все в личной папке является защищенным ресурсом, а также определяет необходимость наличия роли администратора для доступа к ресурсам.

5. Запуск примера

Теперь нам нужно установить сервер Tomcat 10 , настроить конфигурацию, как показано ранее в статье, и поместить веб-приложения Ping и Pong в папку веб-приложения Tomcat.

После запуска сервера и развертывания обоих приложений запросите ресурс http://localhost:8080/ping/private. Сервер покажет аутентификацию входа, потому что мы не вошли в систему:

Затем нам нужно ввести учетные данные, настроенные в разделе конфигурации сервера Tomcat, и отправить форму. Если сервер проверит учетные данные, мы увидим веб-страницу со ссылкой, указывающей на приватный раздел pong:

Если сервер не подтверждает доступ, мы увидим страницу ошибки входа.

После успешного входа в приложение Ping мы могли увидеть механизм единого входа в действии, щелкнув ссылку в приватный раздел pong. Если сеанс уже активен, сервер отправит защищенный ресурс Pong, не требуя повторного входа в систему.

Наконец, мы можем проверить, что после истечения сеанса сервер снова покажет страницу входа. Мы можем сделать это, подождав пару минут и щелкнув ссылку в приватный раздел пинга.

6. Другие решения SSO

В этой статье мы рассмотрели Web-SSO, реализованный сервером Tomcat. Если мы хотим изучить другие варианты SSO, вот несколько популярных:

• Spring Security и OpenID Connect
• Spring Security OAuth с KeyCloak
• SAML с Spring Security
• Служба аутентификации Apereo Central

7. Заключение

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

Как обычно, полный исходный код доступен на GitHub .