Цепочки учетных данных в клиентской библиотеке удостоверений Azure для Java

Статья
11/12/2024

Клиентская библиотека удостоверений Azure предоставляет учетные данные — общедоступные классы, реализующие интерфейс TokenCredential библиотеки Azure Core. Учетные данные представляют собой отдельный поток проверки подлинности для получения маркера доступа из идентификатора Microsoft Entra. Эти учетные данные можно объединить в цепочку, чтобы сформировать упорядоченную последовательность механизмов проверки подлинности, которые необходимо предпринять.

Как работает цепочка учетных данных

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

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

Почему используются цепочки учетных данных

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

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

import com.azure.core.credential.TokenCredential;
import com.azure.identity.AzureCliCredentialBuilder;
import com.azure.identity.ManagedIdentityCredentialBuilder;

// Code omitted for brevity

TokenCredential credential = null;

// Set up credential based on environment (Azure or local development)
String environment = System.getenv("ENV");

if (environment != null && environment.equals("production")) {
    credential = new ManagedIdentityCredentialBuilder()
        .clientId(userAssignedClientId)
        .build();
} else {
    credential = new AzureCliCredentialBuilder()
        .build();
}

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

Выбор цепочки учетных данных

Существует две разрозненные философии для цепочки учетных данных:

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

Обзор DefaultAzureCredential

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

Порядок, в котором DefaultAzureCredential выполняется попытка учетных данных, следует.

Порядок	Подтверждение компетенции	Description
1	Среда	Считывает коллекцию переменных среды, чтобы определить, настроен ли субъект-служба приложений (пользователь приложения) для приложения. В этом случае использует эти значения для `DefaultAzureCredential` проверки подлинности приложения в Azure. Этот метод чаще всего используется в средах сервера, но также может использоваться при разработке локально.
2	Удостоверение рабочей нагрузки	Если приложение развернуто на узле Azure с включенным удостоверением рабочей нагрузки, выполните проверку подлинности этой учетной записи.
3	управляемое удостоверение;	Если приложение развернуто на узле Azure с включенным управляемым удостоверением, выполните проверку подлинности приложения в Azure с помощью этого управляемого удостоверения.
4	Кэш общих маркеров	Если разработчик прошел проверку подлинности в Azure, войдите в Visual Studio, выполните проверку подлинности приложения в Azure с помощью той же учетной записи. (Только Для Windows.)
5	IntelliJ	Если разработчик прошел проверку подлинности через Набор средств Azure для IntelliJ, выполните проверку подлинности этой учетной записи.
6	Azure CLI	Если разработчик прошел проверку подлинности в Azure с помощью команды Azure CLI `az login` , выполните проверку подлинности приложения в Azure с помощью той же учетной записи.
7	Azure PowerShell	Если разработчик прошел проверку подлинности в Azure с помощью командлета `Connect-AzAccount` Azure PowerShell, выполните проверку подлинности приложения в Azure с помощью той же учетной записи.
8	Интерфейс командной строки разработчика Azure	Если разработчик прошел проверку подлинности в Azure с помощью команды Azure Developer CLI `azd auth login` , выполните проверку подлинности с помощью этой учетной записи.

В самой простой форме можно использовать версию DefaultAzureCredential без параметров следующим образом:

import com.azure.identity.DefaultAzureCredential;
import com.azure.identity.DefaultAzureCredentialBuilder;

// Code omitted for brevity

DefaultAzureCredential credential = new DefaultAzureCredentialBuilder()
    .build();

Обзор ChainedTokenCredential

ChainedTokenCredential — это пустая цепочка, в которую добавляются учетные данные в соответствии с потребностями приложения. Например:

import com.azure.identity.AzureCliCredential;
import com.azure.identity.AzureCliCredentialBuilder;
import com.azure.identity.ChainedTokenCredential;
import com.azure.identity.ChainedTokenCredentialBuilder;
import com.azure.identity.ManagedIdentityCredential;
import com.azure.identity.ManagedIdentityCredentialBuilder;

// Code omitted for brevity

ManagedIdentityCredential miCredential = new ManagedIdentityCredentialBuilder()
    .clientId(userAssignedClientId)
    .build();
AzureCliCredential cliCredential = new AzureCliCredentialBuilder()
    .build();

ChainedTokenCredential credential = new ChainedTokenCredentialBuilder()
    .addLast(miCredential)
    .addLast(cliCredential)
    .build();

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

Схема, на которой показан поток проверки подлинности для экземпляра ChainedTokenCredential, состоящего из учетных данных управляемого удостоверения и учетных данных Azure CLI.

Совет

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

Руководство по использованию по DefaultAzureCredential

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

Определенная реализация учетных данных, например ManagedIdentityCredential.
Реализация, оптимизированная ChainedTokenCredential для среды Azure, в которой выполняется приложение.

Для этого есть следующие причины.

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

Отладка цепочки учетных данных

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

Для иллюстрации предположим, что для проверки подлинности запроса к учетной записи хранения BLOB-объектов используется без DefaultAzureCredential параметров. Приложение выполняется в локальной среде разработки, и разработчик прошел проверку подлинности в Azure с помощью Azure CLI. При запуске приложения в выходных данных отображаются следующие соответствующие записи:

[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential EnvironmentCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential WorkloadIdentityCredential is unavailable.
[ForkJoinPool.commonPool-worker-1] WARN com.microsoft.aad.msal4j.ConfidentialClientApplication - [Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd] Execution of class com.microsoft.aad.msal4j.AcquireTokenByClientCredentialSupplier failed: java.util.concurrent.ExecutionException: com.azure.identity.CredentialUnavailableException: ManagedIdentityCredential authentication unavailable. Connection to IMDS endpoint cannot be established.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential ManagedIdentityCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential SharedTokenCacheCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential IntelliJCredential is unavailable.
[main] INFO com.azure.identity.ChainedTokenCredential - Azure Identity => Attempted credential AzureCliCredential returns a token

В предыдущих выходных данных обратите внимание, что:

EnvironmentCredential, , WorkloadIdentityCredentialManagedIdentityCredentialSharedTokenCacheCredentialи IntelliJCredential каждый из них не удалось получить маркер доступа Microsoft Entra в этом порядке.
Вызов AzureCliCredential.getToken завершается успешно, как указано записью returns a token-suffixed. После AzureCliCredential успешного выполнения учетные данные за его пределами не были проверены.

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