Пользователь отправляет конечной точке (endpoint) менеджера запрос API POST /v1/sessions, чтобы получить токены доступа и обновления (access token и refresh token) для дальнейшей работы. Запрос API содержит учётные данные пользователя.

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

При успешной аутентификации дальнейшие запросы HTTP/HTTPS к менеджеру от пользователей содержат заголовок Authorization, в котором после ключевого слова Bearer через пробел указывается текст токена доступа, например:

  headers:
  Content-Type: application/json
  Authorization: "Bearer eyJhbG..."

Предоставляемый доступ определяется с помощью ролевой модели доступа RBAC (Role Based Access Control, RBAC) в соответствии с назначенными пользователю ролями:

Менеджер отправляет конечной точке агента запрос API POST /v1/sessions, чтобы получить токены доступа и обновления для дальнейшей работы. Запрос API выполняется по URL для подключения агента к менеджеру из репозитория и содержит два параметра:

При успешной аутентификации дальнейшие запросы HTTP/HTTPS к агентам от менеджера содержат заголовок Authorization, в котором после ключевого слова Bearer через пробел указывается текст токена доступа, например:

  headers:
  Content-Type: application/json
  Authorization: "Bearer eyJhbG..."

Агент проверяет подлинность токена доступа менеджера. Для этого агент генерирует токен на основании известных ему значений параметров name и api_key. Если сгенерированный и полученный токен совпадают, аутентификация считается успешной. Если подлинность подтверждена и запрашиваемая конечная точка найдена, дальнейшая работа разрешается.

Агент отправляет конечной точке менеджера запрос API POST /v1/sessions, чтобы получить токены доступа и обновления для дальнейшей работы. Запрос API выполняется по URL для подключения агента к менеджеру, который указан в файле конфигурации агента ppem-agent.yml с помощью параметра agent.manager.url. Запрос API содержит два параметра:

При успешной аутентификации дальнейшие запросы HTTP/HTTPS к менеджеру от агента содержат заголовок Authorization, в котором после ключевого слова Bearer через пробел указан текст токена доступа, например:

  headers:
  Content-Type: application/json
  Authorization: "Bearer eyJhbG..."

Менеджер проверяет подлинность токена доступа агента. Для этого менеджер генерирует токен на основании известных ему значений параметров name и api_key. Если сгенерированный и полученный токен совпадают, аутентификация считается успешной. Если подлинность подтверждена и запрашиваемая конечная точка найдена, дальнейшая работа разрешается.

Предоставляемый доступ определяется указанными в коде PPEM правилами доступа агента к ресурсам менеджера.

Субъектами могут выступать:

Объектами могут выступать как ресурсы, так и представления ресурсов в репозитории, например серверы, агенты, экземпляры, пользователи и группы пользователей.

При первом запуске PPEM выполняется инициализация репозитория, при которой заполняются служебные таблицы (права и роли).

При инициализации для каждого плагина устанавливается свой набор прав, ролей и отношений «роль-право». Например, для плагина accounts создаются свои права и роли для управления доступом к объектам этого плагина. Для других плагинов также создаются свои наборы прав и ролей для управления доступом к объектам этих плагинов.

При наличии необходимых прав пользователи могут создавать пользовательские роли, указывать наборы прав, связывать роли с объектами и назначать пользовательские роли субъектам.

Таблица имеет следующие поля:

Таблица заполняется менеджером с помощью миграций. Каждый плагин определяет собственный набор прав.

Для проверки прав используется HTTP middleware-обработчик. Создание, изменение и удаление прав пользователем не предусмотрено, так как проверка прав реализуется в коде менеджера.

Таблица имеет следующие поля:

Роли создаются менеджером с помощью миграций. Базовый набор ролей устанавливается для плагина accounts.

Пользователь через API менеджера может создавать, изменять и удалять пользовательские роли, но не может изменять или удалять роли, установленные менеджером (системные роли).

Таблица устанавливает связи между ролями и правами и имеет следующие поля:

Класс объекта определяется по значению поля privileges.class. Объявленный здесь идентификатор объекта ограничивает действие права, указанного в role_privileges.privilege, одним объектом и разрешает доступ к объекту только участникам одной роли, указанной в role_privileges.role (доступ разрешён пользователям в user_roles.user, у которых user_roles.role = role_privileges.role).

Комбинация role, privilege и object является уникальным ключом с условием object IS NOT NULL.

Таблица не имеет полей, имеющих отношение к RBAC. При создании пользователя через API менеджера можно указать список идентификаторов ролей, которые будут назначены пользователю.

Таблица устанавливает связи между пользователем и ролями и имеет следующие поля:

Класс объекта определяется по значению поля privileges.class. Объявленный здесь идентификатор объекта ограничивает действие права, указанной в role_privileges.privilege, одним объектом и разрешает доступ к объекту пользователю, указанному в user_roles.user.

Это представление показывает пользователей с ролями и правами и позволяет проверять права конкретного субъекта:

Таблица не имеет полей, имеющих отношение к RBAC.

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

Таблица устанавливает связи между группами и ролями и имеет следующие поля:

Класс объекта определяется по значению поля privileges.class. Объявленный здесь идентификатор объекта ограничивает действие права, указанного в role_privileges.privilege, одним объектом и разрешает доступ к объекту пользователю, указанному в group_roles.role_id.

Таблица устанавливает связи между группами и пользователями и имеет следующие поля:

Отношения «группа-пользователь» не имеют объектных привязок.