Gruppi di Microsoft Entra (ME-ID), ruoli di amministratore e ruoli dell'app

Articolo
11/12/2024

Nota

Questa non è la versione più recente di questo articolo. Per la versione corrente, vedere la versione .NET 9 di questo articolo.

Importante

Queste informazioni si riferiscono a un prodotto non definitive che può essere modificato in modo sostanziale prima che venga rilasciato commercialmente. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.

Per la versione corrente, vedere la versione .NET 9 di questo articolo.

Questo articolo illustra come configurare Blazor WebAssembly per l'uso di gruppi e ruoli di Microsoft Entra ID (ME-ID).

ME-ID offre diversi approcci di autorizzazione che possono essere combinati con ASP.NET Core Identity:

Gruppi
- Sicurezza
- Microsoft 365
- Distribuzione
Ruoli
- Ruoli di amministratore predefiniti dell'ID ME
- Ruoli dell'app

Le indicazioni contenute in questo articolo si applicano agli Blazor WebAssembly scenari di distribuzione ME-ID descritti negli articoli seguenti:

Gli esempi in questo articolo sfruttano le nuove funzionalità di .NET/C#. Quando si usano gli esempi con .NET 7 o versioni precedenti, sono necessarie modifiche secondarie. Tuttavia, gli esempi di testo e codice relativi all'interazione con ME-ID e Microsoft Graph sono gli stessi per tutte le versioni di ASP.NET Core.

Esempio di app

Accedere all'app di esempio, denominata BlazorWebAssemblyEntraGroupsAndRoles, tramite la cartella della versione più recente dalla radice del repository con il collegamento seguente. L'esempio viene fornito per .NET 8 o versione successiva. Per informazioni su come eseguire l'app, vedere il file dell'app di README esempio.

L'app di esempio include un UserClaims componente per la visualizzazione delle attestazioni di un utente. Il UserData componente visualizza le proprietà dell'account di base dell'utente.

Visualizzare o scaricare il codice di esempio (procedura per il download)

Prerequisito

Le indicazioni contenute in questo articolo implementano l'API Microsoft Graph per le linee guida di Graph SDK in Usare l'API Graph con ASP.NET CoreBlazor WebAssembly. Seguire le indicazioni sull'implementazione di Graph SDK per configurare l'app e testarla per verificare che l'app possa ottenere i dati dell'API Graph per un account utente di test. Vedere anche l'articolo sulla sicurezza dell'articolo sulla sicurezza dell'API Graph tra collegamenti per esaminare i concetti di sicurezza di Microsoft Graph.

Quando si esegue il test con Graph SDK in locale, è consigliabile usare una nuova sessione del browser in incognito/privata per ogni test per impedire che i cookie persistenti interferiscano con i test. Per altre informazioni, vedere Proteggere un'app autonoma di ASP.NET Core Blazor WebAssembly con Microsoft Entra ID.

Strumenti online di registrazione dell'app ME-ID

Questo articolo si riferisce al portale di Azure durante la richiesta di configurare la registrazione dell'app ME-ID dell'app, ma l'interfaccia di amministrazione di Microsoft Entra è anche un'opzione valida per la gestione delle registrazioni dell'app ME-ID. È possibile usare entrambe le interfacce, ma le indicazioni contenute in questo articolo illustrano in modo specifico i movimenti per il portale di Azure.

Ambiti

Le autorizzazioni e gli ambiti indicano la stessa cosa e vengono usati in modo intercambiabile nella documentazione di sicurezza e nella portale di Azure. A meno che il testo non faccia riferimento alla portale di Azure, questo articolo usa ambiti di ambito/ quando si fa riferimento alle autorizzazioni graph.

Gli ambiti non fanno distinzione tra maiuscole e minuscole, quindi User.Read equivale a user.read. È possibile usare entrambi i formati, ma è consigliabile scegliere in modo coerente il codice dell'applicazione.

Per consentire le chiamate all'API Microsoft Graph per i dati di profilo utente, assegnazione di ruolo e appartenenza a gruppi, l'app viene configurata con l'ambito delegato User.Read (https://graph.microsoft.com/User.Read) nella portale di Azure perché l'accesso ai dati utente in lettura è determinato dagli ambiti concessi (delegati) ai singoli utenti. Questo ambito è necessario oltre agli ambiti necessari negli scenari di distribuzione ME-ID descritti negli articoli elencati in precedenza (autonomo con account Microsoft o autonomo con ME-ID).

Altri ambiti obbligatori includono:

