Файл с настройками сервера аутентификации

Обновлено: 03.07.2024

Authelia — это сервер аутентификации и авторизации с открытым исходным кодом, защищающий современные веб-приложения путем взаимодействия с обратными прокси-серверами, такими как NGINX, Traefik и HAProxy.

Введение

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

Сценариев использования инструмента всего два:

Авторизация по связке логин/пароль — обычное средство защиты.
Двухэтапная аутентификация — добавляет еще один уровень безопасности, к связке логин/пароль добавляется еще код с мобильного телефона.

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

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

В Authelia она реализована двумя вариантами на выбор:

Получение тайм кодов через Google Authenticator
Взаимодействие с сервисом DUO Security

Мы будем настраивать первый вариант. Перейдем к подготовительному этапу.

Подготовка

Для работы Authelia, необходимо наличие:

Контейнера MariaDB или другой СУБД.
Контейнера REDIS — тоже СУБД, только данные хранит в памяти, доступ к которым осуществляется по ключу доступа.
Почтовый ящик.

Шаг 1 — СУБД MariaDB

Установим MariaDB и создадим базу данных, юзера и дадим права пользователю для использования созданной БД как описано в статье. Соберем установленные данные для подключения:

Адрес MariaDB – ИПСЕРВЕРА:3307
Пароль от MariaDB – Password
Имя созданной базы данных – userbase
Имя пользователя базы данных – user
Пароль от базы данных – userpass
MariaDB – система управления базами данных

Шаг 2 — СУБД REDIS

Соберем установленные данные для подключения:

От почтового ящика нам нужно собрать данные:

Установка Authelia

Для упрощения процедуры, разобьем на основные части:

Установка шаблона Authelia из репозитория Community Application, а также привел пример ручной установки, приоритетом является именно он.
Правки файла конфигурации Authelia.
Первый запуск контейнера.
Правки конфигурации пользователей для Authelia.

Шаг 1 — Установка контейнера из CA

В окне анрейд переходим на вкладку APPS, в графе поиска вводим Authelia, в поисковой выдаче видим искомый результат:

Настроим контейнер, проверив поля. В основном стоит обратить внимание на те, которые с пометкой *

Authelia Web UI: порт на котором будет работать будущий сервер авторизации, не должен быть занят другими контейнера.
AppData Config Path: путь, где будут хранится файлы конфигурации.

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

После заполнения данных нажимаем APPLY. В следующем окне будет информация о выполненных операциях по установке.

Нажимаем DONE, переходим на вкладку DOCKER, видим установленный контейнер Authelia, но он окажется выключен.

Если по каким-то причинам возникают сложности с установкой из CA, переходим к ручной установке

Шаг 1 — Ручная установка

Если по каким-то причинам не подошел контейнер из CA(способ установки описан выше), и возникают трудности с установкой из шаблона, то те же действия можно проделать полностью в ручном режиме, для этого переходим на вкладку DOCKER, затем спускаемся в самый низ и нажимаем кнопку

В открывшемся окне включаем расширенный вид активацией ползунка в верхнем правом углу и начинаем методично заполнять поля:

Сверяемся со скринами, обращаем внимание на каждое значение:

Детально разберем каждый пункт:

После заполнения данных нажимаем APPLY. В следующем окне будет информация о выполненных операциях по установке, нажимаем DONE, переходим на вкладку DOCKER, видим установленный контейнер Authelia, но он выключен, т.к. не настроены файлы конфигурации.

Шаг 2 — Файлы конфигурации

При установке контейнера в AppData Config Path указывали директорию хранения файла конфигурации configuration.yml, который следует заполнить в соответствии с собранными данными из подготовительного пункта.

Я указывал путь /mnt/user/appdata/Authelia заходим туда любым файловым менеджером на выбор: WinSCP, MC или Cloud Commander, я буду использовать последний вариант.

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

Основной файл конфигурации configuration.yml скачиваем из репозитория ibracorp и заполняем своими данными исходя и собранных на этапе Подготовки:

Указываем IP и порт для контейнера Authelia:

Параметры переадресации(не обязательно) в случае успешной авторизации, вписываем свой домен:

Параметры TOTP:

Параметры DUO(не пользуюсь, настройки оставляю по дефолту), секрет можно использовать из настроек выше:

Настройка разрешает(по умолчанию, false) или запрещает(true) возможность восстановления пароля:

Настройки файла конфигурации пользовательских данных:

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

Для себя выставил настройки:

В пользовании это будет выглядеть примерно следующим образом:

default_policy: two_factor — от всех будет требовать двухфакторную аутентификацию.

Если вход осуществляется из сети 192.168.1.0/24 , то вместо двухфакторки, требуется только ввод связки лог/пас.

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

Идем далее, очень важные настройки, я оставил как есть, секрет используем тот, который генерировали ранее:

Все субдомены, которые попадают под защиту Authelia, должны быть под одним доменом, только так это работает:

Настройки подключения к СУБД REDIS:

database_index — выбирается свободный порядковый номер из простых чисел. Делается это для того, чтобы не возникало смешения данных из разных контейнеров, которые подключены к redis. Для примера authelia подключена к redis c индексом 0, затем я подключил nextcloud c индексом 1, далее контейнер WP с индексом 2 и так далее.

Настройки защиты от подбора пароля. Если три раза введены неправильные данные, то получаем бан на пять минут:

Настройка подключения к СУБД MariaDB:

Настройки уведомлений о смене пароля, отключил:

При редактировании, также следует обратить внимание на комментарии внутри конфига

После всех манипуляций подготовленный конфиг закидываем по пути /mnt/user/appdata/Authelia с помощью файлового менеджера.

Шаг 3 — Запуск контейнера

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

Шаг 4 — Настройка пользователей

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

Если этого не произошло берем заветный файл из репозитория ibracorp, и проводим его настройку. Создадим пользователя с данными:

Пароль Password представлен в зашифрованном виде, для получения переходим на argon2.online и вводим желаемый пароль с настройками:

Salt: Произвольные 16 символов
Parallelism: 8
Memory Cost: 1024
Iterations: 1
Hash length: 32
Algorithm: Argon2id

Результат должен быть как на скрине:

Сохраняем сформированный users_database.yml по пути /mnt/user/appdata/Authelia

Настройка Nginx Proxy Manager(NPM)

Как установить NPM описал в отдельной статье, он нам понадобится для подключения субдомена к Authelia, получения SSL и настройке авторизации к уже проброшенным контейнерам.

Добавляем ProxyHost для Authelia

Заходим в WebUI контейнера Nginx Proxy Manager, авторизуемся, переходим по вкладкам Dashboard -> Proxy Hosts -> Add Proxy Host

В открывшемся окне — заполняем параметры вкладок Details и SSL:

Вкладка Advanced требует отдельного внимания, туда копируем конфиг:

Пробуем зайти по доменному имени, если все сделано верно, то будет результат:

Авторизация

Пробуем авторизоваться используя логин и пароль созданного пользователя.

Далее в METHODS выбираем способ авторизации для данного пользователя, выбираем One-time-password

На указанную в шаге создания пользователя почту придет письмо с ссылкой на регистрацию мобильного устройства:

Переходим по ссылке, в новом окне сканируем QRCode приложением Google Authenticator

После сканирования в мобильном устройстве будут доступны 6-значные коды для входа.

Подключаем Authelia к контейнерам

Добавлять авторизацию к контейнерам, которые не имеют собственную, будем через Nginx Proxy Manager. Для примера я возьму Jackett

Для начала пробрасываем Jackett в веб, мы уже делали подобное выше, заполняя вкладку Details и SSL, отличия будут в коде вкладке Advanced:

Где SERVERIP:9091 — IP + порт контейнера authelia.

Задаем CONTAINERNAME в двух местах (в моем случае это будет jackett)

Если у контейнера есть API

К таким контейнерам относятся Sonarr, Radarr и Lidarr. Они используют встроенный API с помощью которого подключаются другие контейнеры и приложения.

