Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln visar hur du arbetar med användaridentiteter när du använder inbyggd autentisering och auktorisering i Azure App Service.
Förutsättningar
Ett webbprogram som körs på Azure App Service som har modulen autentisering/auktorisering för App Service aktiverad.
Åtkomst till användarkrav i applikationskod
Appens autentiserade slutanvändare eller klientprogram gör anspråk på inkommande tokens. App Service gör anspråken tillgängliga för din kod genom att mata in dem i begärandehuvuden. Externa begäranden tillåts inte att ange dessa rubriker, så de finns bara om App Service anger dem.
Du kan använda anspråksinformationen som App Service-autentisering tillhandahåller för att utföra auktoriseringskontroller i din appkod. Kod på valfritt språk eller ramverk kan hämta nödvändig information från begärandehuvudena. Vissa kodramverk ger extra alternativ som kan vara mer praktiska. Se Ramverksspecifika alternativ.
I följande tabell beskrivs några exempelrubriker:
Rubrik | Beskrivning |
---|---|
X-MS-CLIENT-PRINCIPAL |
En Base64-kodad JSON-representation av tillgängliga anspråk. Mer information finns i Avkoda klientens titelhuvud. |
X-MS-CLIENT-PRINCIPAL-ID |
En identifierare som identitetsprovidern anger för anroparen. |
X-MS-CLIENT-PRINCIPAL-NAME |
Ett läsbart namn som identitetsprovidern anger för anroparen, till exempel en e-postadress eller användarens huvudnamn. |
X-MS-CLIENT-PRINCIPAL-IDP |
Namnet på den identitetsprovider som App Service-autentisering använder. |
Liknande rubriker exponerar providertoken. Microsoft Entra ställer in X-MS-TOKEN-AAD-ACCESS-TOKEN
och X-MS-TOKEN-AAD-ID-TOKEN
leverantörens tokenhuvuden efter behov.
Anmärkning
App Service gör begäranderubrikerna tillgängliga för alla språkramverk. Olika språkramverk kan presentera dessa rubriker för appkoden i olika format, till exempel gemener eller rubrikfall.
Avkoda klienthuvudhuvudet
Rubriken X-MS-CLIENT-PRINCIPAL
innehåller den fullständiga uppsättningen tillgängliga anspråk i Base64-kodad JSON. För att hantera denna header måste appen dekoda nyttolasten och iterera genom matrisen claims
för att hitta relevanta påståenden.
Anmärkning
Dessa anspråk genomgår en standardprocess för mappning av anspråk, så vissa namn kan skilja sig från de som visas i token.
Den avkodade nyttolaststrukturen är följande:
{
"auth_typ": "",
"claims": [
{
"typ": "",
"val": ""
}
],
"name_typ": "",
"role_typ": ""
}
I följande tabell beskrivs egenskaperna.
Fastighet | Type | Beskrivning |
---|---|---|
auth_typ |
string | Namnet på den identitetsprovider som App Service-autentisering använder. |
claims |
array | En matris med objekt som representerar tillgängliga anspråk. Varje objekt innehåller typ och val egenskaper. |
typ |
string | Namnet på anspråket, som kan omfattas av standardmappning av anspråk och skilja sig från motsvarande anspråk i token. |
val |
string | Anspråkets värde. |
name_typ |
string | Namnanspråkstypen, som vanligtvis är en URI som tillhandahåller schemainformation om anspråket name om ett är definierat. |
role_typ |
string | Rollanspråkstypen, som vanligtvis är en URI som tillhandahåller schemainformation om anspråket role om det har definierats. |
För enkelhetens skull kan du konvertera anspråk till en representation som appens språkramverk använder. I följande C#-exempel skapas en ClaimsPrincipal
typ som appen ska använda.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Claims;
using System.Text;
using System.Text.Json;
using System.Text.Json.Serialization;
using Microsoft.AspNetCore.Http;
public static class ClaimsPrincipalParser
{
private class ClientPrincipalClaim
{
[JsonPropertyName("typ")]
public string Type { get; set; }
[JsonPropertyName("val")]
public string Value { get; set; }
}
private class ClientPrincipal
{
[JsonPropertyName("auth_typ")]
public string IdentityProvider { get; set; }
[JsonPropertyName("name_typ")]
public string NameClaimType { get; set; }
[JsonPropertyName("role_typ")]
public string RoleClaimType { get; set; }
[JsonPropertyName("claims")]
public IEnumerable<ClientPrincipalClaim> Claims { get; set; }
}
public static ClaimsPrincipal Parse(HttpRequest req)
{
var principal = new ClientPrincipal();
if (req.Headers.TryGetValue("x-ms-client-principal", out var header))
{
var data = header[0];
var decoded = Convert.FromBase64String(data);
var json = Encoding.UTF8.GetString(decoded);
principal = JsonSerializer.Deserialize<ClientPrincipal>(json, new JsonSerializerOptions { PropertyNameCaseInsensitive = true });
}
I det här läget kan koden iterera igenom principal.Claims
för att kontrollera anspråk som en del av valideringen. Du kan också konvertera principal.Claims
till ett standardobjekt och använda det för att utföra dessa kontroller senare i pipelinen för begäran. Du kan också använda objektet för att associera användardata och för andra användningsområden.
Resten av funktionen utför den här konverteringen för att skapa en ClaimsPrincipal
som kan användas i annan .NET-kod.
var identity = new ClaimsIdentity(principal.IdentityProvider, principal.NameClaimType, principal.RoleClaimType);
identity.AddClaims(principal.Claims.Select(c => new Claim(c.Type, c.Value)));
return new ClaimsPrincipal(identity);
}
}
Ramverksspecifika alternativ
För ASP.NET 4.6-appar fyller App Service
ClaimsPrincipal.Current
med den autentiserade användarens krav. Du kan följa standardmönstret för .NET-kod, inklusive attributet[Authorize]
.ClaimsPrincipal.Current
är inte ifyllt för .NET-kod i Azure Functions, men du kan fortfarande hitta användaranspråken i begärandehuvudenaClaimsPrincipal
eller hämta objektet från begärandekontexten eller via en bindningsparameter. Mer information finns i Arbeta med klientidentiteter i Azure Functions.För PHP-appar fyller App Service på samma sätt variabeln
_SERVER['REMOTE_USER']
.För Java-appar är anspråken tillgängliga från Tomcat-servleten.
För .NET Core
Microsoft.Identity.Web
har stöd för att fylla den aktuella användaren med App Service-autentisering. Mer information finns i Integrering med Azure App Services-autentisering av webbappar som körs med Microsoft.Identity.Web. En demonstration av en webbapp som har åtkomst till Microsoft Graph finns i Självstudie: Komma åt Microsoft Graph från en skyddad .NET-app som användare.
Anmärkning
För att anspråksmappning ska fungera måste du aktivera tokenarkivet för din app.
Få åtkomst till användarkrav med hjälp av API:et
Om tokenarkivet är aktiverat för din app kan du även anropa /.auth/me
för att hämta annan information om den autentiserade användaren.