Konfigurowanie uwierzytelniania bez certyfikatów przy użyciu Microsoft. Identity.Web

W tym artykule pokazano, jak skonfigurować uwierzytelnianie bez certyfikatów, aby aplikacja uwierzytelniała się przy użyciu Microsoft Entra ID bez zarządzania certyfikatami lub wpisami tajnymi klienta. Aplikacja używa poświadczeń tożsamości federacyjnej (FIC) wspieranych przez zarządzaną tożsamość Azure do uzyskiwania tokenów, co eliminuje rotację poświadczeń, zmniejsza rozrastanie wpisów tajnych i upraszcza wdrażanie na platformie Azure.

Microsoft.Identity.Web obsługuje uwierzytelnianie bez certyfikatów za pośrednictwem typu źródła poświadczeń SignedAssertionFromManagedIdentity, dostępnego w wersji 2.12.0 lub nowszej.

---

Omówienie uwierzytelniania bez certyfikatów

W tej sekcji wyjaśniono, jak działa uwierzytelnianie bez certyfikatów i kiedy należy z niego korzystać.

Tradycyjnie poufne aplikacje klienckie potwierdzają swoją tożsamość dla Microsoft Entra ID przez przedstawienie tajnego kodu klienta lub certyfikatu. Oba podejścia wymagają zarządzania cyklem życia poświadczeń — rotacji tajemnic przed ich wygaśnięciem, odnawiania certyfikatów i ich bezpiecznego przechowywania.

Poświadczenia tożsamości federacyjnej (FIC) zmieniają ten model. W przypadku FIC można skonfigurować relację zaufania między rejestracją aplikacji a tożsamością zarządzaną. Gdy aplikacja musi się uwierzytelnić:

1. Microsoft.Identity.Web żąda tokenu z punktu końcowego zarządzanej tożsamości na hoście Azure.
2. Biblioteka używa tokenu tożsamości zarządzanej jako podpisanej asercji do uwierzytelniania za pomocą Microsoft Entra ID.
3. Microsoft Entra ID sprawdza poprawność podpisanej asercji względem konfiguracji poświadczeń federacyjnych w rejestracji aplikacji.
4. Microsoft Entra ID wystawia token dostępu dla żądanego zasobu.

Wynikiem jest pełne wdrożenie bez poświadczeń, w którym w konfiguracji, kodzie lub zmiennych środowiskowych nie istnieją żadne wpisy tajne ani certyfikaty.

Wybieranie odpowiedniego podejścia do uwierzytelniania

Poniższa tabela ułatwia podjęcie decyzji, kiedy uwierzytelnianie bez certyfikatów jest właściwym wyborem.

Scenario	Zalecane podejście
Aplikacja działa na platformie Azure i chcesz uniknąć zarządzania poświadczeniami.	Bez certyfikatów z FIC
Aplikacja działa w Azure, ale musi obsługiwać plan awaryjny w infrastrukturze lokalnej.	Poświadczenia oparte na certyfikatach z FIC jako podstawowe
Aplikacja działa poza Azure (lokalnie, w innych chmurach)	Certyfikaty lub sekrety klienta
Programowanie i testowanie na maszynach lokalnych	Sekrety klienta lub certyfikat z lokalnego magazynu

---

Wymagania wstępne

Przed rozpoczęciem sprawdź, czy masz następujące zasoby i narzędzia:

• Subskrypcja Azure. Jeśli jej nie masz, utwórz bezpłatne konto.
• Rejestracja aplikacji w Microsoft Entra ID z wymaganymi uprawnieniami do API dla danego scenariusza.
• Tożsamość zarządzana Managed Identity w Azure — przypisana przez system na zasobie obliczeniowym lub autonomiczna tożsamość zarządzana przypisana przez użytkownika.
• Microsoft. Identity.Web w wersji 2.12.0 lub nowszej zainstalowanej w projekcie.
• Zasób obliczeniowy Azure obsługujący tożsamość zarządzaną, taki jak Azure App Service, Azure Kubernetes Service (AKS), Azure Container Apps lub Azure Virtual Machines.

---

Krok 1. Tworzenie lub identyfikowanie tożsamości zarządzanej

