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

  • Статья
  • Чтение занимает 11 мин

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. В меню портала выберите Azure Active Directory.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 2. Включение Azure Active Directory в приложении Служба приложений

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

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

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

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

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

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

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

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

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

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

Добавление настроенной политики авторизации

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

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

В объекте API конфигурация поставщика удостоверений Azure Active Directory содержит validation раздел, который может включать 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 для проверки подлинности пользователей. В этом разделе объясняется, как регистрировать собственные клиенты или управляющие программы в Azure AD, чтобы они могли запрашивать доступ к API, предоставляемым вашим Служба приложений от имени пользователей или от имени самих себя, например в N-уровневой архитектуре. Выполнение действий, описанных в этом разделе, не требуется, если вам нужна только проверка подлинности пользователей.

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

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

  1. В меню портала выберите Azure Active Directory.

  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 в разделе Создание регистрации приложения в Azure AD для приложения Службы приложений.

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

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

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

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

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

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

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

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

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

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

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

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

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