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

Включение проверки подлинности и авторизации в приложениях контейнеров Azure с помощью идентификатора Microsoft Entra

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

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

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

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

  1. Войдите на портал Azure и перейдите в приложение.

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

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

    Секрет клиента создается и хранится в качестве секрета в приложении-контейнере.

  4. В списке срока действия секрета клиента выберите дату окончания срока действия.

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

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

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

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

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

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

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

Создайте регистрацию приложения в Microsoft Entra для вашего контейнерного приложения

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

  • Идентификатор клиента
  • Идентификатор клиента
  • секрет клиента (необязательно);
  • URI-адрес идентификатора приложения

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

  1. Войдите на портал Azure.

  2. Найдите и выберите "Приложения контейнеров", а затем выберите свое приложение. В области "Обзор " обратите внимание на URL-адрес приложения приложения. Вы используете его для настройки регистрации приложения Microsoft Entra.

  3. Выберите "Главная", чтобы вернуться на домашнюю страницу портала. Найдите и выберите Microsoft Entra ID.

  4. В области "Обзор" выберите "Добавить" и выберите "Регистрация приложения".

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

    2. В разделе URI перенаправления выберите Веб-сайт и введите следующее. Замените \<APP_URL\> на URL-адрес приложения, который вы указали ранее.

      <APP_URL>/.auth/login/aad/callback

      Например: https://<CONTAINER_APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION_NAME>.azurecontainerapps.io/.auth/login/aad/callback

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

    4. В разделе "Управление " в области слева выберите "Проверка подлинности( предварительная версия)".

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

  5. Перейдите к новой регистрации приложения.

    1. В области обзора скопируйте идентификатор приложения (клиента) и идентификатор каталога (клиента) для последующего копирования.
    2. (Необязательно) Если вы еще не добавили URI перенаправления в регистрацию приложения, это можно сделать сейчас.

      1. В разделе "Управление " в области слева выберите "Проверка подлинности( предварительная версия)".

      2. В области проверки подлинности (предварительная версия) выберите пункт "Добавить URI перенаправления".

      3. В области выбора платформы для добавления URI перенаправления выберите Веб-сайт.

      4. В области "Добавить URI перенаправления " в поле URI перенаправления введите следующее. Замените \<APP_URL\> на URL-адрес приложения, который вы указали ранее.

        <APP_URL>/.auth/login/aad/callback

        Например: https://<CONTAINER_APP_NAME>.<HOSTNAME>.<LOCATION>.azurecontainerapps.io/.auth/login/aad/callback

      5. Выберите Настроить.

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

      1. Выберите Добавить рядом с URI идентификатора приложения.

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

        Для однотенантного приложения можно использовать значение по умолчанию в формате api://<APPLICATION_CLIENT_ID>. Вы также можете указать более удобочитаемый универсальный код ресурса (URI), например https://contoso.com/api, на основе одного из проверенных доменов для клиента. Для мультитенантного приложения необходимо указать специальный URI. Дополнительные сведения о принятых форматах для URI идентификаторов приложений см. в рекомендациях по обеспечению безопасности свойств приложений в идентификаторе Microsoft Entra ID.

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

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

      3. В области «Добавить область»URI идентификатора приложения — это значение, заданное на предыдущем шаге.

      4. Выберите Сохранить и продолжить.

      5. В поле Имя области введите user_impersonation.

      6. Введите отображаемое имя согласия администратора и описание согласия администратора, которые вы хотите, чтобы администраторы видели на странице согласия. Пример отображаемого имени согласия — Доступ <название-приложения>.

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

    5. В разделе Управление в области слева выберите Сертификаты и секреты.
      1. В области сертификатов и секретов выберите секреты клиента.
      2. Щелкните Создать секрет клиента.
      3. Введите описание, а затем в поле "Срок действия" выберите дату окончания срока действия.
      4. Выберите Добавить.
      5. Скопируйте значение секрета клиента, показанное на странице. Сайт не будет отображать его вам снова.

Включите Microsoft Entra ID в вашем контейнерном приложении

  1. Войдите на портал Azure и перейдите в приложение.

  2. В области слева в разделе "Безопасность" выберите "Проверка подлинности". Выберите "Добавить поставщика".

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

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

    Предупреждение

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

    Setting Описание
    Идентификатор приложения (клиента) Используйте идентификатор приложения (клиент) для регистрации учетной записи приложения.
    Секрет клиента Используйте секрет клиента, созданный при регистрации приложения. Секреты клиента используют гибридный поток авторизации, а приложение возвращает токены доступа и обновления. Если секрет клиента не задан, используется implicit flow, и возвращается только ID-токен. Поставщик отправляет маркеры, и они хранятся в хранилище маркеров EasyAuth.
    URL-адрес издателя Используйте <AUTHENTICATION-ENDPOINT>/<TENANT-ID>/v2.0. Замените <AUTHENTICATION-ENDPOINT>конечной точкой проверки подлинности для облачной среды (например, "https://login.microsoftonline.com" для глобальной службы Azure). Замените <идентификатор TENANT-ID идентификатором>каталога (клиента), в котором была создана регистрация приложения. Это значение используется для перенаправления пользователей к правильному арендатору Microsoft Entra и для загрузки метаданных, чтобы определить соответствующие ключи подписания токенов и значения утверждений издателя токенов, например. Для приложений, использующих Azure Active Directory версии 1, исключите /v2.0 из URL-адреса.
    Разрешенные аудитории токенов Настроенный идентификатор приложения (клиента)всегда неявно считается допустимой аудиторией. Если это значение указывает на облачное или серверное приложение, и вы хотите принимать токены проверки подлинности из клиентского контейнерного приложения (токен проверки подлинности можно получить в заголовке X-MS-TOKEN-AAD-ID-TOKEN), добавьте здесь идентификатор приложения (клиента) для клиентского приложения.

    Секрет клиента хранится в качестве секрета в приложении контейнера.

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

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

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

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

Настройте клиентские приложения для доступа к вашему контейнерному приложению

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

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

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

  1. На портале Azure найдите и выберите идентификатор Microsoft Entra.

  2. В области "Обзор " выберите "Добавить>регистрацию приложения".

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

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

    Примечание.

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

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

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

  7. В разделе Управление в области слева выберите Разрешения API. Выберите Добавить разрешение>Мои API.

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

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

Клиентское приложение-демон (вызовы от службы к службе)

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

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

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

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

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

Работа с пользователями, прошедшими проверку подлинности

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

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

Общие сведения о проверке подлинности и авторизации

  • Last updated on