Freigeben über

Gruppen, Administratorrollen und App-Rollen in Microsoft Entra ID (ME-ID)

  • Artikel

Hinweis

Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Wichtig

Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.

Die aktuelle Version finden Sie in der .NET 9-Version dieses Artikels.

Dieser Artikel erklärt, wie Blazor WebAssembly für die Verwendung von Microsoft Entra ID (ME-ID) Gruppen und Rollen konfiguriert wird.

ME-ID stellt mehrere Berechtigungsansätze bereit, die mit ASP.NET Core Identity kombiniert werden können:

  • Gruppen
    • Sicherheit
    • Microsoft 365
    • Verteilung
  • Rollen
    • ME-ID integrierte Administrator-Rollen
    • App-Rollen

Die Hinweise in diesem Artikel gelten für die Blazor WebAssembly ME-ID Bereitstellungsszenarien, die in den folgenden Artikeln beschrieben werden:

Die Beispiele in diesem Artikel nutzen neue .NET-/C#-Funktionen. Wenn Sie die Beispiele mit .NET 7 oder früher verwenden, sind geringfügige Änderungen erforderlich. Die Text- und Codebeispiele, die sich auf die Interaktion mit ME-ID und Microsoft Graph beziehen, sind jedoch für alle Versionen von ASP.NET Core identisch.

Beispiel-App

Greifen Sie auf die Beispiel-App mit dem Namen BlazorWebAssemblyEntraGroupsAndRoles über den Ordner mit der neuesten Version im Stammverzeichnis des Repositorys über den folgenden Link zu. Das Beispiel ist für .NET 8 oder höher bereitgestellt. In der README-Datei der Beispiel-App finden Sie die Schritte zur Ausführung der App.

Die Beispiel-App enthält eine UserClaims-Komponente zum Anzeigen der Ansprüche eines Benutzers. Die UserData-Komponente zeigt die grundlegenden Eigenschaften des Benutzerkontos an.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Voraussetzungen

Im Leitfaden in diesem Artikel wird die Microsoft Graph-API gemäß dem Leitfaden zum Graph SDK unter Verwenden der Graph-API mit der Blazor WebAssembly von ASP.NET Core implementiert. Konfigurieren und testen Sie die App gemäß dem Implementierungsleitfaden für das Graph SDK, um sicherzustellen, dass die App Graph-API-Daten für ein Testbenutzerkonto abrufen kann. Lesen Sie außerdem die Informationen zu den Sicherheitskonzepten von Microsoft Graph, die Sie unter den Querlinks im Artikel zur Sicherheit der Graph-API finden.

Beim lokalem Testen mit dem Graph SDK empfehlen wir die Verwendung einer neuen privaten bzw. Inkognito-Browsersitzung für jeden Test, um zu verhindern, dass Tests durch vorhandene Cookies beeinträchtigt werden. Weitere Informationen finden Sie unter Sichern einer eigenständigen ASP.NET Core-Blazor WebAssembly-App mit Microsoft Entra ID.

Onlinetools für die ME-ID-App-Registrierung

Dieser Artikel bezieht sich durchgängig auf das Azure Portal, wenn Sie aufgefordert werden, die ME-ID App-Registrierung zu konfigurieren, aber das Microsoft Entra Admin Center ist ebenfalls eine geeignete Option für die Verwaltung von ME-ID App-Registrierungen. Beide Schnittstellen können verwendet werden, aber die Anleitung in diesem Artikel deckt speziell Gesten für das Azure-Portal ab.

Bereiche

Berechtigungen und Bereiche bedeuten dasselbe und werden in der Sicherheitsdokumentation und im Azure-Portal austauschbar verwendet. Sofern sich der Text nicht auf das Azure-Portal bezieht, verwendet dieser Artikel scope/scopes, wenn er sich auf Graph-Berechtigungen bezieht.

Die Groß- und Kleinschreibung spielt keine Rolle, also ist User.Read dasselbe wie user.read. Sie können beide Formate verwenden, aber wir empfehlen eine einheitliche Wahl für den gesamten Anwendungscode.

