Безопасность API с OIDC с помощью Apache APISIX и Microsoft Azure AD


Введение

В этой статье блога рассказывается о том, как использовать проект с открытым исходным кодом Apache APISIX и OpenID Connect (OIDC) Plugin для Azure Active Directory (Azure AD) в качестве поставщика идентификационных данных. Она содержит концептуальное введение в Apache APISIX и его OIDC Plugin. В нем также содержатся подробные пошаговые инструкции по настройке APISIX OpenID Connect Plugin для защиты вашего API.

Обзор Apache APISIX

Apache APISIX – это легкий шлюз API с открытым исходным кодом, который размещается перед вашими вышестоящими службами. Простой в настройке и быстрый в развертывании, API-шлюз APISIX служит центральной точкой для маршрутизации всех входящих запросов по назначению, будь то вышестоящий API-сервер, сторонний сервис, база данных или даже бессерверный. Шлюз API дополнен бесчисленными встроенными плагинами для обработки аутентификации, авторизации, управления трафиком и безопасности. Мы будем использовать один из них – APISIX OpenID Connect Plugin.

Обзор плагина OpenID Connect

OpenID Connect (OIDC) – это централизованный режим аутентификации личности. Преимущество использования OpenID Connect заключается в том, что пользователям нужно только зарегистрироваться и войти в систему на сайте одного поставщика идентификационных данных OpenID Connect, например Azure AD, и использовать пароль одной учетной записи для доступа к различным приложениям. OpenID Connect Plug-in для Apache APISIX поддерживает OIDC для упрощения процесса разработки и повышения безопасности на уровне шлюза API. Он самостоятельно взаимодействует с поставщиком идентификационных данных и может перехватывать неаутентифицированные запросы к внутренним приложениям.

Централизованный поток аутентификации с IDP

Когда мы используем плагин OIDC вместе с любым провайдером идентификации (помимо Azure AD, существует множество провайдеров IDP, таких как Okta и AWS Cognito), обычно поток аутентификации делится на 3 этапа: вход, доступ и поток сессии:

Поток входа

  1. Клиентский сервис запрашивает доступ к API-шлюзу APSIX.
  2. APISIX инициирует аутентификацию, перенаправляя запрос клиента к провайдеру идентификации, в нашем случае это Azure AD.
  3. Пользователь входит в систему и аутентифицируется в Azure AD.
  4. IDP Azure AD возвращается на API-шлюз APISIX с кодом авторизации и перенаправляет запрос клиента обратно на APISIX.

Как видно из диаграммы, APISIX не позволяет неаутентифицированным запросам проходить к восходящим сервисам (бэкенд-сервисам).

Поток доступа

  1. APISIX запрашивает поставщика идентификационных данных с кодом авторизации, полученным из параметров запроса в предыдущем потоке.
  2. IDP отправляет APISIX ответное сообщение с маркером доступа.
  3. После проверки токена APISIX отправляет информацию о пользователе внутренним службам. Внутренние сервисы принимают соединения только от API Gateway.

Поток сеансов

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

Предварительные условия

Прежде чем использовать плагин OIDC с Azure AD, мы должны подготовить несколько вещей.

Установите Apache APISIX

Существует множество способов установить и запустить APISIX. Смотрите руководство по установке.
Для этого демо я использовал просто вариант сборки с помощью docker-compose.

Конфигурация Azure AD

  1. Создайте учетную запись Azure с активной подпиской. Создайте учетную запись бесплатно.

  1. Зарегистрируйте приложение на платформе идентификации Microsoft. См. раздел Регистрация приложения.

  1. Добавьте клиентский секрет для вашего приложения. См. инструкцию по добавлению нового клиентского секрета на портале Azure. Скопируйте сгенерированный клиентский секрет и сохраните его где-нибудь, чтобы позже использовать его для настройки плагина OIDC. Значение этого секрета больше никогда не будет отображаться после того, как вы покинете эту страницу.

  1. Обновите Manifest в представлении приложения, обновите accessTokenAcceptedVersion до 2 (по умолчанию null). См. раздел Настройка манифеста APP.

  1. Добавьте URI перенаправления в ваше приложение. Это будет URI, который вы позже укажете в свойстве плагина OIDC при настройке маршрута. Вы можете добавить его через раздел Аутентификация в настройках приложения. См. следующий раздел Добавить URI перенаправления. Например, это может быть https://httpbin.org/get или https://127.0.0.1/get. Убедитесь, что он начинается с HTTPS и соответствует атрибуту redirect_uri плагина openid-connect.


Конфигурация плагина OIDC

Когда все готово, мы можем настроить плагин OIDC для маршрута. Мы используем команду curl для создания нового маршрута и включения плагина OIDC для него. Вы можете изменить приведенную ниже конфигурацию маршрута, используя свои значения:

curl  -XPOST 127.0.0.1:9080/apisix/admin/routes -H "X-Api-Key: edd1c9f034335f136f87ad84b625c8f1" -d 
'{
    "uri":"/*",
    "plugins":{
        "openid-connect":{
            "client_id":"<YOUR_CLIENT_ID>",
            "client_secret":"<YOUR_CLIENT_SECRET>",
            "discovery":"https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0/.well-known/openid-configuration",
            "scope":"YOUR_CLIENT_ID/.default",
            "bearer_only":false,
            "redirect_uri":"https://httpbin.org/get"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "httpbin.org:80":1
        }
    }
}'
Войти в полноэкранный режим Выйти из полноэкранного режима

Приведенный выше пример кода создает маршрут через Apache APISIX Admin API, устанавливая цели восходящего потока маршрута на httpbin.org. Это простой имитатор бэкенд-сервиса для получения и ответа на запросы. Давайте рассмотрим некоторые свойства плагина openid-connect:

Поле Описание
client_id Идентификатор клиента приложения, зарегистрированного в Azure ранее. Определите YOUR_CLIENT_ID с идентификатором клиента, показанным на странице обзора приложения.
client_secret Секрет клиента – это секрет, который вы создали для приложения. Приложение использует его для подтверждения своей идентичности при запросе маркера из Azure AD. Замените YOUR_CLIENT_SECRET на секрет, созданный ранее в разделе Сертификаты & секреты.
scope Область применения api вашего приложения
discovery Конечная точка обнаружения службы для поставщиков идентификационных данных. Значение поля discovery можно получить, нажав кнопку Endpoints на странице Overview регистрации вашего приложения.
redirect_uri URI, на который Azure AD IDP перенаправляет обратно, по умолчанию на адрес запроса после успешной аутентификации. Это должен быть URI, который вы указали ранее при настройке вашего приложения.

В этом примере плагин принудительно устанавливает объект маркера доступа в заголовке авторизации запроса при попытке доступа к маршруту.

О других элементах конфигурации читайте в Apache APISIX OpenID Connect Plugin.

Тестирование плагина OIDC

До этого момента мы представили новый маршрут с включенным плагином OIDC и определили конфигурацию плагина для провайдера идентификации Azure AD. Теперь вы можете следовать этим инструкциям для тестирования потоков аутентификации для двух различных сценариев использования. Один – это взаимодействие между службами, где запросчик может получить токен от Azure AD в самой реализации клиентского кода и управлять этим токеном для доступа к вышестоящей службе. В другом случае клиент или запросчик – это человек, взаимодействующий через веб-браузер.

Проверка потока от службы к службе

Шаг 1: Сбор маркера из Azure AD

curl -X POST https://login.microsoftonline.com/<your_tenant_id>/oauth2/v2.0/token 
--data scope="<your_client_id>/.default" 
--data grant_type="client_credentials" 
--data client_id="<your_client_id>" 
--data client_secret="<your_client_secret>"  

Войдите в полноэкранный режим Выйти из полноэкранного режима

Шаг 2: Запросите конечную точку с помощью токена

Вы будете использовать токен, полученный на шаге выше, и установите его в заголовок авторизации запроса:

curl -i -X GET http://127.0.0.1:9080/get -H "Host: httpbin.org" -H "Authorization: <token_from_azure_ad>"
Войти в полноэкранный режим Выйти из полноэкранного режима

Проверить поток входа в систему

Зайдите на http://127.0.0.1:9080 в браузере, и страница будет перенаправлена на страницу входа в Azure AD, поскольку плагин OpenID Connect уже включен.

Страница входа в Azure AD также может быть настроена. См. раздел Добавление брендинга на страницу входа вашей организации.

Вы можете аутентифицироваться с помощью учетных данных пользователя, которые также используются для создания учетной записи Azure. После успешной аутентификации вы будете перенаправлены на URI перенаправления, который мы указали ранее в конфигурации маршрута и аутентификации приложения https://httpbin.org/get.

Резюме

Мы обнаружили еще одно продвинутое использование APISIX в качестве централизованного обработчика аутентификации и авторизации. Apache APISIX имеет 10+ плагинов, связанных с безопасностью, которые могут справиться со многими проблемами безопасности API. Чтобы узнать больше, перейдите на сайт Apache APISIX Plugin hub.

Чтобы узнать больше⤵️

➔ Скачать Apache APISIX

➔ Установите Apache APISIX

➔ Посмотрите видеоурок “Начало работы с Apache APISIX

➔ Смотреть видеоурок Начало работы с панелью управления Apache APISIX

➔ Смотреть видеоурок Централизованная аутентификация с помощью плагинов Apache APISIX

Сообщество⤵️

🙋 Присоединяйтесь к сообществу Apache APISIX
🐦 Следите за нами в Twitter
📝 Найдите нас в Slack
📧 Пишите нам со своими вопросами

Оцените статью
Procodings.ru
Добавить комментарий