Skupiny Microsoft Entra (ME-ID), role správce a role aplikací

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 tématech:

• Samostatná služba s účty Microsoft
• Samostatný s ME-ID

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

• KLIENT: Samostatné Blazor WebAssembly aplikace.
• SERVER: ASP.NET základní serverové rozhraní API nebo webové aplikace API. 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 cookiezasahování do testů. 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ýmUser.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 aplikaceGroupMember.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 jsou vyžadovány kromě oborů požadovaných ve scénářích nasazení ME-ID popsaných výše uvedenými tématy (samostatně s účty Microsoft nebo samostatnou pomocí ME-ID).

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

Poznámka:

Slova "oprávnění" a "obor" se používají zaměnitelně na webu Azure Portal a v různých sadách microsoftu a externí dokumentace. V tomto článku se pro oprávnění přiřazená k aplikaci na webu Azure Portal používá slovo "obor".

Atribut deklarací členství ve skupinách

V manifestu aplikace na webu Azure Portal pro aplikace CLIENT a SERVER nastavte atribut nagroupMembershipClaimsAll. 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):

1. Otevřete registraci webu Azure Portal aplikace.
2. Na bočním panelu vyberte Spravovat>manifest.
3. Vyhledejte groupMembershipClaims atribut.
4. Nastavte hodnotu na All ("groupMembershipClaims": "All").
5. 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:

Následující příklad předpokládá, že soubor nastavení aplikace projektu obsahuje položku základní adresy URL:

{
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com/{VERSION}",
    ...
  }
}

V předchozím příkladu {VERSION} je zástupný symbol verzí rozhraní MS Graph API (například: v1.0).

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(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 = 
        config.GetSection("MicrosoftGraph")["BaseUrl"];

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

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(IAccessTokenProviderAccessor accessor,
        IServiceProvider serviceProvider,
        ILogger<CustomAccountFactory> logger)
    : AccountClaimsPrincipalFactory<CustomUserAccount>(accessor)
{
    private readonly ILogger<CustomAccountFactory> logger = logger;
    private readonly IServiceProvider serviceProvider = serviceProvider;

    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 rolemi správce ME-ID (#microsoft.graph.directoryRoletypu), protože hodnoty GUID vrácené platformou Microsoft Identity Platform jsou ID entity role správce ME-ID a ne ID šablon rolí. ID entit nejsou stabilní napříč tenanty na platformě Microsoft Identity Platform a neměli byste je používat k vytváření zásad autorizace pro uživatele v aplikacích. Id šablon rolí vždy používejte pro role správce ME-ID poskytované deklaracemiwids identity.

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"], 
    builder.Configuration.GetSection("MicrosoftGraph")["Version"]);
var scopes = builder.Configuration.GetSection("MicrosoftGraph:Scopes")
    .Get<List<string>>();

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

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 dvojice klientských serverů samostatných aplikací (samostatná Blazor WebAssembly aplikace a aplikace ASP.NET core server API nebo webového rozhraní API) appRoles musí být 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 manifest mezi registrací klientské a serverové aplikace zrcadlíte appRoles , 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 role deklarací identity.

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 získat role nároky pro uživatele se standardním účtem Azure. Pokyny v této části nevyžadují účet ME-ID Premium.

Pokud máte účet Azure úrovně Premium, na bočním panelu registrace aplikace na webu Azure Portal se zobrazí role Spravovat>aplikace. Postupujte podle pokynů v tématu Přidání rolí aplikace do aplikace a jejich přijetí v tokenu a nakonfigurujte role aplikace.

Pokud nemáte účet Azure úrovně Premium, upravte manifest aplikace na webu Azure Portal. Postupujte podle pokynů v rolích aplikace: Implementace pro ruční vytvoření rolí aplikace v appRoles položce souboru manifestu. Uložte změny souboru.

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": "584e483a-7101-404b-9bb1-83bf9463e335",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Admin"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Developers write code.",
    "displayName": "Developer",
    "id": "82770d35-2a93-4182-b3f5-3d7bfe9dfe46",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Developer"
  }
],

Poznámka:

Identifikátory GUID můžete generovat pomocí online programu 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):

1. V oblasti ME-ID webu Azure Portal přejděte k podnikovým aplikacím .
2. Vyberte aplikaci. Na bočním panelu vyberte Spravovat>uživatele a skupiny.
3. Zaškrtněte políčko u jednoho nebo více uživatelských účtů.
4. V nabídce nad seznamem uživatelů vyberte Upravit přiřazení.
5. U položky Vybrat roli vyberte Možnost Žádný.
6. V seznamu zvolte roli a pomocí tlačítka Vybrat ji vyberte.
7. 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ě).

V CustomAccountFactory části Vlastní uživatelský účet je nastavená akce na role deklaraci identity s JShodnotou pole ON. 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 souboruklientské 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 cookiezasahování do testů. 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ě AdminAuthorizeViewneboDeveloper v roli:

  <AuthorizeView Roles="Admin, Developer">
      ...
  </AuthorizeView>
  

• Vyžadovat, aby byl uživatel v komponentě AdminiDeveloper 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]neboDeveloper v roli:

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

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

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

• Vyžadovat, aby byl uživatel v procedurálním kódu neboDeveloper vAdminroli:

  @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 jakAdminDeveloper 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]neboDeveloper v roli:

  [Authorize(Roles = "Admin, Developer")]
  

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

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

• Vyžadovat, aby byl uživatel v procedurálním kódu neboDeveloper vAdminroli:

  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 jakAdminDeveloper 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ání řetězců .NET ve výchozím nastavení 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ý.

Další materiály

• ID šablon rolí (dokumentace k Entra)
• groupMembershipClaims attribute (dokumentace k Entra)
• Přidání rolí aplikace do aplikace a jejich přijetí v tokenu (dokumentace k Entra)
• Aplikační role (dokumentace k Azure)
• Autorizace založená na deklarací identity v ASP.NET Core
• Autorizace na základě rolí v ASP.NET Core
• Ověřování a autorizace ASP.NET Core Blazor