Для Authelia его необходимо исключить из процесса авторизации, и сделать это можно при помощи все того же NPM, в котором настраивается вкладка Custom Locations. Выглядит настройка следующим образом:

Порядок запуска

При использовании баз данных MariaDB и Redis (рекомендуется) важно отметить, что порядок запуска контейнеров должен быть настроен правильно. В unRAID:

На вкладке DOCKER переключаем ползунок с basic на advanced view.
Переместите строки так, чтобы все контейнеры баз данных были выше в списке, чем Authelia.
Рядом с переключателем Autostart, необходимо установить задержку (в секундах) для контейнера, чтобы он ждал перед запуском следующего контейнера под ним. Устанавливаем 20 для контейнера над authelia.

Это важно, так как позволяет некоторым контейнерам, запуск которых требует времени и может иметь зависимости, полноценно завершить процедуру запуска.

Описанная выше связка контейнеров:

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

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

Из данной статьи вы узнаете, как установить авторизацию при помощи пароля на веб-сервер Apache, работающий на Ubuntu 16.04.

Требования

Перед тем, как приступить к выполнению дальнейших шагов, убедитесь, что у вас есть доступ к серверу Ubuntu 16.04.

Также для выполнения инструкции вам понадобится следующее:

пользователь, который может выполнять команды sudo на вашем сервере;
веб-сервер Apache;
сайт, на котором установлен SSL-сертификат (к примеру, Let’s Encrypt).

Если все вышеперечисленное у вас в наличии, тогда авторизуйтесь на сервере как пользователь с sudo-правами и перейдите к выполнению первого шага.

Шаг 1: устанавливаем пакет с утилитами Apache

Вам понадобится утилита под названием htpasswd, которая является частью пакета apache2-utils. Она используется для создания файла, а также имени пользователя и паролей, которые будут использоваться для доступа к запрещенному для просмотра обычными пользователями контенту.

Введите следующие команды:

Шаг 2: создаем файл с паролями

Теперь вы можете воспользоваться командой htpasswd. При помощи нее вам будет необходимо создать файл с паролями, который Apache будет использовать для аутентификации пользователей. Для этих целей вам следует создать скрытый файл под названием .htpasswd внутри директории с настройками /etc/apache2.

При первом использовании данной утилиты вам будет необходимо прибавить к команде ключ –c для того, чтобы создать указанный файл. Также в конце команды вам необходимо указать имя пользователя (sinatra в данном примере) – это нужно для того, чтобы создать новую запись внутри файла:

У вас будет запрошен пароль и его подтверждение для созданного пользователя.

Если вы хотите добавить еще каких-либо других пользователей (к примеру, another_user), используйте эту же команду, но уже без ключа –c:

Посмотрите содержимое этого файла:

Вы увидите имя пользователя и зашифрованный пароль для каждой записи:

Шаг 3: настраиваем авторизацию при помощи пароля на Apache

Теперь у вас есть файл с именами пользователей и паролями в формате, доступном для чтения Apache.

Следующим шагом вам необходимо настроить Apache так, чтобы он сверялся с этим файлом всегда, когда собирается предоставить доступ к защищенному от посторонних глаз контенту. Вы можете сделать это двумя путями: либо прямо в файле виртуального хоста сайта, либо добавив файлы .htaccess в директории, доступ к которым вы хотите ограничить.

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

То есть выбирайте путь, исходя из своих требований.

Путь 1 (предпочтительный): настраиваем авторизацию через виртуальный хост

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

Для начала откройте файл виртуального хоста, к которому вы собираетесь ограничить доступ. Для примера в данном руководстве будет использоваться файл 000-default.conf, который содержит в себе виртуальный хост по умолчанию, установленный при помощи пакета Apache в Ubuntu.

Внутри файл с раскомментированными строками будет выглядеть примерно так:

Аутентификация происходит на основе каталогов. Для того, чтобы установить аутентификацию, вам нужно поместить директорию, доступ к которой вы хотите запретить, блоком <Directory ___>. В примере ниже доступ будет запрещен к корневому каталогу документов, однако вы можете выбрать какую-либо конкретную директорию:

