Перейти к основному содержимому

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

· 7 мин. чтения

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. Сервер покажет аутентификацию входа, потому что мы не вошли в систему:

./ea613f41ac00ca928711bba103009db8.png

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

./7052c3f075faabb4420392a1cdbbfa13.png

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

./3457bd3f67bc13fae86bf2e843180cb6.png

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

./793329fcd224133348ad1badf887099d.png

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

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

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

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

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

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