Поделиться через

Проверка подлинности и авторизация в Службе приложений и Службе функций Azure

Служба приложений Azure обеспечивает встроенную проверку подлинности (вход пользователей) и авторизацию (предоставление доступа к защищенным данным). Эти возможности иногда называются Easy Auth. Их можно использовать для входа пользователей и доступа к данным, практически не написав кода в вашем веб-приложении, RESTful API, мобильном сервере и функциях.

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

Причины использования встроенной проверки подлинности

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

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

С помощью службы приложений можно интегрировать возможности проверки подлинности в веб-приложение или API, не реализуя их самостоятельно. Эта функция встроена непосредственно на платформу и не требует наличия определенного языка, пакета SDK, опыта безопасности или кода. Ее можно интегрировать с несколькими поставщиками входа, такими как Microsoft Entra, Facebook, Google и X.

Приложению может потребоваться поддержка более сложных сценариев, таких как интеграция Visual Studio или добавочное согласие. Для поддержки этих сценариев доступны несколько решений проверки подлинности. Дополнительные сведения см. в сценариях проверки подлинности и рекомендациях.

Поставщики идентификационных услуг

Служба приложений использует федеративное удостоверение. Провайдер удостоверений Майкрософт или не-Майкрософт управляет удостоверениями пользователей и процессом аутентификации. По умолчанию доступны следующие поставщики удостоверений:

Поставщик Конечная точка входа Практические руководства
Microsoft Entra /.auth/login/aad Вход в службу приложений на платформе Microsoft Entra
Facebook /.auth/login/facebook Вход в Службу приложений Facebook
Google /.auth/login/google Вход в Службу приложений Google
X /.auth/login/x Вход в Службу приложений X
GitHub /.auth/login/github Вход в службу приложений GitHub
Яблоко /.auth/login/apple Вход в Службу приложений с помощью входа Apple (предварительная версия)
Любой поставщик OpenID Connect /.auth/login/<providerName> Вход в Службу приложений OpenID Connect

При настройке этой функции с одним из этих поставщиков ее точка входа для входа в систему доступна для аутентификации пользователей и проверки токенов аутентификации от поставщика. Вы можете предоставить своим пользователям любое количество этих вариантов входа.

Рекомендации по использованию встроенной проверки подлинности

Включение встроенной проверки подлинности приводит к автоматическому перенаправлению всех запросов к приложению на HTTPS независимо от параметра конфигурации службы приложений для принудительного применения HTTPS. Эту автоматическую перенаправлению можно отключить с помощью requireHttps параметра в конфигурации версии 2. Однако рекомендуется продолжать использовать HTTPS и гарантировать, что маркеры безопасности никогда не передаются через небезопасные HTTP-подключения.

Службу приложений можно использовать для проверки подлинности с помощью или без ограничения доступа к содержимому сайта и API. Задайте ограничения доступа в разделе Настройки>Проверка подлинности>параметров аутентификации вашего веб-приложения.

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

Внимание

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

Принцип работы

Архитектура функций

Компонент ПО промежуточного слоя проверки подлинности и авторизации — это функция платформы, которая работает на той же виртуальной машине, что и приложение. При включении каждый входящий HTTP-запрос проходит через этот компонент перед его обработкой.

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

ПО промежуточного слоя платформы выполняет для приложения несколько задач:

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

Модуль выполняется отдельно от кода приложения. Его можно настроить с помощью параметров Azure Resource Manager или с помощью файла конфигурации. Какие-либо пакеты SDK, определенные языки программирования или изменения кода приложения не требуются.

Архитектура функций в Windows (без развертывания контейнера)

Модуль проверки подлинности и авторизации выполняется в качестве встроенного модуля IIS в той же песочнице, что и ваше приложение. При включении каждый входящий HTTP-запрос проходит через него перед обработкой приложения.

Архитектура функций в Linux и контейнерах

Модуль проверки подлинности и авторизации выполняется в отдельном контейнере, изолированном от кода приложения. Модуль использует шаблон "Посол " для взаимодействия с входящим трафиком для выполнения аналогичных функций, как в Windows. Так как он не выполняется в процессе, прямая интеграция с определенными языковыми платформами невозможна. Однако соответствующие сведения, необходимые приложению, передаются в заголовках запросов.

Поток аутентификации

