Блог

У меня есть один ASP.NET MVC app — контроллеры веб-сайтов и API. Я хотел бы использовать Azure API Management для управления этими API, но сохранить тот же URL-адрес, чтобы он был удобным для наших потребителей. У нас есть пользовательская настройка домена в службе приложений для этого веб-приложения, которое в настоящее время используется для обслуживания как сайта, так и API (например, Website: xyz.com , API: xyz.com/api1 , xyz.com/api2 и т.д.). Также мы используем AAD для аутентификации. и настройте перенаправление URI на пользовательский домен (xyz.com ). В настоящее время все работает отлично.

Проблема возникает после того, как мы настраиваем управление API для предоставления доступа к нашим API и, возможно, используем его в качестве сквозного. Чтобы гарантировать, что URL-адреса останутся неизменными после введения управления API, мы установили пользовательский домен в самом экземпляре управления API и удалили его из app. service. Вот как выглядит наша текущая настройка ->

Пользователь попадает xyz.com и запрос выполняется следующим образом -> Диспетчер трафика -> APIM(xyz.com ) -> Служба приложений (xxx.azurewebsites.net )

После этого последнего пункта выше, AAD auth. должен запуститься, и как только у него будет токен доступа после успешной аутентификации. он должен перенаправить пользователя, и страница должна загрузиться. Но это не так. Вместо этого мы получаем пустую страницу, и если мы ее обновим, тогда и только тогда она перейдет к аутентификации. и загрузите страницу.

Мы попытались установить URI перенаправления для обоих пользовательских доменов (xyz.com ), а также базовое имя службы приложений, сгенерированное Azure (xxx.azurewebsites.net ).

Прямое попадание в URL-адреса API (например xyz.com/api1 ) работает нормально. Он проходит через APIM и отвечает, как ожидалось. Единственная проблема заключается в том, что веб-сайт не загружается, как описано выше.

В тот момент, когда мы исключаем APIM из уравнения и снова устанавливаем пользовательский домен в службе приложений, все работает так, как ожидалось.

Я пытаюсь выяснить, не сконфигурировали ли мы каким-то образом наши ресурсы для этого сценария или APIM не поддерживает сквозную передачу для веб-сайта таким образом. Любые мысли / предложения здесь будут высоко оценены!

Вау, это было много текста. Хорошо, давайте посмотрим:

Посетители -> Диспетчер трафика -> APIM -> серверная часть (ваш веб-сайт) — ок, понял.

это похоже на обычный способ использования APIM, и он должен работать. Однако, возможно, ваши политики настроены неправильно?

Вы создали свой продукт / API / операции? Видите ли вы запросы, поступающие от APIM, попадающие на ваш сайт? Какие ответы вы получаете?

Теперь, конечно, вам нужно будет определить и настроить APIM (продукты, API и каждую операцию), чтобы передать его throw в ваш серверный сервер. Это означает, что если вам (как посетителю) нужно перечислить все продукты, вам нужно будет выполнить операцию APIM (sed GetProducts ). Ваш запрос будет передан через Входящую политику (при необходимости скорректируйте и создайте запрос), передайте его на серверную часть (на ваш веб-сайт с пользовательскими API), и ответ будет отправлен обратно из серверной части посетителю.

Теперь к этому: чтобы защитить серверную часть веб-API в APIM, вы можете использовать авторизацию OAuth 2.0 в Azure AD: общий обзор:

1. Зарегистрируйте приложение (для вашего бэкэнда) в Azure AD для представления API
2. Зарегистрируйте другое приложение (клиент) в Azure AD для представления клиентского приложения, которое будет вызывать ваш API
3. И я предполагаю, что это то, что вам нужно предоставить разрешения, позволяющие клиентскому приложению вызывать серверное приложение
4. И, конечно же, добавьте политику validate-jwt для проверки токена OAuth для каждого входящего запроса

Читайте об этом здесь https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad