Авторизация

Процесс авторизации (authorization) определяет, какие действия субъект может выполнять над ресурсами после успешной аутентификации. Он отвечает на вопрос: «Можно ли сделать это?». Результатом авторизации является принятие решения о доступе на основе субъекта, действия, ресурса и политик.

Авторизация является одним из этапов контроля доступа. Контроль доступа в Spirit IAM обеспечивает Identity & Access Proxy.

Этапы авторизации

1. Определение субъекта

Кто запрашивает доступ? (пользователь или сервисный аккаунт)

Субъект и все его параметры определяются внутри Identity & Access Proxy на этапе аутентификации и передаются в движок авторизации в виде JSON-объекта.

2. Определение действия

Что хочет сделать субъект?

Над разными ресурсами могут быть выполнены разные действия: чтение, запись, создание, удаление. Операции, которые можно выполнять над ресурсом, зависят от типа ресурса. В Spirit IAM нет фиксированного списка доступных операций. Например, в API-эндпоинтах в качестве операций часто используют HTTP-глаголы: GET, POST, PUT, DELETE, ....

3. Определение ресурса

К какому ресурсу применяется действие? (файл, API, база данных, конфигурация).

Примечание

Действие и ресурс в Spirit IAM в явном виде определяются при написании правил внутри политики. Эти данные извлекаются из запроса, который передается в движок авторизации в виде JSON-объекта.

4. Проверка политик доступа

Система сверяется с правилами (политиками), чтобы решить, разрешено ли действие.

Этот этап реализован внутри Identity & Access Proxy в движке запуска политик. Основным движком политик является opa_builtin. Это Open Policy Agent (OPA), встроенный в IAP в виде библиотеки.

5. Валидация токенов

При обработке запроса в Spirit IAM каждый токен проходит пошаговую проверку, прежде чем по нему будет принято решение о доступе. Ниже описан общий алгоритм проверки токенов. Он применим как к стандартным токенам и сессиям, так и к обменным (делегированным) токенам.

Важно

Перед использованием обменных токенов добавьте Spirit IAM в issuer-whitelist значений iss: https://<spirit-iam-host>/api/v1/.

Обменные токены обрабатываются стандартными средствами Spirit Identity & Access Proxy: IAP умеет аутентифицировать и авторизовать HTTP-запросы к ресурсам с помощью обменных JWT, используя описанный ниже алгоритм. Если настроены политики авторизации по обычному токену или сессии Spirit, то они работают и для обращений с делегированными токенами.

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

1. Провалидировать JWS токена:

   • Получить набор публичных JWK из API Spirit IAM. По умолчанию он доступен по адресу: https://<spirit-iam-host>/api/v1/.well-known/jwks.json.
   • В полученном списке публичных ключей найти ключ по kid из заголовка JWT.
   • Использовать найденный публичный JWK для проверки подписи JWT.

2. Сравнить iss обменного токена с issuer-whitelist. Если Issuer неизвестен, JWT нужно считать невалидным — аутентифицировать запросы с его использованием нельзя.

3. Найти среди значений клейма aud JWT идентификатор системы или ресурса получателя токена.

4. При наличии значений в полях провалидировать unix timestamp для exp, iat и nbf JWT.

5. Убедиться, что клейм sub присутствует и не пустой.

6. По клейму sub идентифицировать identity Spirit IAM как пользователя или сервис-аккаунт.

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

8. Если act присутствует, по самому верхнему значению act.sub выполнить поиск delegation settings. Обязательно проверить, что у полученного объекта значение параметра active равно true. Если найти delegation settings не удалось или active равно false — этот JWT не принимать.

9. Если хотя бы одна проверка не прошла успешно, считать JWT недействительным и не аутентифицировать запросы с его использованием.

10. После того как JWT прошел все проверки, можно считать его валидным и перейти к процессу авторизации — проверке полномочий токена.

6. Сверка ролей с моделью Spirit IAM

Spirit IAM не доверяет слепо данным из токена, полученным от внешнего Identity Provider (например, Keycloak). Роли и группы пользователя, переданные в токене, сопоставляются с MtRBAC — моделью ролей Spirit IAM. Подробнее о механизме маппинга AD-групп на роли см. в разделе Ролевая модель MtRBAC.

7. Принятие решения

В результате принятия решения о доступе будет один из вариантов ответа:

• разрешить (allow),
• запретить (deny).