Możesz użyć przypisanej przez system lub przypisanej przez użytkownika tożsamości zarządzanej. Jeśli jeszcze go nie utworzono, postępuj zgodnie z instrukcjami dotyczącymi danego scenariusza.

Opcja A: Użyj przypisanej przez system tożsamości zarządzanej

Tożsamości zarządzane przypisane przez system są powiązane z cyklem życia zasobu Azure. Po włączeniu tożsamości przypisanej przez system dla zasobu, takiego jak usługa App Service, Azure automatycznie tworzy tożsamość.

1. W portalu Azure przejdź do zasobu obliczeniowego (na przykład usługi App Service).
2. Wybierz pozycję Tożsamość z menu nawigacji po lewej stronie.
3. Na karcie System przypisany ustaw Status na Włączony.
4. Wybierz pozycję Zapisz i potwierdź akcję.
5. Po utworzeniu tożsamości użytkownika skopiuj identyfikator obiektu (podmiot). Ta wartość jest potrzebna podczas konfigurowania poświadczeń federacyjnych.

Opcja B: Tworzenie tożsamości zarządzanej przypisanej przez użytkownika

Tożsamości zarządzane przypisane przez użytkownika są samodzielnymi zasobami Azure, które można przypisać do jednego lub więcej zasobów obliczeniowych.

1. W portalu Azure wyszukaj Managed Identities i wybierz go.
2. Wybierz Utwórz.
3. Wybierz swoją subskrypcję, grupę zasobów, region i wprowadź nazwę tożsamości.
4. Wybierz Recenzuj + Utwórz, a następnie Utwórz.
5. Po zakończeniu wdrażania otwórz nowy zasób tożsamości zarządzanej.
6. Skopiuj identyfikator klienta ze strony Przegląd . Ta wartość jest potrzebna dla konfiguracji aplikacji.

---

Krok 2. Konfigurowanie poświadczeń tożsamości federacyjnej w portalu Azure

Poświadczenie tożsamości federacyjnej ustanawia relację zaufania między rejestracją aplikacji a tożsamością zarządzaną. Wykonaj następujące kroki, aby utworzyć jeden:

1. W portalu Azure przejdź do Microsoft Entra ID>Rejestracje aplikacji.

2. Wybierz rejestrację aplikacji używaną przez aplikację.

3. W menu nawigacji po lewej stronie wybierz pozycję Certyfikaty i wpisy tajne.

4. Wybierz kartę Poświadczenia federacyjne.

5. Wybierz pozycję Dodaj poświadczenie.

6. W obszarze Scenariusz poświadczeń federacyjnych wybierz pozycję Klucze zarządzane przez klienta lub Inny wystawca (dostępne opcje zależą od wersji portalu).

7. Skonfiguruj następujące pola:

   Pole	Wartość
   Emitent	https://login.microsoftonline.com/{tenant-id}/v2.0 — zastąp {tenant-id} identyfikatorem dzierżawy Microsoft Entra.
   Identyfikator podmiotu	Identyfikator obiektu (podmiotu) tożsamości zarządzanej. W przypadku przypisania przez system znajdź to na stronie Tożsamość tego zasobu. Dla tożsamości zarządzanej przypisanej przez użytkownika znajdź tę informację na stronie Przegląd tożsamości w obszarze Identyfikator podmiotu zabezpieczeń.
   Nazwa	Opisowa nazwa, na przykład fic-managed-identity-prod.
   Audiencja	api://AzureADTokenExchange (wartość domyślna).

8. Wybierz opcję Dodaj.

Ważna

Identyfikator podmiotu musi dokładnie odpowiadać identyfikatorowi obiektu (podmiotu) tożsamości zarządzanej. Niezgodność powoduje niepowodzenie uwierzytelniania z powodu błędu AADSTS70021 .

Konfigurowanie poświadczeń tożsamości federacyjnej przy użyciu Azure CLI

Alternatywnie utwórz poświadczenie federacyjne przy użyciu Azure CLI. Następujące polecenie tworzy poświadczenie w rejestracji aplikacji:

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

Adresy URL wystawcy według usługi Azure

Adres URL wystawcy w poświadczeniu federacyjnym zależy od usługi Azure, która hostuje aplikację:

