Интерактивная документация
Работа с данными
Интеграционные сервисы
Управление
Управление процессами
Служебные технологические сервисы
Предоставление кворумного ЦОД
Интеграция с инфраструктурой электронного правительства
Производственный процесс
Демопримеры
Интеграционные шлюзы
Эксплуатационная документация
Часто задаваемые вопросы
Глоссарий
Главная
Служебные технологические сервисы
Ролевая модель
Создание ролевой модели

Создание ролевой модели

Начинать разработку ролевой модели в формате компонента «Авторизация Platform V IAM» следует с общего проектирования ролевой модели прикладного сервиса. Проектирование включает:
  • исследование предметной области;
  • анализ функций потенциальных пользователей;
  • сбор требований сотрудников информационной безопасности;
  • изучение особенностей аутентификации и авторизации Платформы, протоколов OIDC, OAuth 2.0.
В результате проектирования определяются:
  • подходы, применяемые в прикладном приложении для разграничения доступа: RBAC, ABAC, их комбинация и т.д.;
  • роли и группы пользователей: например, на основе должностей или набора функций;
  • необходимость подключения внешнего поставщика учетных данных.
При разработке информационной системы, обрабатывающей внешние HTTP-запросы и, например, реализующей паттерн API Gateway Offloading, нужно определить, какие методы контроллеров будут:
  • требовать только аутентификации (не рекомендуется);
  • требовать определенного уровня авторизации (привилегии);
  • не требовать аутентификации (публичный открытый API).
Каждый непубличный метод контроллера Spring Boot должен запрашивать у пользователя наличие определенной атомарной привилегии (минимальной единицы ролевой модели). На одну привилегию может ссылаться несколько методов. Также допустимо, чтобы один метод требовал наличие одной (ИЛИ)- или нескольких (И)-привилегий. Необходимо соблюдать баланс количества привилегий.
При использовании ЕСИА нужно зарегистрировать сервис в Минкомсвязи РФ, получить сертификаты безопасности и мнемонику (уникальный идентификатор сервиса в ЕСИА). Подробнее с процедурой регистрации организации в ЕСИА и получения сертификатов и мнемоники можно ознакомиться в документах:
Нужно определить, будут ли для задач авторизации ИП/ЮЛ использоваться группы ЕСИА и их типы: непубличный, публичный. Наличие групп и их типов требует дополнительного обращения в Минкомсвязи РФ.

Особенности ролевой модели

Ролевая модель компонента «Авторизация Platform V IAM» состоит из трех ключевых объектов:
  • привилегия (action) — право пользователя на выполнение действия в информационной системе;
  • роль (role) — логическая группировка привилегий;
  • группа (group) — настройка правил сопоставления ролей и пользователей.
Ролевая модель описывается xml-документом с корневым тегом <task>. Внутри корневого элемента перечисляются объекты ролевой модели:
  • resource — ресурсы определяют и классифицируют доступные привилегии;
  • role — роли;
  • group — группы.
Структура xml-документа с ролевой моделью:
Раскрыть
При создании ролевой модели в коды объектов ролевой модели (привилегии, ресурсы, роли, группы) следует добавлять префикс с кодом тенанта: <КОД_ТЕНАНТА>.<КОД>.
Рекомендуется следить за значением атрибута subsystem при описании ролевой модели прикладного сервиса/АС. Оно должно везде быть одинаковым, включая регистр.
Файл с ролевой моделью загружается в интерфейсе администратора компонента «Авторизация Platform V IAM» нажатием кнопки «Импорт». При импорте укажите:
  • Проект (выберите свой тенант из списка);
  • Систему (выберите свойство «Целевая»).
Не забудьте загрузить файл с атрибутами (см. раздел «Атрибуты»).

Ресурсы

