Microsoft Entra (ME-ID) groepen, beheerdersrollen en app-rollen (.NET 5 tot .NET 7)

Artikel
01/23/2025

Notitie

Dit is niet de nieuwste versie van dit artikel. Zie voor de huidige ASP.NET Core-release de nieuwste versie van ASP.NET Core Blazor WebAssembly met Microsoft Entra ID-groepen en -rollen.

In dit artikel wordt uitgelegd hoe u Blazor WebAssembly configureert voor het gebruik van Microsoft Entra ID-groepen en -rollen.

Microsoft Entra (ME-ID) biedt verschillende autorisatiemethoden die kunnen worden gecombineerd met ASP.NET Core Identity:

Groepen
- Veiligheid
- Microsoft 365
- Distributie
Rollen
- ME-ID Beheerdersrollen
- App-rollen

De richtlijnen in dit artikel zijn van toepassing op de Blazor WebAssembly ME-ID implementatiescenario's die worden beschreven in de volgende artikelen:

De richtlijnen van het artikel bevatten instructies voor client- en server-apps:

CLIENT: losstaande Blazor WebAssembly-apps of de Client-app van een extern beheerde Blazor-oplossing.
SERVER-: ASP.NET Core server-API-/web-API-apps of de Server-app van een gehoste Blazor-oplossing. U kunt de SERVER-richtlijnen negeren in het artikel voor een zelfstandige Blazor WebAssembly-app.

De voorbeelden in dit artikel maken gebruik van nieuwe .NET/C#-functies. Wanneer u de voorbeelden met .NET 7 of eerder gebruikt, zijn kleine wijzigingen vereist. De voorbeelden van tekst en code die betrekking hebben op interactie met ME-ID en Microsoft Graph zijn echter hetzelfde voor alle versies van ASP.NET Core.

Voorwaarde

De richtlijnen in dit artikel implementeren de Microsoft Graph API volgens de Graph SDK richtlijnen in Gebruik Graph API met ASP.NET Core Blazor WebAssembly. Volg de Graph SDK implementatierichtlijnen om de app te configureren en te testen om te bevestigen dat de app Graph API-gegevens kan verkrijgen voor een testgebruikersaccount. Bekijk daarnaast de kruisverwijzingen naar het beveiligingsartikel van het Graph API-artikel in om de beveiligingsconcepten van Microsoft Graph te bekijken.

Wanneer u lokaal met de Graph SDK test, raden we u aan om voor elke test een nieuwe privé-/incognitobrowsersessie te gebruiken om te voorkomen dat achterblijvende cookies de tests verstoren. Zie Een ASP.NET Core Blazor WebAssembly zelfstandige app beveiligen met Microsoft Entra IDvoor meer informatie.

Scopes

Om Microsoft Graph API aanroepen voor gebruikersprofiel-, roltoewijzings- en groepslidmaatschapsgegevens toe te laten:

