Groupes Microsoft Entra (ME-ID), rôles d’administrateur et rôles d’application

Article
11/12/2024

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 9 de cet article.

Important

Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Pour la version actuelle, consultez la version .NET 9 de cet article.

Cet article explique comment configurer Blazor WebAssembly pour utiliser des groupes et des rôles Microsoft Entra ID (ME-ID).

Microsoft Entra (ME-ID) fournit plusieurs approches d’autorisation qui peuvent être combinées avec ASP.NET Core Identity:

Groupes
- Sécurité
- Microsoft 365
- Distribution
Rôles
- Rôles d’administrateur intégrés ME-ID
- Rôles d'application

Les conseils de cet article s’appliquent aux scénarios de déploiement Blazor WebAssembly ME-ID décrits dans les articles suivants :

Les exemples de cet article tirent parti des nouvelles fonctionnalités .NET/C#. Lors de l’utilisation des exemples avec .NET 7 ou antérieur, des modifications mineures sont requises. Toutefois, les exemples de texte et de code relatifs à l’interaction avec ME-ID et Microsoft Graph sont identiques pour toutes les versions de ASP.NET Core.

Exemple d’application

Accédez à l’exemple d’application, nommé BlazorWebAssemblyEntraGroupsAndRoles, par le biais du dossier de version le plus récent à partir de la racine du référentiel, à l’aide du lien suivant. L’exemple est fourni pour .NET 8 ou version ultérieure. Consultez le fichier de l’exemple d’application README pour connaître les étapes permettant d’exécuter l’application.

L’exemple d’application inclut un composant UserClaims qui permet d’afficher les revendications d’un utilisateur. Le composant UserData affiche les propriétés de base du compte de l’utilisateur.

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

Prérequis

Les conseils de cet article implémentent l’API Microsoft Graph conformément aux instructions du Kit de développement logiciel (SDK) Graph dans Utiliser l’API Graph avec ASP.NET Core Blazor WebAssembly. Suivez les instructions d’implémentation du Kit de développement logiciel (SDK) Graph pour configurer l’application et la tester afin de confirmer que l’application peut obtenir des données de l’API Graph pour un compte d’utilisateur de test. En outre, consultez les liens croisés de l’article sur la sécurité de l’API Graph pour passer en revue les concepts de sécurité de Microsoft Graph.

Lorsque vous effectuez des tests en local avec le kit de développement logiciel (SDK) Graph, nous vous recommandons d’utiliser une nouvelle session de navigateur privée/incognito pour chaque test afin d’éviter que les cookies persistants n’interfèrent avec les tests. Pour plus d’informations, consultez Sécuriser une application autonome ASP.NET Core Blazor WebAssembly avec Microsoft Entra ID.

Outils en ligne d’inscription pour applications ME-ID

Cet article fait référence au portail Azure lorsqu’il vous invite à configurer l’inscription d’application ME-ID de l’application, mais le centre d’administration Microsoft Entra est également une option viable pour gérer les inscriptions d’applications ME-ID. Les deux interfaces peuvent être utilisées, mais les instructions de cet article traitent spécifiquement des gestes relatifs au portail Azure.

Étendues

Les termes autorisations et étendues signifient la même chose et sont interchangeables dans la documentation sur la sécurité et dans le portail Azure. Sauf si le texte fait référence au portail Azure, cet article utilise étendue/étendues pour désigner les autorisations Graph.

Les étendues ne respectent pas la casse, User.Read est donc la même chose que user.read. Vous pouvez utiliser le format de votre choix, mais nous vous recommandons de faire preuve de cohérence dans le code de l’application.

