Grupos de Microsoft Entra (ME-ID), Roles de Administrador y Roles de aplicación

Artículo
11/12/2024

Nota:

Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión de .NET 9 de este artículo.

Importante

Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.

Para la versión actual, consulte la versión de .NET 9 de este artículo.

En este artículo se explica cómo configurar Blazor WebAssembly para usar grupos y roles de identificadores de Microsoft Entra ID (ME-ID).

ME-ID proporciona diversos enfoques de autorización que se pueden combinar con ASP.NET Core Identity:

Grupos
- Seguridad
- Microsoft 365
- Distribución
Roles
- Roles de cuenta predefinida de administrador de ME-ID
- Roles de aplicación

La guía de este artículo atañe a los escenarios de implementación Blazor WebAssembly de ME-ID descritos en los siguientes artículos:

Los ejemplos de este artículo aprovechan las nuevas características de .NET/C#. Al usar los ejemplos con .NET 7 o versiones anteriores, se requieren modificaciones menores. Sin embargo, los ejemplos de texto y código que pertenecen a la interacción con ME-ID y Microsoft Graph son los mismos para todas las versiones de ASP.NET Core.

Aplicación de ejemplo

Accede a la aplicación de ejemplo, denominada BlazorWebAssemblyEntraGroupsAndRoles, a través de la carpeta de versión más reciente desde la raíz del repositorio con el vínculo siguiente. El ejemplo se proporciona para .NET 8 o posterior. Consulta el archivo README de la aplicación de ejemplo para ver los pasos sobre cómo ejecutar la aplicación.

La aplicación de ejemplo incluye un componente UserClaims para mostrar las notificaciones de un usuario. El componente UserData muestra las propiedades básicas de la cuenta del usuario.

Consulta o descarga el código de ejemplo (cómo descargarlo)

Requisito previo

La guía de este artículo implementa Microsoft Graph API de acuerdo con la guía del SDK de Graph en Uso de Graph API con Blazor WebAssembly de ASP.NET Core. Sigue la guía de implementación del SDK de Graph para configurar la aplicación y probarla a fin de confirmar que esta puede obtener datos de Graph API para una cuenta de usuario de prueba. Asimismo, consulta los vínculos del artículo de seguridad de Graph API para revisar los conceptos de seguridad de Microsoft Graph.

Al realizar pruebas con el SDK de Graph localmente, te recomendamos que utilices una nueva sesión de explorador privada/de incógnito para cada prueba para evitar que las cookies persistentes interfieran con las pruebas. Para obtener más información, consulta Protección de una aplicación ASP.NET Core Blazor WebAssembly independiente con Microsoft Entra ID.

Herramientas en línea de registro de aplicaciones ME-ID

En este artículo se hace referencia a Azure Portal en todo momento en el que se te pide que configures el registro de aplicaciones ME-ID de la aplicación, pero el Centro de administración Microsoft Entra también es una opción viable para administrar registros de aplicaciones ME-ID. Se puede usar cualquiera de las interfaces, pero la guía de este artículo trata específicamente los gestos de Azure Portal.

Ámbitos

Permisos y ámbitos significan lo mismo y se usan indistintamente en la documentación de seguridad y Azure Portal. A menos que el texto haga referencia a Azure Portal, en este artículo se usan ámbito/ámbitos al hacer referencia a los permisos de Graph.

Los ámbitos no distinguen mayúsculas de minúsculas, por lo que User.Read es igual que user.read. No dudes en usar cualquiera de los formatos, pero se recomienda una opción uniforme en todo el código de aplicación.