usługa Azure	Adres URL wystawcy
Azure App Service/Azure Functions	https://login.microsoftonline.com/{tenant-id}/v2.0
Azure Container Apps	https://login.microsoftonline.com/{tenant-id}/v2.0
Azure Kubernetes Service (AKS)	Adres URL wystawcy OIDC dla klastra (pobierz za pomocą polecenia az aks show --query oidcIssuerProfile.issuerUrl)
Azure Virtual Machines	https://login.microsoftonline.com/{tenant-id}/v2.0

Format identyfikatora podmiotu

Format identyfikatora podmiotu zależy od typu tożsamości zarządzanej:

Tożsamość zarządzana przypisana przez system — użyj identyfikatora obiektu (podmiotu) ze strony Tożsamość zasobu. Jest to wartość identyfikatora GUID, na przykład a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Tożsamość zarządzana przypisana przez użytkownika — użyj identyfikatora głównego (nazywanego również identyfikatorem obiektu) ze strony Przegląd zasobu tożsamości zarządzanej. Jest to również wartość identyfikatora GUID.

Uwaga / Notatka

W przypadku usługi AKS z tożsamością obciążenia identyfikator podmiotu używa innego formatu: system:serviceaccount:{namespace}:{service-account-name}. Ta wartość musi być zgodna z kontem usługi Kubernetes powiązanym z podem.

---

Krok 3. Konfigurowanie aplikacji

Zaktualizuj plik appsettings.json

Dodaj sekcję ClientCredentials do AzureAd konfiguracji. Ustaw SourceType na SignedAssertionFromManagedIdentity.

W przypadku tożsamości zarządzanej przypisanej przez użytkownika

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Zastąp następujące symbole zastępcze:

Placeholder	Opis
YOUR_TENANT_ID	Identyfikator dzierżawy Microsoft Entra.
YOUR_CLIENT_ID	Identyfikator aplikacji (klienta) w rejestracji aplikacji.
USER_ASSIGNED_MSI_CLIENT_ID	Identyfikator klienta tożsamości zarządzanej przypisanej przez użytkownika (na stronie Przegląd tożsamości).

W przypadku tożsamości zarządzanej przypisanej przez system

Jeśli używasz przypisanej przez system tożsamości zarządzanej, pomiń ManagedIdentityClientId właściwość . Microsoft. Identity.Web automatycznie używa przypisanej przez system tożsamości hosta:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Rejestrowanie usług w Program.cs

W konfiguracji uruchamiania nie są wymagane żadne specjalne zmiany kodu. Standardowe metody rejestracji Microsoft.Identity.Web automatycznie odczytują sekcję ClientCredentials.

Poniższy przykład rejestruje uwierzytelnianie dla aplikacji internetowej, która loguje użytkowników i wywołuje podrzędne interfejsy API:

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

Poniższy przykład rejestruje uwierzytelnianie dla internetowego API, które wywołuje podrzędne API.

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

Poniższy przykład rejestruje uwierzytelnianie dla aplikacji demona bez interakcji użytkownika:

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft.Identity.Web wykrywa typ źródła SignedAssertionFromManagedIdentity i obsługuje wymianę tokenu w sposób przejrzysty.

---

Porównanie tożsamości zarządzanej przypisanej przez system i przypisanej przez użytkownika

Wybierz typ tożsamości zarządzanej, który najlepiej pasuje do twojej architektury. W poniższych sekcjach opisano kompromisy.

Tożsamość zarządzana przypisana przez system

Tożsamość przypisana przez system jest tworzona i usuwana automatycznie przy użyciu zasobu Azure, do którego należy.

Zalety:

• Brak oddzielnego zasobu do zarządzania — cykl życia identyfikatora jest zgodny z zasobem obliczeniowym.
• Prostsza konfiguracja wdrożeń z jednym zasobem.
• Nie ManagedIdentityClientId jest wymagane w konfiguracji.

Considerations:

• Nie można udostępnić tożsamości w wielu zasobach.
• Jeśli usuniesz i ponownie utworzysz zasób, tożsamość ulegnie zmianie — musisz zaktualizować poświadczenia tożsamości federacyjnej.

Najlepsze dla: Wdrożenia jednokrotnego wystąpienia, w których jeden zasób obliczeniowy jest przypisany do jednej rejestracji aplikacji.

Tożsamość zarządzana przypisana przez użytkownika

Tożsamość przypisana przez użytkownika to autonomiczny zasób Azure z własnym cyklem życia.

Zalety:

• Udzielanie dostępu do jednej tożsamości w wielu zasobach obliczeniowych (na przykład wielu instancji usługi App Service na różnych obszarach).
• Tożsamość jest utrwalana niezależnie od cyklu życia zasobów obliczeniowych.
• Przed wdrożeniem zasobu obliczeniowego należy utworzyć i skonfigurować go wstępnie.

Considerations:

• Dodatkowy zasób Azure do zarządzania.
• Należy określić ManagedIdentityClientId w konfiguracji.

Najlepsze dla: Wdrożenia wieloinstancyjne lub wieloregionowe, wzorce wdrażania blue-green i scenariusze, w których zasoby obliczeniowe są często odtwarzane.

---

Wdrażanie w usługach obliczeniowych Azure

Po skonfigurowaniu aplikacji wdróż ją w usłudze obliczeniowej Azure obsługującej tożsamość zarządzaną.

Azure App Service

1. Włączanie tożsamości zarządzanej w usłudze App Service (zobacz Krok 1).

2. Wdróż aplikację w usłudze App Service przy użyciu preferowanej metody (Visual Studio, Azure CLI, GitHub Actions).

3. Upewnij się, że sekcja we wdrożonej AzureAd konfiguracji jest zgodna z ustawieniami w kroku 3.

4. Jeśli używasz tożsamości zarządzanej przypisanej przez użytkownika, przypisz ją do usługi App Service:

   az webapp identity assign \
     --resource-group <resource-group> \
     --name <app-service-name> \
     --identities <managed-identity-resource-id>
   

5. Uruchom ponownie usługę App Service, aby zastosować przypisanie tożsamości.

Azure Kubernetes Service (AKS)

W przypadku usługi AKS użyj tożsamości obciążenia, aby skojarzyć konto usługi Kubernetes z tożsamością zarządzaną. Zakończ poniższe kroki:

1. Włącz funkcję tożsamości roboczej w klastrze AKS:

   az aks update \
     --resource-group <resource-group> \
     --name <aks-cluster-name> \
     --enable-oidc-issuer \
     --enable-workload-identity
   

2. Utwórz konto usługi Kubernetes z adnotacjami przy użyciu identyfikatora klienta tożsamości zarządzanej:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-app-sa
     namespace: default
     annotations:
       azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"
   

3. Utwórz poświadczenia federacyjne łączące wystawcę usługi AKS OIDC z tożsamością zarządzaną.

4. Skonfiguruj pod do korzystania z konta usługi:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
     namespace: default
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: my-app-sa
     containers:
       - name: my-app
         image: <your-container-image>
   

5. Wdróż zasobnik. Element webhook tożsamości obciążenia wprowadza wymagane zmienne środowiskowe dla punktu końcowego tokenu tożsamości zarządzanej.

Azure Container Apps

1. Utwórz lub zaktualizuj aplikację kontenera przy użyciu tożsamości zarządzanej:

   az containerapp identity assign \
     --resource-group <resource-group> \
     --name <container-app-name> \
     --user-assigned <managed-identity-resource-id>
   

2. Wdróż obraz kontenera przy użyciu odpowiedniej AzureAd konfiguracji.

3. Punkt końcowy tokenu tożsamości zarządzanej jest automatycznie dostępny w kontenerze.

---

Migrowanie z certyfikatów do uwierzytelniania bez certyfikatów

Jeśli aplikacja używa obecnie uwierzytelniania opartego na certyfikatach, możesz przeprowadzić migrację do uwierzytelniania bez certyfikatów z minimalnymi zmianami konfiguracji.

Wykonaj kroki migracji

1. Utwórz tożsamość zarządzaną dla zasobu obliczeniowego Azure (zobacz Krok 1).

2. Dodaj poświadczenie tożsamości federacyjnej do rejestracji aplikacji (zobacz Krok 2).

