Продолжаю проект по переводу инфраструктуры компании на RedOS и так как мы уже определились, что будем использовать FreeIPA в качестве аналога Active Directory, то следовательно следующий этап это создание единой точки входа в другие сервисы с использованием учётных данных FreeIPA.

Во многих сервисах мы можем использовать авторизацию с использованием учётных данных полученных при прямом доступе к каталогу LDAP, но иногда это становится проблемой с использованием структуры LDAP FreeIPA, так как приложение которое надо интегрировать разрабатывалось исключительно для работы с Active Directory.

Будем использовать OAuth 2.0

OAuth 2.0 — это отраслевой стандарт авторизации, позволяющий приложениям получать ограниченный доступ к пользовательским ресурсам на других сервисах без передачи логина и пароля.
Ключевая идея: вместо того чтобы давать приложению свои учётные данные, пользователь делегирует ему права через доверенного поставщика идентификации (например, Google, GitHub, Keycloak).

Соответственно, Keycloak который мы уже установили и установка описана в статье «Установка Keycloak в Ubuntu Linux 22.04«. Следовательно Keycloak будет как раз сервером авторизации OAuth 2.0, а данные пользователей будем получать из FreeIPA.

Настройка источника данных авторизации для Keycloak

В терминологии Keycloak такого рода источники данных называются «User federation» и настраиваются они очень просто.

User Federation (федерация пользователей) в Keycloak — это механизм, позволяющий подключать внешние хранилища учётных записей (LDAP, Active Directory, базы данных и др.) и использовать их в качестве источника пользователей для Keycloak. Вместо дублирования данных Keycloak «проксирует» аутентификацию и синхронизацию с внешним сервером, сохраняя централизованное управление доступом.

Если вы хоть раз настраивали интеграцию приложений с LDAP или Active Directory, то думаю вам все будет знакомо.

Нам необходимо создать новую федерацию пользователей например в основном Realm (про Realm поговорим попозже).

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

Connection URL

ldap://srv-kvm-prod-rain-01.rain.shiskitech.ru — адрес сервера LDAP используемый для подключения. Выбирайте использовать TLS или нет и можно сразу проверить подключение соответствующей кнопкой.

• Connection URL — адрес подключения с указанием ldap/ldaps для шифрованных или не шифрованных соединений
• Enable StartTLS — собственно шифрование вкл/выкл
• Остальное по умолчанию

Bind credentials

Здесь нам потребуется создать сервисного пользователя в FreeIPA с правами на чтение и указать в настройках Keycloak тип подключения, логин и пароль.

Создайте непривилегированного пользователя в FreeIPA Identity Management. В моем случае я создал пользователя _keycloak типа авторизации в FreeIPA будет Simple.

BindDN пользователя мы можем найти через Apache Directory Studio и в моем случае получилось uid=_keycloak,cn=users,cn=accounts,dc=rain,dc=shiskitech,dc=ru.

Естественно проверяем, что авторизация прошла успешно соответствующей кнопкой.

LDAP searching and updating

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

Edit mode

Устанавливаем в Read Only и нам пока не требуется возможность модификации записей в LDAP.

Users DN

Это область поиска пользователей в LDAP каталоге. Все наши пользователи в CN Users и соответственно от туда поиск и начинаем. Получается значение cn=users,cn=accounts,dc=rain,dc=shiskitech,dc=ru.

Основные атрибуты пользователей

• Username LDAP attribute — uid
• RDN LDAP attribute — uid
• UUID LDAP attribute — ipaUniqueID
• User object classes — inetOrgPerson, organizationalPerson
• Search scope — Subtree

Единственное, что может вызвать вопросы, это User LDAP filter и вот здесь при тестировании фильтров LDAP могу порекомендовать Apache Directory Studio и так называемые быстрые фильтры.

В результате подбора подходящего фильтра я остановился на конструкции вида (User LDAP filter):

(&(objectclass=person)(uid=*)(memberOf=cn=_keycloak_allow,cn=groups,cn=accounts,dc=rain,dc=shiskitech,dc=ru)(objectClass=top)(!(nsaccountlock=True)))

Обратите внимание на часть (!(nsaccountlock=True)) и ее постоянно забывают, а она как раз отвечает за фильтрацию заблокированных пользователей в FreeIPA.

И наверное последнее, что стоит отметить это раздел Mapper в котором описано соотношение атрибутов Ldap и атрибутов Oauth2. В этом разделе надо изменить атрибут first name на Ldap значение givenname (по умолчанию там cn, что как-то странно).

Synchronization settings

Здесь как говорится все настраивается на вкус и цвет и я включил дополнительно периодическую полную и частичную синхронизацию.

Проверка работы федерации пользователей

Сохраняем данные и выполняем полную синхронизацию.

В результате увидим, сколько пользователей добавлено, обновлено, удалено.

Переходим в раздел Manage -> Users и выполняем поиск пользователя который должен быть синхронизирован с FreeIPA.

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