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

Примечание.

Начиная с 1 июня 2024 г. все созданные Служба приложений приложения будут иметь возможность создать уникальное имя узла по умолчанию с помощью соглашения <app-name>-<random-hash>.<region>.azurewebsites.netоб именовании. Существующие имена приложений останутся неизменными.

Пример: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

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

Служба приложений Azure предоставляет встроенные возможности проверки подлинности и авторизации (иногда называемые "EasyAuth"), поэтому для входа пользователей в систему и предоставления доступа к данным необходимо написать минимальный код или обойтись без кода в веб-приложении, RESTfu API и серверной части мобильных приложений, а также в Функциях Azure. В этой статье описывается, как служба приложений помогает упростить проверку подлинности и авторизацию для вашего приложения.

Зачем использовать встроенную проверку подлинности?

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

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

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

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

Поставщики удостоверений

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

Provider	Конечная точка входа	Практическое руководство
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
Вход с помощью Apple	/.auth/login/apple	Служба приложений войти с помощью имени входа Apple (предварительная версия)
Любой поставщик OpenID Connect	/.auth/login/<providerName>	Вход через OpenID Connect в Службе приложений

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

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

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

Службу приложений можно использовать для проверки подлинности с ограничением или без ограничения доступа к содержимому и API сайта. Ограничения доступа можно задать в разделе параметров проверки подлинности>веб-приложения. Чтобы предоставить доступ к приложению только пользователям, прошедшим проверку подлинности, для параметра Предпринимаемое действие, если проверка подлинности для запроса не выполнена установите вход с помощью одного из настроенных поставщиков удостоверений. Чтобы выполнять проверку подлинности, но не ограничивать доступ, для параметра Предпринимаемое действие, если проверка подлинности для запроса не выполнена установите "Разрешить анонимные запросы (нет действия)".

Внимание

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

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

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

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

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

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

Ведение журнала и трассировка

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

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

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

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

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

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

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

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

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

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

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

• Без использования пакета SDK поставщика. Приложение делегирует федеративный вход в службу приложений. Обычно это относится к приложениям браузера, которые могут предоставить пользователю страницу входа поставщика. Код сервера управляет процессом входа, поэтому он также называется управляемым сервером потоком или потоком сервера. Это касается приложений браузера и мобильных приложений, использующих внедренный браузер для проверки подлинности.
• С использованием пакета SDK поставщика. Вход пользователей в приложение на странице поставщика выполняется вручную, а затем приложение отправляет маркер проверки подлинности в Службу приложений Azure для проверки. Обычно это относится к внебраузерным приложениям, которые не могут предоставить пользователю страницу входа в систему. Код приложения управляет процессом входа, поэтому его также называют управляемым клиентом потоком или потоком клиента. Этот вариант применяется к REST API, Функциям Azure и клиентам браузера JavaScript, а также к браузерным приложениям, которым требуется больше гибкости при входе в систему. Это также относится к собственным мобильным приложениям, в которых вход пользователей в систему выполняется с помощью пакета SDK поставщика.

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

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

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

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

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

Внимание

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

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

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

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

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

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

  В этом случае в клиентском приложении не нужен код для проверки подлинности. Более точная авторизация, например авторизация для конкретной роли, может выполняться путем проверки утверждений пользователя (см. раздел Access user claims (Доступ к утверждениям пользователя)).

  Внимание

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

  Примечание.

  При использовании поставщика удостоверений 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;

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

Токены идентификатора, доступа и обновления кэшируются для проверенного сеанса. Они доступны только соответствующему пользователю.

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

Отладка и трассировка

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

Устранение проблем с несколькими сайтами для подделки запросов

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

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

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

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

При использовании службы приложение Azure с проверкой подлинности за Azure Front Door или другими обратными прокси-серверами необходимо учитывать несколько дополнительных элементов.

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

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

  Служба приложений обычно недоступен напрямую при использовании Azure Front Door. Это можно предотвратить, например, предоставляя Служба приложений через Приватный канал в Azure Front Door Premium. Чтобы предотвратить перенаправление трафика обратно в Служба приложений, важно настроить приложение для перенаправления обратно https://<front-door-endpoint>/.auth/login/<provider>/callbackв .

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

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

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

Дополнительные ресурсы

• Практическое руководство. Настройка приложения Служба приложений или Функции Azure для использования имени входа Microsoft Entra
• Настройка входа и выхода

• Работа с токенами и сеансами OAuth
• Доступ к утверждениям пользователей и приложений
• Конфигурация на основе файлов

Примеры кода:

• Руководство. Добавление проверки подлинности в веб-приложение, работающее в службе приложение Azure
• Руководство по сквозной проверке подлинности и авторизации в Службе приложений Azure (Windows или Linux)
• Интеграция .NET Core с EasyAuth Службы приложений Azure (сторонняя)
• Получение проверки подлинности Службы приложений Azure, работающей с использованием .NET Core (сторонняя)