Проверка подлинности и авторизация в Контейнерах приложений Azure

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

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

Зачем использовать встроенную проверку подлинности?

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

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

К преимуществам относятся:

  • Контейнеры приложений Azure предоставляют доступ к разным встроенным поставщикам проверки подлинности.
  • Встроенные функции проверки подлинности не обязывают использовать конкретный язык или пакет SDK, не требуют опыта безопасности или даже написания любого кода.
  • Вы можете интегрироваться с несколькими поставщиками, включая идентификатор Microsoft Entra, Facebook, Google и X.

Примечание.

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

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

Поставщики удостоверений

Container Apps использует федеративную идентификацию, при которой сторонний поставщик удостоверений управляет удостоверениями пользователей и процессом проверки подлинности для вас. По умолчанию доступны следующие поставщики удостоверений:

Поставщик Конечная точка входа Практическое руководство
Платформа удостоверений Майкрософт /.auth/login/aad Платформа удостоверений Майкрософт
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
X /.auth/login/x X
Любой поставщик OpenID Connect /.auth/login/<providerName> OpenID Connect

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

Рекомендации по использованию встроенной проверки подлинности

Эта возможность должна использоваться только с протоколом HTTPS. Убедитесь, что в параметрах ingress вашего контейнерного приложения отключен allowInsecure.

Для контейнера приложения можно настроить проверку подлинности с ограничением или без ограничения доступа к содержимому и API-интерфейсам сайта. Чтобы разрешить доступ к приложению только пользователям, прошедшим проверку подлинности, установите для параметра Ограничить доступ значение Требовать проверку подлинности. Чтобы включить проверку подлинности, не ограничивая доступ, задайте для параметра Ограничить доступ значение Разрешить доступ без проверки подлинности.

По умолчанию каждое приложение контейнера выдает собственный уникальный файл cookie или маркер для проверки подлинности. Вы также можете предоставить собственные ключи подписи и шифрования.

Архитектура функций

Компонент промежуточного ПО для аутентификации и авторизации — это функция платформы, которая выполняется как sidecar-контейнер в каждой реплике вашего приложения. При включении приложение обрабатывает каждый входящий HTTP-запрос после прохождения через уровень безопасности.

Схема архитектуры, на которой показано, как запросы перехватываются контейнером sidecar, который взаимодействует с поставщиками удостоверяющих данных, прежде чем разрешить передачу трафика в контейнер приложения

ПО промежуточного слоя платформы выполняет для приложения несколько задач:

  • Проверка подлинности пользователей и клиентов с помощью указанных поставщиков удостоверений
  • Управляет аутентифицированным сеансом
  • вставка сведений об удостоверении в заголовки HTTP-запросов.

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

Поток аутентификации

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

  • Без SDK поставщика (поток, управляемый сервером или серверный поток): приложение делегирует федеративную аутентификацию службе Container Apps. Обычно делегация применяется для браузерных приложений, которые предоставляют пользователю страницу поставщика для входа в систему.

  • С SDK поставщика (поток, управляемый клиентом или клиентский поток): приложение вручную выполняет вход пользователей у поставщика, а затем отправляет токен аутентификации в Container Apps для проверки. Такой подход является типичным для приложений без браузера, которые не предоставляют пользователю страницу поставщика для входа. Например, собственное мобильное приложение авторизует пользователей с помощью SDK поставщика.

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

В таблице показаны шаги потока проверки подлинности.

Этап Без использования пакета SDK поставщика С использованием пакета SDK поставщика
1. Вход пользователя Перенаправляет клиента к /.auth/login/<PROVIDER>. Клиентский код напрямую выполняет вход пользователя с помощью SDK поставщика и получает токен аутентификации. Дополнительные сведения см. в документации поставщика.
2. После аутентификации Поставщик перенаправляет клиент к /.auth/login/<PROVIDER>/callback. Код клиента отправляет маркер от поставщика в /.auth/login/<PROVIDER> для проверки.
3. Установка проверенного сеанса Container Apps добавляет в ответ аутентифицированный файл cookie. Container Apps возвращает клиентскому коду собственный токен аутентификации.
4. Предоставлять аутентифицированный контент Клиент включает файлы cookie, прошедшие проверку подлинности, в последующие запросы (автоматически обрабатываются браузером). Код клиента предоставляет токен проверки подлинности в заголовке X-ZUMO-AUTH.

