Nakonfigurujte ověřování bez certifikátů pomocí Microsoft. Identity.Web

V tomto článku se dozvíte, jak nakonfigurovat ověřování bez certifikátů tak, aby se vaše aplikace ověřila pomocí Microsoft Entra ID bez správy certifikátů nebo tajných klíčů klienta. Aplikace používá k získání tokenů pověření federované identity (FIC) založené na spravované identitě Azure, což eliminuje obměnu přihlašovacích údajů, snižuje šíření tajných kódů a zjednodušuje nasazení v Azure.

Microsoft. Identity.Web podporuje ověřování bez certifikátů prostřednictvím typu zdroje přihlašovacích údajů SignedAssertionFromManagedIdentity, který je k dispozici ve verzi 2.12.0 a novější.

Pochopte autentizaci bez certifikátů

Tato část vysvětluje, jak funguje ověřování bez certifikátů a kdy ho používat.

Důvěrné klientské aplikace tradičně prokázaly svou identitu Microsoft Entra ID předložením tajného klíče klienta nebo certifikátu. Oba přístupy vyžadují správu životního cyklu přihlašovacích údajů – obměně tajných kódů před vypršením jejich platnosti, obnovením certifikátů a jejich bezpečném uložením.

Přihlašovací údaje federované identity (FIC) tento model mění. Pomocí FIC nakonfigurujete vztah důvěryhodnosti mezi registrací vaší aplikace a spravovanou identitou. Když vaše aplikace potřebuje ověřit:

Microsoft. Identity.Web požaduje token z koncového bodu spravované identity na hostiteli Azure.
Knihovna používá token spravované identity jako podepsané tvrzení k ověření pomocí Microsoft Entra ID.
Microsoft Entra ID ověří podepsanou aserci vůči konfiguraci federovaných pověření v registraci aplikace.
Microsoft Entra ID vydá přístupový token pro požadovaný prostředek.

Výsledkem je plně bez přihlašovacích údajů nasazení, ve kterém v konfiguraci, kódu nebo proměnných prostředí neexistují žádné tajné kódy nebo certifikáty.

Volba správného přístupu k ověřování

Následující tabulka vám pomůže rozhodnout, kdy je správné ověřování bez certifikátů.

Scénář	Doporučený přístup
Aplikace běží na Azure a chcete mít nulovou správu přihlašovacích údajů.	Bez certifikátů pomocí FIC
Aplikace běží na Azure, ale potřebuje podporovat místní záložní nasazení.	Přihlašovací údaje založené na certifikátech s FIC jako primárním
Aplikace běží mimo Azure (místní, jiné cloudy)	Certifikáty nebo tajné kódy klienta
Vývoj a testování na místních počítačích	Tajné klíče klienta nebo certifikát z místního úložiště

Předpoklady

Než začnete, ověřte, že máte následující prostředky a nástroje:

Předplatné Azure. Pokud ho nemáte, vytvořte bezplatný účet.
Registrace aplikace ve Microsoft Entra ID s požadovanými oprávněními rozhraní API pro váš scénář.
Identita Spravovaná identita v Azure – buď systémově přiřazená ke svému výpočetnímu prostředku, nebo samostatná identita přiřazená uživatelem.
Microsoft. Identity.Web verze 2.12.0 nebo novější nainstalovaná v projektu.
Výpočetní prostředek Azure, který podporuje spravovanou identitu, jako jsou Azure App Service, Azure Kubernetes Service (AKS), Azure Container Apps nebo Azure Virtual Machines.

Krok 1: Vytvoření nebo identifikace spravované identity

Můžete použít spravovanou identitu přiřazenou systémem nebo přiřazenou uživatelem. Pokud jste ho ještě nevytvořili, postupujte podle pokynů pro váš scénář.

Možnost A: Použití spravované identity přiřazené systémem

Spravované identity přiřazené systémem jsou svázané s životním cyklem prostředků služby Azure. Když povolíte identitu přiřazenou systémem u prostředku, jako je app Service, Azure automaticky vytvoří identitu.

Na portálu Azure přejděte ke svému výpočetnímu prostředku (například ke službě App Service).
V levé navigační nabídce vyberte Identitu .
Na kartě Systém přiřazený nastavte Stav na Zapnuto.
Vyberte Uložit a potvrďte akci.
Po vytvoření identity zkopírujte ID objektu (principálu). Tuto hodnotu potřebujete při konfiguraci federovaných přihlašovacích údajů.

Možnost B: Vytvoření spravované identity přiřazené uživatelem

