7.5. Схема работы аутентификации и авторизации #
Существует три типа взаимодействия, для которых требуется аутентификация и авторизация в процессе работы менеджера:
Все взаимодействия осуществляются с помощью протокола HTTP или HTTPS в зависимости от параметров PPEM.
7.5.1. Пользователь → Менеджер #
В рамках этого типа взаимодействия пользователи работают в веб-приложении.
7.5.1.1. Пользователь → менеджер: аутентификация #
Пользователь отправляет конечной точке (endpoint) менеджера запрос API POST /v1/sessions, чтобы получить токены доступа и обновления (access token и refresh token) для дальнейшей работы. Запрос API содержит учётные данные пользователя.
В базовом сценарии учётные данные проверяются в репозитории. При использовании аутентификации LDAP учётные данные сначала проверяются в службе каталогов, затем, если они не были обнаружены, выполняется проверка в репозитории.
7.5.1.2. Пользователь → менеджер: авторизация #
При успешной аутентификации дальнейшие запросы HTTP/HTTPS к менеджеру от пользователей содержат заголовок Authorization, в котором после ключевого слова Bearer через пробел указывается текст токена доступа, например:
headers: Content-Type: application/json Authorization: "Bearer eyJhbG..."
Предоставляемый доступ определяется с помощью ролевой модели доступа RBAC (Role Based Access Control, RBAC) в соответствии с назначенными пользователю ролями:
Пользователям PPEM роли можно назначить напрямую или через группы PPEM, в которых они состоят.
LDAP-пользователям роли назначаются только через группы PPEM, в которых они состоят.
Чтобы добавить пользователя LDAP в группу PPEM, администратору необходимо сопоставить отличительное имя (distinguished name, DN) группы LDAP этого пользователя с именем группы PPEM. После этого пользователь будет автоматически добавлен в группу PPEM при входе в веб-приложение.
Состав групп пользователей периодически сверяется с сервером LDAP и при необходимости обновляется.
За подробной информацией о сопоставлении групп LDAP и групп PPEM обратитесь к Главе 25.
7.5.2. Менеджер → агент #
В рамках этого типа взаимодействия менеджер отправляет агентам пакеты команд API для выполнения различных операций.
7.5.2.1. Менеджер → агент: аутентификация #
Менеджер отправляет конечной точке агента запрос API POST /v1/sessions, чтобы получить токены доступа и обновления для дальнейшей работы. Запрос API выполняется по URL для подключения агента к менеджеру из репозитория и содержит два параметра:
name: имя агента из репозитория.api_key: API-ключ для подключения агента к менеджеру из репозитория.
7.5.2.2. Менеджер → агент: авторизация #
При успешной аутентификации дальнейшие запросы HTTP/HTTPS к агентам от менеджера содержат заголовок Authorization, в котором после ключевого слова Bearer через пробел указывается текст токена доступа, например:
headers: Content-Type: application/json Authorization: "Bearer eyJhbG..."
Агент проверяет подлинность токена доступа менеджера. Для этого агент генерирует токен на основании известных ему значений параметров name и api_key. Если сгенерированный и полученный токен совпадают, аутентификация считается успешной. Если подлинность подтверждена и запрашиваемая конечная точка найдена, дальнейшая работа разрешается.
7.5.3. Агент → менеджер #
В рамках этого типа взаимодействия агенты отправляют менеджеру отчёты о выполнении команд API, а также обновления информации об объектах обслуживаемых экземпляров.
7.5.3.1. Агент → менеджер: аутентификация #
Агент отправляет конечной точке менеджера запрос API POST /v1/sessions, чтобы получить токены доступа и обновления для дальнейшей работы. Запрос API выполняется по URL для подключения агента к менеджеру, который указан в файле конфигурации агента ppem-agent.yml с помощью параметра agent.manager.url. Запрос API содержит два параметра:
name: имя агента, которое указано в файле конфигурации агентаppem-agent.ymlс помощью параметраagent.name.api_key: ключ API для подключения агента к менеджеру, который указан в файле конфигурации агентаppem-agent.ymlс помощью параметраagent.manager.api_key.
7.5.3.2. Агент → менеджер: авторизация #
При успешной аутентификации дальнейшие запросы HTTP/HTTPS к менеджеру от агента содержат заголовок Authorization, в котором после ключевого слова Bearer через пробел указан текст токена доступа, например:
headers: Content-Type: application/json Authorization: "Bearer eyJhbG..."
Менеджер проверяет подлинность токена доступа агента. Для этого менеджер генерирует токен на основании известных ему значений параметров name и api_key. Если сгенерированный и полученный токен совпадают, аутентификация считается успешной. Если подлинность подтверждена и запрашиваемая конечная точка найдена, дальнейшая работа разрешается.
Предоставляемый доступ определяется указанными в коде PPEM правилами доступа агента к ресурсам менеджера.
7.5.4. Время жизни токенов доступа и обновления #
Время жизни токенов доступа и обновления ограничено. Его можно указать в файле конфигурации менеджера ppem-manager.yml или агента ppem-agent.yml с помощью параметров jwt.lifetime.access и jwt.lifetime.refresh.
Когда время жизни токена доступа истекает, менеджер или агент начинает отвечать владельцу токенов ошибкой «401 Unauthorized» с кодом «ERR_AUTH_TOKEN_EXPIRED», например:
{
"error":{
"code":"ERR_AUTH_TOKEN_EXPIRED",
"title":"token is expired"
}
}Чтобы получить новый токен доступа, владельцу токенов необходимо отправить конечной точке запрос API PUT /v1/sessions с токеном обновления, который был получен вместе с устаревшим токеном доступа. В результате будут получены новые токены доступа и обновления, которые можно использовать для дальнейшей работы.
Если время жизни токена обновления также истекло, владельцу токенов необходимо повторно пройти аутентификацию.