Функция Azure v2 с аутентификацией Jwt без сертификата

Question

Я работаю над тестовым внутренним проектом Azure Function v2.Цель состоит в том, чтобы атрибуты авторизации метода функции использовали токен jwt, который я передал из нашего интерфейсного проекта, который использует MSAL для аутентификации в нашем приложении v2, зарегистрированном на портале Azure.Мой внешний интерфейс написан на Angular 7, и я использую этот пакет npm для MSAL https://www.npmjs.com/package/@azure/msal-angular.. Я бы использовал одно и то же зарегистрированное приложение для внешнего и внутреннего проекта.Что я могу сделать при запуске, чтобы установить аутентификацию jwt и связать ее с атрибутами авторизации функции?

Это проект концепции, поэтому мы заменили бы наш веб-API службы приложений на функцию Azure.Внешний и внутренний проекты используют одно и то же приложение, зарегистрированное на портале Azure.Мы все равно будем использовать одно и то же зарегистрированное приложение, и интерфейс будет вызывать функцию Azure вместо службы приложений.Я попытался использовать пример привязки из этой ссылки https://www.ben -morris.com / custom-token-authentication-in-azure-functions-using-bindings , но они используют сертификат.Я хотел бы использовать идентификатор приложения и идентификатор арендатора вместо передачи сертификата.

Answer 1

Функция Аутентификация / авторизация службы приложений Azure (также известная как EasyAuth) фактически поддерживает токены Bearer для аутентификации запросов на AAD.

Чтобы включить функцию для своего функционального приложения, перейдите к своему приложению на портале. Затем перейдите в Функции платформы> Сеть> Аутентификация / Авторизация. Оттуда выберите расширенную конфигурацию для AAD и укажите идентификатор клиента и URL-адрес эмитента для регистрации приложения AAD. Теперь ваше приложение сможет проверять подлинность запросов с токенами Bearer с вашей регистрацией приложения AAD в качестве аудитории.

Для компонента авторизации у вас есть два варианта.

1. Установите Action to take when request is not authenticated на Log in with Azure Active Directory. Это глобальная настройка, поэтому все HTTP-запросы к вашему приложению-функции защищены этой логикой авторизации.

2. Установите Action to take when request is not authenticated на Allow Anonymous requests (no action). В этом случае платформа не будет выполнять какую-либо логику авторизации, и вы должны реализовать ее в своем коде. Несмотря на то, что это больше работы, это дает вам больше гибкости в отношении того, какие API должны быть защищены, а также позволяет использовать более сложную логику авторизации, чем просто «запрос аутентифицирован?».

   Если ваши триггеры HTTP используют C #, вы можете легко получить доступ к объекту ClaimsPrincipal с заполненной идентификационной информацией AAD. Оттуда вы можете легко выполнить свою логику авторизации. Поддержка JavaScript должна появиться в ближайшее время. Если у вас нет доступа к этому ClaimsPrincipal, вы также можете вручную проанализировать токен на предъявителя и посмотреть на существующие в нем утверждения.

ПРИМЕЧАНИЕ. Игнорируйте утверждение в верхней части документации о неподдержке конечных точек MSAL и AAD V2. Это больше не относится к апрелю 2019 года. Конфигурация почти идентична для конечных точек AAD v1, но к URL-адресу эмитента добавлен /v2.0 в конце.