Microsoft Entra (ME-ID) groepen, beheerdersrollen en app-rollen

Artikel
01/23/2025

Notitie

Dit is niet de nieuwste versie van dit artikel. Zie de .NET 9-versie van dit artikelvoor de huidige release.

Belangrijk

Deze informatie heeft betrekking op een pre-releaseproduct dat aanzienlijk kan worden gewijzigd voordat het commercieel wordt uitgebracht. Microsoft geeft geen garanties, uitdrukkelijk of impliciet, met betrekking tot de informatie die hier wordt verstrekt.

Zie de .NET 9-versie van dit artikelvoor de huidige release.

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

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

Groepen
- Veiligheid
- Microsoft 365
- Distributie
Rollen
- ingebouwde beheerdersrollen ME-ID
- 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:

zelfstandig met Microsoft-accounts
zelfstandig met ME-ID

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.

Voorbeeld-app

Open de voorbeeld-app met de naam BlazorWebAssemblyEntraGroupsAndRolesvia de meest recente versiemap uit de hoofdmap van de opslagplaats met de volgende koppeling. Het voorbeeld is beschikbaar voor .NET 8 of hoger. Zie het README-bestand van de voorbeeld-app voor stappen voor het uitvoeren van de app.

De voorbeeld-app bevat een UserClaims onderdeel voor het weergeven van claims van een gebruiker. In het UserData-onderdeel worden de basisaccounteigenschappen van de gebruiker weergegeven.

voorbeeldcode weergeven of downloaden (hoe te downloaden)

Voorwaarde

De richtlijnen in dit artikel implementeren de Microsoft Graph API volgens de Graph SDK richtlijnen in Graph API gebruiken 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. Zie ook het beveiligingsartikel van het Graph API-artikel over koppelingen om 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.

onlinehulpprogramma's voor app-registratie ME-ID

Dit artikel verwijst naar de Azure Portal wanneer u wordt gevraagd om de ME-ID app-registratie van de app te configureren, maar het Microsoft Entra-beheercentrum is ook een haalbare optie voor het beheren van ME-ID app-registraties. Beide interfaces kunnen worden gebruikt, maar de richtlijnen in dit artikel hebben specifiek betrekking op bewegingen voor Azure Portal.

Scopes

Machtigingen en toepassingsbereiken 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 wanneer er wordt verwezen naar 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.

Om Microsoft Graph API aanroepen voor gebruikersprofiel-, roltoewijzings- en groepslidmaatschapsgegevens toe te staan, wordt de app met het gedelegeerdeUser.Read bereik (https://graph.microsoft.com/User.Read) in de Azure-portal geconfigureerd, omdat de toegang tot het lezen van gebruikersgegevens wordt bepaald door het bereik(en) dat aan afzonderlijke gebruikers is verleend (gedelegeerd). Dit scope is vereist naast de scopes die vereist zijn in de ME-ID implementatiescenario's die in de eerder genoemde artikelen worden beschreven (Standalone met Microsoft Accounts of Standalone met ME-ID).

Aanvullende vereiste toepassingsgebieden zijn:

GedelegeerdRoleManagement.Read.Directory bereik (https://graph.microsoft.com/RoleManagement.Read.Directory): hiermee kan de app de RBAC-instellingen (op rollen gebaseerd toegangsbeheer) voor de adreslijst van uw bedrijf lezen namens de aangemelde gebruiker. Dit omvat het lezen van sjablonen voor directoryrollen, directoryrollen en lidmaatschappen. Directory-rollidmaatschappen worden gebruikt voor het maken van directoryRole claims in de app voor ME-ID ingebouwde beheerdersrollen. Beheerderstoestemming is vereist.
GedelegeerdAdministrativeUnit.Read.All bereik (https://graph.microsoft.com/AdministrativeUnit.Read.All): Hiermee kan de app beheereenheden en lidmaatschap van beheereenheden lezen namens de aangemelde gebruiker. Deze lidmaatschappen worden gebruikt om administrativeUnit claims in de app te maken. Beheerderstoestemming is vereist.

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

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 app te beheren.

Breid RemoteUserAccount uit om eigenschappen op te nemen voor:

Roles: matrix ME-ID App-rollen (behandeld in de sectie App-rollen)
Oid: Onveranderbare claim voor objectidentificatie (oid) (identificeert een gebruiker uniek binnen en tussen tenants)

CustomUserAccount.cs:

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

namespace BlazorWebAssemblyEntraGroupsAndRoles;

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

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

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

Notitie

Zie de artikelen onder Pakketten installeren en beheren bij Package consumption workflow in de NuGet-documentatievoor richtlijnen over 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 van het artikel Gebruik de Graph API met ASP.NET Core Blazor WebAssembly. Geef de User.Read-, RoleManagement.Read.Directory- en AdministrativeUnit.Read.All-bereiken voor het toegangstoken op, zoals in het artikel met het voorbeeldbestand wwwroot/appsettings.json wordt weergegeven.

Voeg de volgende aangepaste gebruikersaccountfabriek toe aan de app. De aangepaste gebruikersfabriek wordt gebruikt om het volgende te creëren:

App-rolclaims (role) (behandeld in de sectie App-rollen).
Voorbeeld van gebruikersprofielgegevensclaims voor het mobiele telefoonnummer van de gebruiker (mobilePhone) en kantoorlocatie (officeLocation).
ME-ID claims voor beheerdersrol (directoryRole).
ME-ID claims voor beheereenheden (administrativeUnit).
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 BlazorWebAssemblyEntraGroupsAndRoles;

public class CustomAccountFactory(IAccessTokenProviderAccessor accessor,
        IServiceProvider serviceProvider, ILogger<CustomAccountFactory> logger,
        IConfiguration config)
    : AccountClaimsPrincipalFactory<CustomUserAccount>(accessor)
{
    private readonly ILogger<CustomAccountFactory> logger = logger;
    private readonly IServiceProvider serviceProvider = serviceProvider;
    private readonly string? baseUrl = string.Join("/",
        config.GetSection("MicrosoftGraph")["BaseUrl"],
        config.GetSection("MicrosoftGraph")["Version"]);

    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.Oid is not null)
            {
                account?.Roles?.ForEach((role) =>
                {
                    userIdentity.AddClaim(new Claim("role", role));
                });

                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 memberOf = client.Users[account?.Oid].MemberOf;

                    var graphDirectoryRoles = await memberOf.GraphDirectoryRole.GetAsync();

                    if (graphDirectoryRoles?.Value is not null)
                    {
                        foreach (var entry in graphDirectoryRoles.Value)
                        {
                            if (entry.RoleTemplateId is not null)
                            {
                                userIdentity.AddClaim(
                                    new Claim("directoryRole", entry.RoleTemplateId));
                            }
                        }
                    }

                    var graphAdministrativeUnits = await memberOf.GraphAdministrativeUnit.GetAsync();

                    if (graphAdministrativeUnits?.Value is not null)
                    {
                        foreach (var entry in graphAdministrativeUnits.Value)
                        {
                            if (entry.Id is not null)
                            {
                                userIdentity.AddClaim(
                                    new Claim("administrativeUnit", entry.Id));
                            }
                        }
                    }

                    var graphGroups = await memberOf.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;
    }
}

De voorgaande code:

Omvat geen transitieve lidmaatschappen. Als voor de app directe en transitieve groepslidmaatschapsclaims zijn vereist, vervangt u de eigenschap MemberOf (IUserMemberOfCollectionWithReferencesRequestBuilder) door TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).
Stelt GUID-waarden in directoryRole claims zijn ME-ID beheerdersrol sjabloon-id's (Microsoft.Graph.Models.DirectoryRole.RoleTemplateId). Sjabloon-id's zijn stabiele id's voor het maken van beleid voor gebruikersautorisatie in apps. Dit wordt verderop in dit artikel besproken. Gebruik geen entry.Id voor claimwaarden voor directoryrollen, omdat ze niet stabiel zijn in huurderaccounts.

Configureer vervolgens de MSAL-verificatie om de factory van het aangepaste gebruikersaccount te gebruiken.

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

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Werk de aanroep van AddMsalAuthentication als volgt 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);
        options.UserOptions.RoleClaim = "role";
    })
    .AddAccountClaimsPrincipalFactory<RemoteAuthenticationState, CustomUserAccount,
        CustomAccountFactory>();

Bevestig de aanwezigheid van de Graph SDK-code in het Program-bestand, zoals beschreven door het -artikel over het gebruik van Graph API met ASP.NET Core Blazor WebAssembly.

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);

Belangrijk

Bevestig in de registratie van de app in Azure Portal dat de volgende machtigingen zijn verleend:

User.Read
RoleManagement.Read.Directory (beheerderstoestemming vereist)
AdministrativeUnit.Read.All (beheerderstoestemming vereist)

Controleer of de wwwroot/appsettings.json-configuratie juist is volgens de Graph SDK richtlijnen.

wwwroot/appsettings.json:

{
  "AzureAd": {
    "Authority": "https://login.microsoftonline.com/{TENANT ID}",
    "ClientId": "{CLIENT ID}",
    "ValidateAuthority": true
  },
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com",
    "Version": "v1.0",
    "Scopes": [
      "User.Read",
      "RoleManagement.Read.Directory",
      "AdministrativeUnit.Read.All"
    ]
  }
}

Geef waarden op voor de volgende tijdelijke aanduidingen uit de ME-ID app-registratie in het Azure-portaal:

{TENANT ID}: De GUID-waarde van de Directory (Tenant) Id.
{CLIENT ID}: De GUID-waarde van de Applicatie-ID (Client).

Autorisatieconfiguratie

Maak een -beleid voor elke app-rol (op rolnaam), ME-ID ingebouwde beheerdersrol (op rolsjabloon-id/GUID) of beveiligingsgroep (op object-id/GUID) 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 ME-ID documentatie voor de volledige lijst met ID's (GUID's) voor ME-ID beheerdersrollen. Voor een Azure-beveiligings- of O365-groeps-id (GUID) raadpleegt u de Object-id voor de groep in Azure Portal deelvenster Groepen deelvenster van de registratie van de app. Zie Autorisatie op basis van beleid in ASP.NET Corevoor meer informatie over autorisatiebeleid.

In de volgende voorbeelden gebruikt de 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 beveiligingsgroepen, waarbij de GUID die voor het beleid wordt gebruikt, overeenkomt met de

App-rollen

Zie App-rollen toevoegen aan uw toepassing en deze ontvangen in het token in de documentatie van de ME-ID om de app te configureren in de Azure Portal voor het verstrekken van lidmaatschapsclaims van app-rollen.

In het volgende voorbeeld wordt ervan uitgegaan dat de app is geconfigureerd met twee rollen en dat de rollen zijn toegewezen aan een testgebruiker:

Admin
Developer

Hoewel u rollen niet kunt toewijzen aan groepen zonder een ME-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.

Voer een van de volgende methoden uit om app-rollen toe te voegen in ME-ID:

Wanneer u met de standaardmapwerkt, volgt u de richtlijnen in App-rollen toevoegen aan uw toepassing en ontvangt u deze in het token om ME-ID rollen te maken.
Als u niet werkt met de standaardmap, 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 later op onderdeelniveau gebruikt om toegangsbeperkingen te implementeren:

Belangrijk

De volgende methode wordt alleen aanbevolen voor apps die niet zijn geregistreerd in de standaardmap van het Azure-account. Zie de vorige punt in deze lijst voor apps die zijn geregistreerd in de standaarddirectory.
```
"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 boven de gebruikerslijst de optie Toewijzing bewerken.
Selecteer voor de Een rol item selecteren 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 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.

Voeg in het bestand Program de claim met de naamroletoe of bevestig deze als de rolclaim voor ClaimsPrincipal.IsInRole controles:

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

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

Notitie

Als u de directoryRoles claim (ME-ID administratorrollen) wilt gebruiken, wijst u hetdirectoryRolestoe aan de RemoteAuthenticationUserOptions.RoleClaim.

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 role 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 claims 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. Elk van de autorisatiemechanismen in onderdelen van de 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 zich in de AdminofDeveloper rol met het AuthorizeView-onderdeel:
```
<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.
Vereisen dat de gebruiker zich in de Admin- ofDeveloper rol met het kenmerk [Authorize]:
```
@attribute [Authorize(Roles = "Admin, Developer")]
```
Vereist dat de gebruiker zich bevindt in zowel de rollen AdminalsDeveloper met het kenmerk [Authorize].
```
@attribute [Authorize(Roles = "Admin")]
@attribute [Authorize(Roles = "Developer")]
```

Vereisen dat de gebruiker zich in bevindt de AdminofDeveloper 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"))
```

Er worden meerdere roltests ondersteund:

Vereisen dat de gebruiker zich in de Admin- ofDeveloper rol 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 ...
}

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"))
```

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

Pascal-case wordt meestal gebruikt voor rolnamen (bijvoorbeeld BillingAdministrator), maar het gebruik van Pascal-case is geen strikte vereiste. Verschillende notatiestijlen, 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

Voorbeeld-app

Voorwaarde

onlinehulpprogramma's voor app-registratie ME-ID

Scopes

Aangepast gebruikersaccount

Autorisatieconfiguratie

App-rollen

Aanvullende informatiebronnen

Aanvullende resources