Поток проверки подлинности одинаков для всех поставщиков. Он отличается в зависимости от того, хотите ли вы войти с помощью пакета SDK поставщика:

  • Без SDK-пакета поставщика: приложение делегирует процесс федеративного входа в App Service. Обычно это является типичным случаем для браузерных приложений, которые могут отображать пользователю страницу входа поставщика. Код сервера управляет процессом входа, поэтому он также называется потоком, направленным на сервер или потоком сервера.

    Это касается приложений браузера и мобильных приложений, использующих внедренный браузер для проверки подлинности.

  • С помощью пакета SDK поставщика: приложение вручную авторизует пользователей через поставщика. Затем он отправляет маркер проверки подлинности в службу приложений для проверки. Этот процесс обычно относится к приложениям без браузера, которые не могут представить пользователю страницу входа поставщика. Код приложения управляет процессом входа, поэтому он также называется потоком, направленным клиентом или потоком клиента.

    Этот случай применяется к REST API, функциям Azure и клиентам браузеров JavaScript, а также к приложениям браузера, которые нуждаются в большей гибкости в процессе входа. Это также относится к собственным мобильным приложениям, которые входят пользователей с помощью SDK-пакета поставщика.

Вызовы из доверенного браузерного приложения в службе приложений к другому REST API в службе приложений или Функциях Azure могут быть аутентифицированы через поток, управляемый сервером. Дополнительные сведения см. в статье Настройка входа и выхода при проверке подлинности в Службе приложений Azure.

В следующей таблице показаны шаги потока проверки подлинности.

Этап Без использования пакета SDK поставщика С использованием пакета SDK поставщика
1. Вход пользователя Поставщик перенаправляет клиента на /.auth/login/<provider>. Клиентский код аутентифицирует пользователя непосредственно с помощью пакета SDK поставщика и получает токен аутентификации. Дополнительные сведения см. в документации поставщика.
2. Осуществить действия после аутентификации Поставщик перенаправляет клиента на /.auth/login/<provider>/callback. Клиентский код отправляет маркер от поставщика на /.auth/login/<provider> для проверки.
3. Установка сеанса, прошедшего проверку подлинности Служба приложений добавляет в ответ файл cookie, прошедший проверку подлинности. Сервис App возвращает собственный токен аутентификации в клиентский код.
4. Предоставление аутентифицированного контента Клиент включает файл cookie проверки подлинности в последующих запросах (автоматически обрабатывается браузером). Клиентский код представляет маркер проверки подлинности в заголовке X-ZUMO-AUTH .

Для клиентских браузеров служба приложений может автоматически перенаправлять всех не прошедших проверку пользователей к /.auth/login/<provider>. Вы также можете предоставить пользователям одну или несколько /.auth/login/<provider> ссылок для входа в приложение с помощью выбранного поставщика.

Поведение авторизации

На портале Azure можно настроить службу приложений с различными поведениями, если входящие запросы не проходят проверку подлинности. В следующих разделах описаны опции.

Внимание

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

Ограниченный доступ

  • Разрешить запросы, не прошедшие проверку подлинности: этот параметр отложит авторизацию неавторентированного трафика в код приложения. Для запросов, прошедших проверку подлинности, служба приложений также передает сведения о проверке подлинности в заголовках HTTP.

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

  • Требовать проверку подлинности: в этом варианте любой трафик к приложению, не прошедший проверку подлинности, отклоняется. Конкретные действия, которые необходимо предпринять, указаны в разделе "Запросы без проверки подлинности " далее в этой статье.

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

    Внимание

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

    Примечание.

    При использовании поставщика удостоверений Microsoft для пользователей в вашей организации поведение по умолчанию заключается в том, что любой пользователь в арендатора Microsoft Entra может запросить токен для вашего приложения. Вы можете настроить приложение в Microsoft Entra , если вы хотите ограничить доступ к приложению определенным набором пользователей. Служба приложений также предлагает некоторые базовые встроенные проверки подлинности, которые могут помочь в некоторых проверках. Дополнительные сведения об авторизации в Microsoft Entra см. в статью Основы авторизации Microsoft Entra.

При использовании поставщика удостоверений Microsoft для пользователей в вашей организации поведение по умолчанию заключается в том, что любой пользователь в клиенте Microsoft Entra может запросить токен для вашего приложения. Вы можете настроить приложение в Microsoft Entra , если вы хотите ограничить доступ к приложению определенным набором пользователей. Служба приложений также предлагает некоторые основные встроенные проверки авторизации , которые могут помочь в некоторых проверках. Дополнительные сведения об авторизации в Microsoft Entra см. в статью Основы авторизации Microsoft Entra.

