Аутентификация в Salt.Box

Алгоритм аутентификации пользователя

Процедура аутентификации реализована с использованием современных стандартов OAuth 2.0 и OpenID Connect:

1. Фронтенд инициирует процесс аутентификации при открытии веб-приложения

2. Фронтенд формирует URL для перенаправления на сервер KeyCloak со следующими параметрами:

   • client_id - идентификатор клиентского приложения в KeyCloak
   • redirect_uri - URL для возврата после успешной аутентификации
   • response_type - code для flow-авторизации
   • scope - запрашиваемые разрешения (например, openid profile email)
   • state - случайное значение для предотвращения CSRF-атак

3. Пользователь вводит учётные данные на странице KeyCloak

4. При успешной аутентификации сервис KeyCloak:

   • создаёт сессию для пользователя;
   • генерирует токены JWT (access и refresh);
   • перенаправляет пользователя обратно на указанный redirect_uri с токенами.

5. Фронтенд получает токены JWT и сохраняет их в localStorage

6. Все последующие запросы от фронтенда к API включают JWT access token в заголовок Authorization

7. Когда access token истекает, фронтенд автоматически использует refresh token для получения нового access token без повторной аутентификации пользователя

Рисунок 1. Диаграмма процесса аутентификации пользователя Salt.Box

Аутентификация пользователей через LDAP

Интеграция KeyCloak с корпоративным каталогом LDAP позволяет использовать существующие учетные записи пользователей.
Для настройки интеграции администратор KeyCloak выполняет следующие действия:

1. Создает новый User Federation Provider типа LDAP в консоли администратора

2. Настраивает параметры подключения:

   • Connection URL — адрес LDAP-сервера (например, ldap://ldap.example.com:389)
   • Bind DN и Bind Credential — учётные данные для подключения к LDAP
   • Users DN — база для поиска пользователей (Base DN)
   • Connection Pooling — включение пула соединений для производительности

3. Настраивает стратегию синхронизации:

   • Edit Mode — режим редактирования (READ_ONLY, WRITABLE, UNSYNCED)
   • Sync Registrations — синхронизация новых регистраций
   • Batch Size — размер пакета при синхронизации большого числа пользователей

4. Определяет сопоставление (mapping):

   • Атрибутов Username, Email, First Name, Last Name и пр. атрибутам в KeyCloak
   • групп LDAP группам в KeyCloak

5. Запускает первичную синхронизацию для импорта существующих пользователей.
   Далее система автоматически аутентифицирует пользователей через LDAP при их входе в KeyCloak

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

Open Policy Agent (OPA) и распространение политик

OPA — это инструмент для определения и применения единых политик безопасности в микросервисной архитектуре:

1. Бандлы (bundles) — основной механизм распространения политик OPA:

   • упакованные архивы с политиками, правилами и данными
   • обычно включают файлы в формате Rego (язык политик OPA)
   • могут содержать дополнительные JSON-данные для контекста

2. Жизненный цикл бандла:

   • Создание политик в Rego разработчиками безопасности
   • Упаковка политик в бандл (архив) с помощью CLI или API
   • Публикация бандла в хранилище (HTTP-сервер, S3, Git)
   • Загрузка бандла агентами OPA через настроенные точки дистрибуции

3. Обновление политик:

   • OPA периодически проверяет источник на наличие обновлений
   • OPA загружает новые версии бандлов автоматически
   • OPA применяет изменения без перезапуска сервисов

4. Версионирование:

   • Каждый бандл имеет ревизию для отслеживания изменений
   • OPA поддерживает атомарные обновления политик