Ambito delegato RoleManagement.Read.Directory (https://graph.microsoft.com/RoleManagement.Read.Directory): consente all'app di leggere le impostazioni di controllo degli accessi in base al ruolo per la directory della società, per conto dell'utente connesso. Sono inclusi la lettura dei modelli di ruolo della directory, dei ruoli della directory e delle appartenenze. Le appartenenze ai ruoli della directory vengono usate per creare directoryRole attestazioni nell'app per i ruoli di amministratore predefiniti dell'ID ME. Il consenso dell'amministratore è obbligatorio.
Ambito delegato AdministrativeUnit.Read.All (https://graph.microsoft.com/AdministrativeUnit.Read.All): consente all'app di leggere le unità amministrative e l'appartenenza alle unità amministrative per conto dell'utente connesso. Queste appartenenze vengono usate per creare administrativeUnit attestazioni nell'app. Il consenso dell'amministratore è obbligatorio.

Per altre informazioni, vedere Panoramica delle autorizzazioni e del consenso nella piattaforma Microsoft identity e Panoramica delle autorizzazioni di Microsoft Graph.

Account utente personalizzato

Assegnare gli utenti ai gruppi di sicurezza ME-ID e ai ruoli di amministratore ME-ID nella portale di Azure.

Gli esempi in questo articolo:

Si supponga che un utente sia assegnato al ruolo Amministratore fatturazione ME-ID nel tenant portale di Azure ME-ID per l'autorizzazione ad accedere ai dati dell'API del server.
Usare i criteri di autorizzazione per controllare l'accesso all'interno dell'app.

Estendere RemoteUserAccount per includere le proprietà per:

Roles: matrice ruoli app ME-ID (descritta nella sezione Ruoli app)
Oid: attestazione dell'identificatore di oggetto non modificabile () (oididentifica in modo univoco un utente all'interno e tra i tenant)

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

Aggiungere un riferimento al pacchetto all'app per Microsoft.Graph.

Nota

Per indicazioni sull'aggiunta di pacchetti alle app .NET, vedere gli articoli sotto Installare e gestire pacchetti in Flusso di lavoro dell'utilizzo di pacchetti (documentazione di NuGet). Confermare le versioni corrette del pacchetto all'indirizzo NuGet.org.

Aggiungere le classi di utilità e la configurazione di Graph SDK nelle linee guida per Graph SDK dell'articolo Usare l'API Graph con ASP.NET Core Blazor WebAssembly . Specificare gli User.Readambiti , RoleManagement.Read.Directorye AdministrativeUnit.Read.All per il token di accesso come illustrato nell'articolo nel relativo file di esempio wwwroot/appsettings.json .

Aggiungere la factory dell'account utente personalizzata seguente all'app. La factory utente personalizzata viene usata per stabilire:

Attestazioni del ruolo app () (roledescritte nella sezione Ruoli app).
Attestazioni di dati del profilo utente di esempio per il numero di telefono cellulare dell'utente (mobilePhone) e la posizione dell'ufficio (officeLocation).
Attestazioni del ruolo amministratore ME-ID (directoryRole).
Attestazioni di unità amministrativa ME-ID (administrativeUnit).
Attestazioni del gruppo ME-ID (directoryGroup).
logger(ILogger) per praticità nel caso in cui si desideri registrare informazioni o errori.

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

Il codice precedente:

Non include appartenenze transitive. Se l'app richiede attestazioni di appartenenza diretta e transitiva ai gruppi, sostituire la MemberOf proprietà (IUserMemberOfCollectionWithReferencesRequestBuilder) con TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).
Imposta i valori GUID nelle directoryRole attestazioni sono IDMicrosoft.Graph.Models.DirectoryRole.RoleTemplateId ruolo amministratore ME-ID (). Gli ID modello sono identificatori stabili per la creazione di criteri di autorizzazione utente nelle app, illustrati più avanti in questo articolo. Non usare entry.Id per i valori di attestazione del ruolo della directory, perché non sono stabili tra i tenant.

Configurare quindi l'autenticazione MSAL per usare la factory dell'account utente personalizzata.

Verificare che il Program file usi lo Microsoft.AspNetCore.Components.WebAssembly.Authentication spazio dei nomi :

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Aggiornare la AddMsalAuthentication chiamata al codice seguente. Si noti che il Blazor framework viene sostituito da quello dell'app RemoteUserAccount CustomUserAccount per l'autenticazione MSAL e la factory principale delle attestazioni dell'account:

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

Verificare la presenza del codice graph SDK nel Program file descritto nell'articolo Usare l'API Graph con 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);

Importante

Verificare nella registrazione dell'app nel portale di Azure che siano concesse le autorizzazioni seguenti:

User.Read
RoleManagement.Read.Directory (Richiede il consenso amministratore)
AdministrativeUnit.Read.All (Richiede il consenso amministratore)

Verificare che la wwwroot/appsettings.json configurazione sia corretta in base alle indicazioni di 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"
    ]
  }
}

Specificare i valori per i segnaposto seguenti dalla registrazione ME-ID dell'app nel portale di Azure:

{TENANT ID}: valore GUID ID directory (tenant).
{CLIENT ID}: valore GUID ID applicazione (client).

Configurazione dell'autorizzazione

Creare un criterio per ogni ruolo dell'app (in base al nome del ruolo), ruolo amministratore predefinito ME-ID (per ID modello di ruolo/GUID) o gruppo di sicurezza (per ID oggetto/GUID) nel Program file. L'esempio seguente crea un criterio per il ruolo Amministratore fatturazione predefinito ME-ID:

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

Per l'elenco completo degli ID (GUID) per i ruoli di amministratore ME-ID, vedere ID modello di ruolo nella documentazione di ME-ID. Per una sicurezza di Azure o un ID gruppo di Office 365 (GUID), vedere l'ID oggetto per il gruppo nel riquadro gruppi di portale di Azure della registrazione dell'app. Per altre informazioni sui criteri di autorizzazione, vedere Autorizzazione basata su criteri in ASP.NET Core.

Negli esempi seguenti l'app usa i criteri precedenti per autorizzare l'utente.

Il AuthorizeView componente funziona con i criteri:

<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'accesso a un intero componente può essere basato sui criteri usando una [Authorize] direttiva di attributo (AuthorizeAttribute):

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

Se l'utente non è autorizzato, viene reindirizzato alla pagina di accesso ME-ID.

È anche possibile eseguire un controllo dei criteri nel codice con logica procedurale.

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

Usando gli approcci precedenti, è anche possibile creare l'accesso basato su criteri per i gruppi di sicurezza, in cui il GUID usato per i criteri corrisponde a

Ruoli dell'app

Per configurare l'app nella portale di Azure per fornire attestazioni di appartenenza ai ruoli dell'app, vedere Aggiungere ruoli dell'app all'applicazione e riceverli nel token nella documentazione di ME-ID.

L'esempio seguente presuppone che l'app sia configurata con due ruoli e che i ruoli vengano assegnati a un utente di test:

Admin
Developer

Anche se non è possibile assegnare ruoli ai gruppi senza un account PREMIUM ME-ID, è possibile assegnare ruoli agli utenti e ricevere attestazioni di ruolo per gli utenti con un account Azure standard. Le indicazioni contenute in questa sezione non richiedono un account ME-ID Premium.

Adottare uno degli approcci seguenti per aggiungere i ruoli dell'app in ME-ID:

Quando si usa la directory predefinita, seguire le indicazioni riportate in Aggiungere ruoli dell'app all'applicazione e riceverli nel token per creare i ruoli DELL'ID ME.
Se non si usa la directory predefinita, modificare il manifesto dell'app nel portale di Azure per stabilire manualmente i ruoli dell'app nella appRoles voce del file manifesto. Di seguito è riportata una voce di esempio appRoles che crea Admin e Developer ruoli. Questi ruoli di esempio vengono usati in un secondo momento a livello di componente per implementare le restrizioni di accesso:

Importante

L'approccio seguente è consigliato solo per le app non registrate nella directory predefinita dell'account Azure. Per le app registrate nella directory predefinita, vedere il punto elenco precedente di questo elenco.
```
"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"
  }
],
```
Per i {ADMIN GUID} segnaposto e {DEVELOPER GUID} nell'esempio precedente, è possibile generare GUID con un generatore GUID online (risultato della ricerca Google per "generatore guid").

Per assegnare un ruolo a un utente (o a un gruppo se si ha un account Azure di livello Premium):

Passare ad Applicazioni aziendali nell'area ID ME del portale di Azure.
Seleziona l'app. Selezionare Gestisci>utenti e gruppi dalla barra laterale.
Selezionare la casella di controllo per uno o più account utente.
Dal menu sopra l'elenco degli utenti selezionare Modifica assegnazione.
Per la voce Selezionare un ruolo selezionare Nessuno selezionato.
Scegliere un ruolo dall'elenco e usare il pulsante Seleziona per selezionarlo.
Usare il pulsante Assegna nella parte inferiore della schermata per assegnare il ruolo.

Più ruoli vengono assegnati nel portale di Azure aggiungendo di nuovo un utente per ogni assegnazione di ruolo aggiuntiva. Usare il pulsante Aggiungi utente/gruppo nella parte superiore dell'elenco di utenti per aggiungere nuovamente un utente. Usare i passaggi precedenti per assegnare un altro ruolo all'utente. È possibile ripetere questo processo tutte le volte necessario per aggiungere altri ruoli a un utente (o a un gruppo).

La CustomAccountFactory sezione Account utente personalizzato è configurata per agire su un'attestazione role con un valore di matrice JSON. Aggiungere e registrare CustomAccountFactory nell'app come illustrato nella sezione Account utente personalizzato. Non è necessario fornire codice per rimuovere l'attestazione originale role perché viene rimossa automaticamente dal framework.

Program Nel file aggiungere o confermare l'attestazione denominata "role" come attestazione del ruolo per ClaimsPrincipal.IsInRole i controlli:

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

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

Nota

Se si preferisce usare l'attestazione directoryRoles (ruoli di amministratore ME-ID), assegnare "directoryRoles" a RemoteAuthenticationUserOptions.RoleClaim.

Dopo aver completato i passaggi precedenti per creare e assegnare ruoli agli utenti (o ai gruppi se si dispone di un account Azure di livello Premium) e aver implementato CustomAccountFactory con Graph SDK, come illustrato in precedenza in questo articolo e in Usare l'API Graph con ASP.NET Core Blazor WebAssembly, dovrebbe essere visualizzata un'attestazione role per ogni ruolo assegnato a un utente connesso (o ruoli assegnati a gruppi di cui sono membri). Eseguire l'app con un utente di test per verificare che le attestazioni siano presenti come previsto. Quando si esegue il test con Graph SDK in locale, è consigliabile usare una nuova sessione del browser in incognito/privata per ogni test per impedire che i cookie persistenti interferiscano con i test. Per altre informazioni, vedere Proteggere un'app autonoma di ASP.NET Core Blazor WebAssembly con Microsoft Entra ID.

Gli approcci di autorizzazione dei componenti sono funzionali a questo punto. Uno dei meccanismi di autorizzazione nei componenti dell'app può usare il Admin ruolo per autorizzare l'utente:

AuthorizeView componente
```
<AuthorizeView Roles="Admin">
```
[Authorize] direttiva attribute (AuthorizeAttribute)
```
@attribute [Authorize(Roles = "Admin")]
```

Logica procedurale

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

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

Sono supportati più test di ruolo:

Richiedere che l'utente sia nel Admin ruolo o Developer con il AuthorizeView componente :
```
<AuthorizeView Roles="Admin, Developer">
    ...
</AuthorizeView>
```
Richiedere che l'utente sia in entrambi i Admin ruoli e Developer con il AuthorizeView componente:
```
<AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>
```
Per altre informazioni su per l'interfaccia Context interna, vedere ASP.NET'autenticazione e autorizzazione core Blazor AuthorizeView.
Richiedere che l'utente sia nel Admin ruolo o Developer con l'attributo :[Authorize]
```
@attribute [Authorize(Roles = "Admin, Developer")]
```
Richiedere che l'utente sia in entrambi i ruoli e Developer con l'attributo [Authorize] :Admin
```
@attribute [Authorize(Roles = "Admin")]
@attribute [Authorize(Roles = "Developer")]
```

Richiedere che l'utente sia nel ruolo o Developer con codice Admin procedurale:

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

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

Richiedere che l'utente sia in entrambi i ruoli e Developer con codice procedurale modificando l'OR condizionale (||) in un AND condizionale (&&) nell'esempio precedente:Admin
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
```

Sono supportati più test di ruolo:

Richiedere che l'utente sia nel Admin ruolo o Developer con l'attributo :[Authorize]
```
[Authorize(Roles = "Admin, Developer")]
```
Richiedere che l'utente sia in entrambi i ruoli e Developer con l'attributo [Authorize] :Admin
```
[Authorize(Roles = "Admin")]
[Authorize(Roles = "Developer")]
```

Richiedere che l'utente sia nel ruolo o Developer con codice Admin procedurale:

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

Richiedere che l'utente sia in entrambi i ruoli e Developer con codice procedurale modificando l'OR condizionale (||) in un AND condizionale (&&) nell'esempio precedente:Admin
```
if (User.IsInRole("Admin") && User.IsInRole("Developer"))
```

Poiché i confronti tra stringhe .NET fanno distinzione tra maiuscole e minuscole, anche i nomi dei ruoli corrispondenti fanno distinzione tra maiuscole e minuscole. Ad esempio, Admin (maiuscolo A) non viene considerato come lo stesso ruolo di admin (minuscolo a).

Il caso Pascal viene in genere usato per i nomi dei ruoli ,ad esempio BillingAdministrator, ma l'uso del caso Pascal non è un requisito rigoroso. Sono consentiti diversi schemi di maiuscole e minuscole, come il case camel, il kebab case e il caso serpente. Anche l'uso di spazi nei nomi dei ruoli è insolito ma consentito. Ad esempio, billing administrator è un formato di nome di ruolo insolito nelle app .NET, ma valido.

Condividi tramite

Gruppi di Microsoft Entra (ME-ID), ruoli di amministratore e ruoli dell'app

Esempio di app

Prerequisito

Strumenti online di registrazione dell'app ME-ID

Ambiti

Account utente personalizzato

Configurazione dell'autorizzazione

Ruoli dell'app

Risorse aggiuntive

Risorse aggiuntive