Внутри блока директории укажите, что вы хотите установить базовую аутентификацию (Basic). Для графы AuthName необходимо выбрать имя, которое будет отображаться пользователю при запросе данных для аутентификации. В графе AuthUserFile необходимо указать файл с паролем, который был создан ранее, для того, чтобы Apache мог его найти. Также вам понадобится valid-user, который может получить доступ к данным; иными словами, в директорию будет допущен любой, кто сможет подтвердить свою личность при помощи пароля.

После редактирования сохраните и закройте файл.

Перед перезагрузкой сервера проверьте настройки следующей командой:

Если все нормально, и вы увидели Syntax OK, тогда перезагрузите сервер для того, чтобы новая политика доступа с запросом пароля вступила в силу. Для этого введите следующие команды:

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

Путь 2: настраиваем авторизацию при помощи файлов .htaccess

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

Для того, чтобы при помощи .htaccess файлов активизировать защиту посредством паролей, откройте главный конфигурационный файл Apache:

Далее найдите блок <Directory> для директории /var/www, который содержит корневой каталог документов. Включите поддержку файлов .htaccess, изменив значение директивы AllowOverride с "None" на "All" – в этом случае сервер будет допускать все директивы .htaccess файла:

После этого сохраните и закройте файл.

Теперь вам необходимо добавить файл .htaccess в директорию, доступ к которой вы хотите ограничить. В данном руководстве для примера доступ будет запрещен ко всему корневому каталогу документов (то есть полностью к сайту), который находится в /var/www/html, но вы можете поместить этот файл в любую директорию, доступ к которой вы хотите ограничить:

Внутри этого файла укажите, что вы хотите установить базовую аутентификацию (Basic). Для графы AuthName необходимо выбрать имя, которое будет отображаться пользователю при запросе данных для аутентификации. В графе AuthUserFile необходимо указать файл с паролем, который был создан ранее, для того, чтобы Apache мог его найти. Также вам понадобится valid-user, который может получить доступ к данным; иными словами, в директорию будет допущен любой, кто сможет подтвердить свою личность при помощи пароля:

Сохраните и закройте файл. Перезагрузите сервер для того, чтобы все изменения, касающиеся защиты паролем выбранной директории, вступили в силу. Затем используйте команду systemctl status для того, чтобы убедиться в успешной перезагрузке:

Шаг 4: проверяем наличие защиты при аутентификации

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

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

Заключение

Если вы выполнили все перечисленные в этом руководстве шаги, то теперь на вашем сайте есть базовая аутентификация. Однако не забывайте и про другие способы защиты от несанкционированного доступа к вашим данным, например, о SSL-сертификатах и использовании SSH.

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

Данный мануал поможет настроить парольную аутентификацию через Apache на сервере Ubuntu 18.04, благодаря чему у сервера появится дополнительный уровень безопасности.

Требования

Войдите в сессию вашего пользователя sudo и приступайте к работе.

1: Установка пакета apache2-utils

Для начала нам нужно установить на сервер пакеты, которые понадобятся нам в работе.

Чтобы создать файл для хранения паролей, понадобится утилита htpasswd. Она входит в пакет apache2-utils, который можно найти в стандартном репозитории.

Обновите индекс пакетов и установите apache2-utils с помощью следующих команд:

sudo apt update
sudo apt install apache2-utils

2: Создание файла паролей

Теперь у вас есть доступ к команде htpasswd, которая позволяет создавать файлы паролей. С помощью такого файла Apache будет выполнять аутентификацию пользователей. Создайте скрытый файл .htpasswd в каталоге /etc/apache2.

При первом запуске утилита требует флаг -c, который создаёт необходимый файл .htpasswd. Чтобы создать новую запись в файле, укажите в конце команды имя пользователя:

sudo htpasswd -c /etc/apache2/.htpasswd 8host

Команда запросит пароль текущего пользователя.

