Beheerde identiteiten gebruiken voor App Service en Azure Functions

In dit onderwerp ziet u hoe u een beheerde identiteit maakt voor App Service en Azure Functions toepassingen en hoe u deze kunt gebruiken voor toegang tot andere resources.

Belangrijk

Beheerde identiteiten voor App Service en Azure Functions gedragen zich niet zoals verwacht als uw app wordt gemigreerd tussen abonnementen/tenants. De app moet een nieuwe identiteit verkrijgen, die wordt uitgevoerd door de functie uit te stellen en opnieuw in te stellen. Zie Een identiteit verwijderen hieronder. Downstream-resources moeten ook toegangsbeleid hebben bijgewerkt om de nieuwe identiteit te kunnen gebruiken.

Notitie

Beheerde identiteiten zijn niet beschikbaar voor apps die zijn geïmplementeerd in Azure Arc.

Met een beheerde identiteit van Azure Active Directory (Azure AD) heeft uw app eenvoudig toegang tot andere met Azure AD beveiligde resources, zoals Azure Key Vault. De identiteit wordt beheerd door het Azure-platform en vereist niet dat u geheimen inrichten of roteren. Zie Beheerde identiteiten voor Azure-resourcesvoor meer informatie over beheerde identiteiten in Azure AD.

Aan uw toepassing kunnen twee typen identiteiten worden verleend:

  • Een door het systeem toegewezen identiteit is gekoppeld aan uw toepassing en wordt verwijderd als uw app wordt verwijderd. Een app kan slechts één door het systeem toegewezen identiteit hebben.
  • Een door de gebruiker toegewezen identiteit is een zelfstandige Azure-resource die kan worden toegewezen aan uw app. Een app kan meerdere door de gebruiker toegewezen identiteiten hebben.

Een door het systeem toegewezen identiteit toevoegen

Voor het maken van een app met een door het systeem toegewezen identiteit moet een extra eigenschap worden ingesteld voor de toepassing.

Azure Portal gebruiken

Als u een beheerde identiteit in de portal instelt, moet u eerst een toepassing als normaal aanmaken en vervolgens de functie inschakelen.

  1. Maak een app in de portal zoals u dat normaal zou doen. Navigeer ernaar in de portal.

  2. Als u een functie-app gebruikt, gaat u naar Platformfuncties. Schuif voor andere app-typen omlaag naar de Instellingen in het linkernavigatievenster.

  3. Selecteer Identiteit.

  4. Schakel op het tabblad Systeem toegewezen de status in op Aan. Klik op Opslaan.

    Screenshot that shows where to switch Status to On and then select Save.

Notitie

Als u de beheerde identiteit voor uw web-app of site-app wilt vinden in de Azure Portal, gaat u onder Bedrijfstoepassingen naar de sectie Gebruikersinstellingen. Meestal is de naam van de sleuf vergelijkbaar met <app name>/slots/<slot name> .

Met behulp van de Azure CLI

Als u een beheerde identiteit wilt instellen met behulp van de Azure CLI, moet u de opdracht az webapp identity assign gebruiken voor een bestaande toepassing. U hebt drie opties voor het uitvoeren van de voorbeelden in deze sectie:

De volgende stappen helpen u bij het maken van een web-app en het toewijzen van een identiteit met behulp van de CLI:

  1. Als u de Azure CLI in een lokale console gebruikt, meldt u zich eerst aan bij Azure met az login. Gebruik een account dat is gekoppeld aan het Azure-abonnement waaronder u de toepassing wilt implementeren:

    az login
    
  2. Maak een webtoepassing met behulp van de CLI. Voor meer voorbeelden van het gebruik van de CLI met App Service, App Service CLI-voorbeelden:

    az group create --name myResourceGroup --location westus
    az appservice plan create --name myPlan --resource-group myResourceGroup --sku S1
    az webapp create --name myApp --resource-group myResourceGroup --plan myPlan
    
  3. Voer de identity assign opdracht uit om de identiteit voor deze toepassing te maken:

    az webapp identity assign --name myApp --resource-group myResourceGroup
    

Azure PowerShell gebruiken

Notitie

In dit artikel wordt de Azure Az PowerShell-module gebruikt. Dit is de aanbevolen PowerShell-module voor interactie met Azure. Raadpleeg Azure PowerShell installeren om aan de slag te gaan met de Az PowerShell-module. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