Pour autoriser les appels vers l’API Microsoft Graph pour le profil utilisateur, l’attribution de rôles et les données d’appartenance à des groupes, l’application est configurée avec l’étendue déléguéeUser.Read (https://graph.microsoft.com/User.Read) dans le portail Azure, car l’accès de lecture aux données utilisateur est déterminé par les étendues accordées (déléguées) à des utilisateurs individuels. Cette étendue est requise en plus des étendues requises dans les scénarios de déploiement ME-ID décrits dans les articles précédemment indiqués (autonome avec des comptes Microsoft ou autonome avec ME-ID).

Les étendues requises supplémentaires sont les suivantes :

Étendue déléguéeRoleManagement.Read.Directory (https://graph.microsoft.com/RoleManagement.Read.Directory) : permet à l’application de lire les paramètres de contrôle d’accès basés sur des rôles de l’annuaire de votre entreprise, au nom de l’utilisateur connecté. Cela inclut la lecture des modèles de rôles d’annuaire, des rôles d’annuaire, et des appartenances. Les appartenances aux rôles d’annuaire sont utilisées pour créer des revendications directoryRole dans l’application pour les rôles d’administrateur intégrés ME-ID. Le consentement de l’administrateur est requis.
Étendue déléguéeAdministrativeUnit.Read.All (https://graph.microsoft.com/AdministrativeUnit.Read.All) : permet à l’application de lire les unités administratives et l’appartenance aux unités administratives au nom de l’utilisateur connecté. Ces appartenances sont utilisées pour créer des revendications administrativeUnit dans l’application. Le consentement de l’administrateur est requis.

Pour plus d’informations, consultez Vue d’ensemble des autorisations et du consentement dans la plateforme identity Microsoft et Vue d’ensemble des autorisations Microsoft Graph.

Compte d’utilisateur personnalisé

Affectez des utilisateurs à des groupes de sécurité ME-ID et des rôles d’administrateur ME-ID dans le portail Azure.

Les exemples de cet article :

Supposons qu’un utilisateur est affecté à ME-ID rôle d’administrateur de facturation dans le locataire ME-ID du portail Azure pour l’autorisation d’accéder aux données d’API du serveur.
Utilisez des stratégies d’autorisation pour contrôler l’accès au sein de l’application.

Étendez RemoteUserAccount afin d’inclure les propriétés pour :

Roles: tableau des rôles d’application ME-ID (couvert dans la section Rôles d’application )
Oid : revendication d’identificateur d’objet immuable (oid) immuable (identifie de manière unique un utilisateur au sein et entre les locataires)

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

Ajoutez une référence de package à l’application pour Microsoft.Graph.

Remarque

Pour obtenir des conseils sur l’ajout de packages à des applications .NET, consultez les articles figurant sous Installer et gérer des packages dans Flux de travail de la consommation des packages (documentation NuGet). Vérifiez les versions du package sur NuGet.org.

Ajoutez les classes et la configuration de l’utilitaire du Kit de développement logiciel (SDK) Graph dans les instructions du Kit de développement logiciel (SDK) Graph de l’article Utiliser l’API Graph avec ASP.NET CoreBlazor WebAssembly. Spécifiez les étendues User.Read, RoleManagement.Read.Directory et AdministrativeUnit.Read.All du jeton d’accès comme indiqué par l’article dans son exemple de fichier wwwroot/appsettings.json.

Ajoutez la fabrique de compte d’utilisateur personnalisée suivante à l’application. La fabrique d’utilisateur personnalisée est utilisée pour établir :

Revendications de rôle d’application (role) (couvertes dans la section Rôles d’application).
Exemple de revendications de données de profil utilisateur pour le numéro de téléphone mobile de l’utilisateur (mobilePhone) et l’emplacement du bureau (officeLocation).
Revendications de rôle d’administrateur ME-ID (directoryRole).
Revendications de l’unité administrative ME-ID (administrativeUnit).
Revendications de groupe ME-ID (directoryGroup).
Un ILogger (logger) pour plus de commodité dans le cas où vous souhaitez enregistrer des informations ou des erreurs.

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

Le code précédent :

N’inclut pas d’appartenances transitives. Si l’application nécessite des revendications d’appartenance directe et transitive à un groupe, remplacez la propriété MemberOf (IUserMemberOfCollectionWithReferencesRequestBuilder) par TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).
Définit les valeurs GUID dans les revendications directoryRole comme étant des ID de modèle de rôle d’administrateur ME-ID (Microsoft.Graph.Models.DirectoryRole.RoleTemplateId). Les ID de modèle sont des identificateurs stables pour la création de stratégies d’autorisation utilisateur dans les applications, qui est abordée plus loin dans cet article. N’utilisez pas entry.Id pour les valeurs de revendication de rôle d’annuaire, car elles ne restent pas stables d’un locataire à un autre.

Configurez ensuite l’authentification MSAL pour utiliser la fabrique de compte d’utilisateur personnalisée.

Vérifiez que le fichier Program utilise l’espace de noms Microsoft.AspNetCore.Components.WebAssembly.Authentication :

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Mettez à jour l’appel AddMsalAuthentication de la manière suivante. Notez que le RemoteUserAccount de l’infrastructure Blazor est remplacé par le CustomUserAccount de l’application pour l’authentification MSAL et la fabrique principale des revendications de compte :

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

Confirmez la présence du code du kit de développement logiciel Graph SDK dans le fichier Program décrit dans l’article Utiliser l’API Graph avec 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);

Important

Vérifiez dans l’inscription de l’application dans le portail Azure que les autorisations suivantes sont accordées :

User.Read
RoleManagement.Read.Directory (consentement administrateur requis)
AdministrativeUnit.Read.All (consentement administrateur requis)

Vérifiez que la configuration de wwwroot/appsettings.json est correcte conformément aux instructions du kit de développement logiciel 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"
    ]
  }
}

