Аутентификация пользователя с помощью IdentityServer и Azure API Management - PullRequest
Новая
       32

Аутентификация пользователя с помощью IdentityServer и Azure API Management

0 голосов
/ 10 мая 2019

Мне нужна помощь со службой управления API Azure.

В настоящее время у нас есть приложение SinglePage, которое использует два Backend Services (WebApi .Net Core), размещенных в Azure. Для аутентификации и аутентификации пользователя мы используем IdentityServer (также размещенный на Azure как сервис) + SubscriptionService. Здесь IdSrv аутентифицирует пользователя, а также определяет, к каким API имеет доступ веб-приложение. SubscriptionService содержит информацию, если у пользователя есть права на данные API. Более или менее так.

Итак, поток: WebApp -> перенаправление на конечную точку IdSrv -> логин -> обратно в пользовательский интерфейс -> запросить бэкэнд с учетными данными пользователя (токен)

Теперь мы хотим добавить Azure API Management к смеси, и я изо всех сил пытаюсь это сделать ...

Изначально мы думали, что можем спрятать все, включая IdentityServer, за шлюзом управления API, но, похоже, это не имеет смысла или невозможно. Я нашел это в качестве справки: Создание токена доступа и проверка на IdentityServer4 с помощью управления API Azure , в котором второй ответ является довольно важным замечанием.

Исходя из этого, я думаю, что мне нужно оставить Клиенту использовать IdentityServer для аутентификации, поскольку для этого требуется взаимодействие с пользовательским интерфейсом, а затем каким-то образом установить глобальную политику в API-интерфейсе, чтобы авторизовать пользователя с помощью упомянутой политики отправки-запроса. А затем изменить бэкэнд для принятия токенов JWT из этой политики? Правильно ли мое мышление? Как это реализовать?

Или я должен просто пропустить заголовок авторизации из клиентского запроса через API Management?

Все эти вещи для меня новы, так что, может быть, я что-то пропустил или испортил условия ...

1 Ответ

0 голосов
/ 10 мая 2019

Способ интеграции APIM в изображение может зависеть от целей, которые вы хотите достичь с помощью APIM.Вы можете скрыть IdSrv за APIM, так как существует поток учетных данных клиента, который позволит APIM аутентифицировать / авторизовать себя для API, или вы могли бы разрешить пользователю авторизовать APIM один раз с помощью предоставления кода авторизации, а затем сохранить токены обновления и использовать их для связи с API,Но я не уверен, что это будет лучше, поскольку это немного меняет вашу систему и заставляет решать другие проблемы, например, как аутентифицировать пользователя в APIM.В некоторых случаях это может быть хорошим подходом, решать вам.

Если вы хорошо держите IdSrv лицом к пользователю, то APIM получает токен с каждым запросом.Затем вы можете иметь глобальную / API-политику в APIM, которая будет отправлять токен, полученный от пользователя, на SUbscriptionService для проверки авторизации пользователя на вызов), сделать это с политикой отправки-запроса), и либо разрешить вызов, либо отклонить его.Этот подход наиболее полезен, если вы хотите использовать другой механизм аутентификации между APIM и бэкэндом, потому что, если APIM выполняет работу по авторизации, ваш бэкэнд может избежать проверки доступа любого пользователя и вместо этого просто авторизовать APIM на все.

Посмотрите этот пример о том, как авторизовать запросы с использованием внешнего сервиса: https://docs.microsoft.com/en-us/azure/api-management/policies/authorize-request-using-external-authorizer

...