Een CLIENT--app wordt geconfigureerd met het gedelegeerdeUser.Read bereik (https://graph.microsoft.com/User.Read) in de Azure portal, omdat de toegang tot het lezen van gebruikersgegevens wordt bepaald door de bereiken die aan afzonderlijke gebruikers zijn verleend (gedelegeerd).
Een SERVER--app is geconfigureerd met het toepassingsbereikGroupMember.Read.All (https://graph.microsoft.com/GroupMember.Read.All) in Azure Portal, omdat de app toegang heeft tot informatie over groepslidmaatschap, niet op basis van afzonderlijke gebruikersautorisatie voor toegang tot gegevens over groepsleden.

De voorgaande bereiken zijn vereist naast de bereiken die nodig zijn in ME-ID implementatiescenario's zoals beschreven in de eerder genoemde artikelen (Stand-alone met Microsoft Accounts, Stand-alone met ME-IDen gehost door ME-ID).

Zie Overzicht van machtigingen en toestemming in het Microsoft Identity Platform en Overzicht van Microsoft Graph-machtigingenvoor meer informatie.

Machtigingen en omvangen hebben dezelfde betekenis en worden door elkaar gebruikt in beveiligingsdocumentatie en de Azure portal. Tenzij de tekst verwijst naar de Azure portal, gebruikt dit artikel -bereik/-bereiken bij het verwijzen naar de Graph-machtigingen.

Scopes zijn niet hoofdlettergevoelig, dus User.Read is hetzelfde als user.read. U kunt beide indelingen gebruiken, maar we raden een consistente keuze aan in toepassingscode.

Attribuut groepslidmaatschapsclaims

Stel in het manifest van de app in Azure Portal voor CLIENT-- en SERVER--apps het kenmerk in op . Een waarde van DirectoryRole resulteert in ME-ID het verzenden van alle rollen van de aangemelde gebruiker in de bekende id-claim (wids):

Open de Azure Portal-registratie van de app.
Selecteer >manifest beheren in de zijbalk.
Zoek het kenmerk groupMembershipClaims.
Stel de waarde in op DirectoryRole ("groupMembershipClaims": "DirectoryRole").
Selecteer de knop Opslaan als u wijzigingen hebt aangebracht.

Stel in het manifest van de app in Azure Portal voor CLIENT-- en SERVER--apps het kenmerk in op . Een waarde van All resulteert in ME-ID het verzenden van alle beveiligingsgroepen, distributiegroepen en rollen van de aangemelde gebruiker in de bekende id-claim (wids):

Open de Azure Portal-registratie van de app.
Selecteer Beheer>Manifest in de zijbalk.
Zoek het kenmerk groupMembershipClaims.
Stel de waarde in op All ("groupMembershipClaims": "All").
Selecteer de knop Opslaan als u wijzigingen hebt aangebracht.

Aangepast gebruikersaccount

Wijs gebruikers toe aan ME-ID beveiligingsgroepen en ME-ID beheerdersrollen in Azure Portal.

De voorbeelden in dit artikel:

Stel dat een gebruiker is toegewezen aan de ME-ID factureringsbeheerder rol in Azure Portal ME-ID tenant voor autorisatie voor toegang tot server-API-gegevens.
Gebruik autorisatiebeleid om de toegang binnen de CLIENT-- en SERVER--apps te beheren.

Breid in de app CLIENTRemoteUserAccount uit om eigenschappen op te nemen voor:

Roles: ME-ID App-rollen-array (behandeld in de sectie App-rollen)
Wids: ME-ID Administrator-rollen in bekende ID-claim (wids)
Oid: Onveranderbare claim voor object-id (oid) (unieke identificatie van een gebruiker binnen en tussen tenants)

CustomUserAccount.cs:

using System.Text.Json.Serialization;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

namespace BlazorSample;

public class CustomUserAccount : RemoteUserAccount
{
    [JsonPropertyName("roles")]
    public List<string>? Roles { get; set; }

    [JsonPropertyName("wids")]
    public List<string>? Wids { get; set; }

    [JsonPropertyName("oid")]
    public string? Oid { get; set; }
}

Voeg een pakketreferentie toe aan de CLIENT--app voor Microsoft.Graph.

Notitie

Zie de artikelen in de NuGet-documentatie onder Pakketten installeren en beheren bij Gebruiksworkflow voor pakketten (NuGet documentatie)voor hulp bij het toevoegen van pakketten aan .NET-apps. Bevestig de juiste pakketversies op NuGet.org.

Voeg de graph SDK-hulpprogrammaklassen en -configuratie toe aan de Graph SDK richtlijnen voor het Graph API gebruiken met ASP.NET Core Blazor WebAssembly artikel. Geef het bereik voor het toegangstoken User.Read op zoals weergegeven in het voorbeeldbestand wwwroot/appsettings.json van het artikel.

Voeg de volgende aangepaste gebruikersaccountfaciliteit toe aan de CLIENT app. De aangepaste gebruikersfabriek wordt gebruikt om het volgende tot stand te brengen:

App-rolclaims (appRole) (behandeld in de sectie App-rollen).
ME-ID claims voor de rol van beheerder (directoryRole).
Voorbeeld van gebruikersprofielgegevensclaims voor het mobiele telefoonnummer van de gebruiker (mobilePhone) en kantoorlocatie (officeLocation).
ME-ID groepsclaims (directoryGroup).
Een ILogger (logger) voor het gemak voor het geval u informatie of fouten wilt vastleggen.

CustomAccountFactory.cs:

using System.Security.Claims;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;
using Microsoft.Graph;
using Microsoft.Kiota.Abstractions.Authentication;

namespace BlazorSample;

public class CustomAccountFactory() 
    : AccountClaimsPrincipalFactory<CustomUserAccount>
{
    private readonly ILogger<CustomAccountFactory> logger;
    private readonly IServiceProvider serviceProvider;
    private readonly string? baseUrl =
        string.Join("/",
            config.GetSection("MicrosoftGraph")["BaseUrl"] ??
                "https://graph.microsoft.com",
            config.GetSection("MicrosoftGraph")["Version"] ??
                "v1.0");

    public CustomAccountFactory(IAccessTokenProviderAccessor accessor,
        IServiceProvider serviceProvider,
        ILogger<CustomAccountFactory> logger)
        : base(accessor)
    {
        this.serviceProvider = serviceProvider;
        this.logger = logger;
    }

    public override async ValueTask<ClaimsPrincipal> CreateUserAsync(
        CustomUserAccount account,
        RemoteAuthenticationUserOptions options)
    {
        var initialUser = await base.CreateUserAsync(account, options);

        if (initialUser.Identity is not null &&
            initialUser.Identity.IsAuthenticated)
        {
            var userIdentity = initialUser.Identity as ClaimsIdentity;

            if (userIdentity is not null && !string.IsNullOrEmpty(baseUrl))
            {
                account?.Roles?.ForEach((role) =>
                {
                    userIdentity.AddClaim(new Claim("appRole", role));
                });

                account?.Wids?.ForEach((wid) =>
                {
                    userIdentity.AddClaim(new Claim("directoryRole", wid));
                });

                try
                {
                    var client = new GraphServiceClient(
                        new HttpClient(),
                        serviceProvider
                            .GetRequiredService<IAuthenticationProvider>(),
                        baseUrl);

                    var user = await client.Me.GetAsync();

                    if (user is not null)
                    {
                        userIdentity.AddClaim(new Claim("mobilephone",
                            user.MobilePhone ?? "(000) 000-0000"));
                        userIdentity.AddClaim(new Claim("officelocation",
                            user.OfficeLocation ?? "Not set"));
                    }

                    var requestMemberOf = client.Users[account?.Oid].MemberOf;
                    var graphGroups = await requestMemberOf.GraphGroup.GetAsync();

                    if (graphGroups?.Value is not null)
                    {
                        foreach (var entry in graphGroups.Value)
                        {
                            if (entry.Id is not null)
                            {
                                userIdentity.AddClaim(
                                    new Claim("directoryGroup", entry.Id));
                            }
                        }
                    }
                }
                catch (AccessTokenNotAvailableException exception)
                {
                    exception.Redirect();
                }
            }
        }

        return initialUser;
    }
}

using System.Security.Claims;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal;
using Microsoft.Graph;

namespace BlazorSample;

public class CustomAccountFactory() 
    : AccountClaimsPrincipalFactory<CustomUserAccount>(accessor)
{
    private readonly ILogger<CustomAccountFactory> logger;
    private readonly IServiceProvider serviceProvider;

    public CustomAccountFactory(IAccessTokenProviderAccessor accessor,
        IServiceProvider serviceProvider,
        ILogger<CustomAccountFactory> logger)
        : base(accessor)
    {
        this.serviceProvider = serviceProvider;
        this.logger = logger;
    }

    public override async ValueTask<ClaimsPrincipal> CreateUserAsync(
        CustomUserAccount account,
        RemoteAuthenticationUserOptions options)
    {
        var initialUser = await base.CreateUserAsync(account, options);

        if (initialUser.Identity is not null &&
            initialUser.Identity.IsAuthenticated)
        {
            var userIdentity = initialUser.Identity as ClaimsIdentity;

            if (userIdentity is not null)
            {
                account?.Roles?.ForEach((role) =>
                {
                    userIdentity.AddClaim(new Claim("appRole", role));
                });

                account?.Wids?.ForEach((wid) =>
                {
                    userIdentity.AddClaim(new Claim("directoryRole", wid));
                });

                try
                {
                    var client = ActivatorUtilities
                        .CreateInstance<GraphServiceClient>(serviceProvider);
                    var request = client.Me.Request();
                    var user = await request.GetAsync();

                    if (user is not null)
                    {
                        userIdentity.AddClaim(new Claim("mobilephone",
                            user.MobilePhone ?? "(000) 000-0000"));
                        userIdentity.AddClaim(new Claim("officelocation",
                            user.OfficeLocation ?? "Not set"));
                    }

                    var requestMemberOf = client.Users[account?.Oid].MemberOf;
                    var memberships = await requestMemberOf.Request().GetAsync();

                    if (memberships is not null)
                    {
                        foreach (var entry in memberships)
                        {
                            if (entry.ODataType == "#microsoft.graph.group")
                            {
                                userIdentity.AddClaim(
                                    new Claim("directoryGroup", entry.Id));
                            }
                        }
                    }
                }
                catch (AccessTokenNotAvailableException exception)
                {
                    exception.Redirect();
                }
            }
        }

        return initialUser;
    }
}

De voorgaande code bevat geen transitieve lidmaatschappen. Als voor de app directe en transitieve groepslidmaatschapsclaims zijn vereist, vervangt u de eigenschap MemberOf (IUserMemberOfCollectionWithReferencesRequestBuilder) door TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).

De voorgaande code negeert groepslidmaatschapsclaims (groups) die ME-ID beheerdersrollen (#microsoft.graph.directoryRole type) zijn, omdat de GUID-waarden die door ME-ID worden geretourneerd beheerdersrol-entiteits-id's zijn en niet rol-sjabloon-id's . Entiteits-id's zijn niet stabiel over tenants heen en mogen niet worden gebruikt om autorisatiebeleid voor gebruikers in applicaties te maken. Gebruik altijd sjabloon-ID's voor ME-ID beheerdersrollen die worden geleverd door wids claims.

De wids claim (en dus directoryRole claim) met een waarde van b79fbf4d-3ef9-4689-8143-76b194e85509 bestaat voor niet-gastaccounts van de tenant. Het verwijst niet naar een ME-ID beheerdersrolsjabloon-id.

Configureer in de CLIENT-app de MSAL-verificatie voor het gebruik van de factory voor aangepaste gebruikersaccounts.

Controleer of het Program-bestand gebruikmaakt van de Microsoft.AspNetCore.Components.WebAssembly.Authentication naamruimte:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Werk de AddMsalAuthentication aanroep naar het volgende bij. Houd er rekening mee dat de RemoteUserAccount van het Blazor framework wordt vervangen door de CustomUserAccount van de app voor de MSAL-verificatie en de principalfactor voor accountclaims:

builder.Services.AddMsalAuthentication<RemoteAuthenticationState,
    CustomUserAccount>(options =>
    {
        builder.Configuration.Bind("AzureAd",
            options.ProviderOptions.Authentication);
    })
    .AddAccountClaimsPrincipalFactory<RemoteAuthenticationState, CustomUserAccount,
        CustomAccountFactory>();

Bevestig de aanwezigheid van de Graph SDK code die wordt beschreven in het Graph API gebruiken met ASP.NET Core Blazor WebAssembly artikel en of de wwwroot/appsettings.json configuratie juist is volgens de Graph SDK richtlijnen:

var baseUrl = 
    string.Join("/",
        builder.Configuration.GetSection("MicrosoftGraph")["BaseUrl"] ??
            "https://graph.microsoft.com",
        builder.Configuration.GetSection("MicrosoftGraph")["Version"] ??
            "v1.0");
var scopes = builder.Configuration.GetSection("MicrosoftGraph:Scopes")
    .Get<List<string>>() ?? [ "user.read" ];

builder.Services.AddGraphClient(baseUrl, scopes);

wwwroot/appsettings.json:

{
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com",
    "Version": "v1.0",
    "Scopes": [
      "user.read"
    ]
  }
}

Autorisatieconfiguratie

Maak in de CLIENT-app een -beleid voor elke app-rol, ME-ID beheerdersrol of beveiligingsgroep in het Program-bestand. In het volgende voorbeeld wordt een beleid gemaakt voor de ME-ID ingebouwde factureringsbeheerder rol:

builder.Services.AddAuthorizationCore(options =>
{
    options.AddPolicy("BillingAdministrator", policy => 
        policy.RequireClaim("directoryRole", 
            "b0f54661-2d74-4c50-afa3-1ec803f12efe"));
});

Zie Rolsjabloon-ID's in de documentatie van Entra voor de volledige lijst met ID's voor ME-ID beheerdersrollen. Zie Autorisatie op basis van beleid in ASP.NET Corevoor meer informatie over autorisatiebeleid.

In de volgende voorbeelden gebruikt de CLIENT--app het voorgaande beleid om de gebruiker te autoriseren.

Het AuthorizeView onderdeel werkt met het beleid:

<AuthorizeView Policy="BillingAdministrator">
    <Authorized>
        <p>
            The user is in the 'Billing Administrator' ME-ID Administrator Role
            and can see this content.
        </p>
    </Authorized>
    <NotAuthorized>
        <p>
            The user is NOT in the 'Billing Administrator' role and sees this
            content.
        </p>
    </NotAuthorized>
</AuthorizeView>

Toegang tot een volledig onderdeel kan worden gebaseerd op het beleid met behulp van een [Authorize] kenmerkrichtlijn (AuthorizeAttribute):

@page "/"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "BillingAdministrator")]

Als de gebruiker niet is gemachtigd, wordt deze omgeleid naar de aanmeldingspagina van ME-ID.

Een beleidscontrole kan ook worden uitgevoerd in code met procedurele logica.

CheckPolicy.razor:

@page "/checkpolicy"
@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService AuthorizationService

<h1>Check Policy</h1>

<p>This component checks a policy in code.</p>

<button @onclick="CheckPolicy">Check 'BillingAdministrator' policy</button>

<p>Policy Message: @policyMessage</p>

@code {
    private string policyMessage = "Check hasn't been made yet.";

    [CascadingParameter]
    private Task<AuthenticationState> authenticationStateTask { get; set; }

    private async Task CheckPolicy()
    {
        var user = (await authenticationStateTask).User;

        if ((await AuthorizationService.AuthorizeAsync(user, 
            "BillingAdministrator")).Succeeded)
        {
            policyMessage = "Yes! The 'BillingAdministrator' policy is met.";
        }
        else
        {
            policyMessage = "No! 'BillingAdministrator' policy is NOT met.";
        }
    }
}

Met behulp van de voorgaande benaderingen kunt u ook op beleid gebaseerde toegang maken voor app-rollen, waarbij de GUID die voor het beleid wordt gebruikt, is ingesteld in het appRoles element van het manifest van de app in Azure Portal en beveiligingsgroepen, waarbij de GUID die voor het beleid wordt gebruikt, overeenkomt met de groep Object-id in azure Portal Groepen deelvenster.