De volgende stappen helpen u bij het maken van een app en het toewijzen van een identiteit met behulp van Azure PowerShell. De instructies voor het maken van een web-app en een functie-app verschillen.

Een Azure PowerShell voor een web-app gebruiken

  1. Installeer zo nodig de Azure PowerShell de instructies in de Azure PowerShell envoer uit om een verbinding met Azure te maken.

  2. Maak een webtoepassing met behulp van Azure PowerShell. Zie PowerShell-voorbeelden voor meer Azure PowerShell hoe App Service gebruikt App Service PowerShell:

    # Create a resource group.
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    
    # Create an App Service plan in Free tier.
    New-AzAppServicePlan -Name $webappname -Location $location -ResourceGroupName $resourceGroupName -Tier Free
    
    # Create a web app.
    New-AzWebApp -Name $webappname -Location $location -AppServicePlan $webappname -ResourceGroupName $resourceGroupName
    
  3. Voer de Set-AzWebApp -AssignIdentity opdracht uit om de identiteit voor deze toepassing te maken:

    Set-AzWebApp -AssignIdentity $true -Name $webappname -ResourceGroupName $resourceGroupName 
    

Een Azure PowerShell voor een functie-app gebruiken

  1. Installeer zo nodig de Azure PowerShell de instructies in de Azure PowerShell envoer uit om een verbinding met Azure te maken.

  2. Een functie-app maken met Azure PowerShell. Zie de Az.Functions-naslagvoor meer Azure PowerShell met Azure Functions:

    # Create a resource group.
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    
    # Create a storage account.
    New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -SkuName $sku
    
    # Create a function app with a system-assigned identity.
    New-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -Location $location -StorageAccountName $storageAccountName -Runtime $runtime -IdentityType SystemAssigned
    

U kunt in plaats daarvan ook een bestaande functie-app bijwerken met Update-AzFunctionApp .

Een sjabloon voor Azure Resource Manager gebruiken

Een Azure Resource Manager kan worden gebruikt om de implementatie van uw Azure-resources te automatiseren. Zie Resource-implementatie automatiseren in App Service en Resource-implementatie automatiseren in Azure Functions voor meer informatie over het implementeren naar App Service en Azure Functions.

Elke resource van het type kan worden gemaakt met een identiteit door de volgende eigenschap op te geven Microsoft.Web/sites in de resourcedefinitie:

"identity": {
    "type": "SystemAssigned"
}

Notitie

Een toepassing kan tegelijkertijd zowel door het systeem toegewezen als door de gebruiker toegewezen identiteiten hebben. In dit geval is type de eigenschap SystemAssigned,UserAssigned

Door het door het systeem toegewezen type toe te voegen, moet Azure de identiteit voor uw toepassing maken en beheren.

Een web-app kan er bijvoorbeeld als volgt uitzien:

{
    "apiVersion": "2016-08-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "SystemAssigned"
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
    ]
}

Wanneer de site is gemaakt, heeft deze de volgende aanvullende eigenschappen:

"identity": {
    "type": "SystemAssigned",
    "tenantId": "<TENANTID>",
    "principalId": "<PRINCIPALID>"
}

De eigenschap tenantId identificeert bij welke Azure AD-tenant de identiteit hoort. De principalId is een unieke id voor de nieuwe identiteit van de toepassing. Binnen Azure AD heeft de service-principal dezelfde naam die u aan uw App Service of Azure Functions-exemplaar hebt gegeven.

Als u in een latere fase in de sjabloon naar deze eigenschappen moet verwijzen, kunt u dit doen via de sjabloonfunctie met de vlag 'Full' , zoals in dit voorbeeld:

{
    "tenantId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.tenantId]",
    "objectId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.principalId]",
}

Een door de gebruiker toegewezen identiteit toevoegen

Voor het maken van een app met een door de gebruiker toegewezen identiteit moet u de identiteit maken en vervolgens de resource-id toevoegen aan uw app-configuratie.

Azure Portal gebruiken

Eerst moet u een door de gebruiker toegewezen identiteitsresource maken.

  1. Maak een door de gebruiker toegewezen beheerde identiteitsresource volgens deze instructies.

  2. Maak een app in de portal zoals u dat normaal zou doen. Navigeer ernaar in de portal.

  3. Als u een functie-app gebruikt, gaat u naar Platformfuncties. Schuif voor andere app-typen omlaag naar de Instellingen in het linkernavigatievenster.

  4. Selecteer Identiteit.

  5. Klik op het tabblad Door de gebruiker toegewezen op Toevoegen.

  6. Zoek de identiteit die u eerder hebt gemaakt en selecteer deze. Klik op Add.

    Managed identity in App Service