Fournissez des valeurs pour les espaces réservés suivants à partir de l’inscription ME-ID de l’application dans le portail Azure :

{TENANT ID} : valeur GUID de l’ID de l’annuaire (locataire).
{CLIENT ID} : valeur GUID de l’ID de l’application (client).

Configuration de l’autorisation

Créez une stratégie pour chaque rôle d’application (par nom de rôle), rôle d’administrateur intégré ME-ID (par GUID/ID de modèle de rôle) ou groupe de sécurité (par GUID/ID d’objet) dans le fichier Program. L’exemple suivant crée une stratégie pour le rôle Administrateur de facturation intégré ME-ID :

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

Pour obtenir la liste complète des ID (GUID) pour les rôles d’administrateur ME-ID, consultez ID de modèle de rôle dans la documentation ME-ID. Pour obtenir un ID (GUID) de groupe de sécurité Azure ou O365, consultez l’ID d’objet du groupe dans le volet Groupes de l’inscription de l’application dans le portail Azure. Pour plus d’informations sur les politiques d’autorisation, consultez Autorisation basée sur des politiques dans ASP.NET Core.

Dans les exemples suivants, l’application utilise la stratégie précédente pour fournir les autorisations à l’utilisateur.

Le composantAuthorizeView fonctionne avec la politique :

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

L’accès à un composant entier peut être basé sur la politique à l’aide d’une directive d’attribut[Authorize] (AuthorizeAttribute) :

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

Si l’utilisateur n’est pas autorisé, il est redirigé vers la page de connexion ME-ID.

Une vérification de politique peut également être effectuée dans le code avec une logique procédurale.

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

À l’aide des approches précédentes, vous pouvez également créer un accès basé sur des stratégies pour les groupes de sécurité, où le GUID utilisé pour la stratégie correspond à l’ID d’objet du groupe.

Rôles d'application

Pour configurer l’application dans le portail Azure afin de fournir des revendications d’appartenance aux rôles d’application, consultez Ajouter des rôles d’application dans votre application et les recevoir dans le jeton dans la documentation ME-ID.

L’exemple suivant suppose que l’application est configurée avec deux rôles et que les rôles sont attribués à un utilisateur de test :

Admin
Developer

Bien que vous ne puissiez pas attribuer de rôles à des groupes sans compte ME-ID Premium, vous pouvez attribuer des rôles à des utilisateurs et recevoir des revendications de rôle pour des utilisateurs avec un compte Azure standard. Les conseils de cette section ne nécessitent pas de compte ME-ID Premium.

