Uwierzytelnianie aplikacji platformy .NET w usługach platformy Azure przy użyciu przeglądu biblioteki tożsamości platformy Azure

Gdy aplikacja musi uzyskać dostęp do zasobu platformy Azure, aplikacja musi zostać uwierzytelniona na platformie Azure. Dotyczy to wszystkich aplikacji, zarówno wdrożonych na platformie Azure, wdrożonych lokalnie, jak i w ramach programowania na lokalnej stacji roboczej dewelopera. W tym artykule opisano zalecane podejścia do uwierzytelniania aplikacji na platformie Azure podczas korzystania z bibliotek klienckich zestawu Azure SDK.

Zalecane podejście do uwierzytelniania aplikacji

Zaleca się, aby aplikacje używały uwierzytelniania opartego na tokenach, a nie parametrów połączenia podczas uwierzytelniania w zasobach platformy Azure. Biblioteka Azure Identity library udostępnia klasy, które obsługują uwierzytelnianie oparte na tokenach i umożliwiają aplikacjom bezproblemowe uwierzytelnianie w zasobach platformy Azure niezależnie od tego, czy aplikacja jest w środowisku lokalnym, wdrożona na platformie Azure, czy wdrożona na serwerze lokalnym.

Określony typ uwierzytelniania opartego na tokenach, którego aplikacja powinna używać do uwierzytelniania w zasobach platformy Azure, zależy od tego, gdzie działa aplikacja i jest wyświetlana na poniższym diagramie:

Gdy aplikacja jest:

• Uruchamiana lokalnie podczas tworzeniaaplikacja może uwierzytelniać się na platformie Azure przy użyciu głównej jednostki usługi aplikacji do programowania lokalnego lub za pomocą poświadczeń platformy Azure dewelopera. Każda opcja została omówiona bardziej szczegółowo w sekcji uwierzytelniania podczas rozwoju lokalnego.
• hostowane na platformie Azureaplikacja powinna uwierzytelniać się w zasobach platformy Azure przy użyciu tożsamości zarządzanej. Ta opcja została omówiona bardziej szczegółowo w uwierzytelnianiu w środowiskach serwerowych.
• Hostowana i wdrożona lokalnie, aplikacja powinna uwierzytelniać się w zasobach platformy Azure przy użyciu principalu usługi aplikacji. Ta opcja jest omówiona bardziej szczegółowo w uwierzytelnianie w środowiskach serwerowych.

Wartość domyślnaAzureCredential

Klasa DefaultAzureCredential dostarczana przez bibliotekę tożsamości platformy Azure umożliwia aplikacjom korzystanie z różnych metod uwierzytelniania w zależności od środowiska, w którym są uruchamiane. Dzięki temu aplikacje mogą być promowane z lokalnego programowania do środowisk testowych do środowiska produkcyjnego bez zmian kodu. Skonfigurujesz odpowiednią metodę uwierzytelniania dla każdego środowiska, a DefaultAzureCredential automatycznie wykryje i użyje tej metody uwierzytelniania. Użycie DefaultAzureCredential powinno być preferowane zamiast ręcznego kodowania logiki warunkowej lub stosowania flag funkcji do różnych metod uwierzytelniania w różnych środowiskach.

Szczegółowe informacje o korzystaniu z DefaultAzureCredential zostały omówione w . Użyj DefaultAzureCredential w aplikacji.

Zalety uwierzytelniania opartego na tokenach

Uwierzytelnianie oparte na tokenach oferuje następujące korzyści wynikające z uwierzytelniania za pomocą parametrów połączenia:

• Metody uwierzytelniania oparte na tokenach opisane poniżej umożliwiają ustanowienie określonych uprawnień wymaganych przez aplikację w zasobie platformy Azure. Jest to zgodne z regułą najniższych uprawnień. Natomiast parametry połączenia udzielają pełnych praw do zasobu platformy Azure.
• Podczas gdy każda osoba lub dowolna aplikacja z parametrami połączenia może połączyć się z zasobem platformy Azure, metody uwierzytelniania oparte na tokenach umożliwiają dostęp do zasobu tylko do aplikacji przeznaczonych do uzyskania dostępu do zasobu.
• W przypadku tożsamości zarządzanej nie ma potrzeby przechowywania tajnego klucza aplikacji. Dzięki temu aplikacja jest bezpieczniejsza, ponieważ nie ma żadnych parametrów połączenia ani sekretu aplikacji, które mogą zostać naruszone.
• Pakiet Azure.Identity uzyskuje tokeny microsoft Entra i zarządza nimi. Dzięki temu uwierzytelnianie oparte na tokenach jest tak łatwe w użyciu jak ciąg połączenia.

Korzystanie z parametrów połączenia powinno być ograniczone do początkowych aplikacji weryfikacji koncepcji lub prototypów programistycznych, które nie uzyskują dostępu do danych produkcyjnych ani poufnych. W przeciwnym razie klasy uwierzytelniania oparte na tokenach dostępne w bibliotece tożsamości platformy Azure powinny być zawsze preferowane podczas uwierzytelniania w zasobach platformy Azure.

Uwierzytelnianie w środowiskach serwera

W przypadku hostowania w środowisku serwera każda aplikacja powinna mieć przypisaną unikatową tożsamość aplikacji na środowisko, w którym jest uruchamiana aplikacja. Na platformie Azure tożsamość aplikacji jest reprezentowana przez główną jednostkę usługi , specjalny typ podmiotu zabezpieczeń służący do identyfikowania i uwierzytelniania aplikacji na platformie Azure. Typ jednostki usługi używanej dla aplikacji zależy od tego, gdzie aplikacja jest uruchomiona.

Metoda uwierzytelniania	Opis
Aplikacje hostowane na platformie Azure	Aplikacje hostowane na platformie Azure powinny używać jednostki usługi tożsamości zarządzanej . Tożsamości zarządzane są przeznaczone do reprezentowania tożsamości aplikacji hostowanej na platformie Azure i mogą być używane tylko z aplikacjami hostowanymi na platformie Azure. Na przykład do aplikacji internetowej platformy .NET hostowanej w usłudze Azure App Service zostanie przypisana tożsamość zarządzana. Tożsamość zarządzana przypisana do aplikacji będzie następnie używana do uwierzytelniania aplikacji w innych usługach platformy Azure. Dowiedz się więcej na temat uwierzytelniania z aplikacji hostowanych na platformie Azure
Aplikacje hostowane poza platformą Azure (na przykład aplikacje lokalne)	Aplikacje hostowane poza platformą Azure (np. aplikacje lokalne), które muszą łączyć się z usługami platformy Azure, powinny używać głównej jednostki usługi aplikacji . Jednostka usługi aplikacji reprezentuje tożsamość aplikacji na platformie Azure i jest tworzona za pośrednictwem procesu rejestracji aplikacji. Rozważmy na przykład aplikację internetową platformy .NET hostowaną lokalnie, która korzysta z usługi Azure Blob Storage. Aby utworzyć główną jednostkę usługi aplikacji dla aplikacji, należy skorzystać z procesu rejestracji aplikacji. Wszystkie AZURE_CLIENT_ID, AZURE_TENANT_IDi AZURE_CLIENT_SECRET będą przechowywane jako zmienne środowiskowe, które mają być odczytywane przez aplikację w czasie wykonywania i umożliwiają aplikacji uwierzytelnianie na platformie Azure przy użyciu jednostki usługi Aplikacji. Dowiedz się więcej o uwierzytelnieniach z aplikacji hostowanych poza usługą Azure

Uwierzytelnianie podczas programowania lokalnego

Gdy aplikacja jest uruchamiana na stacji roboczej dewelopera podczas programowania lokalnego, musi ona nadal uwierzytelniać się w dowolnych usługach platformy Azure używanych przez aplikację. Dwie główne strategie uwierzytelniania aplikacji na platformie Azure podczas programowania lokalnego to:

Metoda uwierzytelniania	Opis
Utwórz dedykowane obiekty główne usługi aplikacji do wykorzystania podczas lokalnego tworzenia	W tej metodzie dedykowane obiekty usługi aplikacji są konfigurowane przy użyciu procesu rejestracji aplikacji do użycia podczas programowania lokalnego. Tożsamość jednostki usługi jest następnie przechowywana jako zmienne środowiskowe, które mają być dostępne przez aplikację podczas jej uruchamiania w środowisku lokalnym. Ta metoda umożliwia przypisanie określonych uprawnień zasobów, które są wymagane przez aplikację, do obiektów głównych usługi używanych przez deweloperów w lokalnym środowisku deweloperskim. Dzięki temu aplikacja ma dostęp tylko do określonych potrzebnych zasobów i replikuje uprawnienia, które aplikacja będzie miała w środowisku produkcyjnym. Wadą tego podejścia jest konieczność utworzenia oddzielnych obiektów głównego elementu usługi dla każdego dewelopera, który pracuje nad aplikacją. Dowiedz się więcej na temat uwierzytelniania z aplikacji hostowanych na platformie Azure
Uwierzytelnianie aplikacji na platformie Azure przy użyciu poświadczeń dewelopera podczas programowania lokalnego	W tej metodzie deweloper musi zalogować się do platformy Azure z poziomu programu Visual Studio, rozszerzenia Azure Tools dla programu VS Code, interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell na lokalnej stacji roboczej. Aplikacja może następnie uzyskać dostęp do poświadczeń dewelopera z magazynu poświadczeń i użyć tych poświadczeń, aby uzyskać dostęp do zasobów platformy Azure z aplikacji. Ta metoda ma zaletę łatwiejszej konfiguracji, ponieważ deweloper musi zalogować się tylko do konta platformy Azure z poziomu programu Visual Studio, programu VS Code lub interfejsu wiersza polecenia platformy Azure. Wadą tego podejścia jest to, że konto dewelopera prawdopodobnie ma więcej uprawnień niż wymagane przez aplikację. W związku z tym takie podejście nie replikuje dokładnie uprawnień, z których aplikacja będzie uruchamiana w środowisku produkcyjnym. Dowiedz się więcej na temat uwierzytelniania z aplikacji hostowanych na platformie Azure

Użyj DefaultAzureCredential w aplikacji

DefaultAzureCredential jest przemyślaną, uporządkowaną sekwencją mechanizmów uwierzytelniania w usłudze Microsoft Entra ID. Każdy mechanizm uwierzytelniania jest klasą pochodzącą z klasy TokenCredential i jest znany jako poświadczenie. W czasie wykonywania DefaultAzureCredential próbuje uwierzytelnić się przy użyciu pierwszego poświadczenia. Jeśli to poświadczenie nie może uzyskać tokenu dostępu, zostanie podjęta próba następnego poświadczenia w sekwencji itd., dopóki token dostępu nie zostanie pomyślnie uzyskany. W ten sposób aplikacja może używać różnych poświadczeń w różnych środowiskach bez konieczności pisania kodu specyficznego dla środowiska.

Dodaj pakiet Azure.Identity i opcjonalnie Microsoft.Extensions.Azure do swojej aplikacji, aby użyć DefaultAzureCredential.

Wiersza polecenia

W wybranym terminalu przejdź do katalogu projektu aplikacji i uruchom następujące polecenia:

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

Menedżer pakietów NuGet

Kliknij prawym przyciskiem myszy projekt w oknie eksploratora rozwiązań programu Visual Studio i wybierz pozycję Zarządzaj pakietami NuGet. Wyszukaj azure.Identityi zainstaluj pasujący pakiet. Powtórz ten proces dla pakietu Microsoft.Extensions.Azure.

Dostęp do usług platformy Azure jest uzyskiwany przy użyciu wyspecjalizowanych klas klientów z różnych bibliotek klienckich zestawu Azure SDK. Te klasy i własne usługi niestandardowe powinny być zarejestrowane, aby można było uzyskać do nich dostęp za pośrednictwem wstrzykiwania zależności w całej aplikacji. W Program.cswykonaj następujące kroki, aby zarejestrować klasę klienta i DefaultAzureCredential:

1. Uwzględnij przestrzenie nazw Azure.Identity i Microsoft.Extensions.Azure za pomocą dyrektyw using.
2. Zarejestruj klienta usługi platformy Azure, używając odpowiedniej metody rozszerzenia z prefiksem Add.
3. Przekaż wystąpienie DefaultAzureCredential do metody UseCredential.

Na przykład:

using Microsoft.Extensions.Azure;
using Azure.Identity;

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));
    clientBuilder.UseCredential(new DefaultAzureCredential());
});

Alternatywą dla UseCredential jest zainicjowanie DefaultAzureCredential bezpośrednio.

using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

Po uruchomieniu poprzedniego kodu na lokalnej stacji roboczej programisty, system szuka w zmiennych środowiskowych głównej jednostki usługi aplikacji lub w lokalnie zainstalowanych narzędziach deweloperskich, takich jak Visual Studio, zestawu poświadczeń dewelopera. Jedną z metod można użyć do uwierzytelniania aplikacji w zasobach platformy Azure podczas programowania lokalnego.

Po wdrożeniu na platformie Azure ten sam kod może również uwierzytelniać aplikację w innych zasobach platformy Azure. DefaultAzureCredential może pobierać ustawienia środowiska i konfiguracje tożsamości zarządzanej w celu automatycznego uwierzytelniania w innych usługach.