Для клиентских браузеров Container Apps может автоматически перенаправлять всех неаутентифицированных пользователей на /.auth/login/<PROVIDER>. Вы также можете показать пользователям одну или несколько /.auth/login/<PROVIDER> ссылок для входа в ваше приложение через выбранного провайдера.

Поведение авторизации

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

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

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

  • Требовать проверку подлинности: в этом варианте любой трафик к приложению, не прошедший проверку подлинности, отклоняется. Такой отказ может представлять собой действие перенаправления к одному из настроенных поставщиков удостоверений. В таких случаях клиент браузера перенаправляется в /.auth/login/<PROVIDER> для выбранного поставщика. Если анонимный запрос поступает из нативного мобильного приложения, в ответ возвращается HTTP 401 Unauthorized. Можно также настроить отклонение так, чтобы для всех запросов возвращался ответ HTTP 401 Unauthorized или HTTP 403 Forbidden.

    В этом случае в клиентском приложении не нужен код для проверки подлинности. Более точная авторизация, например авторизация для конкретной роли, может выполняться путем проверки утверждений пользователя (см. раздел Access user claims (Доступ к утверждениям пользователя)).

    Внимание

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

    Примечание.

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

Настройка входа и выхода

Проверка подлинности контейнерных приложений предоставляет встроенные конечные точки для входа и выхода. Если эта функция включена, эти конечные точки доступны в /.auth префиксе маршрута в приложении контейнера.

Использование нескольких поставщиков входа

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

Во-первых, на странице Authentication / Authorization (Проверка подлинности и авторизация) на портале Azure настройте все поставщики удостоверений, которые нужно включить.

В раскрывающемся списке Action to take when request is not authenticated (Предпринимаемое действие, если проверка подлинности для запроса не выполнена) выберите Разрешить анонимные запросы (нет действия).

На странице входа, на панели навигации или в любом другом расположении приложения добавьте ссылку входа для каждого включенного поставщика (/.auth/login/<provider>). Например:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>

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

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

Для клиентских приложений диспетчер маршрутов на стороне клиента может перехватывать маршруты /.auth/login/, из-за чего сайдкар аутентификации не будет получать запросы. Убедитесь, что конфигурация маршрутизации на стороне клиента позволяет серверу обрабатывать эти маршруты.

Чтобы после входа в систему перенаправить пользователя на пользовательский URL-адрес, используйте параметр строки запроса post_login_redirect_uri (не путать с URI перенаправления в конфигурации поставщика удостоверений). Например, чтобы перенаправить пользователя к /Home/Index после входа в систему, используйте следующий код HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Вход, инициируемый клиентом

При входе, инициируемом клиентом, приложение выполняет вход пользователя через поставщика удостоверений, используя пакет SDK для конкретного поставщика. Затем код приложения отправляет полученный маркер проверки подлинности в Контейнеры приложений на проверку (см. поток проверки подлинности) с помощью запроса HTTP POST.

Чтобы проверить токен поставщика, сначала необходимо настроить контейнерное приложение для работы с нужным поставщиком. Получив токен проверки подлинности у своего поставщика, во время выполнения отправьте токен по адресу /.auth/login/<provider> для проверки. Например:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Формат токена незначительно отличается в соответствии с поставщиком. Дополнительные сведения см. в таблице, приведенной ниже.