Um Microsoft Graph API-Aufrufe für Benutzerprofil-, Rollenzuweisungs- und Gruppenzugehörigkeitsdaten zu ermöglichen, wird die App mit dem delegiertenUser.Read-Bereich (https://graph.microsoft.com/User.Read) im Azure-Portal konfiguriert, da der Zugriff auf das Lesen von Benutzerdaten durch die den einzelnen Benutzenden gewährten (delegierten) Bereiche bestimmt wird. Dieser Bereich ist zusätzlich zu den Bereichen erforderlich, die in den ME-ID Bereitstellungsszenarien erforderlich sind, die in den zuvor aufgeführten Artikeln beschrieben sind (Standalone mit Microsoft Accounts oder Standalone mit ME-ID).

Weitere erforderliche Bereiche sind:

  • DelegierterRoleManagement.Read.Directory Bereich (https://graph.microsoft.com/RoleManagement.Read.Directory): Ermöglicht der App, die Einstellungen der rollenbasierten Zugriffskontrolle (RBAC) für das Verzeichnis Ihres Unternehmens im Namen von angemeldeten Benutzenden zu lesen. Dazu gehört das Lesen von Verzeichnisrollenvorlagen, Verzeichnisrollen und Mitgliedschaften. Verzeichnisrollenmitgliedschaften werden verwendet, um directoryRole Ansprüche in der App für ME-ID eingebaute Administratorrollen zu erstellen. Die Zustimmung des Administrators ist erforderlich.
  • DelegierterAdministrativeUnit.Read.All Bereich (https://graph.microsoft.com/AdministrativeUnit.Read.All): Erlaubt der App, im Namen des angemeldeten Benutzers Verwaltungseinheiten und die Mitgliedschaft in einer Verwaltungseinheit zu lesen. Diese Mitgliedschaften werden verwendet, um administrativeUnit Ansprüche in der App zu erstellen. Die Zustimmung des Administrators ist erforderlich.

Weitere Informationen finden Sie in der Übersicht über Berechtigungen und Zustimmung in der Microsoft-Identitätsplattform und der Übersicht über Microsoft Graph-Berechtigungen.

Benutzerdefiniertes Benutzerkonto

Weisen Sie Benutzer im Azure-Portal zu ME-ID-Sicherheitsgruppen und ME-ID-Administratorrollen zu.

Für die Beispiele in diesem Artikel gilt:

  • Es wird angenommen, dass einem Benutzer im ME-ID-Mandanten im Azure-Portal die ME-ID-Rolle Abrechnungsadministrator zugewiesen ist, damit dieser Benutzer für den Zugriff auf die Zugriffsserver-API-Daten autorisiert ist.
  • Verwenden Sie Berechtigungsrichtlinien, um den Zugriff innerhalb der App zu steuern.

Erweitern Sie RemoteUserAccount um die Eigenschaften für:

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

Hinzufügen eines Paketverweises zur Anwendung für Microsoft.Graph.

Hinweis

Eine Anleitung zum Hinzufügen von Paketen zu .NET-Anwendungen finden Sie in den Artikeln unter Pakete installieren und verwalten unter Workflow für die Paketnutzung (NuGet-Dokumentation). Überprüfen Sie unter NuGet.org, ob die richtige Paketversion verwendet wird.

Fügen Sie die Hilfsklassen des Graph SDK und die Konfiguration im Leitfaden zum Graph SDK im Artikel Verwenden der Graph-API mit der Blazor WebAssembly von ASP.NET Core hinzu. Geben Sie die Bereiche User.Read, RoleManagement.Read.Directory und AdministrativeUnit.Read.All für das Zugriffstoken an, wie im Artikel in der Beispieldatei wwwroot/appsettings.json gezeigt.

Fügen Sie die folgende benutzerdefinierte Benutzerkonto-Factory zur App hinzu. Die benutzerdefinierte Benutzerfactory wird verwendet, um Folgendes einzurichten:

  • App-Rollenansprüche (role) (beschrieben im Abschnitt App-Rollen)

  • Beispiel für Benutzerprofildaten-Ansprüche für die Mobiltelefonnummer (mobilePhone) und den Bürostandort (officeLocation) des Benutzers

  • ME-ID-Administratorrollenansprüche (directoryRole).

  • ME-ID Ansprüche der Verwaltungseinheit (administrativeUnit).

  • ME-ID-Gruppenansprüche (directoryGroup).

  • Ein ILogger (logger) für den Fall, dass Sie Informationen oder Fehler protokollieren möchten

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

Der vorangehende Code:

  • Enthält keine transitiven Mitgliedschaften. Wenn die App direkte und transitive Gruppenmitgliedschaftsansprüche erfordert, ersetzen Sie die MemberOf-Eigenschaft (IUserMemberOfCollectionWithReferencesRequestBuilder) durch TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).
  • Legt GUID-Werte in directoryRole-Ansprüchen fest, sind ME-ID Administrator Role Template IDs (Microsoft.Graph.Models.DirectoryRole.RoleTemplateId). Vorlagen-IDs sind stabile Bezeichner für die Erstellung von Richtlinien für die Berechtigung von Benutzern in Apps, die später in diesem Artikel abgedeckt werden. Verwenden Sie nicht entry.Id für Verzeichnisrollen-Ansprüche, da diese nicht über mehrere Mandanten hinweg stabil sind.

Als Nächstes konfigurieren Sie die MSAL-Authentifizierung für die Verwendung der benutzerdefinierten Benutzerkontenfabrik.

Vergewissern Sie sich, dass die Datei Program den Microsoft.AspNetCore.Components.WebAssembly.Authentication-Namespace verwendet:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Aktualisieren Sie den AddMsalAuthentication-Aufruf wie im Folgenden gezeigt. Beachten Sie, dass das RemoteUserAccount des Blazor-Frameworks durch das CustomUserAccount der App für die MSAL-Authentifizierung und die Kontoanspruchs-Prinzipalfactory ersetzt wird:

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

Bestätigen Sie das Vorhandensein des Graph SDK-Codes in der Program-Datei, der im Artikel Verwenden von Graph API mit ASP.NET Core Blazor WebAssembly beschrieben wird:

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

Wichtig

Bestätigen Sie bei der Registrierung der App im Azure-Portal, dass die folgenden Berechtigungen gewährt werden:

  • User.Read
  • RoleManagement.Read.Directory (Erfordert die Zustimmung des Administrators)
  • AdministrativeUnit.Read.All (Erfordert die Zustimmung des Administrators)

Bestätigen Sie, dass die wwwroot/appsettings.json Konfiguration gemäß der Graph SDK Anleitung korrekt ist.

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

Stellen Sie Werte für die folgenden Platzhalter aus der ME-ID-Registrierung der App im Azure-Portal bereit:

  • {TENANT ID}: Der GUID-Wert der Directory (Mandant) Id.
  • {CLIENT ID}: Der GUID-Wert der Anwendungs-(Client-)Id.

Konfigurieren der Autorisierung

Erstellen Sie eine Richtlinie für jede App-Rolle (nach Rollenname), Administratorrolle mit integrierter ME-ID (nach Rollenvorlagen-ID/GUID) oder Sicherheitsgruppe (nach Objekt-ID/GUID) in der Program-Datei. Das folgende Beispiel erstellt eine Richtlinie für die in ME-ID integrierte Rolle Billing Administrator:

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

Die vollständige Liste der IDs (GUIDs) für ME-ID Administrator-Rollen finden Sie unter Rollenvorlagen-IDs in der ME-ID Dokumentation. Eine Azure-Sicherheits- oder O365-Gruppen-ID (GUID) finden Sie in der Object Id für die Gruppe im Bereich Gruppen des Azure-Portals bei der Registrierung der App. Weitere Informationen zu Autorisierungsrichtlinien finden Sie unter Richtlinienbasierte Autorisierung in ASP.NET Core.

In den folgenden Beispielen verwendet die App die obige Richtlinie für die Autorisierung des Benutzers.

Die AuthorizeView-Komponente verwendet die Richtlinie:

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

Durch Verwendung einer [Authorize]-Attributanweisung (AuthorizeAttribute) kann mithilfe der Richtlinie der Zugriff auf eine gesamte Komponente geregelt werden:

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

Wenn der Benutzer nicht autorisiert ist, wird er zur ME-ID-Anmeldeseite umgeleitet.

Eine Richtlinienüberprüfung kann auch in Code mit prozeduraler Logik durchgeführt werden.

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

Mit den oben genannten Ansätzen können Sie auch einen richtlinienbasierten Zugriff für Sicherheitsgruppen erstellen, wobei die für die Richtlinie verwendete GUID übereinstimmt mit den

App-Rollen

Um die App im Azure-Portal so zu konfigurieren, dass sie App-Rollen-Mitgliedschaftsansprüche bereitstellt, siehe App-Rollen zu Ihrer Anwendung hinzufügen und im Token empfangen in der ME-ID-Dokumentation.

Im folgenden Beispiel wird davon ausgegangen, dass die App mit zwei Rollen konfiguriert ist und die Rollen einem Testbenutzer zugewiesen sind:

  • Admin
  • Developer

Zwar können Sie ohne ME-ID-Premium-Konto nicht Rollen zu Gruppen zuweisen, aber Sie können Benutzenden Rollen zuweisen und Rollenansprüche für Benutzende mit einem Azure-Standardkonto erhalten. Für die Schritte in diesem Abschnitt ist kein ME-ID Premium-Konto erforderlich.

Fügen Sie auf eine der folgenden Arten App-Rollen in ME-ID hinzu:

  • Wenn Sie mit dem Standardverzeichnis arbeiten, folgen Sie der Anleitung in Hinzufügen von App-Rollen zu Ihrer Anwendung und diese im Token zu erhalten, um ME-ID-Rollen zu erstellen.

  • Wenn Sie nicht mit dem Standardverzeichnis arbeiten, bearbeiten Sie das Manifest der App im Azure-Portal, um die Rollen der App manuell im appRoles Eintrag der Manifestdatei festzulegen. Im Folgenden sehen Sie einen appRoles-Beispieleintrag, der Admin- und Developer-Rollen erstellt. Diese Beispielrollen werden später auf der Ebene der Komponenten verwendet, um Zugriffsbeschränkungen zu implementieren:

    Wichtig

    Die folgende Vorgehensweise wird nur für Apps empfohlen, die nicht im Standardverzeichnis des Azure-Kontos registriert sind. Für Apps, die sich im Standardverzeichnis registrieren, siehe den vorangehenden Punkt dieser Liste.

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

    Für die {ADMIN GUID} und {DEVELOPER GUID} Platzhalter im vorherigen Beispiel können Sie GUIDs mit einem Online-GUID-Generator (Google-Suchergebnis für "guid generator") generieren.

So weisen Sie einem Benutzer (oder einer Gruppe, wenn Sie über ein Azure-Konto im Premium-Tarif verfügen) eine Rolle zu:

  1. Navigieren Sie im ME-ID-Bereich des Azure-Portals zu Unternehmensanwendungen.
  2. Wählen Sie die App aus. Wählen Sie auf der Randleiste Verwalten>Benutzer und Gruppen aus.
  3. Aktivieren Sie das Kontrollkästchen für ein oder mehrere Benutzerkonten.
  4. Wählen Sie im Menü über der Liste der Benutzer die Option Zuweisung bearbeiten aus.
  5. Wählen Sie für den Eintrag Rolle auswählen die Option Keine ausgewählt aus.
  6. Klicken Sie in der Liste auf eine Rolle, und wählen Sie sie mit der Schaltfläche Auswählen aus.
  7. Verwenden Sie die Schaltfläche Zuweisen am unteren Bildschirmrand, um die Rolle zuzuweisen.

Mehrere Rollen werden im Azure-Portal durch separates Hinzufügen eines Benutzers für jede weitere Rollenzuweisung zugewiesen. Verwenden Sie die Schaltfläche Benutzer/Gruppe hinzufügen oben in der Liste der Benutzer, um einen Benutzer erneut hinzuzufügen. Führen Sie die obigen Schritte aus, um dem Benutzer eine weitere Rolle zuzuweisen. Sie können diesen Vorgang beliebig oft wiederholen, um einem Benutzer (oder einer Gruppe) zusätzliche Rollen hinzuzufügen.

Die im Abschnitt Benutzerdefiniertes Benutzerkonto gezeigte CustomAccountFactory ist so konfiguriert, dass sie auf einen role-Anspruch mit einem JSON-Arraywert reagiert. Fügen Sie die CustomAccountFactory in der App hinzu und registrieren Sie sich wie im Abschnitt Benutzerkonto gezeigt. Für das Entfernen des ursprünglichen role-Anspruchs muss kein Code bereitgestellt werden, da das Framework diesen automatisch entfernt.

Fügen Sie in der Datei Program den Anspruch mit der Bezeichnung „role“ als Rollenanspruch für die Überprüfung von ClaimsPrincipal.IsInRole hinzu oder bestätigen Sie ihn:

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

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

Hinweis

Wenn Sie den Anspruch directoryRoles (ME-ID Administrator Roles) bevorzugen, ordnen Sie „directoryRoles“ dem RemoteAuthenticationUserOptions.RoleClaim zu.

Nachdem Sie die vorherigen Schritte zum Erstellen und Zuweisen von Rollen für Benutzer (oder Gruppen, wenn Sie über ein Azure-Konto im Premium-Tarif verfügen) ausgeführt und die CustomAccountFactory mit dem Graph SDK wie weiter oben in diesem Artikel und unter Verwenden der Graph-API mit der Blazor WebAssembly von ASP.NET Core beschrieben implementiert haben, sollte ein role-Anspruch für jede Rolle, die einem angemeldeten Benutzer zugewiesen ist (oder Rollen, die Gruppen zugewiesen sind, denen er angehört), angezeigt werden. Führen Sie die App mit einem Testbenutzer aus, um sicherzustellen, dass die Ansprüche wie erwartet vorhanden sind. Beim lokalem Testen mit dem Graph SDK empfehlen wir die Verwendung einer neuen privaten bzw. Inkognito-Browsersitzung für jeden Test, um zu verhindern, dass Tests durch vorhandene Cookies beeinträchtigt werden. Weitere Informationen finden Sie unter Sichern einer eigenständigen ASP.NET Core-Blazor WebAssembly-App mit Microsoft Entra ID.

Die Komponentenautorisierungsansätze sind Stand jetzt funktional. Jeder der Berechtigungsmechanismen in den Komponenten der App kann die Rolle Admin verwenden, um den Benutzer zu berechtigen:

Mehrere Rollentests werden unterstützt:

  • Legen Sie mithilfe der AuthorizeView-Komponente als erforderlich fest, dass der Benutzer entweder die Rolle Admin oder die Rolle Developer innehat:

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

  • Legen Sie mithilfe der AuthorizeView-Komponente als erforderlich fest, dass der Benutzer sowohl die Rolle Admin als auch die Rolle Developer innehat:

    <AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>

    Weitere Informationen zu Context für die innere AuthorizeView finden Sie unter ASP.NET Core-Blazor-Authentifizierung und -Autorisierung.

  • Legen Sie mithilfe des [Authorize]-Attributs als erforderlich fest, dass der Benutzer entweder die Rolle Admin oder die Rolle Developer innehat:

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

  • Legen Sie mithilfe des [Authorize]-Attributs als erforderlich fest, dass der Benutzer sowohl die Rolle Admin als auch die Rolle Developer innehat:

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

  • Legen Sie per prozeduralem Code als erforderlich fest, dass der Benutzer entweder die Rolle Admin oder die Rolle Developer innehat:

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

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

  • Legen Sie per prozeduralem Code als erforderlich fest, dass der Benutzer sowohl die Rolle Admin als auch die Rolle Developer innehat. Ändern Sie dazu im vorherigen Beispiel das bedingte OR (||) in ein bedingtes AND (&&):

    if (user.IsInRole("Admin") && user.IsInRole("Developer"))

Mehrere Rollentests werden unterstützt:

  • Legen Sie mithilfe des [Authorize]-Attributs als erforderlich fest, dass der Benutzer entweder die Rolle Admin oder die Rolle Developer innehat:

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

  • Legen Sie mithilfe des [Authorize]-Attributs als erforderlich fest, dass der Benutzer sowohl die Rolle Admin als auch die Rolle Developer innehat:

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

  • Legen Sie per prozeduralem Code als erforderlich fest, dass der Benutzer entweder die Rolle Admin oder die Rolle Developer innehat:

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

  • Legen Sie per prozeduralem Code als erforderlich fest, dass der Benutzer sowohl die Rolle Admin als auch die Rolle Developer innehat. Ändern Sie dazu im vorherigen Beispiel das bedingte OR (||) in ein bedingtes AND (&&):

    if (User.IsInRole("Admin") && User.IsInRole("Developer"))

Da bei Zeichenfolgenvergleichen in .NET zwischen Groß- und Kleinschreibung unterschieden wird, wird auch beim Abgleich von Rollennamen zwischen Groß- und Kleinschreibung unterschieden. Beispielsweise wird Admin (mit Großbuchstabe A) nicht als dieselbe Rolle wie admin (mit Kleinbuchstabe a) behandelt.

Die Pascal-Schreibweise wird in der Regel für Rollennamen (z. B. BillingAdministrator) verwendet, aber die Verwendung der Pascal-Schreibweise ist keine strenge Anforderung. Unterschiedliche Groß-/Kleinschreibungen wie Camel Case, Kebab Case und Snake Case sind zulässig. Die Verwendung von Leerzeichen in Rollennamen ist ebenfalls ungewöhnlich, aber zulässig. Beispielsweise ist billing administrator ein ungewöhnliches Rollennamenformat in .NET-Apps, aber gültig.

Zusätzliche Ressourcen