Grupy Microsoft Entra (ME-ID), role administratora i role aplikacji

Artykuł
11/12/2024

Uwaga

Nie jest to najnowsza wersja tego artykułu. Aby zapoznać się z bieżącą wersją, zobacz wersję tego artykułu platformy .NET 9.

Ważne

Te informacje odnoszą się do produktu w wersji wstępnej, który może zostać znacząco zmodyfikowany, zanim zostanie wydany komercyjnie. Firma Microsoft nie udziela żadnych gwarancji, jawnych lub domniemanych, w odniesieniu do informacji podanych w tym miejscu.

Aby zapoznać się z bieżącą wersją, zobacz wersję tego artykułu platformy .NET 9.

W tym artykule wyjaśniono, jak skonfigurować używanie Blazor WebAssembly grup i ról microsoft Entra ID (ME-ID).

Me-ID udostępnia kilka metod autoryzacji, które można połączyć z ASP.NET Core Identity:

Grupy
- Zabezpieczenia
- Microsoft 365
- Dystrybucja
Ról
- Wbudowane role administratora me-ID
- Role aplikacji

Wskazówki przedstawione w tym artykule dotyczą Blazor WebAssembly scenariuszy wdrażania identyfikatora ME opisanych w następujących artykułach:

Przykłady w tym artykule korzystają z nowych funkcji platformy .NET/C#. W przypadku używania przykładów z platformą .NET 7 lub starszym wymagane są drobne modyfikacje. Jednak przykłady tekstu i kodu dotyczące interakcji z identyfikatorem ME-ID i programem Microsoft Graph są takie same dla wszystkich wersji platformy ASP.NET Core.

Przykładowa aplikacja

Uzyskaj dostęp do przykładowej aplikacji o nazwie BlazorWebAssemblyEntraGroupsAndRoles, za pośrednictwem najnowszego folderu wersji z katalogu głównego repozytorium przy użyciu następującego linku. Przykład jest udostępniany dla platformy .NET 8 lub nowszej. Zobacz plik przykładowej README aplikacji, aby uzyskać instrukcje dotyczące sposobu uruchamiania aplikacji.

Przykładowa aplikacja zawiera UserClaims składnik do wyświetlania oświadczeń użytkownika. Składnik UserData wyświetla podstawowe właściwości konta użytkownika.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Warunek wstępny

Wskazówki zawarte w tym artykule implementują interfejs API programu Microsoft Graph zgodnie ze wskazówkami dotyczącymi zestawu Graph SDK w temacie Używanie interfejsu API programu Graph z ASP.NET Core Blazor WebAssembly. Postępuj zgodnie ze wskazówkami dotyczącymi implementacji zestawu Graph SDK , aby skonfigurować aplikację i przetestować ją, aby potwierdzić, że aplikacja może uzyskać dane interfejsu API programu Graph dla konta użytkownika testowego. Ponadto zapoznaj się z artykułem dotyczącym zabezpieczeń interfejsu API programu Graph, aby zapoznać się z pojęciami dotyczącymi zabezpieczeń programu Microsoft Graph.

Podczas testowania za pomocą zestawu Graph SDK lokalnie zalecamy użycie nowej sesji przeglądarki w trybie prywatnym/incognito dla każdego testu, aby zapobiec zakłócaniu testów przez utrzymujące się pliki cookie. Aby uzyskać więcej informacji, zobacz Secure an ASP.NET Core standalone app with Microsoft Entra ID (Zabezpieczanie autonomicznej aplikacji ASP.NET Core Blazor WebAssembly przy użyciu identyfikatora Entra firmy Microsoft).

Narzędzia do rejestracji aplikacji ME-ID w trybie online

W tym artykule opisano witrynę Azure Portal podczas monitowania o skonfigurowanie rejestracji aplikacji ME-ID aplikacji, ale centrum administracyjne firmy Microsoft Entra jest również opłacalną opcją zarządzania rejestracjami aplikacji ME-ID. Można użyć dowolnego interfejsu, ale wskazówki zawarte w tym artykule obejmują gesty dla witryny Azure Portal.

Zakresy

Uprawnienia i zakresy oznaczają to samo i są używane zamiennie w dokumentacji zabezpieczeń i witrynie Azure Portal. Jeśli tekst nie odwołuje się do witryny Azure Portal, ten artykuł używa /zakresów podczas odwoływania się do uprawnień programu Graph.

Zakresy są niewrażliwe na wielkość liter, więc User.Read jest taka sama jak user.read. Możesz użyć dowolnego formatu, ale zalecamy spójny wybór w kodzie aplikacji.

Aby zezwolić na wywołania interfejsu API programu Microsoft Graph dla danych profilu użytkownika, przypisania roli i członkostwa w grupie, aplikacja jest skonfigurowana z User.Read delegowanym zakresem (https://graph.microsoft.com/User.Read) w witrynie Azure Portal, ponieważ dostęp do odczytu danych użytkownika jest określany przez zakresy przyznane (delegowane) poszczególnym użytkownikom. Ten zakres jest wymagany oprócz zakresów wymaganych w scenariuszach wdrażania identyfikatora ME opisanych wcześniej w artykułach (autonomiczna z kontami Microsoft lub autonomiczna z identyfikatorem ME).

Dodatkowe wymagane zakresy obejmują:

Zakres delegowany RoleManagement.Read.Directory (https://graph.microsoft.com/RoleManagement.Read.Directory): umożliwia aplikacji odczytywanie ustawień kontroli dostępu opartej na rolach (RBAC) dla katalogu firmy w imieniu zalogowanego użytkownika. Obejmuje to odczytywanie szablonów ról katalogu, ról katalogu i członkostwa. Członkostwa w rolach katalogu są używane do tworzenia directoryRole oświadczeń w aplikacji dla wbudowanych ról administratora ME-ID. Wymagana jest zgoda administratora.
Zakres delegowany AdministrativeUnit.Read.All (https://graph.microsoft.com/AdministrativeUnit.Read.All): umożliwia aplikacji odczytywanie jednostek administracyjnych i członkostwa jednostek administracyjnych w imieniu zalogowanego użytkownika. Te członkostwa są używane do tworzenia administrativeUnit oświadczeń w aplikacji. Wymagana jest zgoda administratora.

Aby uzyskać więcej informacji, zobacz Omówienie uprawnień i zgody na platformie Microsoft identity oraz Omówienie uprawnień programu Microsoft Graph.

Niestandardowe konto użytkownika

Przypisz użytkowników do grup zabezpieczeń ME-ID i ról administratora ME-ID w witrynie Azure Portal.

Przykłady w tym artykule:

Załóżmy, że użytkownik ma przypisaną rolę administratora rozliczeń ME-ID w dzierżawie ME-ID witryny Azure Portal w celu uzyskania autoryzacji w celu uzyskania dostępu do danych interfejsu API serwera.
Użyj zasad autoryzacji, aby kontrolować dostęp w aplikacji.

Rozszerz, RemoteUserAccount aby uwzględnić właściwości dla:

Roles: Tablica ról aplikacji ME-ID (opisana w sekcji Role aplikacji)
Oid: Niezmienne oświadczenie identyfikatora obiektu () (oidunikatowo identyfikuje użytkownika w ramach dzierżaw i między dzierżawami)

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

Dodaj odwołanie do pakietu do aplikacji dla elementu Microsoft.Graph.

Uwaga

Aby uzyskać instrukcje dodawania pakietów do aplikacji .NET, zobacz artykuły w sekcji Instalowanie pakietów i zarządzanie nimi w temacie Przepływ pracy użycia pakietów (dokumentacja programu NuGet). Sprawdź prawidłowe wersje pakietów pod adresem NuGet.org.

Dodaj klasy narzędzi zestawu Graph SDK i konfigurację w wskazówki dotyczące zestawu Graph SDK artykułu Use Graph API with ASP.NET Core (Korzystanie z interfejsu API programu Graph z platformą ASP.NET Core Blazor WebAssembly ). User.ReadOkreśl zakresy , RoleManagement.Read.Directoryi AdministrativeUnit.Read.All dla tokenu dostępu, jak pokazano w przykładowym wwwroot/appsettings.json pliku artykułu.

Dodaj następującą niestandardową fabrykę kont użytkowników do aplikacji. Niestandardowa fabryka użytkowników służy do ustanawiania:

Oświadczenia roli aplikacji () (roleopisane w sekcji Role aplikacji).
Przykładowe oświadczenia dotyczące danych profilu użytkownika dla numeru telefonu komórkowego użytkownika (mobilePhone) i lokalizacji biura (officeLocation).
Oświadczenia roli administratora ME-ID (directoryRole).
Oświadczenia jednostki administracyjnej ME-ID (administrativeUnit).
Oświadczenia grupy ME-ID (directoryGroup).
logger(ILogger) dla wygody, jeśli chcesz rejestrować informacje lub błędy.

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

Powyższy kod ma następujące działanie:

Nie obejmuje przejściowych członkostw. Jeśli aplikacja wymaga bezpośrednich i przechodnich oświadczeń członkostwa w grupie, zastąp MemberOf właściwość () wartością TransitiveMemberOf (IUserMemberOfCollectionWithReferencesRequestBuilderIUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).
Ustawia wartości identyfikatorów GUID w directoryRole oświadczeniach to identyfikatory szablonów ról administratora me-ID (Microsoft.Graph.Models.DirectoryRole.RoleTemplateId). Identyfikatory szablonów są stabilnymi identyfikatorami tworzenia zasad autoryzacji użytkownika w aplikacjach, które zostały omówione w dalszej części tego artykułu. Nie używaj entry.Id wartości oświadczeń roli katalogu, ponieważ nie są one stabilne w dzierżawach.

Następnie skonfiguruj uwierzytelnianie MSAL tak, aby używało niestandardowej fabryki kont użytkowników.

Upewnij się, że Program plik używa Microsoft.AspNetCore.Components.WebAssembly.Authentication przestrzeni nazw:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Zaktualizuj wywołanie AddMsalAuthentication do następującego. Należy pamiętać, że Blazor struktura RemoteUserAccount jest zastępowana przez aplikacje CustomUserAccount dla uwierzytelniania MSAL i głównej fabryki oświadczeń kont:

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

Potwierdź obecność kodu zestawu Graph SDK w Program pliku opisanym w artykule Use Graph API with ASP.NET Core (Korzystanie z interfejsu API programu Graph z platformą 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);

Ważne

Upewnij się, że w rejestracji aplikacji w witrynie Azure Portal udzielono następujących uprawnień:

User.Read
RoleManagement.Read.Directory (Wymaga zgody administratora)
AdministrativeUnit.Read.All (Wymaga zgody administratora)

Upewnij się, że wwwroot/appsettings.json konfiguracja jest poprawna zgodnie ze wskazówkami dotyczącymi zestawu Graph SDK .

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

Podaj wartości następujących symboli zastępczych z rejestracji me-id aplikacji w witrynie Azure Portal:

{TENANT ID}: wartość identyfikatora GUID identyfikatora katalogu (dzierżawy).
{CLIENT ID}: wartość identyfikatora GUID identyfikatora aplikacji (klienta).

Konfiguracja autoryzacji

Utwórz zasady dla każdej roli aplikacji (według nazwy roli), wbudowanej roli administratora ME-ID (według identyfikatora szablonu roli/identyfikatora GUID) lub grupy zabezpieczeń (według identyfikatora obiektu/identyfikatora GUID) w Program pliku. W poniższym przykładzie utworzono zasady dla wbudowanej roli Administratora rozliczeń me-ID:

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

Aby uzyskać pełną listę identyfikatorów (GUID) dla ról administratora identyfikatorów ME-ID, zobacz Identyfikatory szablonów ról w dokumentacji identyfikatora ME-ID. Aby uzyskać informacje o zabezpieczeniach platformy Azure lub identyfikatorze grupy usługi O365 (GUID), zobacz identyfikator obiektu dla grupy w okienku Grupy witryny Azure Portal rejestracji aplikacji. Aby uzyskać więcej informacji na temat zasad autoryzacji, zobacz Autoryzacja oparta na zasadach w programie ASP.NET Core.

W poniższych przykładach aplikacja używa powyższych zasad do autoryzowania użytkownika.

Składnik AuthorizeView działa z zasadami:

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

Dostęp do całego składnika może być oparty na zasadach przy użyciu [Authorize] dyrektywy atrybutu (AuthorizeAttribute):

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

Jeśli użytkownik nie jest autoryzowany, nastąpi przekierowanie do strony logowania ME-ID.

Sprawdzanie zasad można również wykonać w kodzie za pomocą logiki proceduralnej.

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.";
        }
    }
}

Korzystając z powyższych metod, można również utworzyć dostęp oparty na zasadach dla grup zabezpieczeń, gdzie identyfikator GUID używany dla zasad jest zgodny z

Role aplikacji

Aby skonfigurować aplikację w witrynie Azure Portal w celu zapewnienia oświadczeń członkostwa w rolach aplikacji, zobacz Dodawanie ról aplikacji do aplikacji i odbieranie ich w tokenie w dokumentacji me-ID.

W poniższym przykładzie przyjęto założenie, że aplikacja jest skonfigurowana z dwiema rolami, a role są przypisywane do użytkownika testowego:

Admin
Developer

Chociaż nie można przypisywać ról do grup bez konta premium ME-ID, możesz przypisać role do użytkowników i odbierać oświadczenia ról dla użytkowników przy użyciu standardowego konta platformy Azure. Wskazówki w tej sekcji nie wymagają konta Premium z identyfikatorem ME.ID.

Wykonaj jedną z następujących metod dodawania ról aplikacji w identyfikatorze ME-ID:

Podczas pracy z katalogiem domyślnym postępuj zgodnie ze wskazówkami w temacie Dodawanie ról aplikacji do aplikacji i odbieranie ich w tokenie w celu utworzenia ról ME-ID.
Jeśli nie pracujesz z katalogiem domyślnym, zmodyfikuj manifest aplikacji w witrynie Azure Portal, aby ręcznie ustanowić role aplikacji we appRoles wpisie pliku manifestu. Poniżej znajduje się przykładowy appRoles wpis, który tworzy Admin role i Developer . Te przykładowe role są używane później na poziomie składnika w celu zaimplementowania ograniczeń dostępu:

Ważne

Poniższe podejście jest zalecane tylko w przypadku aplikacji, które nie są zarejestrowane w katalogu domyślnym konta platformy Azure. W przypadku aplikacji zarejestrowanych w katalogu domyślnym zobacz poprzedni punktor tej listy.
```
"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"
  }
],
```
{ADMIN GUID} W przypadku symboli zastępczych i {DEVELOPER GUID} w poprzednim przykładzie można wygenerować identyfikatory GUID za pomocą generatora identyfikatora GUID online (wynik wyszukiwania Google dla "generatora identyfikatora GUID").

Aby przypisać rolę do użytkownika (lub grupy, jeśli masz konto platformy Azure w warstwie Premium):

Przejdź do pozycji Aplikacje dla przedsiębiorstw w obszarze ME-ID witryny Azure Portal.
Wybierz aplikację. Wybierz pozycję Zarządzaj użytkownikami i grupami> na pasku bocznym.
Zaznacz pole wyboru dla co najmniej jednego konta użytkownika.
Z menu powyżej listy użytkowników wybierz pozycję Edytuj przypisanie.
W polu Wybierz wpis roli wybierz pozycję Brak.
Wybierz rolę z listy i wybierz ją za pomocą przycisku Wybierz .
Użyj przycisku Przypisz w dolnej części ekranu, aby przypisać rolę.

Wiele ról jest przypisywanych w witrynie Azure Portal przez ponowne dodanie użytkownika dla każdego dodatkowego przypisania roli. Użyj przycisku Dodaj użytkownika/grupę w górnej części listy użytkowników, aby ponownie dodać użytkownika. Użyj powyższych kroków, aby przypisać inną rolę użytkownikowi. Ten proces można powtórzyć wielokrotnie, aby dodać dodatkowe role do użytkownika (lub grupy).

Pokazana CustomAccountFactory w sekcji Niestandardowe konto użytkownika jest skonfigurowana do działania względem role oświadczenia z wartością tablicy JSON. Dodaj i zarejestruj element CustomAccountFactory w aplikacji, jak pokazano w sekcji Niestandardowe konto użytkownika. Nie ma potrzeby podawania kodu w celu usunięcia oryginalnego role oświadczenia, ponieważ jest on automatycznie usuwany przez strukturę.

Program W pliku dodaj lub potwierdź oświadczenie o nazwie "role" jako oświadczenie roli do ClaimsPrincipal.IsInRole sprawdzania:

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

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

Uwaga

Jeśli wolisz użyć directoryRoles oświadczenia (role administratora ME-ID), przypisz "directoryRoles" do .RemoteAuthenticationUserOptions.RoleClaim

Po wykonaniu powyższych kroków tworzenia i przypisywania ról do użytkowników (lub grup, jeśli masz konto platformy Azure w warstwie Premium) i zaimplementowano go CustomAccountFactory przy użyciu zestawu Graph SDK, zgodnie z opisem we wcześniejszej części tego artykułu i w temacie Używanie interfejsu API programu Graph z platformą ASP.NET Core Blazor WebAssemblypowinno zostać wyświetlone role oświadczenie dla każdej przypisanej roli przypisanej przez zalogowanego użytkownika (lub ról przypisanych do grup, do których należą). Uruchom aplikację z użytkownikiem testowym, aby potwierdzić, że oświadczenia są obecne zgodnie z oczekiwaniami. Podczas testowania za pomocą zestawu Graph SDK lokalnie zalecamy użycie nowej sesji przeglądarki w trybie prywatnym/incognito dla każdego testu, aby zapobiec zakłócaniu testów przez utrzymujące się pliki cookie. Aby uzyskać więcej informacji, zobacz Secure an ASP.NET Core standalone app with Microsoft Entra ID (Zabezpieczanie autonomicznej aplikacji ASP.NET Core Blazor WebAssembly przy użyciu identyfikatora Entra firmy Microsoft).

Metody autoryzacji składników działają w tym momencie. Dowolny z mechanizmów autoryzacji w składnikach aplikacji może używać Admin roli do autoryzowania użytkownika:

AuthorizeView składnik
```
<AuthorizeView Roles="Admin">
```
[Authorize] attribute, dyrektywa (AuthorizeAttribute)
```
@attribute [Authorize(Roles = "Admin")]
```

Logika proceduralna

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

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

Obsługiwane są wiele testów ról:

Wymagaj, aby użytkownik był w Admin roli lub Developer ze składnikiem:AuthorizeView
```
<AuthorizeView Roles="Admin, Developer">
    ...
</AuthorizeView>
```
Wymagaj, aby użytkownik był zarówno w rolach, jak Admin i Developer ze składnikiemAuthorizeView:
```
<AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>
```
Aby uzyskać więcej informacji na Context temat wewnętrznego elementu AuthorizeView, zobacz ASP.NET Core authentication and authorization (Uwierzytelnianie i autoryzacja w systemie ASP.NET CoreBlazor).
Wymagaj, aby użytkownik był w Admin roli lub Developer z atrybutem :[Authorize]
```
@attribute [Authorize(Roles = "Admin, Developer")]
```

Wymagaj, aby użytkownik był w rolach Admin i Developer z atrybutem :[Authorize]

@attribute [Authorize(Roles = "Admin")]
@attribute [Authorize(Roles = "Developer")]

Wymagaj, aby użytkownik był w Admin roli lub Developer z kodem proceduralnym:

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

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

Wymagaj, aby użytkownik był zarówno w rolach, jak Admin i Developer z kodem proceduralnym, zmieniając warunkowy or (||) na warunkowy AND (&&) w poprzednim przykładzie:
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
```

Obsługiwane są wiele testów ról:

Wymagaj, aby użytkownik był w Admin roli lub Developer z atrybutem :[Authorize]
```
[Authorize(Roles = "Admin, Developer")]
```
Wymagaj, aby użytkownik był w rolach Admin i Developer z atrybutem :[Authorize]
```
[Authorize(Roles = "Admin")]
[Authorize(Roles = "Developer")]
```

Wymagaj, aby użytkownik był w Admin roli lub Developer z kodem proceduralnym:

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 ...
}

Wymagaj, aby użytkownik był zarówno w rolach, jak Admin i Developer z kodem proceduralnym, zmieniając warunkowy or (||) na warunkowy AND (&&) w poprzednim przykładzie:
```
if (User.IsInRole("Admin") && User.IsInRole("Developer"))
```

Ponieważ w porównaniach ciągów platformy .NET uwzględniana jest wielkość liter, dopasowywanie nazw ról również uwzględnia wielkość liter. Na przykład Admin (wielkie litery A) nie jest traktowana jako ta sama rola co admin (małe litery a).

Przypadek Pascal jest zwykle używany dla nazw ról (na przykład BillingAdministrator), ale użycie przypadku Pascal nie jest ścisłym wymaganiem. Różne schematy wielkości liter, takie jak przypadek wielbłąda, przypadek kebab i przypadek węża, są dozwolone. Używanie spacji w nazwach ról jest również nietypowe, ale dozwolone. Na przykład jest to nietypowy format nazwy roli w aplikacjach .NET, billing administrator ale prawidłowy.

Udostępnij za pośrednictwem

Grupy Microsoft Entra (ME-ID), role administratora i role aplikacji

Przykładowa aplikacja

Warunek wstępny

Narzędzia do rejestracji aplikacji ME-ID w trybie online

Zakresy

Niestandardowe konto użytkownika

Konfiguracja autoryzacji

Role aplikacji

Dodatkowe zasoby

Dodatkowe zasoby