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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Client ID
  • Идентификатор клиента
  • секрет клиента (необязательно);
  • 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. В неявных потоках предоставления и гибридных потоков включите маркеры идентификаторов, чтобы разрешить вход пользователей OpenID Connect из контейнерных приложений.

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

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

      1. В управляемом режиме выберите "Проверка подлинности".

      2. На странице проверки подлинности в конфигурациях платформы выберите "Добавить платформу".

      3. В разделе "Настройка платформ" выберите "Веб".

      4. В разделе "Настройка веб-сайта" в 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 идентификаторов приложений см. в справочнике по регистрации приложений.

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

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

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

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

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

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

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

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

Включение идентификатора Microsoft Entra в приложении контейнера

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

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

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

  4. Для типа регистрации приложений можно выбрать выбор существующей регистрации приложения в этом каталоге , который автоматически собирает необходимые сведения о приложении. Если регистрация выполняется из другого клиента или у вас нет разрешения на просмотр объекта регистрации, выберите вариант Provide the details of an existing app registration (Указать сведения о существующей регистрации приложения). Для этого параметра необходимо указать следующие сведения о конфигурации:

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

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

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

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

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

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

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

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

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

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

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

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

  1. В портал Azure выберите "Добавить> идентификатор Microsoft Entra">Регистрация приложений.

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

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

    Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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