Создание xml-документа с ролевой моделью начинается с определения ресурсов (resource) и привилегий (action).
Ресурсы используются только для классификации и удобного отражения привилегий в интерфейсе администратора. Корневой ресурс может содержать в себе ресурс или привилегию. Не корневой ресурс может содержать только привилегию.
Атрибуты ресурса:
  • code — код, в случае дочернего ресурса указывается в формате <Код_родительского_ресурса>.<Код_дочернего_ресурса> (разделитель «точка»);
  • name — наименование ресурса, отображаемое в интерфейсе администратора;
  • subsystem — код информационной системы — владельца привилегии. Используется для классификации привилегий в интерфейсе администратора.
Атрибуты привилегии:
  • code — код, указывается в формате <Код_родительского_ресурса>.<Код_привилегии> (разделитель «точка»);
  • name — наименование атрибута, отображаемое в интерфейсе администратора;
  • category — категория пользователей, для которой применяется привилегия. Допустимо указывать несколько категорий через разделитель «,» (запятая). Используется для классификации привилегий в интерфейсе администратора. Рекомендуется придерживаться встроенного списка категорий: CLIENT_FL/CLIENT_UL/ADMIN/SOTR.
Для упрощения ролевой модели рекомендуется указывать только одну категорию — CLIENT_FL.
Код корневого ресурса укажите с префиксом. Формат: <КОД_ТЕНАНТА>.<КОД>.
Пример описания ресурсов:
Раскрыть

Роли

Роли (role) следует понимать в классическом определении ролей в RBAC. Внутри тега role задаются ссылки на привилегии через промежуточные теги permission, action-ref и channel-ref.
Атрибуты ролей:
  • code — код;
  • name — наименование роли, отображаемое в интерфейсе администратора;
  • category — категория пользователей, для которой применяется роль. Допустимо указывать несколько категорий через разделитель «,» (запятая). Используется для классификации ролей в интерфейсе администратора. Рекомендуется придерживаться встроенного списка категорий: CLIENT_FL/CLIENT_UL/ADMIN/SOTR.
  • subsystem — код информационной системы — владельца роли. Используется для классификации ролей в интерфейсе администратора.
Тег action-ref используется для ссылки на привилегию (action). Код привилегии задается в атрибуте code.
Тег channel-ref используется для ограничения применяемости привилегии внутри роли в срезе канала, через который поступил запрос в прикладной сервис. Код канала задается в атрибуте code.
Пример описания ролей:
Описание
Для упрощения ролевой модели рекомендуется:
  • указывать только одну категорию — CLIENT_FL и один канал — WEB;
  • делать соответствие один к одному ролей компонента «Авторизация Platform V IAM» с запроектированными ролями/группами информационной системы.
Код роли следует указывать с префиксом: <КОД_ТЕНАНТА>.<КОД>.

Группы

Группы задают правила сопоставления ролей с пользователем, выполняющим запрос в информационную систему, на основании характеристик (атрибутов) пользователя. Характеристиками пользователя могут быть:
  • содержимое access-токена (JWT);
  • данные от ЕСИА:
    • персональные данные;
    • признак активности учетной записи ЕСИА (требуется настройка Keycloak);
    • признак входа из-под организации (ИП/ЮЛ);
    • вхождение в определенную группу ЕСИА в выбранной организации.
Внутри тега group задаются правила сопоставления (groupCondition) и привязка ролей (role-ref). Допускается указывать как несколько правил сопоставления, так и несколько ролей. Для успешного сопоставления необходимо выполнение всех условий.
Атрибуты групп:
  • code — код;
  • name — наименование атрибута группы, отображаемое в интерфейсе администратора;
  • category_code — категория пользователей, для которой применяется группа. Допустимо указывать несколько категорий через разделитель «,» (запятая). Используется для классификации группы в интерфейсе пользователя. Рекомендуется придерживаться встроенного списка категорий: CLIENT_FL/CLIENT_UL/ADMIN/SOTR.
  • subsystem — код информационной системы — владельца роли. Используется для классификации ролей в интерфейсе администратора;
  • enabled — признак доступности группы.
