Как настроить веб-приложение Azure для проверки подлинности веб-приложения?

У меня есть два веб-приложения Azure, одно из которых является веб-сайтом и действует как интерфейс, а другое - API и действует как серверная часть. Я хотел бы добавить в это решение аутентификацию, чтобы только внешний интерфейс мог получить доступ к серверной части. Для этого я настроил аутентификацию AAD в серверном веб-приложении с помощью экспресс-опции, которая создает новое приложение Azure AD, настроенное с правильным URL-адресом ответа, разрешениями API (User.Read) и т. Д. Когда я затем перехожу на серверную часть URL-адрес веб-приложения, мне нужно войти в систему с учетными данными Azure AD.

Какие шаги мне нужно предпринять, чтобы ограничить это, чтобы я, как пользователь, не мог войти в систему, и только интерфейсное веб-приложение могло аутентифицироваться в серверном API?

Например, я могу установить авторизованные клиентские приложения в приложении Azure AD серверного API. Однако мне нужен идентификатор приложения для добавления авторизованного клиента, и я хотел бы использовать для этого управляемую идентификацию интерфейсного веб-приложения, а не новое и дополнительное приложение Azure AD.

есть идеи как это сделать?


azure azure-web-app-service azure-active-directory azure-authentication
person Ronald    schedule 03.02.2021    source источник
comment
Я уже отвечал на аналогичные вопросы раньше для вашей справки. stackoverflow.com/questions/65934246/   -  person Carl Zhao    schedule 03.02.2021
comment
Привет @CarlZhao, спасибо за ссылку. Я добавил идентификатор приложения интерфейсного приложения к авторизованным клиентским приложениям в серверной части. Я также добавил роль приложения в серверное приложение и добавил эту роль через разрешения API в моем интерфейсном приложении. Нужно ли мне также обновлять свой код C #? Когда я перехожу к URL-адресу внешнего интерфейса, я все еще получаю экран входа в систему, когда интерфейс пытается получить доступ к API серверного приложения.   -  person Ronald    schedule 03.02.2021
comment
Это странно, он больше не должен предлагать вам войти в систему. Я нашел подходящий образец, и вы можете посмотреть, поможет ли он вам. github.com/Azure-Samples/active-directory-dotnetcore-daemon- v2   -  person Carl Zhao    schedule 04.02.2021
comment
Если мой ответ полезен для вас, вы можете принять его как ответ (щелкните галочку рядом с ответом, чтобы переключить его с серого на заполненный). Это может быть полезно для других членов сообщества. Спасибо.   -  person Carl Zhao    schedule 05.02.2021

Ответы (1)


arrow_upward
0
arrow_downward

Это странно, если экран входа в систему все еще появляется, значит проблема с конфигурацией вашего кода, потому что поток учетных данных клиента не требует взаимодействия с пользователем.

Я нашел полезный образец для справки, в этом примере приложения показано, как использовать платформу идентификации Microsoft для доступа к данным из защищенного веб-API в неинтерактивном процессе. Он использует OAuth 2 клиентские учетные данные предоставляют для получения токена доступа, который затем используется для вызова веб-API.

person Carl Zhao    schedule 04.02.2021
comment
Привет, Карл, спасибо за ссылку. Я следил за ним, и он работает на 50%. Когда я выполняю запрос в Postman, чтобы получить токен доступа и использовать его при вызове API, он работает. В веб-приложении Azure для авторизации и проверки подлинности включены стандартные настройки. Однако, когда я добавляю атрибут авторизации и код HttpContext.ValidateAppRole("access_as_application");, я получаю 401 при вызове API через Postman, в ответе не дается никакой дополнительной информации. Мое клиентское приложение имеет правильную роль в токене, когда я проверяю его на jwt.io. Есть идеи, что не так? - person Ronald; 08.02.2021
comment
@Ronald Ошибка 401 означает, что audience вашего токена не соответствует вашему API. Как вы установили scope? Можете ли вы использовать jwt.io для анализа вашего токена доступа и предоставления снимков экрана? - person Carl Zhao; 10.02.2021