Проверка подлинности приложений JavaScript в службах Azure с помощью пакета SDK Azure для JavaScript

Если приложению необходимо получить доступ к ресурсу Azure (например, служба хранилища, Хранилищу ключей или Cognitive Services), приложение должно пройти проверку подлинности в Azure. Это верно для всех приложений, развернутых в Azure, развернутых локально или в процессе разработки на локальной рабочей станции разработчика. В этой статье описаны рекомендуемые подходы к проверке подлинности приложения в Azure при использовании пакета SDK Azure для JavaScript.

Рекомендуемый подход к проверке подлинности приложений

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

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

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

При создании приложений для Azure настоятельно рекомендуется использовать проверку подлинности на основе маркеров по секретам (строка подключения или ключам). Проверка подлинности на основе токенов предоставляется с помощью DefaultAzureCredential.

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

Используйте следующий пакет SDK:

• @azure/identity

DefaultAzureCredential

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

Дополнительные сведения об использовании класса DefaultAzureCredential описаны далее в этой статье в разделе Use DefaultAzureCredential в приложении.

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

При размещении в серверной среде каждое приложение должно быть назначено уникальное удостоверение приложения для каждой среды. В Azure удостоверение приложения представлено субъектом-службой, специальным типом субъекта безопасности, предназначенным для идентификации и проверки подлинности приложений в Azure. Тип субъекта-службы, используемого для приложения, зависит от того, где работает ваше приложение.

Проверка подлинности во время локальной разработки

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

Использование DefaultAzureCredential в приложении

Чтобы использовать DefaultAzureCredential в приложении JavaScript, добавьте пакет @azure/identity в приложение.

npm install @azure/identity

Затем в следующем примере кода показано, как создать экземпляр DefaultAzureCredential объекта и использовать его с клиентским классом Azure SDK, в этом случае blobServiceClient, используемый для доступа к хранилищу BLOB-объектов.

// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  new DefaultAzureCredential()
);

DefaultAzureCredential автоматически обнаруживает механизм проверки подлинности, настроенный для приложения, и получает необходимые маркеры для проверки подлинности приложения в Azure. Если приложение использует несколько клиентов ПАКЕТА SDK, то один и тот же объект учетных данных можно использовать с каждым клиентским объектом пакета SDK.

Последовательность выбора методов проверки подлинности при использовании DefaultAzureCredential

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

Если вы настроили несколько учетных данных, порядок поиска учетных данных в цепочке важен.

Порядок DefaultAzureCredential поиска учетных данных для JavaScript показан на схеме и таблице ниже.

Существует два пути:

• Развернутая служба (Azure или локальная среда ): последовательность начинается с переменных среды, а затем управляемого удостоверения, а затем остальные расположения учетных данных (Visual Studio Code, Azure CLI, Azure PowerShell).
• Локальная среда разработчика: цепочка локальной рабочей станции разработчика начинается с входа пользователя Visual Studio Code в Azure, показанного в нижней строке интегрированной среды разработки, а затем переходит к Azure CLI, а затем Azure PowerShell. Важно понимать, настроены ли переменные локальной среды для всей среды или виртуальной среды проекта (например, с DOTENV), эти переменные переопределяют цепочку Visual Studio Code —> Azure CLI —> цепочку PowerShell, так как это первые учетные данные, проверка в цепочке.