Чтобы добавить в этот файл данные других пользователей, используйте команду htpasswd без флага –с.

sudo htpasswd /etc/apache2/.htpasswd another_user

Теперь просмотрите содержимое файла; в нём должны быть имена пользователей и их зашифрованные пароли.

cat /etc/apache2/.htpasswd
8host:$apr1$.0CAabqX$rb8lueIORA/p8UzGPYtGs/
another_user:$apr1$fqH7UG8a$SrUxurp/Atfq6j7GL/VEC1

3: Настройка аутентификации Apache

Файл паролей с необходимыми данными готов. Теперь нужно настроить Apache, чтобы он проверял этот файл перед обслуживанием закрытого контента. Это можно сделать двумя способами: добавить информацию о файле паролей в виртуальный хост или создать файлы .htaccess в тех каталогах, содержимое которых нужно защитить. Обычно использовать виртуальный хост удобнее. Но если в вашем случае обычные пользователи системы должны иметь возможность самостоятельно управлять доступом, лучше добавить файлы .htaccess.

Выберите наиболее подходящий метод настройки и следуйте инструкциям соответствующего раздела.

Вариант 1: Настройка аутентификации через виртуальный хост

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

Откройте файл виртуального хоста того сайта, доступ к которому нужно ограничить. В данном мануале используется стандартный файл default-ssl.conf , который поставляется вместе с apache.

sudo nano /etc/apache2/sites-enabled/default-ssl.conf

Внутри файл выглядит так (для удобства закомментированные строки опущены):

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog $/error.log
CustomLog $/access.log combined
</VirtualHost>

В Apache аутентификация настраивается на основе каталогов. Чтобы настроить ее, сначала найдите раздел каталога, к которому нужно ограничить доступ, в блоке <Directory ___>. Здесь мы для примера показываем, как ограничить доступ к корневому каталогу (а вы при необходимости укажите другой каталог):

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog $/error.log
CustomLog $/access.log combined
<Directory "/var/www/html">
</Directory>
</VirtualHost>

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog $/error.log
CustomLog $/access.log combined
<Directory "/var/www/html">
AuthType Basic

AuthName "Restricted Content"

AuthUserFile /etc/apache2/.htpasswd

Require valid-user
</Directory>
</VirtualHost>

Сохраните и закройте файл.

Проверьте файл на наличие ошибок:

sudo apache2ctl configtest

Команда должна вернуть:

После этого можете перезапустить веб-сервер. Система systemctl не отображает на экране вывода некоторых команд управления сервером, потому состояние сервера после его перезапуска нужно запросить вручную:

sudo systemctl restart apache2
sudo systemctl status apache2

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

Вариант 2: Настройка аутентификации с помощью файлов .htaccess

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

Чтобы включить поддержку аутентификации по файлам .htaccess, откройте конфигурационный файл Apache:

sudo nano /etc/apache2/apache2.conf

Найдите блок <Directory> для каталога /var/www (document root по умолчанию). Чтобы включить поддержку файлов .htaccess, нужно изменить значение директивы AllowOverride с None на All.

. . .
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
. . .

Сохраните и закройте файл.

Затем нужно добавить файл .htaccess в тот каталог, доступ к которому вы хотите ограничить. Мы для примера покажем ниже, как закрыть доступ к каталогу document root, /var/www/html (то есть ко всему сайту). Чтобы ограничить доступ к другому каталогу, внесите в код соответствующие поправки.

sudo nano /var/www/html/.htaccess

В этом файле нужно указать тип аутентификации, в данном случае это Basic. В AuthName укажите имя, которое будет отображаться при запросе учетных данных. В директиве AuthUserFile укажите созданный ранее файл паролей. Для директивы Require укажите значение valid-user, чтобы открыть доступ к контенту только тем пользователям, которые могут пройти аутентификацию.

AuthType Basic
AuthName "Restricted Content"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Сохраните и закройте файл. Перезапустите веб-сервер, чтобы обновить настройки.

sudo systemctl restart apache2
sudo systemctl status apache2