Suivez l’une des approches suivantes pour ajouter des rôles d’application dans ME-ID :

Lorsque vous utilisez l’annuaire par défaut, suivez les instructions décrites dans Ajouter des rôles d’application dans votre application et les recevoir dans le jeton pour créer des rôles ME-ID.
Si vous n’utilisez pas l’annuaire par défaut, modifiez le manifeste de l’application dans le portail Azure pour établir manuellement les rôles de l’application dans l’entrée appRoles du fichier manifeste. Voici un exemple d’entrée appRoles qui crée des rôles Admin et Developer. Ces exemples de rôles sont utilisés par la suite au niveau du composant pour implémenter des restrictions d’accès :

Important

L’approche suivante est recommandée uniquement pour les applications qui ne sont pas inscrites dans l’annuaire par défaut du compte Azure. Pour les applications inscrites dans l’annuaire par défaut, consultez la puce précédente de cette 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"
  }
],
```
Pour les espaces réservés et les {ADMIN GUID} espaces réservés dans l’exemple précédent, vous pouvez générer des GUID avec un générateur GUID en ligne (résultat de recherche Google pour « générateur guid ») .{DEVELOPER GUID}

Pour attribuer un rôle à un utilisateur (ou à un groupe si vous disposez d’un compte Azure de niveau Premium) :

Accédez à applications d’entreprise dans la zone ME-ID du portail Azure.
Sélectionnez l’application. Sélectionnez Gérer>Utilisateurs et groupes dans la barre latérale.
Cochez la case pour un ou plusieurs comptes d’utilisateur.
Dans le menu situé au-dessus de la liste des utilisateurs, sélectionnez Modifier l’affectation.
Pour l’entrée Sélectionner un rôle, sélectionnez Aucun sélectionné.
Choisissez un rôle dans la liste et utilisez le bouton Sélectionner pour le sélectionner.
Utilisez le bouton Attribuer en bas de l’écran pour attribuer le rôle.

Plusieurs rôles sont attribués dans le portail Azure en ajoutant un utilisateur pour chaque attribution de rôle supplémentaire. Utilisez le bouton Ajouter un utilisateur/groupe en haut de la liste des utilisateurs pour rajouter un utilisateur. Utilisez les étapes précédentes pour attribuer un autre rôle à l’utilisateur. Vous pouvez répéter ce processus autant de fois que nécessaire pour ajouter des rôles supplémentaires à un utilisateur (ou un groupe).

Le CustomAccountFactory présent dans la section Compte d’utilisateur personnalisé est configuré pour agir sur une revendication role avec une valeur de tableau JSON. Ajoutez et inscrivez la CustomAccountFactory dans l’application, comme indiqué dans la section Compte d’utilisateur personnalisé. Il n’est pas nécessaire de fournir du code pour supprimer la revendication role d’origine, car elle est automatiquement supprimée par l’infrastructure.

Dans le fichier Program, ajoutez ou confirmez la revendication nommée « role » comme revendication de rôle pour les vérifications ClaimsPrincipal.IsInRole :

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

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

Remarque

Si vous préférez utiliser la revendication directoryRoles (rôles d’administrateur ME-ID), attribuez « directoryRoles » au RemoteAuthenticationUserOptions.RoleClaim.

Une fois que vous avez effectué les étapes précédentes pour créer et attribuer des rôles à des utilisateurs (ou des groupes si vous disposez d’un compte Azure de niveau Premium) et que vous avez implémenté le CustomAccountFactory avec le Kit de développement logiciel (SDK) Graph, comme expliqué plus haut dans cet article et dans Utiliser l’API Graph avec ASP.NET Core Blazor WebAssembly, vous devez voir une revendication role pour chaque rôle attribué auquel un utilisateur connecté est affecté (ou les rôles attribués aux groupes dont il est membre). Exécutez l’application avec un utilisateur de test pour vérifier que les revendications sont présentes comme prévu. Lorsque vous effectuez des tests en local avec le kit de développement logiciel (SDK) Graph, nous vous recommandons d’utiliser une nouvelle session de navigateur privée/incognito pour chaque test afin d’éviter que les cookies persistants n’interfèrent avec les tests. Pour plus d’informations, consultez Sécuriser une application autonome ASP.NET Core Blazor WebAssembly avec Microsoft Entra ID.

Les approches d’autorisation des composants sont fonctionnelles à ce stade. Tous les mécanismes d’autorisation dans les composants de l’application peuvent utiliser le rôle Admin pour fournir des autorisations à l’utilisateur :

Composant AuthorizeView
```
<AuthorizeView Roles="Admin">
```
Directive d’attribut [Authorize] (AuthorizeAttribute)
```
@attribute [Authorize(Roles = "Admin")]
```

Logique procédurale

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

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

Plusieurs tests de rôle sont pris en charge :

Exiger que l’utilisateur soit dans le rôle Admin ou Developer avec le composant AuthorizeView :
```
<AuthorizeView Roles="Admin, Developer">
    ...
