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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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": []
            }
        }
    }
}

Кроме того, некоторые проверки можно настроить с помощью параметра приложения независимо от используемой версии 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.

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

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

• Руководство. Проверка подлинности и авторизация пользователей в веб-приложении, которое обращается к Службе хранилища Azure и Microsoft Graph
• Руководство по сквозной проверке подлинности и авторизации в службе приложений Azure