ym88659208ym87991671
Настройка разрешений | Документация для разработчиков

Настройка разрешений

Обновлено 16 декабря 2022

В DataSpace реализована возможность разграничения прав в разрезе GraphQL-запросов. Разграничение прав определяется фиксацией специальных правил (далее — разрешений) для каждого отдельного GraphQL-запроса.

note

На вкладке Детали можно увидеть точки доступа (endpoints) после выпуска модели.

В текущем разделе рассмотрены правила работы с разрешениями, проверка которых осуществляется через точку доступа "jwt graphql".

Общая схема работы

Ниже представлена общая схема работы системы разграничения прав:

img

Интерфейс настройки разрешений

После выпуска модели предоставлена возможность фиксации разрешений для отдельных GraphQL-запросов на вкладке Разрешения.

Для создания разрешения нажмите кнопку Добавить разрешение. Откроется окно для создания нового разрешения, где имеется возможность задать следующие параметры:

  • Тело GraphQL-запроса создаваемого разрешения.
  • Справа от тела запроса доступны поля, соответствующие переменным, передающимся на вход в запрос. В данных полях имеется возможность отразить дополнительные условия (additionalParam) фильтрации для запросов типа query (см. раздел "Синтаксис условий проверок и дополнительных фильтраций").
  • Флаг Разрешить без проверок — при установке данного флага никакие дополнительные проверки для данного разрешения не будут производиться. Если флаг Разрешить без проверок не установлен, то необходимо явно указать набор проверок (checkSelects), которые будут выполняться последовательно, задав значения в следующих полях:
    • Описание проверки — текстовое описание проверки.
    • Условие — логика проверки (см. раздел "Синтаксис условий проверок и дополнительных фильтраций").
    • Тип — имя типа (сущности) модели данных, относительно которой необходимо применить зафиксированное условие. Для добавления проверки нажмите кнопку Добавить условие.
  • Флаг Отключить проверку JWT — установка флага отключает проверку корректности JWT-запроса загруженным в систему JWKS.

Для сохранения разрешения нажмите кнопку Сохранить.

На рисунке представлен пример заполнения параметров разрешения:

img

На примере GraphQL-запрос searchOrder доступен только пользователям с ролью customer. Об этом говорит соответствующая проверка с условием 'customer' $in ${[]:jwt:realm_access.roles}. За счет дополнительных условий фильтрации it.customer.entityId == ${jwt:email} обратно будут возвращены только заказы пользователя, совершившего запрос.

Также на вкладке Разрешения имеются следующие элементы интерфейса:

  • Кнопка Импорт/Экспорт разрешений позволяют осуществить выгрузку/загрузку разрешений через файл.
  • Кнопка Перезагрузить запросы позволяет осуществить перезагрузку тел запросов по их имени с сохранением ранее зафиксированных правил разрешений. Данная опция полезна в процессе разработки, когда тела запросов часто меняются и необходимо обновить соответствующие разрешения, сохранив ранее выставленные для них флаги и проверки.
  • Кнопка Загрузить JWKS позволяет осуществить загрузку JWKS в формате JSON.

Синтаксис условий проверок и дополнительных фильтраций

Логика условий проверок (checkSelects) и дополнительных фильтраций (additionalParams) в разрешениях описывается той же грамматикой строковых выражений, что и фильтрация в поисковых GraphQL-запросах.

Доступ к содержимому JWT реализован посредством конструкции ${jwt:...}. При этом:

  • Если принимаемый тип данных не является строкой, его необходимо указать явно, например ${Long:jwt:iat}.
  • Если тип данных является массивом примитивов, необходимо после типа данных указать символы [], например ${Integer[]:numbers}.
  • Для строк имя типа можно не указывать, например, ${[]:jwt:realm_access.roles}.

Категории пользователей (субъекты доступа)

Определены три категории потребителей сервиса DataSpace:

  • Администратор системы (Admin) — пользователь, определяющий политики и правила безопасности в рамках системы разграничения прав. Основные задачи:
    • Управление внешней по отношению к DataSpace системой аутентификации и управления доступом (далее — IAM). Основные задачи администратора в рамках управления IAM-системой:
      • Управление пространствами (realms).
      • Управление приложениями-клиентами (clients).
      • Управления пользователями (users) и их ролями (roles).
      • Получение сертификатов (certs) для дальнейшей загрузки в системы DataSpace.
    • Конфигурирование системы разграничения доступа на стороне DataSpace (в режиме разработки/тестирования/отладки приложения) — загрузка сертификатов (certs) для проверки корректности JWT. В данном документе правила настройки IAM не рассматриваются. Для работы можно воспользоваться одной из реализаций IAM keycloack.
    • Формирование правил проверки GraphQL-запросов (объектов доступа) на основании содержимого JWT и бизнес-правил конкретной реализации системы DataSpace.
  • Пользователь системы (User) — потребитель основных функций DataSpace посредством GraphQL-запросов. Основные задачи:
    • Аутентификация в IAM для получения JWT и дальнейшего использования в обращении к DataSpace.
    • Осуществление GraphQL-запросов к системе DataSpace с использованием JWT, полученного шагом ранее при успешной аутентификации в IAM.
  • Backend-приложение (Backend App) — приложение, имеющее доступ к данным DataSpace на чтение/запись посредством запросов GraphQL/Json RPC на основе backend-авторизации (application key/secret key).

Алгоритм проверки разрешений

Алгоритм проверки GraphQL-запроса:

  1. По имени входящего GraphQL-запроса определяется наличие соответствующего разрешения.
  2. Если разрешение найдено, сверяется на идентичность входящий запрос и запрос в разрешении.
  3. Если запросы идентичны, запускается проверка правил для найденного разрешения:
    1. Проверяется необходимость проверки JWT по JWKS (при необходимости проверка по ранее загруженному в систему набору JWKS производится). По умолчанию соответствующий флаг disableJwtVerification не установлен.
    2. Проверяется необходимость явного наличия проверок (checkSelects) на разрешение выполнения запроса. По умолчанию соответствующий флаг enableWithoutChecks не установлен:
      1. Если флаг enableWithoutChecks не установлен, последовательно выполняются все указанные для разрешения проверки.
      2. Если все проверки пройдены, выполнение запроса разрешается, в противном случае выполнение запрещено.
      3. К переменным запроса, фильтрующим запрашиваемую выборку, добавляются обязательные дополнительные ограничения additionalParams.

Ниже представлена блок-схема алгоритма:

img

Заметили ошибку?

Выделите текст и нажмите Ctrl + Enter, чтобы сообщить нам о ней