Значение провайдера Требуется в тексте запроса Комментарии
aad {"access_token":"<ACCESS_TOKEN>"} Свойства id_token, refresh_token и expires_in являются необязательными.
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} или {"authentication_token": "<TOKEN>" Предпочтительнее использовать authentication_token, а не access_token. Свойство expires_in необязательное.
При запросе токена из служб Live всегда запрашивайте область действия wl.basic.
google {"id_token":"<ID_TOKEN>"} Свойство authorization_code необязательное. Указание значения authorization_code добавляет токен доступа и токен обновления в хранилище токенов. Если указано свойство authorization_code, оно может сопровождаться свойством redirect_uri.
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Используйте допустимый токен доступа пользователя из Facebook.
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCESS_TOKEN_SECRET>"}

Если токен поставщика успешно проверен, API возвращает в теле ответа authenticationToken, это ваш токен сеанса.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Получив этот токен сеанса, вы можете получить доступ к защищенным ресурсам приложений, добавив заголовок X-ZUMO-AUTH к HTTP-запросам. Например:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Выход из сеанса

Пользователи могут выйти из службы, отправив GET запрос в конечную точку приложения /.auth/logout . Запрос GET выполняет следующие действия.

  • Очищает файлы cookie проверки подлинности в текущем сеансе.
  • Удаляет текущие маркеры пользователя из хранилища маркеров.
  • Выполняет выход из системы на стороне сервера у поставщика удостоверений для Microsoft Entra ID и Google.

Вот простая ссылка для выхода на веб-странице:

<a href="/.auth/logout">Sign out</a>

По умолчанию успешный выход перенаправляет клиента на URL-адрес /.auth/logout/done. Можно изменить страницу перенаправления после выхода, добавив параметр запроса post_logout_redirect_uri. Например:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Обязательно закодируйте значение post_logout_redirect_uri.

URL-адрес должен размещаться в том же домене, если используются полные URL-адреса.

Доступ к утверждениям пользователей в коде приложения

Для всех языковых сред Container Apps делает утверждения из входящего токена доступными для кода вашего приложения. Эти утверждения внедряются в заголовки запроса, которые присутствуют и для пользователей, прошедших проверку подлинности, и для клиентских приложений. Внешние запросы не могут задавать эти заголовки, поэтому они присутствуют только в том случае, если их задаёт Container Apps. Некоторые примеры заголовков включают:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

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

Помимо этих заголовков идентификации, приложение может получать доступ к токенам аутентификации (например, токенам доступа Microsoft Entra) через заголовки запроса, такие как X-MS-TOKEN-AAD-ACCESS-TOKEN. Чтобы сделать эти маркеры доступными, необходимо включить хранилище маркеров в рамках параметров проверки подлинности приложения контейнера. После включения запросы, отправляемые вашему приложению, содержат дополнительные заголовки, связанные с токенами, в зависимости от настроенного поставщика удостоверений и потока аутентификации.

Примечание.

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

Защита конечных точек с помощью EasyAuth

При защите конечных точек с помощью проверки подлинности azure Container Apps необходимо зарегистрировать приложение с помощью идентификатора Microsoft Entra и настроить параметры проверки подлинности.

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

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

    az ad app create \
  --display-name <APP_DISPLAY_NAME> \
  --sign-in-audience AzureADMyOrg
---

  2. Разрешите приложению выдавать токены идентификатора. Этот шаг необходим для поддержки Easy Auth.

    az ad app update \
  --id <APPLICATION_ID> \
  --enable-id-token-issuance true

  3. Добавьте URI перенаправления для обратного вызова Easy Auth.

    az ad app update \
  --id <APP_ID> \
  --web-redirect-uris "https://<APP-NAME>.<ENVIRONMENT-NAME>.<REGION>.azurecontainerapps.io/.auth/login/aad/callback"
---

  4. Создание секрета клиента

    az ad app credential reset \
  --id <APP_ID>" \
  --display-name "<APP_NAME>-Secret"
---

  5. Создайте учетную запись службы для вашего приложения.

    az ad sp create --id <APP_ID>
---

  6. Настройте приложение-контейнер для использования аутентификации Microsoft Entra ID.

    Убедитесь, что значение, которое вы указали для заполнителя <APP_NAME>, является именем приложения, настроенного для работы с EasyAuth.

    az containerapp auth microsoft update \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --client-id <APP_ID> \
  --client-secret <CLIENT_SECRET> \
  --tenant-id <TENANT_ID> \
  --yes

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

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

  • Last updated on