Пользовательская API-аутентификация функции Azure

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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