Проверка подлинности приложений .NET в службах Azure во время локальной разработки с помощью учетных записей разработчиков
При создании облачных приложений разработчикам необходимо выполнять отладку и тестирование приложений на локальной рабочей станции. Когда приложение выполняется на рабочей станции разработчика во время локальной разработки, оно по-прежнему должно пройти проверку подлинности в любых службах Azure, используемых приложением. В этой статье описывается, как использовать учетные данные разработчика Azure для проверки подлинности приложения в Azure во время локальной разработки.
Чтобы приложение выполнялось проверку подлинности в Azure во время локальной разработки с помощью учетных данных Azure разработчика, разработчик должен войти в Azure из расширения средств VS Code Azure, Azure CLI или Azure PowerShell. Пакет SDK Azure для .NET может обнаружить, что разработчик вошел в систему из одного из этих средств, а затем получите необходимые учетные данные из кэша учетных данных для проверки подлинности приложения в Azure в качестве пользователя, вошедшего в систему.
Этот подход проще всего настроить для команды разработчиков, так как он использует преимущества существующих учетных записей Azure разработчиков. Однако учетная запись разработчика, скорее всего, будет иметь больше разрешений, чем требуется приложению, поэтому превышение разрешений, с которыми приложение будет работать в рабочей среде. В качестве альтернативы можно создать субъекты-службы приложений для использования во время локальной разработки, которые можно область иметь только доступ, необходимый приложению.
1. Создание группы Azure AD для локальной разработки
Так как в приложении почти всегда работает несколько разработчиков, рекомендуется сначала создать группу Azure AD, чтобы инкапсулировать роли (разрешения) приложения, необходимые для локальной разработки. Это дает следующие преимущества.
- Каждый разработчик гарантирует, что на уровне группы назначены одни и те же роли, так как роли назначаются на уровне группы.
- Если для приложения требуется новая роль, ее необходимо добавить только в группу Azure AD для приложения.
- Если новый разработчик присоединяется к команде, они просто должны быть добавлены в правильную группу Azure AD, чтобы получить правильные разрешения для работы с приложением.
Если у вас есть группа Azure AD для вашей группы разработки, вы можете использовать эту группу. В противном случае выполните следующие действия, чтобы создать группу Azure AD.
2. Назначение ролей группе Azure AD
Затем необходимо определить, какие роли (разрешения) приложения требуются для ресурсов и назначить эти роли приложению. В этом примере роли будут назначены группе Azure Active Directory, созданной на шаге 1. Роли можно назначить в ресурсе, группе ресурсов или подписке область. В этом примере показано, как назначать роли в группе ресурсов область, так как большинство приложений группируют все ресурсы Azure в одну группу ресурсов.
3. Вход в Azure с помощью средств .NET
Затем необходимо войти в Azure с помощью одного из нескольких вариантов инструментов .NET. Учетная запись, в которую вы входите, также должна существовать в созданной и настроенной ранее группе Azure Active Directory.
В верхнем меню Visual Studio перейдите к меню "Параметры инструментов>", чтобы открыть диалоговое окно параметров. В строке поиска в левом верхнем углу введите Azure , чтобы отфильтровать параметры. В разделе "Проверка подлинности службы Azure" выберите пункт "Выбор учетной записи".
Выберите раскрывающееся меню в разделе "Выбор учетной записи" и выберите команду "Добавить учетную запись Майкрософт". Откроется окно с запросом на выбор учетной записи. Введите учетные данные для требуемой учетной записи Azure и выберите подтверждение.
4. Реализация DefaultAzureCredential в приложении
DefaultAzureCredential
поддерживает несколько методов проверки подлинности и определяет метод проверки подлинности, используемый во время выполнения. Таким образом, приложение может использовать различные методы проверки подлинности в разных средах без реализации конкретного кода среды.
Порядок и расположения, в которых DefaultAzureCredential
поиск учетных данных найден в DefaultAzureCredential.
Чтобы реализовать DefaultAzureCredential
, сначала добавьте Azure.Identity
в приложение пакеты и при необходимости Microsoft.Extensions.Azure
. Это можно сделать с помощью командной строки или диспетчер пакетов NuGet.
Откройте среду терминала в каталоге проекта приложения и введите следующую команду.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Службы Azure обычно обращаются с помощью соответствующих клиентских классов из пакета SDK. Эти классы и собственные пользовательские службы должны быть зарегистрированы в файле, чтобы их можно было получить с помощью внедрения зависимостей во Program.cs
всем приложении. В ней Program.cs
выполните приведенные ниже действия, чтобы правильно настроить службу и DefaultAzureCredential
.
Azure.Identity
Включите пространства имен сMicrosoft.Extensions.Azure
помощью инструкции using.- Зарегистрируйте службу Azure с помощью соответствующих вспомогательных методов.
- Передайте экземпляр
DefaultAzureCredential
объекта методуUseCredential
.
Пример этого показан в следующем сегменте кода.
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
Кроме того, вы также можете использовать DefaultAzureCredential
службы напрямую без помощи дополнительных методов регистрации Azure, как показано ниже.
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
При запуске приведенного выше кода на локальной рабочей станции во время локальной разработки он будет выглядеть в переменных среды для субъекта-службы приложений или в Visual Studio, VS Code, Azure CLI или Azure PowerShell для набора учетных данных разработчика, который можно использовать для проверки подлинности приложения в ресурсах Azure во время локальной разработки.
При развертывании в Azure этот же код также может пройти проверку подлинности приложения в других ресурсах Azure. DefaultAzureCredential
может получать параметры среды и конфигурации управляемых удостоверений для автоматической проверки подлинности в других службах.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по