Аутентификация и доступ

Epic Версия: 0.1 draft

Контроль доступа к Сервису: вход по логину и паролю с выдачей JWT, проверка полномочий (ABAC) на каждой команде и запросе, скрытие недоступного на UI и настоящий выход с отзывом токена. Точка входа в модель доступа ADR-011.

⟨/⟩ Исходник
🔗 Поделиться⟨/⟩ Исходник

1. Цель

Пускать в Сервис только своих и давать каждому ровно то, что ему разрешено. Пользователь входит по логину и паролю, получает сессию и на каждый защищённый вызов предъявляет полномочия; backend проверяет их у каждой команды/запроса, UI прячет недоступное, выход прекращает сессию сразу.

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

🔗 Поделиться⟨/⟩ Исходник

2. Акторы

Актор Роль в эпике
Пользователь входит, работает в пределах своих прав, выходит
Администратор ведёт пользователей, группы и их назначение (в объёме доступа)
Разработчик сеет функции и их claim-значения (состав прав следует из устройства команд/запросов и экранов)
Сервис выдаёт и валидирует токен, собирает контекст, проверяет права, отзывает токен
🔗 Поделиться⟨/⟩ Исходник

3. Границы

Входит: вход по паролю (JWT + jti), профиль с UI-claims, выход с отзывом токена; проверка прав на каждой команде/запросе (базовый хендлер); скрытие недоступных разделов и действий на UI; экраны входа/выхода/отказа; заполнение полей истории пакета реальным пользователем.

Не входит: периметр (фильтрация данных по орг-структуре — вне охвата, ADR-011); OAuth2/OIDC и refresh-токен; хеширование пароля (на dev — открытый текст); полноценное администрирование пользователей/групп/функций на UI (отдельная работа).

Требования: доступность действий проверки и очереди «по правам» («Верификация и корректировка данных», «Очередь обработки пакетов»); закрывает открытый вопрос видения о составе ролей и прав.

🔗 Поделиться⟨/⟩ Исходник

4. Критерии приёмки

  1. Неаутентифицированный пользователь при обращении к защищённому маршруту попадает на экран входа.
  2. После успешного входа и перезагрузки страницы (F5) пользователь остаётся в системе.
  3. Вход выдаёт токен; выход его отзывает — повторный запрос с тем же токеном отклоняется (401), даже если срок ещё не истёк.
  4. Команда или запрос без нужного claim отклоняется (403); соответствующий раздел/действие на UI не показывается.
  5. После входа UI показывает только разрешённые разделы и действия — по UI-claims из профиля.
  6. Ответ 401 уводит на вход с уведомлением; ответ 403 — на экран отказа, сессия сохраняется.
  7. Поля истории пакета («кто ввёл», «кто взял в работу») заполняются реальным пользователем, а не заглушкой.
  8. Вход, выход и получение профиля работают без предъявления прав; всё остальное — только с ними.
🔗 Поделиться⟨/⟩ Исходник

5. Открытые вопросы

№ Вопрос
OQ-AU-1 Хранение пароля: сейчас открытый текст (dev); переход на хеш + соль до продакшна
OQ-AU-2 Refresh-токен и время жизни сессии; поведение при истечении посреди работы
OQ-AU-3 Администрирование доступа на UI (CRUD пользователей/групп/функций) — отдельным эпиком
OQ-AU-4 Состав ролей-пресетов: какие функции входят в «хранителя» и «администратора» при посеве
OQ-AU-5 Инвалидация кэша контекста между несколькими инстансами (шина/Outbox)
OQ-AU-6 Синхронизация выхода между вкладками браузера

Связанные артефакты

Документы