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

Настройка приложения Служба приложений или Функции 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) или использовать существующую регистрацию, созданную отдельно (вариант 2).

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

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

Примечание.

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

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

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

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

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

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

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

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

Выберите один из вариантов:

  • Выберите существующую регистрацию приложения в этом каталоге и выберите регистрацию приложения из раскрывающегося списка.

  • Укажите сведения о существующей регистрации приложения и укажите:

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

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

Во время регистрации в разделе 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 идентификаторов приложений см. в рекомендациях по обеспечению безопасности свойств приложений в идентификаторе Microsoft Entra ID.

  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-dddd2222eeee.

Для этого параметра может потребоваться, чтобы входящие маркеры были от одного из указанных клиентов, как указано в утверждении tid . Параметр WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL приложения можно настроить или true1 требовать, чтобы входящие маркеры включали oid утверждение. Если allowedPrincipals.identities этот параметр настроен, этот параметр игнорируется и обрабатывается как true, так как oid утверждение проверяется на соответствие указанному списку удостоверений.

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

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

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

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

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

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

  2. В области навигации слева выберите "Управление> Регистрация приложений", а затем нажмите кнопку "Создать регистрацию".

  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". Затем нажмите кнопку "Добавить разрешение>" Мои API".

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

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

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

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

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

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

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

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

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

  2. На регистрации приложения, представляющего клиента, которому требуется авторизоваться, выберите разрешения>API, чтобы добавить разрешение>my API.

  3. Выберите регистрацию приложения, созданную ранее. Если вы не видите регистрацию приложения, убедитесь, что вы добавили роль приложения.

  4. В разделе "Разрешения приложения" выберите роль приложения, созданную ранее. Затем выберите пункт Добавить разрешения.

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

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

В целевом Служба приложений или коде приложения-функции теперь можно проверить наличие ожидаемых ролей в маркере. Служба приложений проверка подлинности не выполняется. Дополнительные сведения см. в разделе Access user claims (Доступ к утверждениям пользователя).

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

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

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

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

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

Некоторые старые приложения могут быть настроены с зависимостью от нерекомендуемого Azure AD Graph, который планируется для полного выхода на пенсию. Например, код приложения может вызвать Azure AD Graph для проверки членства в группах в рамках фильтра авторизации в конвейере ПО промежуточного слоя. Приложения должны перейти на Microsoft Graph. Дополнительные сведения см. в статье "Перенос приложений из Azure AD Graph в Microsoft 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. Любое использование этого маркера из кода приложения также необходимо обновить, как описано в разделе "Перенос приложений из Azure AD Graph в Microsoft Graph".

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