Azure PowerShell gebruiken

Notitie

In dit artikel wordt de Azure Az PowerShell-module gebruikt. Dit is de aanbevolen PowerShell-module voor interactie met Azure. Raadpleeg Azure PowerShell installeren om aan de slag te gaan met de Az PowerShell-module. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.

De volgende stappen helpen u bij het maken van een app en het toewijzen van een identiteit met behulp van Azure PowerShell.

Notitie

De huidige versie van de Azure PowerShell-commandlets voor Azure App Service bieden geen ondersteuning voor door de gebruiker toegewezen identiteiten. De onderstaande instructies zijn voor Azure Functions.

  1. Installeer zo nodig de Azure PowerShell de instructies in de Azure PowerShell envoer uit om een verbinding met Azure te maken.

  2. Een functie-app maken met Azure PowerShell. Zie de Az.Functions-naslagvoor meer voorbeelden van Azure PowerShell met Azure Functions. Het onderstaande script maakt ook gebruik van , dat afzonderlijk moet worden geïnstalleerd volgens Create, list or delete a New-AzUserAssignedIdentityNew-AzUserAssignedIdentityusing Azure PowerShell .

    # Create a resource group.
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    
    # Create a storage account.
    New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -SkuName $sku
    
    # Create a user-assigned identity. This requires installation of the "Az.ManagedServiceIdentity" module.
    $userAssignedIdentity = New-AzUserAssignedIdentity -Name $userAssignedIdentityName -ResourceGroupName $resourceGroupName
    
    # Create a function app with a user-assigned identity.
    New-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -Location $location -StorageAccountName $storageAccountName -Runtime $runtime -IdentityType UserAssigned -IdentityId $userAssignedIdentity.Id
    

U kunt in plaats daarvan ook een bestaande functie-app bijwerken met Update-AzFunctionApp behulp van .

Een sjabloon voor Azure Resource Manager gebruiken

Een Azure Resource Manager kan worden gebruikt om de implementatie van uw Azure-resources te automatiseren. Zie Implementatie van resources automatiseren in App Service en Implementatie van resources automatiseren in Azure Functions voor meer informatie over het implementeren naar App Service en Azure Functions.

Elke resource van het type kan worden gemaakt met een identiteit door het volgende blok op te geven in de resourcedefinitie, te vervangen door de Microsoft.Web/sites<RESOURCEID> resource-id van de gewenste identiteit:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<RESOURCEID>": {}
    }
}

Notitie

Een toepassing kan tegelijkertijd zowel door het systeem toegewezen als door de gebruiker toegewezen identiteiten hebben. In dit geval is type de eigenschap SystemAssigned,UserAssigned

Door het door de gebruiker toegewezen type toe te voegen, moet Azure de door de gebruiker toegewezen identiteit gebruiken die is opgegeven voor uw toepassing.

Een web-app kan er bijvoorbeeld als volgt uitzien:

{
    "apiVersion": "2016-08-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]": {}
        }
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]"
    ]
}

Wanneer de site is gemaakt, heeft deze de volgende aanvullende eigenschappen:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<RESOURCEID>": {
            "principalId": "<PRINCIPALID>",
            "clientId": "<CLIENTID>"
        }
    }
}

De principalId is een unieke id voor de identiteit die wordt gebruikt voor Azure AD-beheer. De clientId is een unieke id voor de nieuwe identiteit van de toepassing die wordt gebruikt om op te geven welke identiteit moet worden gebruikt tijdens runtime-aanroepen.

Tokens voor Azure-resources verkrijgen

Een app kan de beheerde identiteit gebruiken om tokens op te halen voor toegang tot andere resources die worden beveiligd door Azure AD, zoals Azure Key Vault. Deze tokens vertegenwoordigen de toepassing die toegang heeft tot de resource en geen specifieke gebruiker van de toepassing.

Mogelijk moet u de doelresource configureren om toegang vanuit uw toepassing toe te staan. Als u bijvoorbeeld een token aanvraagt voor toegang tot Key Vault, moet u ervoor zorgen dat u een toegangsbeleid hebt toegevoegd dat de identiteit van uw toepassing bevat. Anders worden uw aanroepen Key Vault geweigerd, zelfs als ze het token bevatten. Zie Azure-servicesdie ondersteuning bieden voor Azure AD-verificatie voor meer Azure Active Directory resources die ondersteuning bieden voor tokens.

Belangrijk

De back-endservices voor beheerde identiteiten onderhouden ongeveer 24 uur een cache per resource-URI. Als u het toegangsbeleid van een bepaalde doelresource bij te werken en onmiddellijk een token voor die resource op te halen, kunt u een token in de cache met verouderde machtigingen blijven ophalen totdat dat token verloopt. Er is momenteel geen manier om het vernieuwen van een token af te dwingen.

Er is een eenvoudig REST-protocol voor het verkrijgen van een token in App Service en Azure Functions. Dit kan worden gebruikt voor alle toepassingen en talen. Voor .NET en Java biedt de Azure SDK een abstractie over dit protocol en wordt een lokale ontwikkelervaring mogelijk.

Het REST-protocol gebruiken

Notitie

Een oudere versie van dit protocol, met behulp van de API-versie 2017-09-01, gebruikte de header in plaats van en accepteerde alleen de eigenschap voor door de gebruiker secretX-IDENTITY-HEADERclientid toegewezen. Ook wordt de expires_on geretourneerd in een tijdstempelindeling. MSI_ENDPOINT kunnen worden gebruikt als een alias voor IDENTITY_ENDPOINT en MSI_SECRET kunnen worden gebruikt als alias voor IDENTITY_HEADER. Deze versie van het protocol is momenteel vereist voor Linux-verbruik hosting-abonnementen.

Voor een app met een beheerde identiteit zijn twee omgevingsvariabelen gedefinieerd:

  • IDENTITY_ENDPOINT: de URL naar de lokale tokenservice.
  • IDENTITY_HEADER een header die wordt gebruikt om aanvragenvervalsingsaanvallen (SSRF) aan de serverzijde te beperken. De waarde wordt geroteerd door het platform.

De IDENTITY_ENDPOINT is een lokale URL van waaruit uw app tokens kan aanvragen. Als u een token voor een resource wilt op halen, maakt u een HTTP GET-aanvraag naar dit eindpunt, met inbegrip van de volgende parameters:

Parameternaam In Description
resource Query’s uitvoeren De Azure AD-resource-URI van de resource waarvoor een token moet worden verkregen. Dit kan een van de Azure-services zijn die ondersteuning bieden voor Azure AD-verificatie of een andere resource-URI.
api-versie Query’s uitvoeren De versie van de token-API die moet worden gebruikt. Gebruik '2019-08-01' of hoger (tenzij u Linux-verbruik gebruikt, dat momenteel alleen '2017-09-01' biedt, zie opmerking hierboven).
X-IDENTITY-HEADER Header De waarde van de IDENTITY_HEADER omgevingsvariabele. Deze header wordt gebruikt om aanvragenvervalsingsaanvallen (SSRF) aan de serverzijde te beperken.
client_id Query’s uitvoeren (Optioneel) De client-id van de door de gebruiker toegewezen identiteit die moet worden gebruikt. Kan niet worden gebruikt voor een aanvraag met principal_id , mi_res_id of object_id . Als alle id-parameters ( , , en ) worden weggelaten, wordt de door het systeem toegewezen client_idprincipal_id identiteit object_idmi_res_id gebruikt.
principal_id Query’s uitvoeren (Optioneel) De principal-id van de door de gebruiker toegewezen identiteit die moet worden gebruikt. object_id is een alias die in plaats daarvan kan worden gebruikt. Kan niet worden gebruikt voor een aanvraag met client_id, mi_res_id of object_id. Als alle id-parameters ( , , en ) worden weggelaten, wordt de door het systeem toegewezen client_idprincipal_id identiteit object_idmi_res_id gebruikt.
mi_res_id Query’s uitvoeren (Optioneel) De Azure-resource-id van de door de gebruiker toegewezen identiteit die moet worden gebruikt. Kan niet worden gebruikt voor een aanvraag met principal_id , client_id of object_id . Als alle id-parameters ( , , en ) worden weggelaten, wordt de door het systeem toegewezen client_idprincipal_id identiteit object_idmi_res_id gebruikt.

Belangrijk

Als u tokens wilt verkrijgen voor door de gebruiker toegewezen identiteiten, moet u een van de optionele eigenschappen opnemen. Anders probeert de tokenservice een token te verkrijgen voor een door het systeem toegewezen identiteit, die al dan niet bestaat.

