#azure #asp.net-core #oauth #azure-api-management #azure-policy
#azure #asp.net-core #oauth #azure-api-управление #azure-политика
Вопрос:
Я вижу из документов Microsoft, они предоставляют только эти 3 basic, certificate и MSI в политике. https://learn.microsoft.com/en-us/azure/api-management/api-management-authentication-policies#AuthenticationPolicies
Означает ли это, что я не могу выполнить OIDC?
Ответ №1:
КРАТКИЙ ОТВЕТ: никаких изменений в управлении API, если вы меняете аутентификацию пользователей API с помощью внутреннего API.
Ниже приведен длинный ответ, объясняющий, как политики аутентификации не связаны с аутентификацией пользователя API.
Базовая концепция
Управление API находится в центре вашего API и вашего потребителя.
С точки зрения терминологии ваш API в этом случае вызывается как внутренний API. Интерфейс API — это URL-адрес управления API, которым можно поделиться с вашим потребителем.
Обратитесь к этой странице для получения дополнительной базовой терминологии об управлении API.
На мой взгляд, есть два разных вопроса: один о проверке подлинности пользователя OAuth и другой о том, какую политику аутентификации необходимо настроить в APIM.
Проверка подлинности потребителя
Итак, если вы хотите, чтобы ваш потребитель прошел проверку подлинности с использованием аутентификации JWT или аутентификации OAuth, процедура проста. Потребитель получит токен аутентификации из службы идентификации, а затем использует этот токен для вызова вашего API.
Пока вы не измените его с помощью политик управления API, он должен работать. Для управления API не требуется знать полномочия или какие-либо другие сведения о полномочиях.
Политики аутентификации APIM
В зависимости от вашего дизайна вы можете выбрать, должен ли внутренний API (т. Е. API, Который вы разместили в APIM) иметь логику для аутентификации интерфейсного API — чтобы убедиться, что только известная сторона вызывает ваш API.
Согласно документации, вы можете настроить :
- Базовая политика аутентификации и отправка имени пользователя и пароля с каждым запросом в серверный API
- Политика проверки подлинности сертификата и отправка отпечатка сертификата с каждым запросом в серверный API
- Управляемая идентификация для использования проверки подлинности Azure AD.
Все эти три политики просто помогают вашему серверному API обеспечить идентификацию вызывающего абонента (в данном случае APIM Fronend API). Это не имеет ничего общего с аутентификацией потребителя и OAuth.
Например Вы можете настроить свой API таким образом, чтобы пользователь должен был пройти проверку подлинности с помощью аутентификации Facebook. Кроме того, у вас может быть проверка подлинности сертификата, чтобы определить, что только действительный экземпляр APIM перенаправляет запрос потребителя из интерфейсного API на внутренний API.
Надеюсь, это прояснит ситуацию.
Комментарии:
1. Я думаю, что ответ по-прежнему актуален. Если вы хотите вызвать какой-либо сторонний API, который защищен из-за какой-либо другой аутентификации, вы должны вызвать его из кода, а не настраивать что-либо в APIM, поскольку политики APIM имеют значение только для вашего внутреннего API. Политики аутентификации APIM применимы только для связи между APIM и вашим API, а не сторонним API. Надеюсь, это прояснит ситуацию.
Ответ №2:
Как сказано в статье:
Если ваш внутренний API уже защищен с помощью OAuth2.0 с использованием любой платформы, тогда потребители API должны передать заголовок авторизации в управление API. Вам не нужно добавлять какую-либо политику в управление API. Заголовок будет отправлен потребителем API, а управление API отправит тот же заголовок в серверный API.
Используйте базовую аутентификацию и задайте заголовок вручную.
<authentication-basic username="username" password="password" />
<set-header name="Authorization" exists-action="override">
<value>@("Bearer " (string)context.Variables["token"])</value>
</set-header>