Skupiny Microsoft Entra (ME-ID), role správce a role aplikací (.NET 5 až .NET 7)

Článek
11/12/2024

Poznámka:

Toto není nejnovější verze tohoto článku. Aktuální verzi ASP.NET Core najdete v nejnovější verzi ASP.NET Core Blazor WebAssembly se skupinami a rolemi ID Microsoft Entra.

Tento článek vysvětluje, jak nakonfigurovat Blazor WebAssembly používání skupin a rolí ID Microsoft Entra.

Microsoft Entra (ME-ID) poskytuje několik přístupů autorizace, které lze kombinovat s ASP.NET Core Identity:

Skupiny
- Zabezpečení
- Microsoft 365
- Distribuce
Role
- Role správce ME-ID
- Aplikační role

Pokyny v tomto článku se týkají Blazor WebAssembly scénářů nasazení ME-ID popsaných v následujících článcích:

Pokyny k článku obsahují pokyny pro klientské a serverové aplikace:

KLIENT: Samostatné Blazor WebAssembly aplikace nebo Client aplikace hostovaného Blazorřešení.
SERVER: ASP.NET základní serverové rozhraní API/ webové aplikace API nebo Server aplikace hostovaného Blazor řešení. Pokyny k SERVERU můžete ignorovat v celém článku pro samostatnou Blazor WebAssembly aplikaci.

Příklady v tomto článku využívají nové funkce .NET/C#. Při použití příkladů s .NET 7 nebo staršími jsou vyžadovány menší úpravy. Příklady textu a kódu, které se týkají interakce s ME-ID a Microsoft Graphem, jsou ale stejné pro všechny verze ASP.NET Core.

Požadavek

Pokyny v tomto článku implementují rozhraní Microsoft Graph API podle pokynů sady Graph SDK při použití rozhraní Graph API s ASP.NET Core Blazor WebAssembly. Podle pokynů k implementaci sady Graph SDK nakonfigurujte aplikaci a otestujte ji a ověřte, že aplikace může získat data rozhraní Graph API pro testovací uživatelský účet. Další informace najdete v článku o zabezpečení v článku o rozhraní Graph API, kde najdete křížové odkazy na koncepty zabezpečení Microsoft Graphu.

Při místním testování pomocí sady Graph SDK doporučujeme pro každý test použít novou relaci prohlížeče v privátním nebo anonymním režimu, aby se zabránilo zasahování souborů cookie do souborů cookie. Další informace najdete v tématu Zabezpečení samostatné aplikace ASP.NET Core Blazor WebAssembly pomocí Microsoft Entra ID.

Rozsahy

Povolení volání rozhraní Microsoft Graph API pro profil uživatele, přiřazení rolí a data členství ve skupinách:

Klientská aplikace je nakonfigurovaná s delegovaným User.Read oborem (https://graph.microsoft.com/User.Read) na webu Azure Portal, protože přístup ke čtení uživatelských dat je určen obory udělenými (delegovaným) jednotlivým uživatelům.
Aplikace SERVERU je nakonfigurovaná s oborem aplikace GroupMember.Read.All (https://graph.microsoft.com/GroupMember.Read.All) na webu Azure Portal, protože přístup je určený k získání informací o členství ve skupině, nikoli na základě autorizace jednotlivých uživatelů pro přístup k datům o členech skupiny.

Předchozí obory se vyžadují kromě oborů požadovaných ve scénářích nasazení ME-ID popsaných výše uvedenými články (samostatná služba s účty Microsoft, samostatná s ME-ID a hostovaná pomocí ME-ID).

Další informace najdete v tématu Přehled oprávnění a souhlasu na platformě Microsoftu identity a přehled oprávnění Microsoft Graphu.

Oprávnění a obory znamenají totéž a používají se zaměnitelně v dokumentaci k zabezpečení a na webu Azure Portal. Pokud text odkazuje na web Azure Portal, tento článek při odkazech na oprávnění Graphu používá obory oborů/.

Obory nerozlišují malá a velká písmena, takže User.Read jsou stejné jako user.read. Nebojte se použít některý z formátů, ale doporučujeme konzistentní volbu napříč kódem aplikace.

Atribut deklarací členství ve skupinách

V manifestu aplikace na webu Azure Portal pro aplikace CLIENT a SERVER nastavte atribut nagroupMembershipClaims DirectoryRole. Hodnota DirectoryRole výsledků v id ME, které odesílá všechny role přihlášeného uživatele ve známé deklaraci ID (wids):

Otevřete registraci webu Azure Portal aplikace.
Na bočním panelu vyberte Spravovat>manifest.
Vyhledejte groupMembershipClaims atribut.
Nastavte hodnotu na DirectoryRole ("groupMembershipClaims": "DirectoryRole").
Pokud jste provedli změny, vyberte tlačítko Uložit.

V manifestu aplikace na webu Azure Portal pro aplikace CLIENT a SERVER nastavte atribut nagroupMembershipClaims All. Hodnota All výsledků v odesílání všech skupin zabezpečení, distribučních skupin a rolí přihlášeného uživatele do deklarace identity známých ID (wids):

Otevřete registraci webu Azure Portal aplikace.
Na bočním panelu vyberte Spravovat>manifest.
Vyhledejte groupMembershipClaims atribut.
Nastavte hodnotu na All ("groupMembershipClaims": "All").
Pokud jste provedli změny, vyberte tlačítko Uložit.

Vlastní uživatelský účet

Přiřaďte uživatele ke skupinám zabezpečení ME-ID a rolím správce ME-ID na webu Azure Portal.

Příklady v tomto článku:

Předpokládejme, že je uživatel přiřazen k roli správce fakturace ME-ID na webu Azure Portal pro autorizaci pro přístup k datům rozhraní API serveru.
Pomocí zásad autorizace můžete řídit přístup v aplikacích CLIENT a SERVER .

V aplikaci CLIENT rozšiřte RemoteUserAccount vlastnosti pro:

Roles: Pole role aplikací ME-ID (probírané v části Role aplikací)
Wids: Role správce ME-ID ve známých deklarací identity ID (wids)
Oid: Deklarace identity identifikátoru neměnného objektu () (oidjedinečně identifikuje uživatele v rámci tenantů a napříč tenanty)

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

Přidejte odkaz na balíček do aplikace CLIENT pro Microsoft.Graph.

Poznámka:

Pokyny k přidávání balíčků do aplikací .NET najdete v článcích v části Instalace a správa balíčků na webu Pracovní postup používání balíčků (dokumentace k NuGetu). Ověřte správné verze balíčků na NuGet.org.

Přidejte třídy a konfiguraci sady Graph SDK v pokynech sady Graph SDK k rozhraní Graph API s článkem ASP.NET CoreBlazor WebAssembly. User.Read Zadejte obor přístupového tokenu, jak ukazuje článek v ukázkovém wwwroot/appsettings.json souboru.

Do aplikace CLIENT přidejte následující objekt pro vytváření vlastních uživatelských účtů. Vlastní uživatelská továrna se používá k vytvoření:

Deklarace identity rolí aplikací () (appRoleprobírané v části Role aplikací)
Deklarace identity role správce ME-ID (directoryRole).
Příklad deklarací identity dat profilu uživatele pro mobilní telefonní číslo (mobilePhone) a umístění kanceláře (officeLocation).
Deklarace identity skupiny ME-ID (directoryGroup).
(ILoggerlogger) pro usnadnění v případě, že chcete protokolovat informace nebo chyby.

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

Předchozí kód neobsahuje tranzitivní členství. Pokud aplikace vyžaduje přímé a přechodné deklarace členství ve skupinách, nahraďte MemberOf vlastnost (IUserMemberOfCollectionWithReferencesRequestBuilder) (TransitiveMemberOfIUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).

Předchozí kód ignoruje deklarace členství ve skupinách (groups), které jsou role správcem ME-ID (#microsoft.graph.directoryRoletyp), protože hodnoty GUID vrácené ID ROLE SPRÁVCE jsou ID entity role správce a ne ID šablon rolí. ID entit nejsou stabilní napříč tenanty a neměli byste je používat k vytváření zásad autorizace pro uživatele v aplikacích. Id šablon vždy používejte pro role správce ME-ID poskytované deklaracemi wids identity.

Deklarace wids identity (a tím i directoryRole deklarace identity) s hodnotou b79fbf4d-3ef9-4689-8143-76b194e85509 existuje pro účty mimo hosta tenanta. Neodkazuje na ID šablony role správce ME-ID.

V aplikaci CLIENT nakonfigurujte ověřování MSAL tak, aby používalo vlastní objekt pro vytváření uživatelských účtů.

Ověřte, že Program soubor používá Microsoft.AspNetCore.Components.WebAssembly.Authentication obor názvů:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Aktualizujte AddMsalAuthentication volání následujícím kódem. Všimněte si, že Blazor architektura RemoteUserAccount je nahrazena aplikací CustomUserAccount pro ověřování MSAL a objekt pro vytváření deklarací identity účtů:

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

Ověřte přítomnost kódu sady Graph SDK popsaného rozhraním Graph API s článkem ASP.NET Core Blazor WebAssembly a ověřte správnost wwwroot/appsettings.json konfigurace podle pokynů sady Graph SDK :

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

Konfigurace autorizace

V aplikaci CLIENT vytvořte zásadu pro každou roli aplikace, roli správce ME-ID nebo skupinu zabezpečení v Program souboru. Následující příklad vytvoří zásadu pro předdefinované role správce fakturace ME-ID:

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

Úplný seznam ID pro role správce ME-ID najdete v dokumentaci k šablonám rolí. Další informace o zásadách autorizace najdete v tématu Autorizace na základě zásad v ASP.NET Core.

V následujících příkladech aplikace CLIENT používá předchozí zásady k autorizaci uživatele.

Komponenta AuthorizeView funguje se zásadami:

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

Přístup k celé komponentě může být založený na zásadě pomocí direktivy atributu[Authorize] (AuthorizeAttribute):

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

Pokud uživatel nemá oprávnění, přesměruje se na přihlašovací stránku ME-ID.

Kontrolu zásad je možné provést také v kódu s procedurální logikou.

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

Pomocí předchozích přístupů můžete také vytvořit přístup založený na zásadách pro role aplikací, kde identifikátor GUID použitý pro zásadu je nastavený v appRoles elementu manifestu aplikace na webu Azure Portal a ve skupinách zabezpečení, kde identifikátor GUID použitý pro zásadu odpovídá ID objektu skupiny v podokně Skupiny webu Azure Portal.

Autorizace rozhraní API serveru nebo přístupu k webovému rozhraní API

Aplikace API serveru může autorizovat uživatele pro přístup k zabezpečeným koncovým bodům rozhraní API pomocí zásad autorizace pro skupiny zabezpečení, role správce ME-ID a role aplikací, pokud přístupový token obsahuje groups, widsa role deklarace identity. Následující příklad vytvoří zásadu pro roli správce fakturace ME-ID v Program souboru pomocí wids deklarací identity (známé ID nebo ID šablony role):

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

Úplný seznam ID pro role správce ME-ID najdete v dokumentaci k šablonám rolí Azure. Další informace o zásadách autorizace najdete v tématu Autorizace na základě zásad v ASP.NET Core.

Přístup k řadiči v aplikaci SERVER může být založený na použití [Authorize] atributu s názvem zásady (dokumentace k rozhraní API: AuthorizeAttribute).

Následující příklad omezuje přístup k fakturačním datům od BillingDataController správců fakturace Azure s názvem BillingAdministratorzásady:

using Microsoft.AspNetCore.Authorization;

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

Další informace najdete v tématu Autorizace na základě zásad v ASP.NET Core.

Aplikační role

Pokud chcete aplikaci nakonfigurovat na webu Azure Portal tak, aby poskytovala deklarace identity členství v rolích aplikací, přečtěte si téma Přidání rolí aplikace do aplikace a jejich příjem v tokenu v dokumentaci k Entra.

Následující příklad předpokládá, že aplikace CLIENT a SERVER jsou nakonfigurovány se dvěma rolemi a role jsou přiřazeny testovacímu uživateli:

Admin
Developer

Poznámka:

Při vývoji hostované Blazor WebAssembly aplikace nebo páru samostatných aplikací (samostatná Blazor WebAssembly aplikace a aplikace ASP.NET Core server API nebo webového rozhraní API) appRoles musí vlastnost manifestu klienta i serveru registrace aplikací na webu Azure Portal obsahovat stejné nakonfigurované role. Po navázání rolí v manifestu klientské aplikace je zkopírujte celý do manifestu serverové aplikace. Pokud neprojevíte manifest appRoles mezi registrací klientské a serverové aplikace, deklarace identity rolí nejsou vytvořeny pro ověřené uživatele rozhraní API serveru nebo webového rozhraní API, i když jejich přístupový token obsahuje správné položky v deklarací identity role.

I když nemůžete přiřadit role skupinám bez účtu Microsoft Entra ID Premium, můžete přiřadit role uživatelům a přijímat deklarace rolí pro uživatele se standardním účtem Azure. Pokyny v této části nevyžadují účet ME-ID Premium.

Při práci s výchozím adresářem postupujte podle pokynů v tématu Přidání rolí aplikace do aplikace a jejich přijetí v tokenu za účelem konfigurace a přiřazení rolí. Pokud nepracujete s výchozím adresářem, upravte manifest aplikace na webu Azure Portal a nastavte role aplikace ručně v appRoles položce souboru manifestu. Následuje příklad appRoles položky, která vytvoří Admin a Developer role. Tyto ukázkové role se používají dále v příkladu této části na úrovni komponenty k implementaci omezení přístupu:

"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} Pro zástupné {DEVELOPER GUID} symboly a zástupné symboly v předchozím příkladu můžete vygenerovat identifikátory GUID pomocí online generátoru GUID (výsledek hledání Google pro "generátor guid").

Přiřazení role uživateli (nebo skupině, pokud máte účet Azure úrovně Premium):

V oblasti ME-ID webu Azure Portal přejděte k podnikovým aplikacím.
Vyberte aplikaci. Na bočním panelu vyberte Spravovat>uživatele a skupiny.
Zaškrtněte políčko u jednoho nebo více uživatelských účtů.
V nabídce nad seznamem uživatelů vyberte Upravit přiřazení.
U položky Vybrat roli vyberte Možnost Žádný.
V seznamu zvolte roli a pomocí tlačítka Vybrat ji vyberte.
K přiřazení role použijte tlačítko Přiřadit v dolní části obrazovky.

Více rolí se přiřazuje na webu Azure Portal opětovným přidáním uživatele pro každé další přiřazení role. K opětovnému přidání uživatele použijte tlačítko Přidat uživatele nebo skupinu v horní části seznamu uživatelů. Pomocí předchozích kroků přiřaďte uživateli jinou roli. Tento proces můžete opakovat tolikrát, kolikrát je potřeba k přidání dalších rolí uživateli (nebo skupině).

Zobrazený CustomAccountFactory v části Vlastní uživatelský účet je nastavený tak, aby fungoval s role deklarací identity s hodnotou pole JSON. Přidejte a zaregistrujte CustomAccountFactory aplikaci CLIENT , jak je znázorněno v části Vlastní uživatelský účet . Není nutné zadávat kód pro odebrání původní role deklarace identity, protože se automaticky odebere rozhraním.

Program V souboru klientské aplikace zadejte deklaraci identity s názvem "appRole" jako deklaraci identity role pro ClaimsPrincipal.IsInRole kontroly:

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

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

Poznámka:

Pokud dáváte přednost použití directoryRoles deklarace identity (role SPRÁVCE ADD), přiřaďte mu RemoteAuthenticationUserOptions.RoleClaim"directoryRoles" .

Program V souboru aplikace SERVER zadejte deklaraci identity s názvem "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" jako deklaraci identity role pro ClaimsPrincipal.IsInRole kontroly:

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

Poznámka:

Při registraci jednoho schématu ověřování se schéma ověřování automaticky použije jako výchozí schéma aplikace a není nutné schéma uvést do AddAuthentication nebo přes AuthenticationOptions. Další informace najdete v tématu Přehled ASP.NET základního ověřování a oznámení ASP.NET Core (aspnet/Oznámení č. 490).

Poznámka:

Pokud dáváte přednost použití wids deklarace identity (role SPRÁVCE ADD), přiřaďte mu TokenValidationParameters.RoleClaimType"wids" .

Po dokončení předchozích kroků pro vytváření a přiřazování rolí uživatelům (nebo skupinám, pokud máte účet Azure úrovně Premium) a implementovali CustomAccountFactory ho se sadou Graph SDK, jak je vysvětleno výše v tomto článku a použití rozhraní Graph API s ASP.NET Core Blazor WebAssembly, byste měli vidět appRole deklaraci identity pro každou přiřazenou roli, kterou má přiřazený přihlášený uživatel (nebo role přiřazené skupinám, kterých jsou členy). Spusťte aplikaci s testovacím uživatelem a ověřte, že deklarace identity existují podle očekávání. Při místním testování pomocí sady Graph SDK doporučujeme pro každý test použít novou relaci prohlížeče v privátním nebo anonymním režimu, aby se zabránilo zasahování souborů cookie do souborů cookie. Další informace najdete v tématu Zabezpečení samostatné aplikace ASP.NET Core Blazor WebAssembly pomocí Microsoft Entra ID.

Přístupy k autorizaci komponent jsou v tomto okamžiku funkční. Jakýkoli z autorizačních mechanismů v komponentách klientské aplikace může tuto roli použít Admin k autorizaci uživatele:

AuthorizeView komponenta
```
<AuthorizeView Roles="Admin">
```
[Authorize] attribute – direktiva (AuthorizeAttribute)
```
@attribute [Authorize(Roles = "Admin")]
```

Procedurální logika

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

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

Podporuje se více testů rolí:

Vyžadovat, aby byl uživatel v komponentě Admin AuthorizeView nebo Developer v roli:
```
<AuthorizeView Roles="Admin, Developer">
    ...
</AuthorizeView>
```
Vyžadovat, aby byl uživatel v komponentě Admin i Developer v rolíchAuthorizeView:
```
<AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>
```
Další informace o Context vnitřní AuthorizeViewčásti najdete v tématu ASP.NET Ověřování a autorizace jádraBlazor.
Vyžadovat, aby byl uživatel v atributu Admin [Authorize] nebo Developer v roli:
```
@attribute [Authorize(Roles = "Admin, Developer")]
```

Vyžadovat, aby byl uživatel v atributu Admin [Authorize] i Developer v rolích:

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

Vyžadovat, aby byl uživatel v procedurálním kódu nebo Developer v Admin roli:

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

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

Vyžadovat, aby byl uživatel v procedurálním kódu jak Admin Developer v rolích, tak změnou podmíněného operátoru OR (||) na podmíněný operátor AND (&&) v předchozím příkladu:
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
```

Jakýkoli z autorizačních mechanismů v kontrolerů aplikace SERVER může tuto roli použít Admin k autorizaci uživatele:

[Authorize] attribute – direktiva (AuthorizeAttribute)
```
[Authorize(Roles = "Admin")]
```
Procedurální logika
```
if (User.IsInRole("Admin")) { ... }
```

Podporuje se více testů rolí:

Vyžadovat, aby byl uživatel v atributu Admin [Authorize] nebo Developer v roli:
```
[Authorize(Roles = "Admin, Developer")]
```
Vyžadovat, aby byl uživatel v atributu Admin [Authorize] i Developer v rolích:
```
[Authorize(Roles = "Admin")]
[Authorize(Roles = "Developer")]
```

Vyžadovat, aby byl uživatel v procedurálním kódu nebo Developer v Admin roli:

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

Vyžadovat, aby byl uživatel v procedurálním kódu jak Admin Developer v rolích, tak změnou podmíněného operátoru OR (||) na podmíněný operátor AND (&&) v předchozím příkladu:
```
if (User.IsInRole("Admin") && User.IsInRole("Developer"))
```

Vzhledem k tomu, že porovnávání řetězců .NET rozlišují malá a velká písmena, rozlišují se také odpovídající názvy rolí. Například Admin (velkáA) není považována za stejnou roli jako admin (malá).a

Písmena Pascal se obvykle používají pro názvy rolí (například BillingAdministrator), ale použití případu Pascal není striktní požadavek. Jsou povolena různá schémata, jako jsou velbloudí případ, případ kebabu a hadí případ. Použití mezer v názvech rolí je také neobvyklé, ale povolené. Jedná se například billing administrator o neobvyklý formát názvu role v aplikacích .NET, ale je platný.

Sdílet prostřednictvím

Skupiny Microsoft Entra (ME-ID), role správce a role aplikací (.NET 5 až .NET 7)

Požadavek

Rozsahy

Atribut deklarací členství ve skupinách

Vlastní uživatelský účet

Konfigurace autorizace

Autorizace rozhraní API serveru nebo přístupu k webovému rozhraní API

Aplikační role

Další materiály

Další materiály