</AuthorizeView>
```
Exiger que l’utilisateur soit à la fois dans les rôles Admin et Developer avec le composant AuthorizeView :
```
<AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>
```
Pour plus d'informations sur Context pour le AuthorizeView interne, voir ASP.NET CoreBlazor authentification et autorisation.
Exiger que l’utilisateur soit dans le rôle Admin ou Developer avec l’attribut [Authorize] :
```
@attribute [Authorize(Roles = "Admin, Developer")]
```
Exiger que l’utilisateur soit à la fois dans les rôles Admin et Developer avec l’attribut [Authorize] :
```
@attribute [Authorize(Roles = "Admin")]
@attribute [Authorize(Roles = "Developer")]
```

Exiger que l’utilisateur soit dans le rôle Admin ou Developer avec du code procédural :

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

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

Exiger que l’utilisateur soit à la fois dans les rôles Admin et Developer avec du code procédural en remplaçant le conditionnel OU (||) par un conditionnel ET (&&) dans l’exemple précédent :
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
```

Plusieurs tests de rôle sont pris en charge :

Exiger que l’utilisateur soit dans le rôle Admin ou Developer avec l’attribut [Authorize] :
```
[Authorize(Roles = "Admin, Developer")]
```
Exiger que l’utilisateur soit à la fois dans les rôles Admin et Developer avec l’attribut [Authorize] :
```
[Authorize(Roles = "Admin")]
[Authorize(Roles = "Developer")]
```

Exiger que l’utilisateur soit dans le rôle Admin ou Developer avec du code procédural :

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

Exiger que l’utilisateur soit à la fois dans les rôles Admin et Developer avec du code procédural en remplaçant le conditionnel OU (||) par un conditionnel ET (&&) dans l’exemple précédent :
```
if (User.IsInRole("Admin") && User.IsInRole("Developer"))
```

Étant donné que les comparaisons de chaînes .NET sont sensibles à la casse, les noms de rôle correspondants sont également sensibles à la casse. Par exemple, Admin (A majuscule) n’est pas traité comme le même rôle que admin (a minuscule).

La casse Pascal est généralement utilisée pour les noms de rôles (par exemple, BillingAdministrator), mais son utilisation n’est pas une exigence stricte. Différents schémas de casse, tels que la case chameau, la casse kebab et la casse serpent, sont autorisés. L’utilisation d’espaces dans les noms de rôle est également inhabituelle, mais autorisée. Par exemple, billing administrator est un format de nom de rôle inhabituel dans les applications .NET, mais valide.

Partager via

Groupes Microsoft Entra (ME-ID), rôles d’administrateur et rôles d’application

Exemple d’application

Prérequis

Outils en ligne d’inscription pour applications ME-ID

Étendues

Compte d’utilisateur personnalisé

Configuration de l’autorisation

Rôles d'application

Ressources supplémentaires

Ressources supplémentaires