Условия сопоставления (groupCondition) — описывают логическое выражение, успешное выполнение которого позволит сопоставить роли с пользователем. При описании условий сопоставления укажите:
  • attr_name — название атрибута пользователя, значение которого будет являться левым операндом логического выражения. Вычисленное значение превращается в список строк, разделитель — «,». Для корректной работы убедитесь, что атрибут создан (объявлен) в компоненте «Авторизация Platform V IAM» (см. раздел «Атрибуты»);
  • attr_value — целевое значение атрибута, правый операнд логического выражения. Превращается в список строк, разделитель — «,»;
  • operation — оператор сравнения, применяется к спискам строк. Возможные операторы:
    • = — левый операнд содержит все элементы правого;
    • <> — обратное от условия =;
    • IN — существует одно или большее количество общих элементов;
    • EXCLUDED — нет общих элементов;
    • CALCULATION — не используется в прикладных сервисах.
  • section_name — имя секции, в которой будет выполнен поиск значения атрибута (левого операнда). Допустимо указывать только значение KEYCLOAK_DATA.
Тег role-ref используется для ссылки на роль (role). Код роли задается в атрибуте code.
Пример описания групп:
Раскрыть
Строка левого и правого операнда разбивается в список строк с разделителем «,» (запятая). Операция в логическом выражении будет применяться именно к спискам строк. Учитывайте это при описании правил сопоставления.
Для упрощения ролевой модели рекомендуется:
  • указывать только одну категорию — CLIENT_FL;
  • делать соответствие один к одному группы и компонента «Авторизация Platform V IAM» с запроектированными ролями/группами прикладного сервиса/АС.
Код группы следует указывать с префиксом: <КОД_ТЕНАНТА>.<КОД>.

Примеры условий групп

Список примеров ниже не описывает все возможные случаи сопоставления, но позволяет понять принцип, по которому описываются выражения. Атрибуты пользователей могут быть дополнены исходя из прикладных задач:
  • при необходимости путем настройки Keycloak можно добавить в JWT-токен дополнительную информацию о пользователе и сослаться на нее как на атрибут;
  • в зависимости от указанных scope ЕСИА объем данных, участвующих в сопоставлении, может отличаться.
Список текущих доступных атрибутов JWT-токена можно посмотреть, отправив аутентифицированный запрос GET /jwt/?access=1 в IAM Proxy. Список доступных атрибутов ЕСИА можно получить, отправив запрос GET /auth/realms/{{REALM}}/protocol/openid-connect/userinfo в Keycloak на порт 8443. Доступные атрибуты будут перечислены в секции esia.
Обратите внимание, что в JWT и в ответе от ЕСИА данные описываются в формате JSON и могут содержать в себе списки и объекты. Чтобы сослаться на элемент массива или значение объекта, задайте путь в плоском виде:
  • все промежуточные узлы укажите через символ «.» (точка);
  • если в JWT значением является список, для проверки наличия элемента в списке задайте полный путь до элемента через «.» (точку). В качестве значения при этом будет указано true.
Пример
В плоском виде путь и значение будут выглядеть так:
  • realm_access.roles.EMPLOYEE = TRUE;
  • realm_access.roles.USER = TRUE;
  • emplInfo.position = Бухгалтер;
  • emplInfo.chief = FALSE;
  • emplInfo.blocked = FALSE.
Пример заполнения условий групп:
Раскрыть
Настройка trusted:
Предпросмотр
Настройка esia_id:
Предпросмотр

Атрибуты

Атрибут — объект компонента «Авторизация Platform V IAM», описывающий список доступных значений поля attr_name в groupCondition.
Свойства атрибута:
  • attributeName — название атрибута, должно совпадать с attr_name в groupCondition;
  • description — описание атрибута;
  • sessionSectionName — имя секции, к которой относится атрибут. Допустимо указывать только значение KEYCLOAK_DATA.
Пример
Файл с атрибутами загружается в интерфейсе администратора компонента «Авторизация Platform V IAM» после нажатия кнопки «Импорт справочников».
Предыдущий раздел
1.13 Авторизация Platform V IAM
Следующий раздел
Назначение ролей для внутренних привилегированных польз...
Была ли страница полезной?
© 2024