Toegang tot server-API/web-API autoriseren

Met een API-app SERVER kunnen gebruikers toegang krijgen tot beveiligde API-eindpunten met autorisatiebeleid voor beveiligingsgroepen, ME-ID beheerdersrollen en app-rollen wanneer een toegangstoken groups, widsen role claims bevat. In het volgende voorbeeld wordt een beleid gemaakt voor de ME-ID Factureringsbeheerder rol in het bestand Program met behulp van de claims wids (bekende id's/rolsjabloon-id's):

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("BillingAdministrator", policy => 
        policy.RequireClaim("wids", "b0f54661-2d74-4c50-afa3-1ec803f12efe"));
});

Zie Rolsjabloon-id's in de Azure-documentatie voor de volledige lijst met id's voor ME-ID beheerdersrollen. Zie Autorisatie op basis van beleid in ASP.NET Corevoor meer informatie over autorisatiebeleid.

Toegang tot een controller in de SERVER--app kan worden gebaseerd op het gebruik van een [Authorize] kenmerk met de naam van het beleid (API-documentatie: AuthorizeAttribute).

In het volgende voorbeeld wordt de toegang tot factureringsgegevens van de BillingDataController beperkt tot Azure-factureringsbeheerders met een beleidsnaam van BillingAdministrator:

using Microsoft.AspNetCore.Authorization;

[Authorize(Policy = "BillingAdministrator")]
[ApiController]
[Route("[controller]")]
public class BillingDataController : ControllerBase
{
    ...
}

Zie Op beleid gebaseerde autorisatie in ASP.NET Corevoor meer informatie.

App-rollen

Om de app in de Azure-portal te configureren voor het verstrekken van claims voor app-rollenlidmaatschap, zie App-rollen toevoegen aan uw toepassing en deze ontvangen in het token in de Entra-documentatie.

In het volgende voorbeeld wordt ervan uitgegaan dat de CLIENT-- en SERVER--apps zijn geconfigureerd met twee rollen en dat de rollen zijn toegewezen aan een testgebruiker:

Admin
Developer

Notitie

Bij het ontwikkelen van een gehoste Blazor WebAssembly-app of een clientserverpaar met zelfstandige apps (een zelfstandige Blazor WebAssembly-app en een ASP.NET Core-server-API/web-API-app), moeten de appRoles manifesteigenschap van zowel de client als de server-app-registraties in Azure Portal dezelfde geconfigureerde rollen bevatten. Nadat u de rollen in het manifest van de client-app hebt vastgesteld, kopieert u deze volledig naar het manifest van de server-app. Als u het manifest appRoles niet spiegelt tussen de registraties van de client- en server-app, worden rolclaims niet ingesteld voor geverifieerde gebruikers van de server-API/web-API, zelfs als hun autorisatietoken de juiste toewijzingen in de rolclaims heeft.

Hoewel u rollen niet kunt toewijzen aan groepen zonder een Microsoft Entra ID Premium-account, kunt u rollen toewijzen aan gebruikers en rolclaims ontvangen voor gebruikers met een standaard Azure-account. Voor de richtlijnen in deze sectie is geen ME-ID Premium-account vereist.

Wanneer u met de standaarddirectory werkt, volgt u de richtlijnen in om app-rollen toe te voegen aan uw toepassing en deze in het token te ontvangen, om rollen te configureren en toe te wijzen. Als u niet met de standaardmap werkt, bewerkt u het manifest van de app in Azure Portal om de rollen van de app handmatig in te stellen in de appRoles vermelding van het manifestbestand. Hier volgt een voorbeeld van appRoles vermelding waarmee Admin en Developer rollen worden gemaakt. Deze voorbeeldrollen worden verderop in het voorbeeld van deze sectie gebruikt op onderdeelniveau om toegangsbeperkingen te implementeren:

"appRoles": [
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Administrators manage developers.",
    "displayName": "Admin",
    "id": "{ADMIN GUID}",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Admin"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Developers write code.",
    "displayName": "Developer",
    "id": "{DEVELOPER GUID}",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Developer"
  }
],

Voor de {ADMIN GUID} en {DEVELOPER GUID} tijdelijke aanduidingen in het voorgaande voorbeeld kunt u GUID's genereren met een online GUID-generator (Google-zoekresultaat voor 'guid generator').

Een rol toewijzen aan een gebruiker (of groep als u een Azure-account in de Premium-laag hebt):

Navigeer naar Enterprise-toepassingen in de ME-ID sectie van de Azure-portal.
Selecteer de app. Selecteer Beheren>gebruikers en groepen in de zijbalk.
Schakel het selectievakje in voor een of meer gebruikersaccounts.
Selecteer in het menu bovenaan de gebruikerslijst Toewijzing bewerken.
Selecteer bij de Kies een rol optie Geen geselecteerd.
Kies een rol in de lijst en gebruik de knop Selecteer om deze te selecteren.
Gebruik de knop Toewijzen onder aan het scherm om de rol toe te wijzen.

Er worden meerdere rollen toegewezen in Azure Portal door een gebruiker opnieuw voor elke extra roltoewijzing toe te voegen. Gebruik de knop Gebruiker/groep toevoegen boven aan de lijst met gebruikers om een gebruiker opnieuw toe te voegen. Gebruik de voorgaande stappen om een andere rol toe te wijzen aan de gebruiker. U kunt dit proces zo vaak herhalen als nodig is om extra rollen toe te voegen aan een gebruiker (of groep).

De CustomAccountFactory die wordt weergegeven in de sectie Aangepast gebruikersaccount is ingesteld om te reageren op een role claim met een JSON-matrixwaarde. Voeg de CustomAccountFactory toe en registreer deze in de CLIENT--app, zoals wordt weergegeven in de sectie aangepast gebruikersaccount. U hoeft geen code op te geven om de oorspronkelijke role claim te verwijderen, omdat deze automatisch door het framework wordt verwijderd.

Geef in het Program-bestand van een CLIENT--app de genaamde claim "appRole" op als de rolclaim voor ClaimsPrincipal.IsInRole-controles:

builder.Services.AddMsalAuthentication(options =>
{
    ...

    options.UserOptions.RoleClaim = "appRole";
});

Notitie

Als u de directoryRoles claim (ADD Administrator Roles) wilt gebruiken, wijst u 'directoryRoles' toe aan de RemoteAuthenticationUserOptions.RoleClaim.

Geef in het Program-bestand van een SERVER--app de claim met de naam 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role' op als de rolclaim voor ClaimsPrincipal.IsInRole controles:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(options =>
    {
        Configuration.Bind("AzureAd", options);
        options.TokenValidationParameters.RoleClaimType = 
            "http://schemas.microsoft.com/ws/2008/06/identity/claims/role";
    },
    options => { Configuration.Bind("AzureAd", options); });

Notitie

Wanneer één verificatieschema is geregistreerd, wordt het verificatieschema automatisch gebruikt als het standaardschema van de app en hoeft het schema niet te worden opgegeven voor AddAuthentication of via AuthenticationOptions. Zie Overzicht van ASP.NET Core Authentication en de ASP.NET Core-aankondiging (aspnet/Aankondigingen #490)voor meer informatie.

Notitie

Als u de wids claim (ADD Administrator Roles) wilt gebruiken, wijst u 'wids' toe aan de TokenValidationParameters.RoleClaimType.

Nadat u de voorgaande stappen hebt voltooid om rollen te maken en toe te wijzen aan gebruikers (of groepen als u een Azure-account met een Premium-laag hebt) en de CustomAccountFactory hebt geïmplementeerd met de Graph SDK, zoals eerder in dit artikel en in Graph API gebruiken met ASP.NET Core Blazor WebAssembly, ziet u een appRole claim voor elke toegewezen rol waaraan een aangemelde gebruiker is toegewezen (of rollen die zijn toegewezen aan groepen waarvan ze lid zijn). Voer de app uit met een testgebruiker om te bevestigen dat de claim(en) aanwezig zijn zoals verwacht. Wanneer u lokaal met de Graph SDK test, raden we u aan om voor elke test een nieuwe privé-/incognitobrowsersessie te gebruiken om te voorkomen dat achterblijvende cookies de tests verstoren. Zie Een ASP.NET Core Blazor WebAssembly zelfstandige app beveiligen met Microsoft Entra IDvoor meer informatie.

Op dit moment zijn methoden voor onderdeelautorisatie functioneel. Een van de autorisatiemechanismen in onderdelen van de CLIENT--app kan de Admin rol gebruiken om de gebruiker te autoriseren:

AuthorizeView onderdeel
```
<AuthorizeView Roles="Admin">
```
[Authorize] kenmerkrichtlijn (AuthorizeAttribute)
```
@attribute [Authorize(Roles = "Admin")]
```

procedurele logica

var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
var user = authState.User;

if (user.IsInRole("Admin")) { ... }

Er worden meerdere roltests ondersteund:

Vereisen dat de gebruiker in de rol van AdminofDeveloper met het AuthorizeView-onderdeel is.
```
<AuthorizeView Roles="Admin, Developer">
    ...
</AuthorizeView>
```
Vereisen dat de gebruiker zich in zowel de Admin- alsDeveloper rollen met het AuthorizeView-onderdeel:
```
<AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>
```
Voor meer informatie over de Context voor de interne AuthorizeView, zie ASP.NET Core Blazor authenticatie en autorisatie.
Vereisen dat de gebruiker in de Admin- ofDeveloper rol is met kenmerk [Authorize].
```
@attribute [Authorize(Roles = "Admin, Developer")]
```
Vereisen dat de gebruiker zich in zowel de AdminalsDeveloper rollen met het kenmerk [Authorize]:
```
@attribute [Authorize(Roles = "Admin")]
@attribute [Authorize(Roles = "Developer")]
```

Vereisen dat de gebruiker zich in bevindt, of in de Adminrol of deDeveloper rol, met procedurele code:

@code {
    private async Task DoSomething()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.IsInRole("Admin") || user.IsInRole("Developer"))
        {
            ...
        }
        else
        {
            ...
        }
    }
}

Vereisen dat de gebruiker in zowel de als rollen met procedurele code door de voorwaardelijk OF () te wijzigen in een voorwaardelijk EN () in het voorgaande voorbeeld:
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
```

Een van de autorisatiemechanismen in controllers van de SERVER-app kan de Admin-rol gebruiken om de gebruiker te autoriseren:

[Authorize] kenmerkrichtlijn (AuthorizeAttribute)
```
[Authorize(Roles = "Admin")]
```
procedurele logica
```
if (User.IsInRole("Admin")) { ... }
```

Er worden meerdere roltests ondersteund:

Vereisen dat de gebruiker in de Admin, of deDeveloper rol is met het kenmerk [Authorize]:
```
[Authorize(Roles = "Admin, Developer")]
```
Vereisen dat de gebruiker zich in zowel de AdminalsDeveloper rollen met het kenmerk [Authorize]:
```
[Authorize(Roles = "Admin")]
[Authorize(Roles = "Developer")]
```

Vereisen dat de gebruiker zich in bevindt de AdminofDeveloper rol met procedurele code:

static readonly string[] scopeRequiredByApi = new string[] { "API.Access" };

...

[HttpGet]
public IEnumerable<ReturnType> Get()
{
    HttpContext.VerifyUserHasAnyAcceptedScope(scopeRequiredByApi);

    if (User.IsInRole("Admin") || User.IsInRole("Developer"))
    {
        ...
    }
    else
    {
        ...
    }

    return ...
}

Vereis dat de gebruiker in zowel de -rol als de-rol is met procedurele code door de voorwaardelijke OF () te wijzigen in een voorwaardelijke EN () in het voorgaande voorbeeld.
```
if (User.IsInRole("Admin") && User.IsInRole("Developer"))
```

Omdat .NET-tekenreeksvergelijkingen hoofdlettergevoelig zijn, zijn overeenkomende rolnamen ook hoofdlettergevoelig. Admin (hoofdletter A) wordt bijvoorbeeld niet beschouwd als dezelfde rol als admin (kleine letter a).

Pascal-case wordt meestal gebruikt voor rolnamen (bijvoorbeeld BillingAdministrator), maar het gebruik van Pascal-case is geen strikte vereiste. Verschillende opmaakstijlen, zoals camelCase, kebab-case, en snake_case, zijn toegestaan. Het gebruik van spaties in rolnamen is ook ongebruikelijk, maar toegestaan. billing administrator is bijvoorbeeld een ongebruikelijke indeling voor rolnamen in .NET-apps, maar geldig.

Delen via

Microsoft Entra (ME-ID) groepen, beheerdersrollen en app-rollen (.NET 5 tot .NET 7)

Voorwaarde

Scopes

Attribuut groepslidmaatschapsclaims

Aangepast gebruikersaccount

Autorisatieconfiguratie

Toegang tot server-API/web-API autoriseren

App-rollen

Aanvullende informatiebronnen

Aanvullende resources