4: Тестирование авторизации

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

Authentication Required
The server requires a username and password. The server says:
Restricted server.
User Name:
Password:

Введите валидные учётные данные, чтобы получить доступ к контенту. Если вы предоставите неправильные данные, сервер вернёт ошибку «Unauthorized».

Заключение

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

Это руководство посвящено настройке защиты приложений с помощью TLS-аутентификации. При таком подходе возможность работы пользователей с приложением зависит от имеющихся у них сертификатов. То есть — разработчик может самостоятельно принимать решения о том, каким пользователям разрешено обращаться к приложению.

Мы рассмотрим следующие вопросы:

1. Запуск сервера

Для того чтобы организовать работу сервера — нам понадобится следующее:

Java 11
Maven 3.5.0
Eclipse, Intellij IDEA (или любой другой текстовой редактор вроде VIM)
Доступ к терминалу
Копия этого проекта

В данном проекте содержится Maven-обёртка, поэтому запустить его можно и не устанавливая Maven. Тут будут приведены сведения и о стандартных командах, рассчитанных на mvn, и о командах, ориентированных на использование Maven-обёртки.

Если вы хотите запустить этот проект с использованием Java 8 — вы можете переключиться на более старую его версию с использованием нижеприведённой команды.

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

Сервер можно привести в рабочее состояние, вызвав метод main класса App или выполнив следующую команду в корневой директории проекта:

Вот команда, рассчитанная на Maven-обёртку:

2. Отправка приветствия серверу (без шифрования)

Сейчас сервер работает на порте, используемом по умолчанию (8080) без шифрования. С помощью следующей команды, задействующей curl , можно обратиться к конечной точке hello :

Ответ должен выглядеть примерно так:

Обратиться к серверу можно и с использованием клиента, код которого находится в директории client . Клиент зависит от других компонентов проекта. Поэтому, прежде чем его запускать, нужно выполнить в корневой директории проекта команду mvn install или ./mvnw install .

В клиенте реализован интеграционный тест, основанный на Cucumber. Его можно запустить, обратившись к классу ClientRunnerIT из IDE, или выполнив в корневой директории следующую команду:

При использовании Maven-обёртки это будет такая команда:

Тут имеется файл Hello.feature, который описывает шаги интеграционного теста. Этот файл можно найти в папке ресурсов теста клиентского проекта.

Есть и другой метод запуска и клиента, и сервера. Он представлен следующей командой, выполняемой в корневой директории проекта:

Вариант этой команды для Maven-обёртки выглядит так:

Клиент, по умолчанию, отправляет запросы к localhost , так как он рассчитан на то, что сервер выполняется на том же компьютере, что и он сам. Если сервер работает на другой машине — соответствующий URL можно передать клиенту при запуске, воспользовавшись следующим аргументом VM:

Теперь давайте разберёмся с тем, как защитить сервер с помощью TLS. Сделать это можно, добавив соответствующие свойства в файл application.yml , хранящий настройки приложения.

Речь идёт о следующих настройках:

Для того чтобы вышеописанные настройки вступили в силу — сервер надо перезапустить. Возможно, при этом вы увидите следующее исключение:

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

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

Создать хранилище ключей с открытым и закрытым ключами можно с помощью следующей команды:

Теперь нужно сообщить серверу о том, где именно находится хранилище ключей, и указать пароли. Сделаем это, отредактировав наш файл application.yml :

Замечательно! Только что мы настроили TLS-шифрование соединений между сервером и клиентом! Испытать сервер можно так:

Клиент можно запустить и прибегнув к классу ClientRunnerIT.

Возникает такое ощущение, что клиент пытается поприветствовать сервер, а сервер ему найти не удаётся. Проблема заключается в том, что клиент пытается обратиться к серверу, работающему на порте 8080 , а сервер ждёт запросов на порте 8443 . Исправим это, внеся некоторые изменения в класс Constants . А именно — найдём эту строку:

И приведём её к такому виду:

Экспортировать сертификат сервера можно такой командой:

