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

Выберите другого поставщика проверки подлинности, чтобы перейти к нему.

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

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

Примечание.

Параметр автоматического создания новой регистрации недоступен для государственных облаков или при использовании [идентификатора Microsoft Entra для клиентов (предварительная версия)]. Для них регистрацию лучше определять отдельно.

Вариант 1.Автоматическое создание регистрации приложения

Используйте этот параметр, если вам не нужно создать регистрацию приложения отдельно. После создания можно настроить регистрацию приложения в идентификаторе Microsoft Entra.

  1. Войдите на портал Azure и перейдите к своему приложению.

  2. В меню слева выберите пункт Проверка подлинности. Выберите Добавить поставщик удостоверений.

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

    Секрет клиента будет создан и сохранен как связанный со слотом параметр приложения с именем MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Впоследствии этот параметр можно обновить, чтобы использовать ссылки Key Vault, если вы хотите управлять секретом в Azure Key Vault.

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

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

  5. (Необязательно) Нажмите кнопку "Далее": разрешения и добавление разрешений Microsoft Graph, необходимых приложению. Они будут добавлены в регистрацию приложения, но впоследствии их можно будет изменить.

  6. Выберите Добавить.

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

Пример настройки входа Microsoft Entra для веб-приложения, которое обращается к служба хранилища Azure и Microsoft Graph, см. в этом руководстве.

Вариант 2. Использование существующей регистрации, созданной отдельно

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

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

Шаг 1. Создание регистрации приложения в идентификаторе Microsoft Entra для приложения Служба приложений

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

  • Client ID
  • Идентификатор клиента
  • Секрет клиента (необязательно, но рекомендуется)
  • URI-адрес идентификатора приложения

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

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

  1. Войдите на портал Azure найдите и выберите Службы приложений, а затем выберите приложение. Запишите URL-адрес приложения. Вы будете использовать его для настройки регистрации приложения Microsoft Entra.

  2. Перейдите к клиенту на портале:

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

  3. На экране "Обзор" запишите идентификатор клиента, а также основной домен.

  4. В области навигации слева выберите Регистрация приложений> РегистрацияNew.

  5. На странице Регистрация приложения введите Имя для регистрации приложения.

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

  7. В разделе URI перенаправления выберите Веб-сайт для платформы и типа<app-url>/.auth/login/aad/callback. Например, https://contoso.azurewebsites.net/.auth/login/aad/callback.

  8. Выберите Зарегистрировать.

  9. После создания регистрации приложения скопируйте идентификатор приложения (клиент) и идентификатор каталога (клиент) для дальнейшего использования.

  10. В разделе Неявное предоставление и гибридные потоки активируйте параметр Токен идентификатора, чтобы разрешить вход пользователей OpenID Connect из Службы приложений. Выберите Сохранить.

  11. (Необязательно) В области навигации слева выберите "Фирменная символика" и "Свойства". В поле URL-адрес домашней страницы введите URL-адрес приложения Службы приложений и выберите Сохранить.

  12. В области навигации слева выберите "Предоставить сохранение набора> API".> Это значение однозначно определяет приложение, когда оно используется в качестве ресурса, что позволяет запрашивать токены для предоставления доступа. Он используется в качестве префикса для созданных область.

    Для однотенантного приложения можно использовать значение по умолчанию в формате api://<application-client-id>. Можно также указать более удобочитаемый код URI, например https://contoso.com/api, с использованием одного из проверенных доменов вашего клиента. Для многотенантного приложения необходимо указать пользовательский код URI. Дополнительные сведения о допустимых форматах URI идентификаторов приложений см. в справочнике по регистрации приложений.

  13. Выберите Добавить область.

    1. В разделе Имя области введите user_impersonation.
    2. В Кто может предоставить согласие, выберите Администратор и пользователей, если вы хотите разрешить пользователям согласие на это область.
    3. В текстовых полях введите имя и описание области согласия, которые пользователи должны видеть на странице согласия. Например, введите Доступ к <имя приложения>.
    4. Выберите Добавить область.
  14. (Необязательно) Чтобы создать секрет клиента, выполните приведенные действия.

    1. В области навигации слева выберите сертификаты и секреты>секретов>клиента Создать секрет клиента.
    2. Введите описание, срок действия и нажмите кнопку Добавить.
    3. Скопируйте значение секрета клиента в поле "Значение". Он не будет отображаться еще раз, когда вы перейдете с этой страницы.
  15. (Необязательно) Чтобы добавить несколько URL-адресов ответа, выберите Проверка подлинности.

  16. Завершите настройку регистрации приложения:

    Для клиента рабочей силы не требуется никаких других действий.

Шаг 2. Включение идентификатора Microsoft Entra в приложении Служба приложений

  1. Войдите на портал Azure и перейдите к своему приложению.

  2. В области навигации слева выберите "Добавить>поставщик>удостоверений Майкрософт".

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

  4. Настройте приложение для использования созданной регистрации, используя инструкции для соответствующего типа клиента:

    Для типа регистрации приложений выберите один из следующих вариантов:

    • Выберите существующую регистрацию приложения в этом каталоге: выберите регистрацию приложения из текущего клиента и автоматически соберите необходимые сведения о приложении. Система попытается создать новый секрет клиента для регистрации приложения и автоматически настроить приложение для его использования. URL-адрес издателя по умолчанию устанавливается на основе поддерживаемых типов учетных записей, настроенных в регистрации приложения. Если вы планируете изменить это значение по умолчанию, ознакомьтесь со следующей таблицей.
    • Укажите сведения о существующей регистрации приложения: укажите сведения о регистрации приложений из другого клиента или если у вашей учетной записи нет разрешения в текущем клиенте для запроса регистраций. Для этого параметра необходимо вручную заполнить значения конфигурации в соответствии со следующей таблицей.

    Конечная точка проверки подлинности для клиента рабочей силы должна быть значением , характерным для облачной среды. Например, клиент рабочей силы в глобальной среде Azure будет использовать "https://login.microsoftonline.com" в качестве конечной точки проверки подлинности. Запишите значение конечной точки проверки подлинности, так как необходимо создать правильный URL-адрес издателя.

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

    Поле Description
    Идентификатор приложения (клиент) Используйте идентификатор приложения (клиент) регистрации приложения.
    Секрет клиента Используйте секрет клиента, созданный при регистрации приложения. В этом случае используется гибридный поток, а Служба приложений возвращает маркеры доступа и обновления. Если секрет клиента не задан, используется неявный поток и возвращается только токен идентификатора. Эти маркеры отправляются поставщиком и хранятся в хранилище маркеров проверки подлинности Служба приложений.
    Url-адрес издателя Используйте <authentication-endpoint>/<tenant-id>/v2.0и замените конечную точку > проверки подлинности конечной точкой проверки подлинности, определенной на предыдущем шаге для типа клиента и облачной среды, а также заменив <<идентификатор клиента идентификатором> каталога (клиента), в котором была создана регистрация приложения. Для приложений, использующих Azure AD версии 1, исключите /v2.0 из URL-адреса.

    Это значение используется для перенаправления пользователей в правильный клиент Microsoft Entra, а также для скачивания соответствующих метаданных, чтобы определить соответствующие ключи подписи маркеров и значение утверждения издателя маркеров, например. Любая конфигурация, отличной от конечной точки для конкретного клиента, будет рассматриваться как мультитенантная. В конфигурациях с несколькими клиентами проверка издателя или идентификатора клиента не выполняется системой, и эти проверка должны полностью обрабатываться в логике авторизации приложения.
    Разрешенные аудитории маркеров Это поле необязательно. Настроенный идентификатор приложения (клиента)всегда неявно считается разрешенной аудиторией. Если приложение представляет API, который будет вызываться другими клиентами, необходимо также добавить URI идентификатора приложения, настроенный для регистрации приложения. Существует ограничение в 500 символов в списке разрешенных аудиторий.

    Секрет клиента будет сохранен как связанный со слотом параметр приложения с именем MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Впоследствии этот параметр можно обновить, чтобы использовать ссылки Key Vault, если вы хотите управлять секретом в Azure Key Vault.

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

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

  6. Выберите Добавить.

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

Авторизация запросов

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

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

Совет

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

Выполнение проверок из кода приложения

При выполнении проверка авторизации в коде приложения можно использовать сведения о утверждениях, которые Служба приложений аутентификации. Внедренный x-ms-client-principal заголовок содержит объект JSON в кодировке Base64 с утверждениями, утверждаемые о вызывающем объекте. По умолчанию эти утверждения проходят сопоставление утверждений, поэтому имена утверждений могут не всегда совпадать с тем, что вы увидите в маркере. Например, tid вместо этого утверждение сопоставляется http://schemas.microsoft.com/identity/claims/tenantid .

Вы также можете работать непосредственно с базовым маркером доступа из внедренного заголовка x-ms-token-aad-access-token .

Использование встроенной политики авторизации

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

В этом разделе показано, как включить встроенные проверка с помощью API проверки подлинности Служба приложений версии 2. В настоящее время единственным способом настройки этих встроенных проверка является использование шаблонов Azure Resource Manager или REST API.

В объекте API конфигурация поставщика удостоверений Microsoft Entra содержит validation раздел, который может включать defaultAuthorizationPolicy объект, как в следующей структуре:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Свойство Description
defaultAuthorizationPolicy Группирование требований, которые должны выполняться для доступа к приложению. Доступ предоставляется на основе логического AND доступа по каждому из настроенных свойств. Когда allowedApplications и allowedPrincipals оба настроены, входящий запрос должен соответствовать обоим требованиям, чтобы быть принятым.
allowedApplications Список разрешений идентификаторов клиента строкового приложения, представляющий клиентский ресурс, вызывающий в приложение. Если это свойство настроено как массив nonempty, будут приняты только маркеры, полученные приложением, указанным в списке.

Эта политика оценивает appid или azp утверждает входящие маркеры, которые должны быть маркером доступа. См. справочник по утверждениям платформа удостоверений Майкрософт.
allowedPrincipals Группирование проверка, определяющих, может ли субъект, представленный входящим запросом, получить доступ к приложению. allowedPrincipals Удовлетворенность основывается на логических OR свойствах, настроенных им.
identities (под allowedPrincipals) Список разрешений идентификаторов строковых объектов, представляющих пользователей или приложений, имеющих доступ. Если это свойство настроено как массив nonempty, требование может быть удовлетворено, если пользователь или приложение, представленные запросом, allowedPrincipals указывается в списке. Существует ограничение в 500 символов в списке удостоверений.

Эта политика оценивает oid утверждение входящего маркера. См. справочник по утверждениям платформа удостоверений Майкрософт.

Кроме того, некоторые проверка можно настроить с помощью параметра приложения независимо от используемой версии API. Параметр WEBSITE_AUTH_AAD_ALLOWED_TENANTS приложения можно настроить с разделенным запятыми списком до 10 идентификаторов клиента (например, "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") требует, чтобы входящие токены были от одного из указанных клиентов, как указано tid в утверждении. Параметр WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL приложения можно настроить на "true" или "1", чтобы входящие маркеры включали oid утверждение. Этот параметр игнорируется и обрабатывается как true, если allowedPrincipals.identities он настроен (так как oid утверждение проверка против указанного списка удостоверений).

Запросы, которые завершаются сбоем этих встроенных проверка, получают HTTP-ответ403 Forbidden.

Настройка клиентских приложений для получения доступа к Службе приложений

В предыдущих разделах вы зарегистрировали Служба приложений или функцию Azure для проверки подлинности пользователей. В этом разделе объясняется, как регистрировать собственные клиенты или приложения управляющей программы в идентификаторе Microsoft Entra, чтобы они могли запрашивать доступ к API, предоставляемым Служба приложений от имени пользователей или самих себя, например в архитектуре N-уровня. Выполнение действий, описанных в этом разделе, не требуется, если вам нужна только проверка подлинности пользователей.

Собственное клиентское приложение

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

  1. В меню портала выберите идентификатор Microsoft Entra.

  2. В области навигации слева выберите Регистрация приложений> РегистрацияNew.

  3. На странице Регистрация приложения введите Имя для регистрации приложения.

  4. В разделе URI перенаправления выберите Общедоступный клиент (мобильный и классический) и введите URL-адрес <app-url>/.auth/login/aad/callback. Например, https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Выберите Зарегистрировать.

  6. После создания регистрации приложения скопируйте значение идентификатора приложения (клиент).

    Примечание.

    Для приложения Microsoft Store вместо этого используйте идентификатор безопасности пакета в качестве универсального код ресурса (URI).

  7. В области навигации>слева выберите разрешения API", чтобы добавить разрешение>my API.

  8. Выберите регистрацию приложения, созданную ранее для приложения Службы приложений. Если вы не видите регистрацию приложения, убедитесь, что вы добавили user_impersonation область в разделе "Создание регистрации приложения в идентификаторе Microsoft Entra" для приложения Служба приложений.

  9. В разделе Делегированные разрешения выберите user_impersonation и Добавить разрешения.

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

Управляющее клиентское приложение (вызовы между службами)

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

  1. В меню портала выберите идентификатор Microsoft Entra.
  2. В области навигации слева выберите Регистрация приложений> РегистрацияNew.
  3. На странице Регистрация приложения введите Имя для регистрации приложения.
  4. Для управляющего приложения не требуется URI перенаправления, поэтому это поле можно оставить пустым.
  5. Выберите Зарегистрировать.
  6. После создания регистрации приложения скопируйте значение идентификатора приложения (клиент).
  7. В области навигации слева выберите сертификаты и секреты>секретов>клиента Создать секрет клиента.
  8. Введите описание, срок действия и нажмите кнопку Добавить.
  9. Скопируйте значение секрета клиента в поле "Значение". Он не будет отображаться еще раз, когда вы перейдете с этой страницы.

Теперь вы можете запросить маркер доступа с помощью идентификатора клиента и секрета клиента, присвоив параметру resource значение URI идентификатора приложения для целевого приложения. Затем полученный маркер доступа можно представить целевому приложению с помощью стандартного заголовка авторизации OAuth 2.0, а проверка подлинности Служба приложений будет проверяться и использовать маркер, как обычно, чтобы указать, что вызывающий объект (в данном случае приложение, а не пользователь) проходит проверку подлинности.

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

  1. Определите роль приложения в манифесте регистрации, который определяет защищаемую Службу приложений или приложение-функцию.
  2. На странице регистрации приложения, которое представляет требующего авторизации клиента, выберите Разрешения API>Добавить разрешение>Мои API.
  3. Выберите созданную ранее регистрацию приложения. Если регистрация приложения здесь не отображается, убедитесь, что вы добавили роль приложения.
  4. В разделе Разрешения приложения выберите созданную ранее роль приложения, а затем выберите Добавить разрешения.
  5. Обязательно установите флажок Предоставить согласие администратора, чтобы разрешить клиентскому приложению запрашивать разрешение.
  6. Как и в предыдущем сценарии (еще до добавления ролей), теперь вы можете запросить маркер доступа для того же целевого объекта resource, и этот маркер доступа будет содержать утверждение roles со списком ролей приложения, которые утверждены для клиентского приложения.
  7. В целевом Служба приложений или коде приложения-функции теперь можно проверить наличие ожидаемых ролей в маркере (это не выполняется Служба приложений аутентификации). Дополнительные сведения см. в разделе Access user claims (Доступ к утверждениям пользователя).

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

Рекомендации

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

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

Миграция на Microsoft Graph

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

  1. Обновите URL-адрес издателя, чтобы включить суффикс "/v2.0", если он еще не установлен.

  2. Удалите запросы на разрешения Azure AD Graph из конфигурации входа. Свойства для изменения зависят от используемой версии API управления:

    • Если вы используете API версии 1 (/authsettings), это будет в массиве additionalLoginParams .
    • Если вы используете API версии 2 (/authsettingsV2), это будет в массиве loginParameters .

    Необходимо удалить любую ссылку на "https://graph.windows.net", например. Это включает resource параметр (который не поддерживается конечной точкой "/v2.0") или какие-либо область, которые вы специально запрашиваете из Azure AD Graph.

    Вам также потребуется обновить конфигурацию, чтобы запросить новые разрешения Microsoft Graph, настроенные для регистрации приложения. Вы можете использовать область по умолчанию, чтобы упростить эту настройку во многих случаях. Для этого добавьте новый параметр scope=openid profile email https://graph.microsoft.com/.defaultвхода.

При выполнении этих изменений при попытке входа Служба приложений проверка подлинности больше не будет запрашивать разрешения на Azure AD Graph, а вместо этого будет получать маркер для Microsoft Graph. Любое использование этого маркера из кода приложения также должно быть обновлено в соответствии с рекомендациями, предоставленными идентификатором Microsoft Entra.

Дальнейшие действия