Een geslaagd 200 OK-antwoord bevat een JSON-body met de volgende eigenschappen:

Naam van eigenschap Description
access_token Het aangevraagde toegangs token. De aanroepende webservice kan dit token gebruiken om te verifiëren bij de ontvangende webservice.
client_id De client-id van de identiteit die is gebruikt.
expires_on De periode waarin het toegangs token verloopt. De datum wordt weergegeven als het aantal seconden van '1970-01-01T0:0:0Z UTC' (komt overeen met de claim van het exp token).
not_before De periode waarin het toegangsken van kracht wordt en kan worden geaccepteerd. De datum wordt weergegeven als het aantal seconden van '1970-01-01T0:0:0Z UTC' (komt overeen met de claim van het nbf token).
resource De resource waarvoor het toegangs token is aangevraagd, die overeenkomt met de resource queryreeksparameter van de aanvraag.
token_type Geeft de waarde van het tokentype aan. Het enige type dat door Azure AD wordt ondersteund, is Bearer. Zie het OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) voormeer informatie over Bearer-tokens.

Dit antwoord is hetzelfde als het antwoord voor de toegangsaanvraag van de Azure AD-service-naar-service-toegang.

REST-protocolvoorbeelden

Een voorbeeldaanvraag kan er als volgt uitzien:

GET /MSI/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1
Host: localhost:4141
X-IDENTITY-HEADER: 853b9a84-5bfa-4b22-a3f3-0b9a43d9ad8a

En een voorbeeldreactie kan er als volgt uitzien:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJ0eXAi…",
    "expires_on": "1586984735",
    "resource": "https://vault.azure.net",
    "token_type": "Bearer",
    "client_id": "5E29463D-71DA-4FE0-8E69-999B57DB23B0"
}

Codevoorbeelden

Tip

Voor .NET-talen kunt u ook Microsoft.Azure.Services.AppAuthentication gebruiken in plaats van deze aanvraag zelf te maken.

private readonly HttpClient _client;
// ...
public async Task<HttpResponseMessage> GetToken(string resource)  {
    var request = new HttpRequestMessage(HttpMethod.Get, 
        String.Format("{0}/?resource={1}&api-version=2019-08-01", Environment.GetEnvironmentVariable("IDENTITY_ENDPOINT"), resource));
    request.Headers.Add("X-IDENTITY-HEADER", Environment.GetEnvironmentVariable("IDENTITY_HEADER"));
    return await _client.SendAsync(request);
}

De bibliotheek Microsoft.Azure.Services.AppAuthentication voor .NET gebruiken

Voor .NET-toepassingen en -functies is de eenvoudigste manier om met een beheerde identiteit te werken via het pakket Microsoft.Azure.Services.AppAuthentication. Met deze bibliotheek kunt u uw code ook lokaal testen op uw ontwikkelmachine, met behulp van uw gebruikersaccount van Visual Studio, de Azure CLIof geïntegreerde Active Directory-verificatie. Wanneer deze wordt gehost in de cloud, wordt standaard een door het systeem toegewezen identiteit gebruikt, maar u kunt dit gedrag aanpassen met behulp van een connection string-omgevingsvariabele die verwijst naar de client-id van een door de gebruiker toegewezen identiteit. Zie de Naslag voor Microsoft.Azure.Services.AppAuthenticationvoor meer informatie over ontwikkelingsopties met deze bibliotheek. In deze sectie ziet u hoe u aan de slag gaat met de bibliotheek in uw code.

  1. Voeg verwijzingen naar Microsoft.Azure.Services.AppAuthentication en andere benodigde NuGet-pakketten toe aan uw toepassing. In het onderstaande voorbeeld wordt ook Microsoft.Azure.KeyVault gebruikt.

  2. Voeg de volgende code toe aan uw toepassing en wijzig deze om de juiste resource te bereiken. In dit voorbeeld ziet u twee manieren om te werken met Azure Key Vault:

    using Microsoft.Azure.Services.AppAuthentication;
    using Microsoft.Azure.KeyVault;
    // ...
    var azureServiceTokenProvider = new AzureServiceTokenProvider();
    string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync("https://vault.azure.net");
    // OR
    var kv = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(azureServiceTokenProvider.KeyVaultTokenCallback));
    

