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

• Azure Active Directory
• Facebook
• Google
• Twitter
• Поставщик OpenID Connect
• Вход с помощью Apple (предварительная версия)

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

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

• Автоматическое создание регистрации приложения
• Использование существующей регистрации, созданной отдельно

Примечание

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

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

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

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

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

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

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

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

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

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

6. Нажмите кнопку Добавить.

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

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

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

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

Создание регистрации приложения в Azure AD для приложения Службы приложений

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

• Идентификатор клиента
• Tenant ID
• секрет клиента (необязательно);
• универсальный код ресурса (URI) идентификатора приложения.

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

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

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

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

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

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

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

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

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

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

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

   Значение сохраняется автоматически.

10. Нажмите Добавить группу.

    1. В поле Добавить группуURI идентификатора приложения — это значение, заданное на предыдущем шаге. Выберите Сохранить и продолжить.
    2. В разделе Имя области введите user_impersonation.
    3. В текстовых полях введите имя и описание области согласия, которые пользователи должны видеть на странице согласия. Например, введите Доступ к <имя приложения>.
    4. Выберите Добавить область.

11. (Необязательно) Чтобы создать секрет клиента, выберите Сертификаты и секреты>Секреты клиента>Новый секрет клиента. Введите описание, срок действия и нажмите кнопку Добавить. Скопируйте значение секрета клиента, показанное на странице. Он больше не будет отображаться.

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

Включение Azure Active Directory в приложение Службы приложений

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

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

3. В раскрывающемся списке поставщиков удостоверений выберите пункт Майкрософт.

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

   Поле	Описание
   Идентификатор приложения (клиента)	Используйте идентификатор приложения (клиент) регистрации приложения.
   Секрет клиента	Используйте секрет клиента, созданный при регистрации приложения. В этом случае используется гибридный поток, а Служба приложений возвращает маркеры доступа и обновления. Если секрет клиента не задан, используется неявный поток и возвращается только маркер идентификатора. Эти маркеры отправляются поставщиком и хранятся в хранилище маркеров EasyAuth.
   Url-адрес издателя	Используйте <authentication-endpoint>/<tenant-id>/v2.0 и замените значение <конечная_точка_проверки_подлинности>конечной точкой проверки подлинности облачной среды (например, https://login.microsoftonline.com" для глобальной среды Azure). Также замените <идентификатор_клиента>идентификатором каталога (клиента), в котором была создана регистрация приложения. Это значение используется для перенаправления пользователей в правильный клиент Azure AD, а также для скачивания соответствующих метаданных, чтобы определить, например, соответствующие ключи подписей маркера и значение утверждения поставщика маркеров. Для приложений, использующих Azure AD версии 1, исключите /v2.0 из URL-адреса.
   Разрешенные аудитории маркеров	Настроенный идентификатор приложения (клиента)всегда неявно считается разрешенной аудиторией. Если это облачное или серверное приложение и вы хотите принимать токены проверки подлинности из клиентского приложения Службы приложений (токен проверки подлинности можно получить в заголовке X-MS-TOKEN-AAD-ID-TOKEN), добавьте здесь идентификатор клиентского приложения (клиента).

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

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

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

6. Нажмите кнопку Добавить.

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

Дополнительные проверки (необязательно)

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

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

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

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}

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

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

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

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

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

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

1. На Портал Azure последовательно выберите Active Directory>Регистрация приложений>Новая регистрация.

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

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

   Примечание

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

4. Нажмите кнопку создания.

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

6. Выберите Разрешения API>Добавить разрешение>Мои API.

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

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

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

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

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

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

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

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

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

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

Примечание

Маркеры доступа, предоставляемые приложению с помощью EasyAuth, не имеют областей для других API, таких как Graph, даже если у приложения есть разрешения на доступ к этим API. Чтобы использовать эти API, необходимо с помощью Azure Resource Manager настроить возвращенный маркер так, чтобы его можно было применять для проверки подлинности в других службах. Дополнительные сведения см. в статье Руководство. Доступ к Microsoft Graph из защищенного приложения .NET от имени пользователя.

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

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

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

Следующие шаги

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

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