Запросы без проверки подлинности

  • Http 302 Found redirect: рекомендуется для веб-сайтов: перенаправляет действие на один из настроенных поставщиков удостоверений. В таких случаях клиент браузера перенаправляется на /.auth/login/<provider> выбранного вами поставщика.
  • HTTP 401 Неавторизован: рекомендуется для API: возвращает HTTP 401 Unauthorized ответ, если анонимный запрос поступает из родного мобильного приложения. Вы также можете настроить отклонение HTTP 401 Unauthorized для всех запросов.
  • HTTP 403 Запрещено: настраивает отклонение HTTP 403 Forbidden для всех запросов.
  • Http 404 Не найден: настраивает отклонение HTTP 404 Not found для всех запросов.

Хранилище токенов

Служба приложений предоставляет встроенное хранилище токенов. Хранилище маркеров — это репозиторий маркеров, связанных с пользователями веб-приложений, API или собственных мобильных приложений. При включении проверки подлинности с помощью любого поставщика это хранилище токенов немедленно становится доступным для вашего приложения.

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

  • Опубликуйте временную шкалу пользователя, прошедшего проверку подлинности, в Facebook.
  • Чтение корпоративных данных пользователя с помощью API Microsoft Graph.

В хранилище токенов вы просто извлекаете токены, когда они вам нужны, и сообщаете службе приложений (App Service) обновить их, когда они становятся недействительными.

Маркеры идентификатора, маркеры доступа и маркеры обновления кэшируются для сеанса, прошедшего проверку подлинности. Доступ к ним может получить только связанный пользователь.

Если вам не требуется работать с токенами в приложении, вы можете отключить хранилище токенов на странице Параметры>Аутентификация вашего приложения.

Логирование и трассировка

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

Если включить трассировку неудачных запросов, вы можете точно увидеть, какую роль может играть модуль проверки подлинности и авторизации в неудачном запросе. Найдите ссылки на модуль с именем EasyAuthModule_32/64 в журналах трассировки.

Смягчение межсайтовой подделки запроса

Проверка подлинности службы приложений устраняет подделку межсайтовых запросов, проверяя клиентские запросы на следующие условия:

  • Это запрос, прошедший POST проверку подлинности через файл cookie сеанса.
  • Запрос поступил из известного браузера, как определено заголовком HTTP User-Agent .
  • Заголовок HTTP Origin или HTTP Referer отсутствует или отсутствует в настроенном списке утвержденных внешних доменов для перенаправления.
  • Заголовок HTTP Origin отсутствует или отсутствует в настроенном списке источников общего доступа к ресурсам (CORS).

Когда запрос выполняет все эти условия, Служба приложений аутентификация автоматически отклоняет его. Вы можете обойти эту логику защиты, добавив ваш внешний домен в список перенаправления в разделе Параметры>Проверка подлинности>Изменить параметры проверки подлинности>Разрешенные URL-адреса внешнего перенаправления.

Рекомендации по использованию Azure Front Door

Если вы используете Службу приложений Azure с аутентификацией за Azure Front Door или другими обратными прокси-серверами, учтите следующие действия.

Отключите кэширование Azure Front Door

Отключите кэширование Azure Front Door для рабочего процесса проверки подлинности.

Использование конечной точки Azure Front Door для перенаправлений

Служба приложений обычно недоступна напрямую, когда она публикуется через Azure Front Door. Это поведение можно предотвратить, например, предоставив Службе приложений приватный канал Azure в Azure Front Door Premium. Чтобы рабочий процесс проверки подлинности предотвратил перенаправление трафика обратно в службу приложений напрямую. Дополнительные сведения см. в URI перенаправления.

Убедитесь, что Служба приложений использует правильный URI перенаправления

В некоторых конфигурациях App Service использует свое полное доменное имя (FQDN) в качестве URI перенаправления вместо FQDN Azure Front Door. Эта конфигурация вызывает проблему, когда клиент перенаправляется в службу приложений вместо Azure Front Door. Чтобы изменить это, установите forwardProxy на Standard, чтобы служба приложений учитывала заголовок, заданный X-Forwarded-Host Azure Front Door.

Другие обратные прокси-серверы, такие как Шлюз приложений Azure или продукты, отличные от Майкрософт, могут использовать разные заголовки и требуют другого forwardProxy параметра.

Вы не можете изменить конфигурацию forwardProxy с помощью портала Azure. Вам нужно использовать az rest.

Параметры экспорта

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Обновление параметров

Искать:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Убедитесь, что convention установлено на Standard, чтобы соответствовать заголовку X-Forwarded-Host, который использует Azure Front Door.

Импорт параметров

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Связанный контент

Дополнительные сведения о проверке подлинности службы приложений см. в следующем разделе:

Примеры см. в разделах: