Configureer certificaatloze verificatie met Microsoft. Identity.Web

In dit artikel wordt beschreven hoe u certificaatloze verificatie configureert, zodat uw toepassing wordt geverifieerd met Microsoft Entra ID zonder certificaten of clientgeheimen te beheren. Uw app maakt gebruik van een FIC (Federated Identity Credential) die wordt ondersteund door een Azure Beheerde identiteit om tokens te verkrijgen, waardoor referentierotatie wordt geëlimineerd, geheime sprawl wordt verminderd en Azure implementaties worden vereenvoudigd.

Microsoft. Identity.Web ondersteunt certificaatloze verificatie via het SignedAssertionFromManagedIdentity referentiebrontype, beschikbaar in versie 2.12.0 en hoger.

Begrijp certificaatloze verificatie

In deze sectie wordt uitgelegd hoe certificaatloze verificatie werkt en wanneer deze moet worden gebruikt.

Normaal gesproken bewijzen vertrouwelijke clienttoepassingen hun identiteit aan Microsoft Entra ID door een clientgeheim of een certificaat te presenteren. Voor beide benaderingen moet u de levenscyclus van inloggegevens beheren: geheimen roteren of vernieuwen voordat ze verlopen, certificaten vernieuwen en ze veilig opslaan.

Federatieve identiteitsreferenties (FIC) wijzigen dit model. Met FIC configureert u een vertrouwensrelatie tussen uw app-registratie en een beheerde identiteit. Wanneer uw toepassing moet worden geverifieerd:

1. Microsoft.Identity.Web vraagt een token aan bij het Managed Identity-eindpunt op de Azure-host.
2. De bibliotheek gebruikt het token voor beheerde identiteit als een ondertekende assertie om te verifiëren met Microsoft Entra ID.
3. Microsoft Entra ID valideert de ondertekende assertie op basis van de configuratie van federatieve referenties in de app-registratie.
4. Microsoft Entra ID geeft een toegangstoken voor de aangevraagde resource uit.

Het resultaat is een volledig referentievrije implementatie waarbij er geen geheimen of certificaten bestaan in uw configuratie, code of omgevingsvariabelen.

De juiste verificatiemethode kiezen

In de volgende tabel kunt u bepalen wanneer certificaatloze verificatie de juiste keuze is.

Vereiste voorwaarden

Controleer of u de volgende resources en hulpprogramma's hebt voordat u begint:

• Een Azure-abonnement. Als je er geen hebt, maak een gratis account aan.
• Een app-registratie in Microsoft Entra ID met de vereiste API-machtigingen voor uw scenario.
• Een Managed Identity in Azure: door het systeem toegewezen aan uw rekenresource of een zelfstandige door de gebruiker toegewezen beheerde identiteit.
• Microsoft. Identity.Web versie 2.12.0 of hoger die in uw project is geïnstalleerd.
• Een Azure rekenresource die beheerde identiteit ondersteunt, zoals Azure App Service, Azure Kubernetes Service (AKS), Azure Container Apps of Azure Virtuele Machines.

Stap 1: Een beheerde identiteit maken of identificeren

U kunt een door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit gebruiken. Als u er nog geen hebt gemaakt, volgt u de instructies voor uw scenario.

Optie A: Een door het systeem toegewezen beheerde identiteit gebruiken

Door het systeem toegewezen beheerde identiteiten zijn gekoppeld aan de levenscyclus van een Azure-resource. Wanneer u een door het systeem toegewezen identiteit inschakelt voor een resource zoals een App Service, Azure automatisch een identiteit maakt.

1. Navigeer in de Azure-portal naar uw rekenresource (bijvoorbeeld uw App Service).
2. Selecteer Identiteit in het linkernavigatiemenu.
3. Stel op het tabblad Systeem toegewezenStatus in op Op.
4. Selecteer Opslaan en bevestig de actie.
5. Nadat de identiteit is gemaakt, kopieert u de object-id (principal). U hebt deze waarde nodig bij het configureren van de federatieve referentie.

Optie B: Een door de gebruiker toegewezen beheerde identiteit maken

Door de gebruiker toegewezen beheerde identiteiten zijn zelfstandige Azure resources die u kunt toewijzen aan een of meer rekenresources.

1. Zoek in de Azure portal naar Beheerde identiteiten en selecteer deze.
2. Klik op Creëren.
3. Kies uw abonnement, resourcegroep, regio en voer een naam in voor de identiteit.
4. Selecteer Beoordelen en maken en vervolgens Maken.
5. Nadat de implementatie is voltooid, opent u de nieuwe managed identity-resource.
6. Kopieer de Client-ID van de pagina Overzicht. U hebt deze waarde nodig voor de configuratie van uw toepassing.

Stap 2: Een federatieve identiteitsreferentie configureren in de Azure-portal

Een federatieve identiteitsreferentie brengt een vertrouwensrelatie tot stand tussen uw app-registratie en de beheerde identiteit. Volg deze stappen om er een te maken:

1. Ga in de Azure portal naar Microsoft Entra ID>App-registraties.

2. Selecteer de app-registratie die uw toepassing gebruikt.

3. Selecteer certificaten en geheimen in het linkernavigatiemenu.

4. Selecteer het tabblad Federatieve referenties.

5. Selecteer Referentie toevoegen.

6. Selecteer onder Federatief referentie scenario de optie klantspecifieke beheerde sleutels of andere uitgever (de beschikbare opties zijn afhankelijk van uw portalversie).

7. Configureer de volgende velden:

   Veld	Waarde
   Uitgever	https://login.microsoftonline.com/{tenant-id}/v2.0 — Vervang {tenant-id} door de tenant-id van uw Microsoft Entra.
   Onderwerp-id	De object-id (principal) van de beheerde identiteit. Zoek dit op de identiteitspagina van de resource voor systeemtoewijzingen. Zoek dit op de overzichtspagina van de beheerde identiteit onder Principal ID voor een door de gebruiker toegewezen identiteit.
   Naam	Een beschrijvende naam, bijvoorbeeld fic-managed-identity-prod.
   Audiëntie	api://AzureADTokenExchange (de standaardwaarde).

8. Selecteer Toevoegen.

Een federatieve identiteitsreferentie configureren met Azure CLI

U kunt ook de federatieve referentie maken met de Azure CLI. Met de volgende opdracht maakt u een referentie voor uw app-registratie:

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"
    }'

URL's van verleners per Azure-service

De URL van de verlener in de federatieve referentie is afhankelijk van de Azure-service die als host fungeert voor uw toepassing:

Indeling van onderwerpidentificatie

De indeling van de onderwerp-id is afhankelijk van het type beheerde identiteit:

Door het systeem toegewezen beheerde identiteit: gebruik de object-id (principal) op de pagina Identiteit van de resource. Dit is bijvoorbeeld a1b2c3d4-e5f6-7890-abcd-ef1234567890een GUID-waarde.

Door de gebruiker toegewezen beheerde identiteit : gebruik de principal-id (ook wel object-id genoemd) op de overzichtspagina van de beheerde identiteit. Dit is ook een GUID-waarde.

Stap 3: Uw toepassing configureren

appsettings.json bijwerken

Voeg de ClientCredentials sectie toe aan uw AzureAd configuratie. Stel de SourceType in op SignedAssertionFromManagedIdentity:

Voor door de gebruiker toegewezen beheerde identiteit

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

Vervang de volgende tijdelijke aanduidingen:

Voor door het systeem toegewezen beheerde identiteit

Wanneer u een door het systeem toegewezen beheerde identiteit gebruikt, laat u de ManagedIdentityClientId eigenschap weg. Microsoft. Identity.Web maakt automatisch gebruik van de door het systeem toegewezen identiteit van de host:

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

Services registreren in Program.cs

Er zijn geen speciale codewijzigingen vereist in de opstartconfiguratie. De standaard Microsoft. Identity.Web-registratiemethoden lezen automatisch de sectie ClientCredentials.

In het volgende voorbeeld wordt verificatie geregistreerd voor een web-app waarmee gebruikers worden aangemeld en downstream-API's worden aangeroepen:

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

In het volgende voorbeeld wordt verificatie geregistreerd voor een web-API die downstream-API's aanroept:

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

In het volgende voorbeeld wordt verificatie geregistreerd voor een daemon-toepassing zonder tussenkomst van de gebruiker:

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

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

Microsoft. Identity.Web detecteert het SignedAssertionFromManagedIdentity brontype en verwerkt de tokenuitwisseling transparant.

Door het systeem toegewezen en door de gebruiker toegewezen beheerde identiteit vergelijken

Kies het type beheerde identiteit dat het beste bij uw architectuur past. In de volgende secties worden de compromissen beschreven.

Door het systeem toegewezen beheerde identiteit

Er wordt een door het systeem toegewezen identiteit gemaakt en automatisch verwijderd met de Azure resource waartoe deze behoort.

Voordelen:

• Er is geen afzonderlijke resource die moet worden beheerd. Identiteitslevenscyclus komt overeen met de rekenresource.
• Eenvoudigere installatie voor implementaties met één resource.
• ManagedIdentityClientId niet vereist in de configuratie.

Overwegingen:

• U kunt de identiteit niet delen over meerdere resources.
• Als u de resource verwijdert en opnieuw maakt, wordt de identiteit gewijzigd. U moet de federatieve identiteitsreferentie bijwerken.

Geschikt voor: Implementaties met één exemplaar waarbij één computing resource wordt toegewezen aan één app-registratie.

Door de gebruiker toegewezen beheerde identiteit

Een door de gebruiker toegewezen identiteit is een zelfstandige Azure resource met een eigen levenscyclus.

Voordelen:

• Deel één identiteit over meerdere rekenresources (bijvoorbeeld meerdere App Service-exemplaren in verschillende regio's).
• Identiteit blijft onafhankelijk van de levenscyclus van rekenresources behouden.
• Vooraf maken en vooraf configureren voordat u de rekenresource implementeert.

Overwegingen:

• Een extra Azure resource die moet worden beheerd.
• U moet de ManagedIdentityClientId in de configuratie opgeven.

Geschikt voor: Implementaties met meerdere exemplaren of meerdere regio's, blauwgroene implementatiepatronen en scenario's waarbij rekenresources vaak opnieuw worden gemaakt.

Implementeren in Azure compute-services

Nadat u uw toepassing hebt geconfigureerd, implementeert u deze in een Azure compute-service die beheerde identiteit ondersteunt.

Azure App Service

1. Beheerde identiteit inschakelen in uw App Service (zie stap 1).

2. Implementeer uw toepassing in de App Service met behulp van uw voorkeursmethode (Visual Studio, Azure CLI, GitHub Actions).

3. Zorg ervoor dat de sectie in uw AzureAd geïmplementeerde configuratie overeenkomt met de instellingen in stap 3.

4. Als u een door de gebruiker toegewezen beheerde identiteit gebruikt, wijst u deze toe aan de App Service:

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

5. Start de App Service opnieuw op om de identiteitstoewijzing op te halen.

Azure Kubernetes-service (AKS)

Gebruik voor AKS workloadidentiteit om een Kubernetes-serviceaccount te koppelen aan de beheerde identiteit. Voltooi de volgende stappen:

1. Schakel de functie voor werkbelasting-identiteit in op uw AKS-cluster.

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

2. Maak een Kubernetes-service-account voorzien van de Managed Identity client-ID.

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

3. Maak een federatieve referentie die de AKS OIDC-verlener koppelt aan de beheerde identiteit.

4. Configureer uw pod voor het gebruik van het serviceaccount:

   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. Implementeer de pod. De webhook voor de werkbelastingidentiteit injecteert de vereiste omgevingsvariabelen voor het eindpunt van het token voor beheerde identiteit.

Azure Container Apps

1. Uw container-app maken of bijwerken met een beheerde identiteit:

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

2. Implementeer de container-image met de juiste AzureAd configuratie.

3. Het eindpunt van het beheerde identiteitstoken is automatisch beschikbaar in de container.

Migreren van certificaten naar certificaatloze verificatie

Als uw toepassing momenteel gebruikmaakt van verificatie op basis van certificaten, kunt u migreren naar certificaatloze verificatie met minimale configuratiewijzigingen.

De migratiestappen voltooien

1. Maak een beheerde identiteit voor uw Azure rekenresource (zie Step 1).

2. Voeg een federatieve identiteitsreferentie toe aan uw app-registratie (zie stap 2).

3. Werk uw configuratie bij om de SignedAssertionFromManagedIdentity referentie toe te voegen. U kunt de bestaande certificaatreferentie behouden als een terugval tijdens de migratie:

   {
     "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 probeert inloggegevensbronnen in volgorde. Bij uitvoering op Azure slaagt de eerste referentie (SignedAssertionFromManagedIdentity). Als dit mislukt (bijvoorbeeld tijdens lokale ontwikkeling), valt de bibliotheek terug op het certificaat.

4. Implementeer en valideer deze in een faseringsomgeving voordat u op productie toepast.

5. Verwijder de certificaatreferentie uit de configuratie nadat u hebt bevestigd dat verificatie zonder certificaat werkt in productie.

6. Het certificaat verwijderen uit Azure Key Vault en de app-registratie wanneer het niet meer nodig is.

Vergelijken vóór en na configuratie

In de volgende voorbeelden ziet u de configuratiewijziging van certificaatgebaseerde verificatie naar verificatie zonder certificaat.

Voor (op certificaten gebaseerd):

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

Na (certificaatloos):

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

Veelvoorkomende fouten oplossen

Gebruik de volgende richtlijnen om problemen met certificaatloze verificatie vast te stellen en op te lossen.

AADSTS70021: Er is geen overeenkomende federatieve identiteitsrecord gevonden

Oorzaak: De subject-id in de referentie voor federatieve identiteit komt niet overeen met de object-id (principal) van de beheerde identiteit.

Resolutie:

1. Navigeer in de Azure-portal naar de beheerde identiteitresource en kopieer de Principal-id (ook wel object-id genoemd) van de pagina Overview.
2. Navigeer naar uw app-registratie >Certificaten en geheimen>Federatieve referenties.
3. Controleer of het veld Onderwerp-id exact overeenkomt met de principal-id.
4. Als de waarden niet overeenkomen, verwijdert u de referentie en maakt u deze opnieuw met de juiste onderwerp-id.

AADSTS700024: Clientbewering ligt niet in de geldige tijdspanne

Oorzaak: Het managed identity-token dat wordt gebruikt als de ondertekende assertie is verlopen of de systeemklok is scheefgetrokken.

Resolutie:

• Controleer of de systeemklok op uw Azure resource juist is.
• Start de toepassing opnieuw om een nieuwe beheerde identiteitstokenaanvraag af te dwingen.
• Als u een proces in een container uitvoert, zorg ervoor dat de klok van de container is gesynchroniseerd met de host.

ManagedIdentityException: Eindpunt voor beheerde identiteit niet beschikbaar

Cause: De toepassing kan de Azure Instance Metadata Service (IMDS) of het eindpunt van het managed identity-token niet bereiken.

Resolutie:

• Controleer of de toepassing wordt uitgevoerd op een Azure rekenresource die beheerde identiteit ondersteunt.
• Controleer of de beheerde identiteit is ingeschakeld en toegewezen aan de rekenresource.
• Controleer voor AKS of de webhook voor de workload-identiteit draait en of de pod de juiste serviceaccountannotatie heeft.
• Voor lokale ontwikkeling wordt deze fout verwacht. Gebruik een terugvalreferentiebron (zie migratiestappen).

AADSTS700016: De toepassing is niet gevonden in de map

Oorzaak: De ClientId in uw configuratie komt niet overeen met een geldige app-registratie in de opgegeven tenant.

Resolutie:

• Controleer of de ClientId overeenkomt met de Application (client) ID van uw app-registratie.
• Controleer of de TenantId tenant overeenkomt met de tenant waarin de app is geregistreerd.

Logboekregistratie voor foutopsporing inschakelen

Oorzaak: De bronvolgorde of configuratie van de referentie komt mogelijk niet overeen, waardoor de bibliotheek de FIC-referentie overslaat.

Resolutie:

1. Schakel logboekregistratie in Microsoft.Identity.Web in om gedetailleerde stappen voor het verkrijgen van tokens te zien. Met de volgende code configureert u logboekregistratie op foutopsporingsniveau voor de identiteitsbibliotheken:

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

2. Bekijk de logboeken voor berichten over welke referentiebron de bibliotheek heeft geprobeerd te gebruiken en eventuele fouten die zijn ontvangen.

Door de gebruiker toegewezen beheerde identiteit is niet herkend

Oorzaak: Wanneer meerdere door de gebruiker toegewezen beheerde identiteiten worden toegewezen aan een rekenresource, kan de bibliotheek de verkeerde gebruiken als ManagedIdentityClientId deze niet is opgegeven.

Resolutie:

• Geef altijd de ManagedIdentityClientId-eigenschap op wanneer u een door een gebruiker toegewezen beheerde identiteit gebruikt.
• Controleer of de client-id overeenkomt met de identiteit waarvoor u de federatieve identiteitsreferentie hebt geconfigureerd.

Beveiligingsvoordelen bekijken

Verificatie zonder certificaat met FIC biedt aanzienlijke beveiligingsvoordelen ten opzichte van traditionele benaderingen op basis van referenties:

Geen geheimen om te lekken

Omdat er geen certificaatbestanden, PFX-wachtwoorden of clientgeheimen bestaan in uw configuratie- of implementatieartefacten, hoeft een aanvaller niets te extraheren. Zelfs als een aanvaller leestoegang krijgt tot uw configuratiebestanden, kunnen ze uw toepassing niet van buiten Azure imiteren.

Geen referentierotatie

Beheerde identiteitstokens zijn kortstondig, en worden automatisch vernieuwd door het Azure-platform. U hoeft geen rotatieschema's te implementeren, vervaldatums te bewaken of referentie-updates te coördineren voor implementaties.

Verminderd kwetsbaarheid voor aanvallen

Het tokeneindpunt van de beheerde identiteit is alleen toegankelijk vanuit de specifieke Azure resource waaraan de identiteit is toegewezen. Een aanvaller kan de referenties van een andere host, netwerk of cloudomgeving niet gebruiken.

Vereenvoudiging van naleving

Door geen inloggegevens met een lange levensduur te gebruiken, elimineert u verschillende nalevingszorgen.

• Er zijn geen geheimen opgeslagen in broncodebeheer, omgevingsvariabelen of configuratiebestanden.
• Geen sleutelmateriaal om te auditen, roteren of in te trekken.
• Er zijn geen certificaatinfrastructuur (CA, vernieuwingsprocessen) die moeten worden onderhouden.

Diepgaande verdediging

Combineer certificaatloze verificatie met andere Azure beveiligingsfuncties voor gelaagde beveiliging:

• Azure RBAC: bepalen welke identiteiten toegang hebben tot welke resources.
• Voorwaardelijke toegang: beleid toepassen op basis van identiteitsrisico, locatie en apparaatstatus.
• Private-eindpunten: Netwerktoegang tot Azure resources beperken.
• Microsoft Defender voor Cloud: Controleren op verdachte verificatiepatronen.

Verwante inhoud

• Overzicht van referenties
• Certificates
• Client Secret
• Azure Managed Identities-documentatie
• Documentatie over federatieve identiteitsreferenties
• Microsoft. Identity.Web GitHub opslagplaats