- Введение
- Обзор Apache APISIX
- Обзор плагина OpenID Connect
- Централизованный поток аутентификации с IDP
- Поток входа
- Поток доступа
- Поток сеансов
- Предварительные условия
- Установите Apache APISIX
- Конфигурация Azure AD
- Конфигурация плагина OIDC
- Тестирование плагина OIDC
- Проверка потока от службы к службе
- Шаг 1: Сбор маркера из Azure AD
- Шаг 2: Запросите конечную точку с помощью токена
- Проверить поток входа в систему
- Резюме
Введение
В этой статье блога рассказывается о том, как использовать проект с открытым исходным кодом 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 этапа: вход, доступ и поток сессии:
Поток входа
- Клиентский сервис запрашивает доступ к API-шлюзу APSIX.
- APISIX инициирует аутентификацию, перенаправляя запрос клиента к провайдеру идентификации, в нашем случае это Azure AD.
- Пользователь входит в систему и аутентифицируется в Azure AD.
- IDP Azure AD возвращается на API-шлюз APISIX с кодом авторизации и перенаправляет запрос клиента обратно на APISIX.
Как видно из диаграммы, APISIX не позволяет неаутентифицированным запросам проходить к восходящим сервисам (бэкенд-сервисам).
Поток доступа
- APISIX запрашивает поставщика идентификационных данных с кодом авторизации, полученным из параметров запроса в предыдущем потоке.
- IDP отправляет APISIX ответное сообщение с маркером доступа.
- После проверки токена APISIX отправляет информацию о пользователе внутренним службам. Внутренние сервисы принимают соединения только от API Gateway.
Поток сеансов
До сих пор аутентификация уже произошла, и на последующих этапах клиентское приложение может напрямую запрашивать APISIX без дублирующей проверки в OKTA с помощью токена доступа до тех пор, пока не истечет сессия запроса. Тем не менее, вышестоящие сервисы должны уметь обрабатывать пользовательские заголовки с информацией о пользователе.
Предварительные условия
Прежде чем использовать плагин OIDC с Azure AD, мы должны подготовить несколько вещей.
Установите Apache APISIX
Существует множество способов установить и запустить APISIX. Смотрите руководство по установке.
Для этого демо я использовал просто вариант сборки с помощью docker-compose.
Конфигурация Azure AD
- Создайте учетную запись Azure с активной подпиской. Создайте учетную запись бесплатно.
- Зарегистрируйте приложение на платформе идентификации Microsoft. См. раздел Регистрация приложения.
- Добавьте клиентский секрет для вашего приложения. См. инструкцию по добавлению нового клиентского секрета на портале Azure. Скопируйте сгенерированный клиентский секрет и сохраните его где-нибудь, чтобы позже использовать его для настройки плагина OIDC. Значение этого секрета больше никогда не будет отображаться после того, как вы покинете эту страницу.
- Обновите Manifest в представлении приложения, обновите accessTokenAcceptedVersion до 2 (по умолчанию null). См. раздел Настройка манифеста APP.
- Добавьте 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
📧 Пишите нам со своими вопросами