Бизнес-требования к управлению ролями и правами

[Columpio]

Область применения

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

Пользовательские сценарии

1. Просмотр доступных ролей

• Основной сценарий: уполномоченный администратор запрашивает каталог ролей для аудита текущей конфигурации.
• Альтернативный сценарий: пользователь без расширенных прав запрашивает тот же список и видит только базовые роли для самообслуживания.
• Краевые случаи: при отсутствии конфигурации арендатора возвращается базовый каталог; неожиданные ошибки логируются, а ответ всё равно содержит минимальный перечень для предотвращения блокировки онбординга.
• Критерии приемки:
  • Система проверяет авторизацию отправителя перед выдачей полного списка ролей.
  • Неавторизованные отправители получают только заранее определённый минимальный набор ролей.
  • Ответ сортируется по алфавиту для предсказуемого отображения в интерфейсе.
  • Все сбои фиксируются в логах, а пользователю возвращается базовый список ролей.

2. Получение матрицы ролей и прав

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

3. Получение описаний прав

• Основной сценарий: потребитель (UI или интеграция) запрашивает человеко-читаемые описания прав для подсказок и справочных материалов.
• Краевые случаи: новые права должны появляться автоматически без ручной настройки; при отсутствии локализации используется каноническое описание.
• Критерии приемки:
  • Каждому идентификатору права соответствует строка описания.
  • Операция только на чтение и не требует повышенных привилегий.

4. Обновление прав роли

• Основной сценарий: администратор отправляет пакет переключателей "роль–право" для приведения доступа в соответствие с политикой.
• Краевые случаи: дублирующиеся переключения в запросе устраняются; некорректные комбинации ролей и прав отклоняются с понятным сообщением; частичные сбои не приводят к нек консистентным данным.
• Критерии приемки:
  • Перед обработкой проверяется право на управление разрешениями.
  • Каждый переключатель приводит либо к добавлению, либо к удалению права, и хранилище отражает изменения сразу после успешного ответа.
  • После успешного изменения система обновляет кеши ролей, чтобы последующие чтения были актуальными.
  • При ошибке не происходит побочных эффектов, а клиент получает объяснение причины.

5. Добавление новой роли

• Основной сценарий: администратор создаёт новую роль под новую область ответственности.
• Краевые случаи: идентификаторы ролей регистронезависимы и сохраняются в верхнем регистре; пробелы удаляются; дубликаты отклоняются с понятной ошибкой.
• Критерии приемки:
  • Перед созданием проверяется право на администрирование ролей.
  • Новая роль автоматически получает базовое право на чтение, чтобы быть доступной сразу.
  • Ответ об успехе возвращается только после сохранения роли и обновления кешей.

6. Удаление существующей роли

• Основной сценарий: администратор удаляет роль, которая больше не требуется.
• Краевые случаи: системные роли (например, роль конечного пользователя или супер-администратора) защищены от удаления; попытка удалить используемую роль возвращает контекстную ошибку из слоя данных.
• Критерии приемки:
  • Перед удалением проверяется право на администрирование ролей.
  • Защищённые роли нельзя удалить, и ответ явно сообщает причину.
  • Успешное удаление инициирует обновление кешей, чтобы роль исчезла из последующих чтений.

7. Определение ролей-апруверов для заявок

• Основной сценарий: движок рабочих процессов или отчётность запрашивает роли, которые могут одобрять заявки определённого типа (топики, подписки, схемы, коннекторы), чтобы маршрутизировать процесс и анализировать SLA.
• Краевые случаи: неподдерживаемые типы заявок возвращают пустой набор; арендаторы без настроенных апруверов возвращают пустой набор и логируют аномалию; права, общие для нескольких типов заявок (например, использование прав схем для коннекторов), документируются для потребителей.
• Критерии приемки:
  • В ответ включаются только роли, у которых явно включено соответствующее право на одобрение.
  • Список содержит уникальные идентификаторы ролей без дубликатов.
  • Операция выполняется без повышенных прав, так как использует кэшированные данные о разрешениях.

Сквозные требования

• Мультиарендность: каждая операция определяет арендатора отправителя перед чтением или изменением данных ролей; кросс-арендный доступ запрещён.
• Аудит: отказы в авторизации, некорректные запросы и ошибки бэкенда логируются с контекстом арендатора и отправителя (без чувствительных данных).
• Устойчивость: отказ слоя данных приводит к информативной ошибке без раскрытия стек-трейсов; частичные обновления не фиксируются.
• Консистентность: при любом изменении ролей или прав кеши обновляются, чтобы исключить устаревшие данные.
• Безопасность: дефолтные fallback-ответы не раскрывают привилегированные права, а базовые защищённые роли остаются неизменяемыми.