Para permitir que la API de Microsoft Graph llame al perfil de usuario, la asignación de roles y los datos de pertenencia, la aplicación se configura con el ámbitoUser.Read (https://graph.microsoft.com/User.Read) delegado en Azure Portal, porque el acceso a la lectura de datos de usuario viene determinado por los ámbitos concedidos (delegados) a los usuarios individuales. Este ámbito es necesario además de los ámbitos requeridos en los escenarios de implementación de ME-ID que describen los temas enumerados anteriormente (Independiente con Cuentas de Microsoft o Independiente con ME-ID).

Entre los ámbitos necesarios adicionales se incluyen:

RoleManagement.Read.Directory ámbito delegado(https://graph.microsoft.com/RoleManagement.Read.Directory): permite a la aplicación leer la configuración del control de acceso basado en rol (RBAC) del directorio de la empresa, en nombre del usuario que ha iniciado sesión. Esto incluye leer plantillas de rol de directorio, roles de directorio y pertenencias. Las pertenencias a roles de directorio se usan para crear notificaciones directoryRole en la aplicación para roles de cuenta predefinida de administrador de ME-ID. Se necesita el consentimiento del administrador.
AdministrativeUnit.Read.All ámbito delegado (https://graph.microsoft.com/AdministrativeUnit.Read.All): permite a la aplicación leer unidades administrativas y pertenencia a unidades administrativas en nombre del usuario que ha iniciado sesión. Estas pertenencias se usan para crear notificaciones administrativeUnit en la aplicación. Se necesita el consentimiento del administrador.

Para obtener más información, consulta Información general sobre los permisos y el consentimiento en la Plataforma de identity de Microsoft e Información general sobre los permisos de Microsoft Graph.

Cuenta de usuario personalizada

Asigna usuarios a grupos de seguridad de ME-ID y Roles de Administrador de ME-ID en Azure Portal.

En los ejemplos de este artículo:

Se supone que un usuario tiene asignado el rol de ME-IDAdministrador de facturación en el suscriptor de Azure Portal ME-ID para que tenga autorización y acceder a los datos de la API del servidor.
Usa las directivas de autorización para controlar el acceso dentro de la aplicación.

Amplía RemoteUserAccount para incluir propiedades para:

Roles: matriz de Roles de aplicación de ME-ID (consulta Roles de aplicación)
Oid: Notificación de identificador de objeto (oid) inmutable (identifica de forma única a un usuario dentro de los inquilinos y entre ellos)

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

Agrega una referencia de paquete a la aplicación para Microsoft.Graph.

Nota:

Para obtener instrucciones sobre cómo agregar paquetes a aplicaciones .NET, consulta los artículos de Instalación y administración de paquetes en Flujo de trabajo de consumo de paquetes (documentación de NuGet). Confirma las versiones correctas del paquete en NuGet.org.

Agrega la configuración y las clases de utilidad del SDK de Graph de la guía del SDK de Graph del artículo Uso de Graph API con Blazor WebAssembly de ASP.NET Core. Especifica los ámbitos User.Read, RoleManagement.Read.Directory y AdministrativeUnit.Read.All para el token de acceso como muestra el artículo en su archivo wwwroot/appsettings.json de ejemplo.

Agrega la siguiente fábrica de cuentas de usuario personalizadas a la aplicación. La fábrica de usuarios personalizada se usa para establecer:

Notificaciones de rol de aplicación (role) (se trata en la sección Roles de aplicación).
Notificaciones de datos de perfil de usuario de ejemplo para el número de teléfono móvil del usuario (mobilePhone) y la ubicación de la oficina (officeLocation).
Notificaciones de Rol de Administrador de ME-ID (directoryRole).
Notificaciones de unidad administrativa de ME-ID (administrativeUnit).
Notificaciones de Grupo de ME-ID (directoryGroup).
Una instancia de ILogger (logger) para mayor comodidad en caso de que quiera registrar información o errores.

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

El código anterior:

No incluye pertenencias transitivas. Si la aplicación requiere notificaciones directas y transitivas de pertenencia a grupos, reemplaza la propiedad MemberOf (IUserMemberOfCollectionWithReferencesRequestBuilder) por TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).
Establece los valores GUID en directoryRole las notificaciones son identificadores de plantilla (Microsoft.Graph.Models.DirectoryRole.RoleTemplateId) de rol Administrador de ME-ID. Los identificadores de plantilla son identificadores estables para crear directivas de autorización de usuario en aplicaciones, que se tratan más adelante en este artículo. No uses entry.Id para los valores de notificación de rol de directorio, ya que no son estables entre inquilinos.

A continuación, configura la autenticación de MSAL para usar la fábrica de cuentas de usuario personalizada.

Confirma que el archivo Program usa el espacio de nombres Microsoft.AspNetCore.Components.WebAssembly.Authentication:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

Actualiza la llamada AddMsalAuthentication a lo siguiente. Ten en cuenta que el elemento RemoteUserAccount del marco de Blazor se reemplaza por el objeto CustomUserAccount de la aplicación para la autenticación de MSAL y la fábrica de entidades de seguridad de notificaciones de cuenta:

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

Confirma la presencia del código de SDK de Graph en el archivo Program descrito por el artículo Uso de Graph API 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

Confirma en el registro de la aplicación en Azure Portal que se conceden los permisos siguientes:

User.Read
RoleManagement.Read.Directory (Se necesita el consentimiento del administrador)
AdministrativeUnit.Read.All (Se necesita el consentimiento del administrador)

Confirma que la configuración wwwroot/appsettings.json es correcta según la guía de SDK de Graph.

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

Proporciona valores para los siguientes marcadores de posición del registro ME-ID de la aplicación en Azure Portal:

{TENANT ID}: valor GUID del Id. de directorio (inquilino).
{CLIENT ID}: es el valor GUID del Id. de aplicación (cliente).

Configuración de autorización

Crea una directiva para cada rol de aplicación (por nombre de rol), rol de cuenta predefinida de administrador de ME-ID (por Id. de plantilla de rol/GUID) o grupo de seguridad (por Id. de objeto/GUID) en el archivo Program. En el siguiente ejemplo se crea una directiva para el rol integrado de Administrador de facturación de ME-ID:

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

Para una lista completa de los identificadores (GUID) de los roles Administrador de ME-ID, consulta la documentación de ME-ID enIdentificadores de plantilla de rol. Para ver un Id. de grupo (GUID) o seguridad de Azure o O365, consulta el Id. de objeto del grupo en el panel Grupos de Azure Portal del registro de la aplicación. Para obtener más información sobre las directivas de autorización, consulta Autorización basada en directivas en ASP.NET Core.

En los siguientes ejemplos, la aplicación usa la directiva anterior para autorizar al usuario.

El componente AuthorizeView funciona con la directiva:

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

El acceso a un componente completo se puede basar en la directiva usando una directiva de atributo [Authorize] (AuthorizeAttribute):

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

Si el usuario no está autorizado, se le redirigirá a la página de inicio de sesión de ME-ID.

También se puede realizar una comprobación de directiva en el código con lógica de procedimientos.

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

Con los enfoques anteriores, también puedes crear acceso basado en directivas para grupos de seguridad, donde el GUID usado para la directiva coincide con

Roles de aplicación

Para configurar la aplicación en Azure Portal para proporcionar notificaciones de pertenencia a roles de aplicación, consulta Incorporación de roles de aplicación a la aplicación y recibirlos en el token de la documentación de ME-ID.

En el siguiente ejemplo se da por supuesto que la aplicación está configurada con dos roles, y que los roles están asignados a un usuario de prueba:

Admin
Developer

Aunque no se pueden asignar roles a grupos sin una cuenta de Microsoft Entra ID Premium, sí se pueden asignar roles a usuarios y recibir una notificación para usuarios con una cuenta de Azure estándar. Las instrucciones de esta sección no requieren una cuenta ME-ID Premium.

Adopta uno de los siguientes enfoques para agregar roles de aplicación en ME-ID:

Cuando trabajes con el directorio predeterminado, sigue la guía en Incorpora roles de aplicación a tu aplicación y recíbelos en el token para crear roles ME-ID.
Si no estás trabajando con el directorio predeterminado, edita el manifiesto de la aplicación en Azure Portal para establecer manualmente los roles de la aplicación en la entrada appRoles del archivo de manifiesto. A continuación, se muestra una entrada appRoles de ejemplo que crea los roles Admin y Developer. Estos roles de ejemplo se usan más adelante en el nivel de componente para implementar restricciones de acceso:

Importante

El siguiente enfoque solo se recomienda para las aplicaciones que no están registradas en el directorio predeterminado de la cuenta de Azure. Para las aplicaciones registradas en el directorio predeterminado, consulta la viñeta anterior de esta lista.
```
"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"
  }
],
```
Para los {ADMIN GUID} marcadores de posición y {DEVELOPER GUID} del ejemplo anterior, puede generar GUID con un generador guid en línea (resultado de búsqueda de Google para "generador guid") .

Para asignar un rol a un usuario (o a un grupo si tiene una cuenta de Azure de nivel Premium):

Ve a Aplicaciones empresariales en el área de ME-ID de Azure Portal.
Selecciona la aplicación. Selecciona Administrar>Usuarios y grupos en la barra lateral.
Selecciona la casilla de una o varias cuentas de usuario.
En el menú situado sobre la lista de usuarios, selecciona Editar asignación.
En la entrada Seleccionar un rol, selecciona Ninguno seleccionado.
Elige un rol de la lista y usa el botón Seleccionar para seleccionarlo.
Usa el botón Asignar situado en la parte inferior de la pantalla para asignar el rol.

Puedes asignar varios roles en Azure Portal volviendo a agregar un usuario en cada asignación de rol adicional. Usa el botón Agregar usuario o grupo en la parte superior de la lista de usuarios para volver a agregar un usuario. Usa los pasos anteriores para asignar otro rol al usuario. Puedes repetir este proceso tantas veces como sea necesario para agregar roles adicionales a un usuario (o grupo).

El valor CustomAccountFactory que se muestra en la sección Cuenta de usuario personalizada se configura para que actúe en una notificación de role con un valor de matriz JSON. Agrega y registra CustomAccountFactory en la aplicación como se muestra en la sección Cuenta de usuario personalizada. No es necesario incluir código para quitar la notificación role original, ya que el marco la quitará automáticamente.

En el archivo Program, agrega o confirma la notificación denominada "role" como notificación de rol para comprobaciones ClaimsPrincipal.IsInRole:

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

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

Nota:

Si prefieres usar la notificación directoryRoles (roles de administrador de ME-ID), asigna "directoryRoles" a RemoteAuthenticationUserOptions.RoleClaim.

Una vez que se hayan completado los pasos anteriores para crear y asignar roles a usuarios (o a grupos si tiene una cuenta de Azure de nivel Premium) y se haya implementado CustomAccountFactory con el SDK de Graph, tal y como se explicó anteriormente en este artículo y en Uso de Graph API con Blazor WebAssembly de ASP.NET Core, deberías ver una notificación de role para cada rol asignado al que se asigna un usuario que ha iniciado sesión (o roles asignados a grupos de los que son miembros). Ejecuta la aplicación con un usuario de prueba para confirmar que las notificaciones están presentes según lo previsto. Al realizar pruebas con el SDK de Graph localmente, te recomendamos que utilices una nueva sesión de explorador privada/de incógnito para cada prueba para evitar que las cookies persistentes interfieran con las pruebas. Para obtener más información, consulta Protección de una aplicación ASP.NET Core Blazor WebAssembly independiente con Microsoft Entra ID.

Los métodos de autorización de componentes son funcionales en este momento. Cualquiera de los mecanismos de autorización de los componentes de la aplicación puede usar el rol Admin para autorizar al usuario:

Componente AuthorizeView
```
<AuthorizeView Roles="Admin">
```
Directiva de atributo [Authorize] (AuthorizeAttribute)
```
@attribute [Authorize(Roles = "Admin")]
```

Lógica de procedimientos

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

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

Se admiten pruebas de rol múltiple:

Requiere que el usuario esté en cualquiera de los roles Admin o Developer con el componente AuthorizeView:
```
<AuthorizeView Roles="Admin, Developer">
    ...
</AuthorizeView>
```
Requiere que el usuario esté en ambos roles Admin y Developer con el componente AuthorizeView:
```
<AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>
```
Para obtener más información sobre el Context del AuthorizeView interno, consulta ASP.NET Core Blazor autenticación y autorización.
Requiere que el usuario esté en cualquiera de los roles Admin o Developer con el atributo [Authorize]:
```
@attribute [Authorize(Roles = "Admin, Developer")]
```

Requiere que el usuario esté en ambos roles Admin y Developer con el atributo [Authorize]:

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

Requiere que el usuario esté en cualquiera de los roles Admin o Developer con el código de procedimientos:

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

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

Requiere que el usuario esté en ambos roles AdminyDeveloper con el código de procedimientos cambiando el OR condicional (||) a un AND condicional (&&) en el ejemplo anterior:
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
```

Se admiten pruebas de rol múltiple:

Requiere que el usuario esté en cualquiera de los roles Admin o Developer con el atributo [Authorize]:
```
[Authorize(Roles = "Admin, Developer")]
```
Requiere que el usuario esté en ambos roles Admin y Developer con el atributo [Authorize]:
```
[Authorize(Roles = "Admin")]
[Authorize(Roles = "Developer")]
```

Requiere que el usuario esté en cualquiera de los roles Admin o Developer con el código de procedimientos:

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

Requiere que el usuario esté en ambos roles AdminyDeveloper con el código de procedimientos cambiando el OR condicional (||) a un AND condicional (&&) en el ejemplo anterior:
```
if (User.IsInRole("Admin") && User.IsInRole("Developer"))
```

Dado que las comparaciones de cadenas de .NET distinguen mayúsculas de minúsculas, los nombres de rol coincidentes también distinguen mayúsculas de minúsculas. Por ejemplo, Admin (A mayúscula) no se trata como el mismo rol que admin (a minúscula).

Normalmente se usa la notación Pascal Case para los nombres de rol (por ejemplo, BillingAdministrator), pero el uso de Pascal Case no es un requisito estricto. Se permiten diferentes notaciones, como la grafía camel, la grafía kebab y la grafía de serpiente (distintos tipos de uso de mayúsculas y minúsculas y separaciones con guiones). El uso de espacios en nombres de roles también es inusual, pero se permite. Por ejemplo, billing administrator es un formato inusual de nombre de rol en aplicaciones de .NET, pero es válido.

Compartir a través de

Grupos de Microsoft Entra (ME-ID), Roles de Administrador y Roles de aplicación

Aplicación de ejemplo

Requisito previo

Herramientas en línea de registro de aplicaciones ME-ID

Ámbitos

Cuenta de usuario personalizada

Configuración de autorización

Roles de aplicación

Recursos adicionales

Recursos adicionales