Als u een door de gebruiker toegewezen beheerde identiteit wilt gebruiken, kunt u de AzureServicesAuthConnectionString toepassingsinstelling instellen op RunAs=App;AppId=<clientId-guid> . Vervang <clientId-guid> door de client-id van de identiteit die u wilt gebruiken. U kunt meerdere van dergelijke verbindingsreeksen definiëren met behulp van aangepaste toepassingsinstellingen en hun waarden doorgeven aan de AzureServiceTokenProvider-constructor.

    var identityConnectionString1 = Environment.GetEnvironmentVariable("UA1_ConnectionString");
    var azureServiceTokenProvider1 = new AzureServiceTokenProvider(identityConnectionString1);
    
    var identityConnectionString2 = Environment.GetEnvironmentVariable("UA2_ConnectionString");
    var azureServiceTokenProvider2 = new AzureServiceTokenProvider(identityConnectionString2);

Zie de naslag voor Microsoft.Azure.Services.AppAuthentication en het voorbeeld van App Service en KeyVault met MSI .NETvoor meer informatie over het configureren van AzureServiceTokenProvider en de bewerkingen die worden uitgevoerd.

De Azure SDK voor Java gebruiken

Voor Java-toepassingen en -functies is de eenvoudigste manier om met een beheerde identiteit te werken via de Azure SDK voor Java. In deze sectie ziet u hoe u aan de slag gaat met de bibliotheek in uw code.

  1. Voeg een verwijzing toe naar de Azure SDK-bibliotheek. Voor Maven-projecten kunt u dit fragment toevoegen aan de dependencies sectie van het POM-bestand van het project:

    <dependency>
      <groupId>com.azure.resourcemanager</groupId>
      <artifactId>azure-resourcemanager</artifactId>
      <version>2.10.0</version>
    </dependency>
    
  2. Gebruik het ManagedIdentityCredential -object voor verificatie. In dit voorbeeld ziet u hoe dit mechanisme kan worden gebruikt voor het werken met Azure Key Vault:

    import com.azure.core.management.AzureEnvironment;
    import com.azure.core.management.profile.AzureProfile;
    import com.azure.identity.ManagedIdentityCredential;
    import com.azure.identity.ManagedIdentityCredentialBuilder;
    import com.azure.resourcemanager.AzureResourceManager;
    import com.azure.resourcemanager.keyvault.models.Vault;
    //...
    AzureProfile azureProfile = new AzureProfile(AzureEnvironment.AZURE);
    ManagedIdentityCredential managedIdentityCredential = new ManagedIdentityCredentialBuilder().build();
    AzureResourceManager azure = AzureResourceManager.authenticate(managedIdentityCredential, azureProfile).withSubscription("subscription");
    
    Vault vault = azure.vaults().getByResourceGroup("resourceGroup", "keyVaultName");
    
    

Raadpleeg deze quickstartvoor meer informatie over het gebruik van de Azure SDK voor Java. Raadpleeg deze handleiding voor meer informatie over Azure Identiy en verificatie en beheerde identiteit in het algemeen

Een identiteit verwijderen

Een door het systeem toegewezen identiteit kan worden verwijderd door de functie uit te uitschakelen via de portal, PowerShell of CLI op dezelfde manier als de functie is gemaakt. Door de gebruiker toegewezen identiteiten kunnen afzonderlijk worden verwijderd. Als u alle identiteiten wilt verwijderen, stelt u het identiteitstype in op Geen.

Als u een door het systeem toegewezen identiteit op deze manier verwijdert, wordt deze ook verwijderd uit Azure AD. Door het systeem toegewezen identiteiten worden ook automatisch verwijderd uit Azure AD wanneer de app-resource wordt verwijderd.

Alle identiteiten in een ARM-sjabloon verwijderen:

"identity": {
    "type": "None"
}

Alle identiteiten in de Azure PowerShell verwijderen (Azure Functions alleen):

# Update an existing function app to have IdentityType "None".
Update-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -IdentityType None

Notitie

Er is ook een toepassingsinstelling die kan worden ingesteld, WEBSITE_DISABLE_MSI, waarmee alleen de lokale tokenservice wordt uitgeschakeld. De identiteit blijft echter op zijn plaats en hulpprogramma's tonen de beheerde identiteit nog steeds als 'aan' of 'ingeschakeld'. Als gevolg hiervan wordt het gebruik van deze instelling niet aanbevolen.

Volgende stappen