Теперь можно создать TrustStore для клиента и импортировать туда сертификат сервера такой командой:

TrustStore для клиента мы создали, но сам клиент пока об этом не знает. А это значит, что клиенту надо сообщить о том, что ему следует пользоваться TrustStore, указав адрес хранилища и пароль. Клиенту надо сообщить и о том, что включена аутентификация. Всё это делается путём приведения файла application.yml клиентского приложения к такому виду:

4. Аутентификация клиента (двусторонний TLS)

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

Приведём файл сервера application.yml к такому виду:

Это указывает на то, что клиент не обладает подходящим сертификатом. Точнее — у клиента пока вообще нет сертификата. Поэтому создадим сертификат следующей командой:

Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:

Теперь создадим TrustStore сервера, в котором будет сертификат клиента:

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

Приведём файл application.yml клиента к такому виду:

Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл application.yml к такому виду:

Если снова запустить клиент — можно будет убедиться в том, что тест завершается успешно, и что клиент получает данные от сервера в защищённом виде.

Примите поздравления! Только что вы настроили двусторонний TLS!

5. Установление двустороннего TLS-соединения с использованием доверенного удостоверяющего центра

Есть и другой способ организации двусторонней аутентификации. Он основан на использовании доверенного удостоверяющего центра. У такого подхода есть сильные и слабые стороны.

Клиентам не нужно добавлять в свои хранилища сертификат сервера.
Серверу не нужно добавлять в своё хранилище все сертификаты клиентов.
Меньше времени уходит на поддержку такой конфигурации, так как срок действия может истечь лишь у сертификата удостоверяющего центра.

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

1. Создание удостоверяющего центра

Обычно работают с уже существующими удостоверяющими центрами, которым, для подписи, нужно передавать сертификаты. Здесь же мы создадим собственный удостоверяющий центр и подпишем с его помощью сертификаты клиента и сервера. Для создания удостоверяющего центра воспользуемся такой командой:

Ещё можно воспользоваться существующим удостоверяющим центром.

2. Создание файла запроса на подпись сертификата

Для того чтобы подписать сертификат — нужен .csr-файл (Certificate Signing Request, файл запроса на подпись сертификата). Создать его можно с помощью особой команды.

Вот её вариант для сервера:

Вот — эта команда для клиента:

Такой файл нужен удостоверяющему центру для подписи сертификата. Следующий шаг нашей работы заключается в подписании сертификата.

3. Подписание сертификата с помощью запроса на подпись сертификата

Вот соответствующая команда для клиента:

Вот команда для сервера:

4. Замена неподписанного сертификата подписанным

Экспортируем подписанный сертификат:

Выполним на клиенте следующие команды:

На сервере выполним такие команды:

5. Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру

Теперь нужно настроить клиент и сервер так, чтобы они доверяли бы только удостоверяющему центру. Сделать это можно, импортировав сертификат удостоверяющего центра в хранилища TrustStore клиента и сервера.

Сделаем это, выполнив на клиенте следующую команду:

На сервере выполним такую команду:

В хранилищах TrustStore всё ещё хранятся собственные сертификаты клиента и сервера. Эти сертификаты нужно удалить.

Выполним на клиенте такую команду:

Вот — команда для сервера:

Если снова запустить клиент — можно видеть успешное прохождение теста. А это значит, что клиент и сервер успешно обмениваются данными, используя сертификаты, подписанные удостоверяющим центром.

6. Автоматизация различных подходов к аутентификации

Всё, о чём мы говорили выше, можно автоматизировать с помощью скриптов, которые находятся в папке script рассматриваемого нами проекта. Для запуска скриптов можете воспользоваться следующими командами:

./configure-one-way-authentication — настройка односторонней аутентификации.
./configure-two-way-authentication-by-trusting-each-other my-company-name — настройка двусторонней аутентификации.
./configure-two-way-authentication-by-trusting-root-ca my-company-name — настройка двусторонней аутентификации с использованием удостоверяющего центра.

Протестированные клиенты

Читайте также: