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

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

  • Статья

Примечание.

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

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

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

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

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

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

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

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

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

  3. На странице "Добавление поставщика удостоверений" выберите Корпорацию Майкрософт в качестве поставщика удостоверений для входа в удостоверения Майкрософт и Microsoft Entra.

  4. Для типа клиента выберите конфигурацию рабочей силы (текущий клиент) для сотрудников и бизнес-гостей или выберите внешнюю конфигурацию для потребителей и бизнес-клиентов.

Выбор регистрации приложения

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

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

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

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

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

Вариант 1. Создание и использование регистрации нового приложения

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

Примечание.

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

Введите имя для регистрации нового приложения.

Выберите тип поддерживаемой учетной записи:

  • Текущий клиент — один клиент. Учетные записи только в этом каталоге организации. Все учетные записи пользователей и гостевые учетные записи в вашем каталоге могут использовать ваше приложение или API. Используйте этот вариант, если целевой аудиторией являются сотрудники вашей организации.
  • Любой каталог Microsoft Entra — Multitenant. Учетные записи в любом каталоге организации. Все пользователи с рабочей или учебной учетной записью корпорации Майкрософт могут использовать приложение или API. Сюда относятся учебные заведения и предприятия, которые используют Office 365. Используйте этот параметр, если целевая аудитория — бизнес или образовательные клиенты, а также для включения мультитенантности.
  • Любой каталог Microsoft Entra и личные учетные записи Майкрософт. Учетные записи в любом каталоге организации и личных учетных записях Майкрософт (например, Skype, Xbox). Все пользователи с рабочей, учебной или личной учетной записью Майкрософт могут использовать ваше приложение или API. Сюда относятся школы и компании, использующие Office 365, а также личные учетные записи, которые используются для входа в службы, например Xbox и Скайп. Используйте этот параметр, чтобы использовать самый широкий набор удостоверений Майкрософт и включить мультитенантность.
  • Только личные учетные записи Майкрософт. Личные учетные записи, используемые для входа в такие службы, как Xbox и Skype. Используйте этот параметр, чтобы использовать самый широкий набор удостоверений Майкрософт.

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

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

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

Любое из следующих:

  • Выберите существующую регистрацию приложения в этом каталоге и выберите регистрацию приложения в раскрывающемся списке.
  • Выберите "Указать сведения о существующей регистрации приложения" и укажите:
    • Код приложения (клиента).
    • Секрет клиента (рекомендуется). Значение секрета, которое приложение использует для подтверждения удостоверения при запросе маркера. Это значение сохраняется в конфигурации приложения в качестве параметра приложения с помощью слотов с именем MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Если секрет клиента не задан, операции входа из службы используют неявный поток предоставления OAuth 2.0, который не рекомендуется.
    • URL-адрес издателя, который принимает форму <authentication-endpoint>/<tenant-id>/v2.0. Замените <authentication-endpoint> значение конечной точки проверки подлинности, относящееся к облачной среде. Например, клиент рабочей силы в глобальной среде Azure будет использовать "https://login.microsoftonline.com" в качестве конечной точки проверки подлинности.

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

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

После создания измените регистрацию приложения:

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

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

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

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

  3. (Рекомендуется) Чтобы создать секрет клиента, выполните приведенные действия.

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

  4. (Необязательно) Чтобы добавить несколько URL-адресов ответа, выберите Проверка подлинности.

Настройка дополнительных проверок

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

Для требования клиентского приложения выберите, следует ли:

  • Разрешить запросы только из этого приложения
  • Разрешить запросы из конкретных клиентских приложений
  • Разрешить запросы из любого приложения (не рекомендуется)

Для требования удостоверения выберите, следует ли:

  • Разрешить запросы от любого удостоверения
  • Разрешить запросы из определенных удостоверений

Для требования клиента выберите, следует ли:

  • Разрешить запросы только из клиента издателя
  • Разрешить запросы от определенных клиентов
  • Использование ограничений по умолчанию на основе издателя

Ваше приложение может по-прежнему принимать дополнительные решения об авторизации в коде. Дополнительные сведения см. в статье "Использование встроенной политики авторизации".

Настройка параметров проверки подлинности

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

Для ограничения доступа решите, следует ли:

  • Требуется аутентификация
  • Разрешить доступ без проверки подлинности

Для запросов, не прошедших проверку подлинности

  • Http 302 Найдено перенаправление: рекомендуется для веб-сайтов
  • Http 401 Неавторизован: рекомендуется для API
  • HTTP 403 — запрещено
  • Http 404 Не найден

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

Добавление поставщика удостоверений

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

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

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

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

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

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

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

Совет

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

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

При проверке авторизации в коде приложения можно использовать сведения о утверждениях, которые Служба приложений проверка подлинности предоставляется. Внедренный 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 идентификаторов клиента (например, aaaabbbb-0000-cccc-1111-dd222eeee), чтобы требовать, чтобы входящие маркеры были из одного из указанных клиентов, как указано 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 в регистрацию приложения.

  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.
  • Предоставьте каждому приложению Службы приложений свои разрешения и согласие.
  • Создайте отдельные регистрации приложений для отдельных слотов развертывания, чтобы не предоставлять общий доступ к разрешениям в средах. Это поможет предотвратить проблемы с рабочим приложением при тестировании нового кода.

Миграция на 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.

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