Блог

Я получил функцию Azure, запускаемую HTTP, которая используется одним из моих веб-приложений. Пользователем этого сайта может быть любой, кто зарегистрировался на сайте. Теперь я хочу реализовать аутентификацию для функции Azure таким образом, чтобы только зарегистрированный пользователь мог получить доступ к функции Azure через мой веб-сайт. Я мог видеть множество встроенных аутентификаций, таких как функции Azure, OAuth с использованием Azure AD и других поставщиков удостоверений и т.д. Я ищу способ аутентификации пользователей, зарегистрированных через мой веб-сайт, а не у поставщиков удостоверений.

Одно из решений, которое я могу придумать, — это при регистрации зарегистрировать этого пользователя в Azure AD. Затем при вызове API передайте учетные данные пользователя в API и выполните проверку на соответствие AD. Может кто-нибудь посоветовать, пожалуйста, это хорошее решение? Если нет, пожалуйста, посоветуйте лучшее решение для моего варианта использования.

Я не хочу использовать какого-либо внешнего поставщика аутентификации

Просто ссылаюсь на документацию:

• Функции Azure HTTP Trigger — ключи авторизации

  Хотя ключи могут помочь запутать ваши конечные точки HTTP во время разработки, они не предназначены для защиты HTTP-триггера в рабочей среде. Чтобы узнать больше, см. раздел Защита конечной точки HTTP в рабочей среде.

• Вторая ссылка на защиту конечной точки HTTP в рабочей среде дает больше информации о том, как защитить функции, запускаемые HTTP:

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

  • Включите аутентификацию / авторизацию службы приложений для вашего функционального приложения. Платформа службы приложений позволяет использовать Azure Active Directory (AAD) и несколько сторонних поставщиков удостоверений для аутентификации клиентов. Вы можете использовать это для реализации пользовательских правил авторизации для своих функций, и вы можете работать с пользовательской информацией из кода вашей функции. Дополнительные сведения см. в разделе Проверка подлинности и авторизация в службе приложений Azure и работа с удостоверениями клиентов.
  • Используйте Azure API Management (APIM) для проверки подлинности запросов. APIM предоставляет множество параметров безопасности API для входящих запросов. Чтобы узнать больше, см. Политики аутентификации управления API. Установив APIM, вы можете настроить свое функциональное приложение так, чтобы оно принимало запросы только с IP-адреса вашего экземпляра APIM. Чтобы узнать больше, см. раздел Ограничения IP-адресов.
  • Разверните свое функциональное приложение в среде службы приложений Azure (ASE). ASE предоставляет выделенную среду размещения, в которой выполняются ваши функции. ASE позволяет настроить единый интерфейсный шлюз, который можно использовать для проверки подлинности всех входящих запросов. Дополнительные сведения см. в разделе Настройка брандмауэра веб-приложений (WAF) для среды службы приложений.

На мой взгляд, вы можете сделать это следующими способами.

Использование ключа авторизации на уровне функции (не является предпочтительным, но простым)

Если ваше веб-приложение является единственным, которое будет получать доступ к функциональному приложению, вы можете включить авторизацию непосредственно в функции. Любой, кто хочет получить доступ к функции, должен передать ключ, иначе вы получите 401 . Поскольку вы хотите, чтобы пользователи получали доступ к вашей функции напрямую, вам необходимо создать дополнительную конечную точку на вашем веб-сайте, которая будет вызывать приложение function от имени пользователей и передавать ключ. Вы можете найти больше о ключе авторизации здесь

Использование Azure B2C или AD

Вы думаете в правильном направлении. Если ваш веб-сайт доступен внешнему пользователю, вы можете рассмотреть Azure B2C. Вы получаете множество готовых функций, включая регистрацию с использованием учетных записей в социальных сетях, и вам, возможно, не потребуется сохранять пользователей по отдельности. Поток остается тем же, пользователи проходят аутентификацию в Azure AD (или B2C) и выдается токен. Затем токен передается при вызове функций Azure.