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

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

• Отдельные учетные данные обеспечивают скорость и уверенность. Если они завершаются ошибкой, вы знаете, что учетные данные не прошли проверку подлинности.
• Цепочки обеспечивают резервные копии. Если учетные данные не удается пройти проверку подлинности, выполняется попытка выполнить следующую проверку подлинности.

Проектирование потоков проверки подлинности

При использовании клиентских библиотек пакета SDK Azure сначала необходимо выполнить проверку подлинности в Azure. Существует множество вариантов проверки подлинности, таких как средства и идентификаторы, используемые в команде разработки, рабочие процессы автоматизации, такие как тестирование и CI/CD, а также платформы размещения, такие как Служба приложений Azure.

Выберите следующие распространенные прогрессии для потока проверки подлинности:

• DefaultAzureCredential Используйте команды, разработчики которых используют различные идентификаторы и среды CL Для проверки подлинности в Azure. Это обеспечивает максимальную гибкость. Эта гибкость предоставляется по стоимости производительности, чтобы проверить учетные данные в цепочке до тех пор, пока не будет выполнено успешно.

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

• ChainedTokenCredential Используйте команды, которые имеют строгий и ограниченный выбор инструментов. Например, все они проходят проверку подлинности и используют одну и ту же интегрированную среду разработки или CLI. Это позволяет команде выбрать точные учетные данные и порядок, который по-прежнему обеспечивает гибкость, но при сниженной производительности.

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

• Для команд с определенными учетными данными во всех средах оператор потока управления, например if/else, позволяет узнать, какие учетные данные были выбраны в каждой среде.

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

Как работает связанное удостоверение

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

Использование DefaultAzureCredential для гибкости

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

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

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

import { DefaultAzureCredential } from "@azure/identity";
import { BlobServiceClient } from "@azure/storage-blob";

// Acquire a credential object
const credential = new DefaultAzureCredential();

const blobServiceClient = new BlobServiceClient(
    "https://<my_account_name>.blob.core.windows.net",
    credential
);

Учетные данные являются глобальными для среды

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

Как настроить DefaultAzureCredential

Чтобы исключить все Developer tool или Deployed service учетные данные, установите значение переменной среды AZURE_TOKEN_CREDENTIALS на prod или dev, соответственно. Если используется значение prod, основная цепочка учетных данных выглядит следующим образом:

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

Использование ChainedTokenCredential для детализации

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

import { 
    ChainedTokenCredential, 
    ManagedIdentityCredential, 
    AzureCliCredential 
} from "@azure/identity";

const credential = new ChainedTokenCredential(
    new ManagedIdentityCredential({ clientId: "<YOUR_CLIENT_ID>" }),
    new AzureCliCredential()
);

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

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

Чтобы выполнить отладку цепочки учетных данных, включите ведение журнала пакета SDK Для Azure.

Дополнительные ресурсы

• Azure CLI