Groupes Microsoft Entra (ME-ID), rôles d’administrateur et rôles d’application (.NET 5 à .NET 7)

Cet article explique comment configurer Blazor WebAssembly pour utiliser des groupes et des rôles Microsoft Entra 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 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 :

• Autonome avec des comptes Microsoft
• Autonome avec ME-ID
• Hébergé avec ME-ID

Les conseils de l’article fournissent des instructions pour les applications clients et serveurs :

• CLIENT : applications autonomes Blazor WebAssembly ou l’application Client d’une solution Blazor hébergée.
• SERVEUR : les applications ASP.NET Core server API/web API ou l’application Server d’une solution Blazor hébergée. Vous pouvez ignorer les conseils SERVEUR tout au long de l’article pour une application Blazor WebAssembly autonome.

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.

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.

Portées

Pour autoriser les appels de l’API Microsoft Graph pour les données de profil utilisateur, d’attribution de rôle et d’appartenance à un groupe :

• Une application CLIENTE est configurée avec l’étendue User.Read déléguée (https://graph.microsoft.com/User.Read) dans le portail Azure, car l’accès aux données utilisateur de lecture est déterminé par les étendues accordées (déléguées) à des utilisateurs individuels.
• Une application SERVEUR est configurée avec l’étendue GroupMember.Read.All de l’application (https://graph.microsoft.com/GroupMember.Read.All) dans le portail Azure, car l’accès est destiné à l’application pour obtenir des informations sur l’appartenance au groupe, et non en fonction de l’autorisation utilisateur individuelle d’accéder aux données relatives aux membres du groupe.

Les étendues précédentes sont requises en plus des étendues requises dans les scénarios de déploiement ME-ID décrits dans les articles répertoriés précédemment (Autonome avec des comptes Microsoft, Autonome avec ME-ID et Hébergé avec ME-ID).

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.

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.

Attribut des revendications d’appartenance à un groupe

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 politiques d’autorisation pour contrôler l’accès au sein des applications CLIENT et SERVEUR .

Dans l’application CLIENT, étendez RemoteUserAccount pour inclure les propriétés pour :

• Roles: tableau des rôles d’application ME-ID (couvert dans la section Rôles d’application )
• Wids: Rôles d’administrateur ME-ID dans revendication d’ID connues (wids)
• 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 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; }
}

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

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 l’étendue User.Read du jeton d’accès comme illustré dans l’article avec son exemple de fichier wwwroot/appsettings.json.

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

• Revendications de rôle d’application (appRole) (couvertes dans la section Rôles d’application).
• Revendications de rôle d’administrateur ME-ID (directoryRole).
• 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 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 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;
    }
}

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

La revendication wids (et donc la revendication directoryRole) avec la valeur b79fbf4d-3ef9-4689-8143-76b194e85509 existe pour les comptes non invités du locataire. Elle ne fait pas référence à un ID de modèle de rôle d’administrateur ME-ID.

Dans l’application CLIENT, configurez 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);
    })
    .AddAccountClaimsPrincipalFactory<RemoteAuthenticationState, CustomUserAccount,
        CustomAccountFactory>();

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

{
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com",
    "Version": "v1.0",
    "Scopes": [
      "user.read"
    ]
  }
}

Configuration de l’autorisation

Dans l'application CLIENT, créez une stratégie pour chaque rôle d'application, rôle d'administrateur ME-ID ou groupe de sécurité 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 pour les rôles d’administrateur ME-ID, consultez ID de modèle de rôle dans la documentation Entra. 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 CLIENT utilise la politique précédente pour autoriser 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 rôles d’application, où le GUID utilisé pour la stratégie est défini dans l’élément appRoles du manifeste de l’application dans le portail Azure, et pour les groupes de sécurité, où le GUID utilisé pour la stratégie correspond à l’ID d’objet du groupe dans le volet Groupes dans le portail Azure.

Autoriser l’accès à l’API serveur/API web

Une application API SERVER peut autoriser les utilisateurs à accéder à des points de terminaison d’API sécurisés avec stratégies d’autorisation pour les groupes de sécurité, les rôles d’administrateur ME-ID et les rôles d’application lorsqu’un jeton d’accès contient les revendications groups, widset role. L'exemple suivant crée une stratégie pour le rôle d'administrateur de facturation ME-ID dans le fichier Program à l'aide des revendications wids (ID bien connus/ID de modèle de rôle) :

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

Pour obtenir la liste complète des ID pour les rôles d’administrateur ME-ID, consultez ID de modèle de rôle dans la documentation Azure. Pour plus d’informations sur les politiques d’autorisation, consultez Autorisation basée sur des politiques dans ASP.NET Core.

L’accès à un contrôleur dans l’application SERVEUR peut être basé sur l’utilisation d’un attribut[Authorize] portant le nom de la politique (documentation de l’API : AuthorizeAttribute).

L’exemple suivant limite l’accès aux données de facturation du BillingDataController aux Administrateurs de facturation Azure avec un nom de politique :BillingAdministrator

using Microsoft.AspNetCore.Authorization;

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

Pour plus d’informations, consultez Autorisation basée sur une stratégie dans ASP.NET Core.

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

L’exemple suivant suppose que les applications CLIENT et SERVEUR sont configurées 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 Microsoft Entra ID Premium, vous pouvez attribuer des rôles aux 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.

Lorsque vous utilisez le répertoire par défaut, suivez les instructions détaillées dans Ajouter des rôles d’application dans votre application et les recevoir dans le jeton pour configurer et attribuer des rôles. Si vous n’utilisez pas le répertoire 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 plus loin dans l’exemple de cette section au niveau du composant pour implémenter des restrictions d’accès :

"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) :

1. Accédez à applications d’entreprise dans la zone ME-ID du portail Azure.
2. Sélectionnez l’application. Sélectionnez Gérer>Utilisateurs et groupes dans la barre latérale.
3. Cochez la case pour un ou plusieurs comptes d’utilisateur.
4. Dans le menu situé au-dessus de la liste des utilisateurs, sélectionnez Modifier l’affectation.
5. Pour l’entrée Sélectionner un rôle, sélectionnez Aucun sélectionné.
6. Choisissez un rôle dans la liste et utilisez le bouton Sélectionner pour le sélectionner.
7. 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 le CustomAccountFactory dans l’application CLIENT, 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 d'une application CLIENT, précisez la revendication nommée "appRole" comme revendication de rôle pour les contrôles ClaimsPrincipal.IsInRole :

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

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

Dans le fichier Program d'une application SERVEUR, spécifiez la revendication nommée "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" comme revendication de rôle pour les contrôles ClaimsPrincipal.IsInRole :

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

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 appRole 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 la ou 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 CLIENT peuvent utiliser le rôle Admin pour autoriser 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"))
  

Tous les mécanismes d’autorisation dans les contrôleurs de l’application SERVEUR peuvent utiliser le rôle Admin pour autoriser l’utilisateur :

• Directive d’attribut[Authorize] (AuthorizeAttribute)

  [Authorize(Roles = "Admin")]
  

• Logique procédurale

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

Ressources supplémentaires

• ID de modèle de rôle (documentation Entra)
• Attribut groupMembershipClaims (documentation Entra)
• Ajouter des rôles d’application dans votre application et les recevoir dans le jeton (documentation Entra)
• Rôles d’application (documentation Azure)
• Autorisation basée sur les revendications dans ASP.NET Core
• Autorisation basée sur les rôles dans ASP.NET Core
• Authentification et autorisation avec ASP.NET Core Blazor