Интеграция с Azure AD, Angular Spa и микросервисами Spring
Мы используем Azure AD для аутентификации и авторизации. В нашем угловом спа-центре включен единый вход с Azure AD. Нам нужно защитить наш бэкэнд service и разрешить только API, у которого есть действующий токен jwt.
Что мы уже сделали:
Зарегистрировали наше угловое приложение в Azure AD.
Мы настроили микросервис Spring как сервер ресурсов и свойства приложения содержат jwt.issuer-uri
spring.security.oauth2.resourceserver.jwt.issuer-uri = XXXXXXXXXXX-XXXXXXXXX-XXXXXXX-XXXXXXXXXXX
Проблема в том, что токен, который мы получаем от Azure AD, имеет аудиторию как «00000003-0000-0000-c000-000000000000», что означает, что токен создается для Граф Microsoft. Я также попытался получить доступ к графу Api с этим токеном, и это сработало. Но мы хотим проверить этот токен в нашем собственном микросервисе Spring и предоставить разрешение. на основе предоставленного jwt.
Чтобы решить эту проблему, мне пришлось внести некоторые изменения в конфигурацию нашего приложения Angular, зарегистрированного в Azure. Я добавил собственный область действия api: // <> / app и использую эта область при получении токена. Теперь токен проходит проверку в бэкэнде, и API работает нормально.
Этот конфиг как-то работает, но мне не кажется правильным. Я новичок в лазурном, поэтому не знаю, как все взаимосвязано.
- Новый токен, который сейчас создается, имеет аудиторию в качестве нашей Идентификатор клиента angular spa. Это правильно? Разве это не должно быть серверной частью услуга? Любая причина, по которой он проверяется серверной частью с помощью текущая конфигурация?
- Насколько я понимаю, нам не нужно регистрировать нашу пружину микросервис с Azure Ad. Я буду просто выступать в роли сервера ресурсов и будет декодировать токен, предоставленный приложением angular, используя эмитент-url.
- Если нам нужно зарегистрировать наши серверные службы в Azure AD, тогда трудно ли сделать то же самое для всех микросервисов?
Я выполнил все настройки по ссылке. https://ordina-jworks.github.io/security/2020/08/18/Securing-Applications-Azure-AD.html
В некоторых других ссылках я нахожу совершенно другую конфигурацию для настройки серверной службы. Я не уверен, какой из них правильный. https://docs.microsoft.com/en-us/java/api/overview/azure/active-directory-spring-boot-starter-readme?view=azure-java-stable
Ответы 1
Azure AD немного сбивает с толку, если следовать подходу, основанному на стандартах. Пару лет назад я написал об этом Сообщение блога:
Вы уже поняли, что вам нужна хотя бы одна регистрация API для работы, чтобы открыть область действия API - чтобы получить пригодные для использования токены доступа.
Сгенерированный идентификатор из записи API в Azure становится вашей аудиторией, как на шаге 9 статьи.
Что мы действительно хотели бы сделать, так это сделать что-то вроде перенаправления JWT в микросервисе на вызовы микросервиса:
Получите Azure AD для выдачи утверждения аудитории, такого как api.mycompany.com, которое является общим для всех микросервисов.
Выпустить несколько областей в токенах доступа на основе областей данных в микросервисах - как в этот документ Curity
Я бы хотел, чтобы в Azure AD была одна запись, представляющая вашу платформу API. Тогда каждый микросервис может использовать одну и ту же сгенерированную ценность аудитории.
Надеюсь, вы также можете заставить работать несколько настраиваемых областей, хотя здесь есть некоторые неудобства, особенно когда вы хотите использовать встроенные области информации о пользователе OpenID Connect, которые Azure AD предоставляет через Graph API.
Из вашего сообщения я понимаю, что мне нужно создать новую регистрацию приложения для API и добавить его в разрешение API для SPA, чтобы токен доступа содержал аудиторию в качестве идентификатора клиента API серверной части Azure. А затем принудительно активируйте настраиваемую проверку на каждом микросервисе, чтобы проверить аудиторию. Также, как вы сказали, даже я был на одной странице, чтобы использовать один и тот же токен для всех микросервисов. Но правильно ли это с точки зрения безопасности? Из angular SPA пользователю был предоставлен токен для вызова API «X» на сервере ресурсов «A», но он может использовать тот же токен для вызова API «Y» на сервере ресурсов «B».
С другой стороны, если я не использую один и тот же токен в микросервисах, было бы очень утомительно всегда генерировать новый токен на сервере ресурсов A (микросервис Spring) для вызова конечной точки Rest на сервере ресурсов B. Также в этом случае В приложении angular нам потребуется некоторая логика для динамического получения токена из Azure AD для различных приложений Backend Api, зарегистрированных в Azure Ad (регистрация разных приложений для каждого микросервиса в Azure AD), в зависимости от того, какой вызов API сервера ресурсов был вызван пользователем.
Спасибо, что вернулись и поделились полезной информацией. Еще один дополнительный вопрос, поскольку я сказал, что на данный момент я зарегистрировал только Angular SPA в Azure AD и не зарегистрировал ни одного приложения для API. Вместо этого я открыл новую область Api в зарегистрированном приложении Angular SPA. Итак, теперь в моем токене доступа я получаю ту же аудиторию, что и мой идентификатор клиента angular SPA в Azure. Но я не уверен, почему этот токен успешно проверяется серверной службой. Может по умолчанию не проверять аудиторию