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

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

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

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

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

The built-in capabilities of App Service and Azure Functions can save you time and effort by providing out-of-the-box authentication with federated identity providers, so you can focus on the rest of your application.

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

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

Identity providers

Служба приложений использует федеративное удостоверение. A Microsoft or non-Microsoft identity provider manages the user identities and authentication flow for you. По умолчанию доступны следующие поставщики удостоверений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Without provider SDK: The application delegates federated sign-in to App Service. This delegation is typically the case with browser apps, which can present the provider's sign-in page to the user. Код сервера управляет процессом входа, поэтому он также называется потоком, направленным на сервер или потоком сервера.

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

• With provider SDK: The application signs in users to the provider manually. Затем он отправляет маркер проверки подлинности в службу приложений для проверки. Этот процесс обычно относится к приложениям без браузера, которые не могут представить пользователю страницу входа поставщика. Код приложения управляет процессом входа, поэтому он также называется потоком, направленным клиентом или потоком клиента.

  Этот случай применяется к REST API, функциям Azure и клиентам браузеров JavaScript, а также к приложениям браузера, которые нуждаются в большей гибкости в процессе входа. It also applies to native mobile apps that sign in users by using the provider's SDK.

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

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

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

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

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

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

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

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

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

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

  Внимание

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

  Примечание.

  When using the Microsoft identity provider for users in your organization, the default behavior is that any user in your Microsoft Entra tenant can request a token for your application. Вы можете настроить приложение в Microsoft Entra , если вы хотите ограничить доступ к приложению определенным набором пользователей. Служба приложений также предлагает некоторые базовые встроенные проверки подлинности, которые могут помочь в некоторых проверках. Дополнительные сведения об авторизации в Microsoft Entra см. в статью Основы авторизации Microsoft Entra.

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

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

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

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

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

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

• Post to the authenticated user's Facebook timeline.
• Чтение корпоративных данных пользователя с помощью API Microsoft Graph.

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

The ID tokens, access tokens, and refresh tokens are cached for the authenticated session. Доступ к ним может получить только связанный пользователь.

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

Logging and tracing

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

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

Mitigation of cross-site request forgery

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

• It's a POST request that authenticated through a session cookie.
• Запрос поступил из известного браузера, как определено заголовком HTTP User-Agent .
• Заголовок HTTP Origin или HTTP Referer отсутствует или отсутствует в настроенном списке утвержденных внешних доменов для перенаправления.
• Заголовок HTTP Origin отсутствует или отсутствует в настроенном списке источников общего доступа к ресурсам (CORS).

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

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

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

Disable Azure Front Door caching

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

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

Служба приложений обычно недоступна напрямую, когда она публикуется через Azure Front Door. You can prevent this behavior, for example, by exposing App Service by using Azure Private Link in Azure Front Door Premium. Чтобы рабочий процесс проверки подлинности не перенаправлял трафик обратно в службу приложений, важно настроить приложение для перенаправления обратно в https://<front-door-endpoint>/.auth/login/<provider>/callback.

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

В некоторых конфигурациях App Service использует свое полное доменное имя (FQDN) в качестве URI перенаправления вместо FQDN Azure Front Door. Эта конфигурация вызывает проблему, когда клиент перенаправляется в службу приложений вместо Azure Front Door. To change it, set forwardProxy to Standard to make App Service respect the X-Forwarded-Host header that Azure Front Door set.

Другие обратные прокси-серверы, такие как Шлюз приложений 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

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

Search for:

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

Ensure that convention is set to Standard to respect the X-Forwarded-Host header that Azure Front Door uses.

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

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

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

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

• Настройте сервис приложений или приложение Azure Functions для использования входа в Microsoft Entra
• Настройка входа и выхода из системы в аутентификации службы приложений Azure
• Работа с токенами OAuth в службе аутентификации приложений Azure
• Работа с удостоверениями пользователей в службе аутентификации приложений Azure
• Конфигурация на основе файлов в проверке подлинности Службы приложений Azure

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

• Краткое руководство. Добавление проверки подлинности приложения в веб-приложение, работающее в Службе приложений Azure
• Учебное пособие: проверка подлинности и авторизация пользователей от начала до конца в службе приложений Azure
• .NET Core integration of Azure AppService Easy Auth (non-Microsoft GitHub content)
• Настройка проверки подлинности Службы приложений Azure для работы с .NET Core (немайкрософтовское содержимое GitHub)