Spravované identity přiřazené uživatelem jsou samostatné Azure prostředky, které můžete přiřadit k jednomu nebo více výpočetním prostředkům.

Na portálu Azure vyhledejte Managed Identities a vyberte je.
Vyberte Vytvořit.
Zvolte své předplatné, skupinu prostředků, oblast a zadejte název identity.
Vyberte Zkontrolovat a vytvořit a pak Vytvořit.
Po dokončení nasazení otevřete nový prostředek spravované identity.
Zkopírujte ID klienta ze stránky Přehled . Tuto hodnotu potřebujete pro konfiguraci aplikace.

Krok 2: Konfigurace přihlašovacích údajů federované identity na portálu Azure

Přihlašovací údaje federované identity vytvářejí vztah důvěryhodnosti mezi registrací vaší aplikace a spravovanou identitou. Vytvořte ho podle těchto kroků:

Na portálu Azure přejděte na Microsoft Entra ID>Registrace aplikací.
Vyberte registraci aplikace, kterou vaše aplikace používá.
V levé navigační nabídce vyberte Certifikáty a tajné kódy.
Vyberte kartu Federované přihlašovací údaje.
Vyberte Přidat přihlašovací údaje.
V části Scénář federovaných přihlašování vyberte klíče spravované zákazníkem nebo jiný vydavatel (dostupné možnosti závisí na vaší verzi portálu).

Nakonfigurujte následující pole:

Pole	Hodnota
Emitent	`https://login.microsoftonline.com/{tenant-id}/v2.0` – Nahraďte `{tenant-id}` ID tenanta služby Microsoft Entra.
Identifikátor subjektu	ID objektu (hlavní) spravované identity. Pokud má prostředek systémem přidělenou identitu, najdete to na stránce Identity prostředku. Pro uživatelsky přiřazené vyhledejte tuto možnost na stránce Přehled spravované identity v části ID osoby.
název	Popisný název, například `fic-managed-identity-prod`.
Obecenstvo	`api://AzureADTokenExchange` (výchozí hodnota).

Vyberte Přidat.

Důležité

Identifikátor předmětu musí přesně odpovídat ID objektu (objektu zabezpečení) spravované identity. Nesoulad způsobí selhání ověřování s chybou AADSTS70021.

Konfigurace přihlašovacích údajů federované identity pomocí Azure CLI

Případně vytvořte federované přihlašovací údaje pomocí Azure CLI. Následující příkaz vytvoří přihlašovací údaje pro registraci vaší aplikace:

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 vystavitele podle služby Azure

Adresa URL vystavitele v federovaných přihlašovacích údajích závisí na službě Azure, která hostuje vaši aplikaci:

služba Azure	Adresa URL vystavitele
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)	Adresa URL vystavitele OIDC pro váš cluster (načtěte pomocí `az aks show --query oidcIssuerProfile.issuerUrl`)
Azure Virtual Machines	`https://login.microsoftonline.com/{tenant-id}/v2.0`

Formát identifikátoru subjektu

Formát identifikátoru subjektu závisí na typu spravované identity:

Spravovaná identita přiřazená systémem – Použijte ID objektu (hlavního) na stránce Identita prostředku. Jedná se o hodnotu GUID, například a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Spravovaná identita přiřazená uživatelem – Použijte ID objektu (označované také jako ID objektu) ze stránky Přehled prostředku spravované identity. Jedná se také o hodnotu GUID.

Poznámka:

Pro AKS s identitou úlohy používá identifikátor subjektu jiný formát: system:serviceaccount:{namespace}:{service-account-name}. Tato hodnota musí odpovídat účtu služby Kubernetes, který váš pod používá.

Krok 3: Konfigurace aplikace

Aktualizace appsettings.json

Přidejte sekci ClientCredentials do konfigurace AzureAd. Nastavte SourceType na SignedAssertionFromManagedIdentity

Pro spravovanou identitu přiřazenou uživatelem

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

Nahraďte následující zástupné symboly:

Placeholder	Description
`YOUR_TENANT_ID`	Vaše ID tenanta Microsoft Entra.
`YOUR_CLIENT_ID`	ID aplikace (klienta) registrace aplikace.
`USER_ASSIGNED_MSI_CLIENT_ID`	ID klienta spravované identity přiřazené uživatelem (ze stránky Přehled identity).

Pro spravovanou identitu přiřazenou systémem

Pokud použijete spravovanou identitu přiřazenou systémem, tuto vlastnost vynecháte ManagedIdentityClientId . Microsoft. Identity.Web automaticky používá identitu přiřazenou systémem hostitele:

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

Registrace služeb v Program.cs

V konfiguraci spouštění nejsou vyžadovány žádné speciální změny kódu. Standardní metody registrace Microsoft.Identity.Web čtou oddíl ClientCredentials automaticky.

Následující příklad zaregistruje ověřování pro webovou aplikaci, která přihlašuje uživatele a volá podřízená rozhraní 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();

Následující příklad registruje autentizaci pro webové API, které volá následná API.

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

Následující příklad registruje ověřování pro aplikaci démon bez zásahu uživatele:

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

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

Microsoft. Identity.Web rozpozná typ zdroje SignedAssertionFromManagedIdentity a transparentně zpracovává výměnu tokenů.

Porovnání spravované identity přiřazené systémem a přiřazené uživatelem

Zvolte typ spravované identity, který nejlépe vyhovuje vaší architektuře. Následující části popisují kompromisy.

Spravovaná identita přiřazená systémem

Identita přidělená systémem je vytvořena a automaticky odstraněna spolu s Azure prostředkem, ke kterému patří.

Výhody:

Žádný samostatný prostředek ke správě – životní cyklus identity odpovídá výpočetnímu prostředku.
Jednodušší nastavení pro jednoinstanční nasazení.
V konfiguraci se ManagedIdentityClientId nevyžaduje.

Aspekty:

Identitu nemůžete sdílet mezi více zdroji.
Pokud prostředek odstraníte a znovu vytvoříte, identita se změní – musíte aktualizovat přihlašovací údaje federované identity.

Nejvhodnější pro: Nasazení s jednou instancí, kde se jeden výpočetní prostředek mapuje na jednu registraci aplikace.

Spravovaná identita přiřazená uživatelem

Identita přiřazená uživatelem je samostatný Azure prostředek s vlastním životním cyklem.

Výhody:

Sdílejte jednu identitu napříč několika výpočetními prostředky (například několik instancí služby App Service v různých oblastech).
Identita se udržuje nezávisle na životním cyklu výpočetních prostředků.
Před nasazením výpočetního prostředku předem vytvořte a předkonfigurujte.

Aspekty:

Další Azure prostředek ke správě.
Je nutné zadat ManagedIdentityClientId v konfiguraci.

Nejvhodnější pro: Nasazení s více instancemi nebo více oblastmi, vzory nasazení s modrou zelenou barvou a scénáře, ve kterých se často znovu vytváří výpočetní prostředky.

Nasazení do Azure výpočetních služeb

Po nakonfigurování aplikace ji nasaďte do Azure výpočetní služby, která podporuje spravovanou identitu.

Azure App Service

Povolení spravované identity ve službě App Service (viz krok 1).
Nasaďte aplikaci do služby App Service pomocí upřednostňované metody (Visual Studio, Azure CLI, GitHub Actions).
Ujistěte se AzureAd, že sekce v nasazené konfiguraci odpovídá nastavení v kroku 3.

Pokud používáte spravovanou identitu přiřazenou uživatelem, přiřaďte ji službě App Service:

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

Restartujte App Service, aby se aktivovalo přiřazení identity.

Azure Kubernetes Service (AKS)

Pro AKS použijte identitu úlohy k přidružení účtu služby Kubernetes ke spravované identitě. Proveďte následující kroky:

Povolení funkce identity úloh v clusteru AKS:

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

Vytvořte účet služby Kubernetes s anotací ID klienta spravované identity.

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

Vytvořte federované přihlašovací údaje propojující vydavatele AKS OIDC se spravovanou identitou.

Nakonfigurujte pod tak, aby používal servisní účet:

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>

Nasaďte modul. Webhook identity úloh vloží potřebné proměnné prostředí pro tokenový koncový bod spravované identity.

Azure Container Apps

Vytvoření nebo aktualizace kontejnerové aplikace pomocí spravované identity:

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

Nasaďte image kontejneru s odpovídající AzureAd konfigurací.
Koncový bod tokenu spravované identity je automaticky dostupný uvnitř kontejneru.

Migrace z certifikátů na ověřování bez certifikátů

Pokud vaše aplikace aktuálně používá ověřování pomocí certifikátů, můžete migrovat na ověřování bez certifikátů s minimálními změnami konfigurace.

Dokončení kroků migrace

Vytvoření spravované identity pro výpočetní prostředek Azure (viz Step 1).
Přidejte do registrace aplikace přihlašovací údaje federované identity (viz krok 2).

Aktualizujte konfiguraci tak, aby se přidaly SignedAssertionFromManagedIdentity přihlašovací údaje. Během migrace můžete zachovat stávající přihlašovací údaje certifikátu jako záložní:

{
  "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 zkouší zdroje přihlašovacích údajů v pořadí. Při spuštění na Azure jsou první přihlašovací údaje (SignedAssertionFromManagedIdentity) úspěšné. Pokud selže (například při místním vývoji), knihovna se vrátí k certifikátu.

Před použitím na produkční prostředí nasaďte a ověřte ho v přípravném prostředí.
Po potvrzení, že ověřování bez certifikátů funguje v produkčním prostředí, odeberte přihlašovací údaje certifikátu z konfigurace.
Odstraňte certifikát z Azure Key Vault i z registrace aplikace, když už není potřeba.

Porovnání před a po konfiguraci

Následující příklady ukazují změnu konfigurace z ověřování založeného na certifikátu na ověřování bez certifikátů.

Před (založené na certifikátech):

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

Za (bez certifikátu):

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

Řešení běžných chyb

Při diagnostice a řešení problémů s ověřováním bez certifikátů využijte následující doprovodné materiály.

AADSTS70021: Nebyly nalezeny žádné odpovídající záznamy federované identity.

Příčina: Identifikátor subjektu v přihlašovacích údajích federované identity neodpovídá ID objektu (hlavního) spravované identity.

Řešení:

Na portálu Azure přejděte k prostředku spravované identity a zkopírujte Principal ID (označované také jako ID objektu) ze stránky Overview.
Přejděte k registračním >certifikátům aplikace a tajným klíčům>federovaných přihlašovacích údajů.
Ověřte, že pole identifikátoru subjektu přesně odpovídá ID objektu zabezpečení.
Pokud se hodnoty neshodují, odstraňte přihlašovací údaje a vytvořte je znovu se správným identifikátorem subjektu.

AADSTS700024: Vyjádření (nebo prohlášení) klienta není v platném časovém rozsahu.

Příčina: Vypršela platnost tokenu spravované identity, který je použit jako podepsané tvrzení, nebo jsou systémové hodiny posunuty.

Řešení:

Ověřte, že hodiny systému vašeho Azure prostředku jsou přesné.
Restartujte aplikaci, aby vynutil novou žádost o token spravované identity.
Pokud běžíte v kontejneru, ujistěte se, že se hodiny kontejneru synchronizují s hostitelem.

ManagedIdentityException: Koncový bod spravované identity není k dispozici

Cause: Aplikace se nemůže spojit se službou Azure IMDS (Instance Metadata Service) ani koncovým bodem tokenu spravované identity.

Řešení:

Ověřte, že aplikace běží na Azure výpočetním prostředku, který podporuje spravovanou identitu.
Ověřte, že je spravovaná identita povolená a přiřazená výpočetnímu prostředku.
V případě AKS ověřte, že je webhook identifikace úlohy spuštěný a že pod obsahuje správnou anotaci účtu služby.
U místního vývoje se tato chyba očekává. Použijte záložní zdroj přihlašovacích údajů (viz kroky migrace).

AADSTS700016: Aplikace nebyla v adresáři nalezena.

Příčina:ClientId ve vaší konfiguraci neodpovídá platné registraci aplikace ve zadaném tenantovi.

Řešení:

Ověřte, že ClientId odpovídá ID aplikace (klienta) vaší registrace aplikace.
Ověřte, že TenantId odpovídá tenantovi, ve kterém je aplikace zaregistrovaná.

Povolte protokolování ladění

Příčina: Neshoda v pořadí zdrojů nebo konfigurace přihlašovacích údajů může způsobit, že knihovna přeskočí přihlašovací údaje FIC.

Řešení:

Povolte protokolování v Microsoft. Identity.Web pro zobrazení podrobných kroků získání tokenu Následující kód nakonfiguruje protokolování na úrovni debug pro knihovny identity:
```
builder.Services.AddLogging(logging =>
{
    logging.AddConsole();
    logging.SetMinimumLevel(LogLevel.Debug);
    logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
});
```
Projděte si protokoly kvůli zprávám o tom, který zdroj přihlašovacích údajů se knihovna pokusila použít, a jaké chyby byly vráceny.

Spravovaná identita přiřazená uživatelem nebyla zaznamenána

Příčina: Pokud je k výpočetnímu prostředku přiřazeno více uživatelských spravovaných identit, může knihovna použít nesprávnou, pokud ManagedIdentityClientId není zadána.

Řešení:

Vlastnost ManagedIdentityClientId vždy zadejte, když použijete uživatelsky přiřazenou spravovanou identitu.
Ověřte, že ID klienta odpovídá identitě, pro kterou jste nakonfigurovali přihlašovací údaje federované identity.

Kontrola výhod zabezpečení

Ověřování bez certifikátů pomocí FIC poskytuje významné výhody zabezpečení oproti tradičním přístupům založeným na přihlašovacích údajích:

Žádná tajemství k úniku

Vzhledem k tomu, že v konfiguraci nebo artefaktech nasazení neexistují žádné soubory certifikátů, hesla PFX ani tajné kódy klienta, neexistuje nic, co by útočník extrahuje. I když útočník získá přístup ke čtení konfiguračních souborů, nemůže mimo prostředí Azure zosobnit vaši aplikaci.

Bez obměně přihlašovacích údajů

Tokeny spravované identity jsou krátkodobé a automaticky se aktualizují platformou Azure. Nemusíte implementovat plány obměny, monitorovat data vypršení platnosti ani koordinovat aktualizace přihlašovacích údajů napříč nasazeními.

Omezený prostor pro útok

Koncový bod tokenu spravované identity je přístupný jenom z konkrétního Azure prostředku, ke kterému je identita přiřazená. Útočník nemůže použít přihlašovací údaje z jiného hostitele, sítě nebo cloudového prostředí.

Zjednodušení dodržování předpisů

Bez dlouhodobých přihlašovacích údajů eliminujete několik kategorií problémů s dodržováním předpisů:

Žádné tajné kódy uložené ve správě zdrojového kódu, proměnných prostředí ani konfiguračních souborech.
Žádný klíčový materiál k auditování, obměně nebo odvolání.
Není potřeba udržovat žádnou infrastrukturu certifikátů (certifikační autoritu, procesy obnovení).

Hloubková obrana

Kombinování ověřování bez certifikátů s jinými funkcemi zabezpečení Azure pro vrstvenou ochranu:

Azure RBAC: Určuje, které identity mají přístup k prostředkům.
Podmíněný přístup: Použijte zásady na základě rizika identity, umístění a stavu zařízení.
Privátní koncové body: Omezují síťový přístup k prostředkům Azure.
Microsoft Defender for Cloud: Monitorujte podezřelé vzory ověřování.

Přehled přihlašovacích údajů
Certifikáty
Tajné kódy klienta
Dokumentace ke spravovaným identitám Azure
Dokumentace k federované identitě a jejím přihlašovacím údajům
Úložiště Microsoft.Identity.Web na GitHubu

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-04-29

Nakonfigurujte ověřování bez certifikátů pomocí Microsoft. Identity.Web

Pochopte autentizaci bez certifikátů

Volba správného přístupu k ověřování

Předpoklady

Krok 1: Vytvoření nebo identifikace spravované identity

Možnost A: Použití spravované identity přiřazené systémem

Možnost B: Vytvoření spravované identity přiřazené uživatelem

Krok 2: Konfigurace přihlašovacích údajů federované identity na portálu Azure

Konfigurace přihlašovacích údajů federované identity pomocí Azure CLI

Adresy URL vystavitele podle služby Azure

Formát identifikátoru subjektu

Krok 3: Konfigurace aplikace

Aktualizace appsettings.json

Pro spravovanou identitu přiřazenou uživatelem

Pro spravovanou identitu přiřazenou systémem

Registrace služeb v Program.cs

Porovnání spravované identity přiřazené systémem a přiřazené uživatelem

Spravovaná identita přiřazená systémem

Spravovaná identita přiřazená uživatelem

Nasazení do Azure výpočetních služeb

Azure App Service

Azure Kubernetes Service (AKS)

Azure Container Apps

Migrace z certifikátů na ověřování bez certifikátů

Dokončení kroků migrace

Porovnání před a po konfiguraci

Řešení běžných chyb

AADSTS70021: Nebyly nalezeny žádné odpovídající záznamy federované identity.

AADSTS700024: Vyjádření (nebo prohlášení) klienta není v platném časovém rozsahu.

ManagedIdentityException: Koncový bod spravované identity není k dispozici

AADSTS700016: Aplikace nebyla v adresáři nalezena.

Povolte protokolování ladění

Spravovaná identita přiřazená uživatelem nebyla zaznamenána

Kontrola výhod zabezpečení

Žádná tajemství k úniku

Bez obměně přihlašovacích údajů

Omezený prostor pro útok

Zjednodušení dodržování předpisů

Hloubková obrana

Související obsah

Váš názor

Další materiály