3. Zaktualizuj konfigurację, aby dodać SignedAssertionFromManagedIdentity poświadczenie. Istniejące poświadczenia certyfikatu można zachować jako rezerwowe podczas migracji:

   {
     "AzureAd": {
       "Instance": "https://login.microsoftonline.com/",
       "TenantId": "YOUR_TENANT_ID",
       "ClientId": "YOUR_CLIENT_ID",
       "ClientCredentials": [
         {
           "SourceType": "SignedAssertionFromManagedIdentity",
           "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
         },
         {
           "SourceType": "KeyVault",
           "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
           "KeyVaultCertificateName": "your-cert-name"
         }
       ]
     }
   }
   

   Microsoft.Identity.Web próbuje źródła danych uwierzytelniających w kolejności. Podczas działania na platformie Azure pierwsze poświadczenie (SignedAssertionFromManagedIdentity) zostanie pomyślnie uwierzytelnione. Jeśli zakończy się to niepowodzeniem (na przykład podczas programowania lokalnego), biblioteka wróci do certyfikatu.

4. Wdróż i zweryfikuj je w środowisku przejściowym przed zastosowaniem do środowiska produkcyjnego.

5. Usuń poświadczenia certyfikatu z konfiguracji po potwierdzeniu, że uwierzytelnianie bez certyfikatu działa w środowisku produkcyjnym.

6. Usuń certyfikat z Azure Key Vault i rejestracji aplikacji, gdy nie jest już potrzebny.

Porównanie przed konfiguracją i po nim

W poniższych przykładach pokazano zmianę konfiguracji z opartego na certyfikatach na uwierzytelnianie bez certyfikatów.

Przed (oparte na certyfikatach):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

Po (bez certyfikatu):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

---

Rozwiązywanie typowych błędów

Skorzystaj z poniższych wskazówek, aby zdiagnozować i rozwiązać problemy z uwierzytelnianiem bez certyfikatów.

AADSTS70021: nie znaleziono pasującego rekordu tożsamości federacyjnej

Przyczyna: Identyfikator podmiotu w poświadczeniu tożsamości federacyjnej nie jest zgodny z identyfikatorem obiektu (głównego) tożsamości zarządzanej.

Rozwiązanie:

1. W portalu Azure przejdź do zasobu tożsamości zarządzanej i skopiuj Principal ID (nazywany również identyfikatorem obiektu) ze strony Overview.
2. Przejdź do rejestracji aplikacji >Certyfikaty i tajemnice>Poświadczenia federacyjne.
3. Sprawdź, czy pole Identyfikator podmiotu jest dokładnie zgodne z identyfikatorem podmiotu.
4. Jeśli wartości nie są zgodne, usuń poświadczenie i utwórz je ponownie przy użyciu poprawnego identyfikatora podmiotu.

AADSTS700024: Aseracja klienta nie mieści się w prawidłowym zakresie czasu

Przyczyna: Token tożsamości zarządzanej używany jako podpisane potwierdzenie wygasł lub zegar systemowy jest przesunięty.

Rozwiązanie:

• Sprawdź, czy zegar systemowy w zasobie Azure jest dokładny.
• Uruchom ponownie aplikację, aby wymusić nowe żądanie tokenu tożsamości zarządzanej.
• W przypadku uruchomienia w kontenerze upewnij się, że zegar kontenera jest synchronizowany z hostem.

ManagedIdentityException: Punkt końcowy tożsamości zarządzanej jest niedostępny

Cause: Aplikacja nie może uzyskać dostępu do usługi Azure Instance Metadata Service (IMDS) ani punktu końcowego tokenu tożsamości zarządzanej.

Rozwiązanie:

• Upewnij się, że aplikacja jest uruchomiona w zasobie obliczeniowym Azure obsługującym tożsamość zarządzaną.
• Sprawdź, czy tożsamość zarządzana jest włączona i przypisana do zasobu obliczeniowego.
• W przypadku usługi AKS sprawdź, czy webhook tożsamości zasobu jest uruchomiony, a pod ma poprawną adnotację konta usługi.
• W przypadku programowania lokalnego ten błąd jest oczekiwany. Użyj rezerwowego źródła poświadczeń (zobacz Kroki migracji).

AADSTS700016: Aplikacja nie została znaleziona w katalogu

Przyczyna: Element ClientId w konfiguracji nie jest zgodny z prawidłową rejestracją aplikacji w określonej dzierżawie.

Rozwiązanie:

• Sprawdź, czy ClientId pasuje do identyfikatora aplikacji (klienta) rejestracji aplikacji.
• Sprawdź, czy TenantId pasuje do dzierżawcy, u którego zarejestrowano aplikację.

Włącz logowanie debugowania

Przyczyna: Niezgodność kolejności źródeł poświadczeń lub konfiguracji może spowodować, że biblioteka pominie poświadczenie FIC.

Rozwiązanie:

1. Włącz logowanie w Microsoft. Identity.Web, aby wyświetlić szczegółowe kroki pozyskiwania tokenów. Poniższy kod konfiguruje rejestrowanie na poziomie debugowania dla bibliotek tożsamości:

   builder.Services.AddLogging(logging =>
   {
       logging.AddConsole();
       logging.SetMinimumLevel(LogLevel.Debug);
       logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
   });
   

2. Przejrzyj dzienniki w poszukiwaniu komunikatów o źródle poświadczeń, które próbowała wykorzystać biblioteka, oraz wszelkich zwróconych błędach.

Tożsamość zarządzana przypisana przez użytkownika nie została zarejestrowana

Przyczyna: Jeśli wiele użytkownik przypisanych tożsamości zarządzanych jest przypisanych do zasobu obliczeniowego, biblioteka może użyć niewłaściwej tożsamości, jeśli ManagedIdentityClientId nie zostanie określony.

Rozwiązanie:

• Zawsze określaj właściwość ManagedIdentityClientId podczas używania przypisanej przez użytkownika tożsamości zarządzanej.
• Sprawdź, czy identyfikator klienta jest zgodny z tożsamością, dla której skonfigurowano poświadczenie tożsamości federacyjnej.

---

Przegląd korzyści zabezpieczeń

Uwierzytelnianie bez certyfikatów z FIC zapewnia znaczne korzyści zabezpieczeń w porównaniu z tradycyjnymi podejściami opartymi na poświadczeniach:

Brak tajemnic do wycieku

Ponieważ w konfiguracji lub artefaktach wdrażania nie istnieją żadne pliki certyfikatów, hasła PFX ani wpisy tajne klienta, nie ma nic do wyodrębnienia przez osobę atakującą. Nawet jeśli osoba atakująca uzyska dostęp do odczytu do plików konfiguracji, nie może podszywać się pod Twoją aplikację spoza środowiska Azure.

Brak rotacji poświadczeń

Tokeny tożsamości zarządzanej są krótkotrwałe i automatycznie odświeżane przez platformę Azure. Nie trzeba implementować harmonogramów rotacji, monitorować daty wygaśnięcia ani koordynować aktualizacji poświadczeń we wdrożeniach.

Zmniejszona powierzchnia ataku

Punkt końcowy tokenu tożsamości zarządzanej jest dostępny tylko z określonego zasobu Azure, do której jest przypisana tożsamość. Osoba atakująca nie może użyć poświadczeń z innego hosta, sieci lub środowiska chmury.

Uproszczenie zgodności

Bez długotrwałych poświadczeń można wyeliminować kilka kategorii problemów ze zgodnością:

• Brak wpisów tajnych przechowywanych w kontroli źródła, zmiennych środowiskowych lub plikach konfiguracji.
• Brak kluczowych danych do audytowania, rotacji lub odwołania.
• Brak infrastruktury certyfikatów (ca, procesów odnawiania) do utrzymania.

Obrona w głąb

Połącz uwierzytelnianie bez certyfikatów z innymi funkcjami zabezpieczeń Azure na potrzeby ochrony warstwowej:

• Azure RBAC: Kontrolowanie tożsamości, które mogą uzyskiwać dostęp do zasobów.
• Dostęp warunkowy: stosowanie zasad na podstawie ryzyka tożsamości, lokalizacji i stanu urządzenia.
• Private endpoints: Ogranicz dostęp sieciowy do zasobów Azure.
• Microsoft Defender dla Chmury: Monitorowanie podejrzanych wzorców uwierzytelniania.

---

Treści powiązane

• Omówienie poświadczeń
• Certificates
• Wpisy tajne klienta
• Dokumentacja zarządzanych tożsamości platformy Azure
• Dokumentacja poświadczeń tożsamości federacyjnej
• Repozytorium GitHub Microsoft.Identity.Web