Группы Microsoft Entra (ME-ID), роли Администратор istrator и роли приложения

В этой статье объясняется, как настроить Blazor WebAssembly использование групп и ролей идентификаторов Microsoft Entra.

Microsoft Entra (ME-ID) предоставляет несколько подходов авторизации, которые можно объединить с ASP.NET Core Identity:

• Группы
  • Безопасность
  • Microsoft 365
  • Распределение
• Роли
  • Роли Администратор istrator ME-ID
  • Роли приложения

Рекомендации, описанные в этой статье, относятся к Blazor WebAssembly сценариям развертывания ME-ID, описанным в следующих разделах:

• Автономное развертывание с помощью учетных записей Майкрософт
• Автономный с идентификатором ME-ID

В этой статье приведены инструкции для клиентских и серверных приложений.

• КЛИЕНТ: автономные Blazor WebAssembly приложения.
• SERVER: ASP.NET основные приложения API сервера или веб-API. Инструкции ПО SERVER можно игнорировать в статье для автономного Blazor WebAssembly приложения.

Примеры, приведенные в этой статье, используют новые функции .NET/C#. При использовании примеров с .NET 7 или более ранней версией требуются незначительные изменения. Однако примеры текста и кода, относящиеся к взаимодействию с ME-ID и Microsoft Graph, одинаковы для всех версий ASP.NET Core.

Необходимые условия

В этой статье описано, как реализовать API Microsoft Graph для каждого руководства по пакету SDK Graph в руководстве по использованию API Graph с ASP.NET Core Blazor WebAssembly. Следуйте инструкциям по реализации пакета SDK Graph, чтобы настроить приложение и проверить его, чтобы убедиться, что приложение может получить данные API Graph для тестовой учетной записи пользователя. Кроме того, ознакомьтесь со статьей по безопасности API Graph, чтобы ознакомиться с концепциями безопасности Microsoft Graph.

При локальном тестировании с помощью пакета SDK Graph рекомендуется использовать новый сеанс браузера in-private/incognito для каждого теста, чтобы предотвратить cookieпомехи тестам. Дополнительные сведения см. в статье "Защита автономного приложения ASP.NET Core Blazor WebAssembly с помощью идентификатора Microsoft Entra.

Области

Чтобы разрешить вызовы API Microsoft Graph для профиля пользователя, назначения ролей и данных членства в группах:

• Клиентское приложение настроено с делегированнымUser.Read область (https://graph.microsoft.com/User.Read) в портал Azure, так как доступ к данным пользователя определяется предоставленными область (делегированными) отдельным пользователям.
• Приложение SERVER настроено с помощью приложенияGroupMember.Read.All область (https://graph.microsoft.com/GroupMember.Read.All) в портал Azure, так как доступ предназначен для приложения для получения сведений о членстве в группах, а не на основе авторизации отдельных пользователей для доступа к данным о членах группы.

Предыдущие область требуются в дополнение к область, необходимым в сценариях развертывания ME-ID, описанных в разделах, перечисленных ранее (автономный с учетными записями Майкрософт или автономными с me-ID).

Дополнительные сведения см. в разделе "Обзор разрешений и согласия" в платформа удостоверений Майкрософт и обзоре разрешений Microsoft Graph.

Примечание.

Слова "разрешение" и "область" являются взаимозаменяемыми в контексте портала Azure, а также разных наборов документации Майкрософт и сторонней документации. В этой статье для всех разрешений, назначенных приложению на портале Azure, используется слово "область".

Атрибут утверждений членства в группах

В манифесте приложения на портале Azure для клиентского и серверного приложений установите для атрибута groupMembershipClaims значение All. Значение All результатов в me-ID отправляет все группы безопасности, группы рассылки и роли пользователя, выполнившего вход в систему, в утверждении известных идентификаторов (wids):

1. Откройте регистрацию приложения на портале Azure.
2. Выберите Управление>Манифест на панели сбоку.
3. Найдите атрибут groupMembershipClaims.
4. Задайте для значения All ("groupMembershipClaims": "All").
5. Нажмите кнопку "Сохранить", если вы внесли изменения.

Настраиваемая учетная запись пользователя

Назначьте пользователей группам безопасности ME-ID и ролям Администратор istrator в портал Azure.

Примеры в этой статье:

• Предположим, что пользователю назначена роль Администратор istrator для выставления счетов me-ID в клиенте портал Azure ME-ID для авторизации для доступа к данным API сервера.
• Используйте политики авторизации для управления доступом в клиентском и серверном приложении.

В клиентском приложении обновите RemoteUserAccount, чтобы включить свойства для:

• Roles: массив ролей приложений ME-ID (в разделе "Роли приложений ")
• Wids: me-ID Администратор istrator Role in well-known IDs claim (wids)
• Oid: неизменяемое утверждение идентификатора объекта () (oidоднозначно идентифицирует пользователя внутри и между клиентами)

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

Добавьте ссылку на пакет в приложение CLIENT для Microsoft.Graph:

Примечание.

Рекомендации по добавлению пакетов в приложения .NET см. в разделе Способы установки пакетов NuGet в статье Рабочий процесс использования пакета (документация по NuGet). Проверьте правильность версий пакета на сайте NuGet.org.

Добавьте служебные классы и конфигурацию пакета SDK Graph в руководство по использованию API Graph с ASP.NET ОсновнойBlazor WebAssemblyстатьей. User.Read Укажите область для маркера доступа, как показано в статье в примере wwwroot/appsettings.json файла.

Добавьте следующую настраиваемую фабрику учетных записей пользователей в клиентское приложение. Эта фабрика используется для установки:

• Утверждения роли приложения () (appRoleрассматриваются в разделе " Роли приложений ").
• Утверждения роли Администратор istrator me-ID (directoryRole).
• Пример утверждений данных профиля пользователя для номера мобильного телефона пользователя (mobilePhone) и расположения офиса (officeLocation).
• Утверждения группы ME-ID (directoryGroup).
• logger(ILogger) для удобства в случае, если вы хотите регистрировать сведения или ошибки.

CustomAccountFactory.cs:

В следующем примере предполагается, что файл параметров приложения проекта содержит запись для базового URL-адреса:

{
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com/{VERSION}",
    ...
  }
}

В предыдущем примере заполнитель — это версия API MS Graph (например: {VERSION}v1.0).

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(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 = 
        config.GetSection("MicrosoftGraph")["BaseUrl"];

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

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(IAccessTokenProviderAccessor accessor,
        IServiceProvider serviceProvider,
        ILogger<CustomAccountFactory> logger)
    : AccountClaimsPrincipalFactory<CustomUserAccount>(accessor)
{
    private readonly ILogger<CustomAccountFactory> logger = logger;
    private readonly IServiceProvider serviceProvider = serviceProvider;

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

Приведенный выше код не включает в себя транзитивные членства. Если приложению требуются прямые и транзитивные утверждения членства в группах, замените свойство MemberOf (IUserMemberOfCollectionWithReferencesRequestBuilder) на TransitiveMemberOf (IUserTransitiveMemberOfCollectionWithReferencesRequestBuilder).

Предыдущий код игнорирует утверждения о членстве в группах (), которые являются идентификаторами Администратор istrator Role (groups#microsoft.graph.directoryRoletype), так как значения GUID, возвращаемые платформа удостоверений Майкрософт являются идентификаторами сущностей роли me-ID Администратор istrator Role, а не идентификаторами шаблонов ролей. Идентификаторы сущностей не стабильны для клиентов в платформа удостоверений Майкрософт и не должны использоваться для создания политик авторизации для пользователей в приложениях. Всегда используйте идентификаторы шаблонов ролей для ролей me-ID Администратор istrator, предоставляемых утверждениямиwids.

В клиентском приложении настройте проверку подлинности MSAL для использования фабрики пользовательских учетных записей.

Убедитесь, что Program файл использует Microsoft.AspNetCore.Components.WebAssembly.Authentication пространство имен:

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

AddMsalAuthentication Обновите вызов следующим образом. Обратите внимание, что Blazor платформа RemoteUserAccount заменена приложением CustomUserAccount для проверки подлинности MSAL и фабрики утверждений учетной записи:

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

Убедитесь, что наличие кода пакета SDK Graph, описанного API Use Graph, с ASP.NET основной Blazor WebAssembly статьей и правильной конфигурацией в соответствии с руководством по пакету SDK Graph:wwwroot/appsettings.json

var baseUrl = string.Join("/", 
    builder.Configuration.GetSection("MicrosoftGraph")["BaseUrl"], 
    builder.Configuration.GetSection("MicrosoftGraph")["Version"]);
var scopes = builder.Configuration.GetSection("MicrosoftGraph:Scopes")
    .Get<List<string>>();

builder.Services.AddGraphClient(baseUrl, scopes);

wwwroot/appsettings.json:

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

Настройка авторизации

В клиентском приложении создайте политику для каждой роли приложения, me-ID Администратор istrator Role или группы безопасности в Program файле. В следующем примере создается политика для роли выставления счетов по идентификатору ME-ID Администратор istrator:

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

Полный список идентификаторов для ролей me-ID Администратор istrator см. в документации по шаблонам ролей ролей. Дополнительные сведения о политиках авторизации см. в статье Авторизация на основе политик в ASP.NET Core.

В следующих примерах клиентское приложение использует предыдущую политику для авторизации пользователя.

С политикой работает компонентAuthorizeView:

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

Доступ ко всему компоненту может основываться на политике, использующей директиву атрибута [Authorize] (AuthorizeAttribute):

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

Если пользователь не авторизован, он перенаправляется на страницу входа ME-ID.

Проверку политики можно также выполнять в коде с помощью процедурной логики.

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

Авторизация доступа к API и веб-API сервера

Приложение API SERVER может авторизовать пользователей для доступа к защищенным конечным точкам API с помощью политик авторизации для групп безопасности, ролей Администратор istrator ME-ID и ролей приложений при наличии widsgroupsмаркера доступа и role утверждений. В следующем примере создается политика для роли выставления счетов за идентификаторы me-ID Администратор istrator в Program файле с помощью wids утверждений (известные идентификаторы и идентификаторы шаблонов ролей):

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

Полный список идентификаторов для ролей me-ID Администратор istrator см. в документации По шаблонам ролей Azure. Дополнительные сведения о политиках авторизации см. в статье Авторизация на основе политик в ASP.NET Core.

Доступ к контроллеру в серверном приложении может быть основан на использовании атрибута [Authorize] с именем политики (документация по API: AuthorizeAttribute).

Следующий пример ограничивает доступ к данным выставления счетов с BillingDataController для администраторов выставления счетов Azure с использованием имени политики BillingAdministrator:

using Microsoft.AspNetCore.Authorization;

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

Дополнительные сведения см. в статье Авторизация на основе политик в ASP.NET Core.

Роли приложения

Чтобы настроить приложение в портал Azure для предоставления утверждений о членстве в ролях приложений, см. статью "Добавление ролей приложения в приложение" и их получение в маркере в документации По записи.

В следующем примере предполагается, что клиентское и серверное приложения настроены с помощью двух ролей, а роли назначены тестовому пользователю:

• Admin
• Developer

Примечание.

При разработке пары автономных приложений (автономного Blazor WebAssembly приложения и приложения ASP.NET Core SERVER API/веб-APIappRoles) свойство манифеста как клиента, так и сервера, портал Azure регистрации приложений должно включать те же настроенные роли. Установив роли в манифесте клиентского приложения, скопируйте их целиком в манифест серверного приложения. Если вы не зеркало манифест appRoles между регистрацией клиентских и серверных приложений, утверждения роли не устанавливаются для прошедших проверку подлинности пользователей серверного API/веб-API, даже если их маркер доступа содержит правильные записи в утвержденияхrole.

Хотя вы не можете назначать роли группам без учетной записи Microsoft Entra ID Premium, вы можете назначить роли пользователям и получить утверждение для пользователей со стандартной role учетной записью Azure. В этом разделе не требуется учетная запись ME-ID Premium.

Если у вас есть учетная запись уровня "Премиум" Azure, на боковой панели регистрации приложений портал Azure появится роль управления>приложениями. Следуйте инструкциям в разделе "Добавление ролей приложения в приложение" и получите их в маркере , чтобы настроить роли приложения.

Если у вас нет учетной записи Azure уровня "Премиум", измените манифест приложения в портал Azure. Следуйте указаниям в ролях приложений: реализация , чтобы вручную установить роли приложения в appRoles записи файла манифеста. Сохраните изменения в файле.

Ниже приведен пример appRoles записи, которая создает Admin и Developer роли. Эти примеры ролей используются далее в примере этого раздела на уровне компонента для реализации ограничений доступа:

"appRoles": [
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Administrators manage developers.",
    "displayName": "Admin",
    "id": "584e483a-7101-404b-9bb1-83bf9463e335",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Admin"
  },
  {
    "allowedMemberTypes": [
      "User"
    ],
    "description": "Developers write code.",
    "displayName": "Developer",
    "id": "82770d35-2a93-4182-b3f5-3d7bfe9dfe46",
    "isEnabled": true,
    "lang": null,
    "origin": "Application",
    "value": "Developer"
  }
],

Примечание.

Вы можете создавать идентификаторы GUID с помощью веб-программы генератора GUID (результат поиска Google для "генератор guid").

Чтобы назначить роль пользователю (или группе, если у вас есть учетная запись уровня "Премиум"):

1. Перейдите к корпоративным приложениям в области me-ID портал Azure.
2. Выберите приложение. Выберите "Управление пользователями и группами>" на боковой панели.
3. Выберите проверка box для одной или нескольких учетных записей пользователей.
4. В меню над списком пользователей выберите "Изменить назначение".
5. Для записи "Выбор роли" выберите "Нет".
6. Выберите роль из списка и нажмите кнопку "Выбрать ", чтобы выбрать ее.
7. Нажмите кнопку "Назначить " в нижней части экрана, чтобы назначить роль.

На портале Azure назначается несколько ролей путем повторного добавления пользователей для каждого дополнительного назначения роли. Нажмите кнопку "Добавить пользователя или группу " в верхней части списка пользователей, чтобы повторно добавить пользователя. Используйте описанные выше действия, чтобы назначить пользователю другую роль. Этот процесс можно повторять столько раз, сколько необходимо для добавления дополнительных ролей пользователю (или группе).

Пример CustomAccountFactory из раздела Настраиваемая учетная запись пользователя настраивается для работы в утверждении role со значением массива JSON. Добавьте и зарегистрируйте CustomAccountFactory в клиентском приложении, как показано в разделе Настраиваемая учетная запись пользователя. Нет необходимости предоставлять код для удаления исходного утверждения role, поскольку оно автоматически удаляется платформой.

Program В файле клиентскогоприложения укажите утверждение с именем "appRole" в качестве утверждения роли для ClaimsPrincipal.IsInRole проверка:

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

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

Примечание.

Если вы предпочитаете использовать утверждение directoryRoles (роли администратора AAD), назначьте directoryRoles для RemoteAuthenticationUserOptions.RoleClaim.

Program В файле приложения SERVER укажите утверждение с именем "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" в качестве утверждения роли для 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); });

Примечание.

При регистрации одной схемы проверки подлинности схема проверки подлинности автоматически используется в качестве схемы по умолчанию приложения, и не требуется указать схему или AddAuthentication через нее AuthenticationOptions. Дополнительные сведения см. в разделе "Обзор проверки подлинности ядра" ASP.NET и объявление ASP.NET Core (aspnet/Announcements #490).

Примечание.

Если вы предпочитаете использовать утверждение wids (роли администратора AAD), назначьте wids для TokenValidationParameters.RoleClaimType.

После выполнения описанных выше действий по созданию и назначению ролей пользователям (или группам, если у вас есть учетная запись Azure уровня "Премиум") и реализован CustomAccountFactory пакет SDK Graph, как описано ранее в этой статье, и в разделе "Использование API Graph с ASP.NET Core Blazor WebAssembly", должно появиться appRole утверждение для каждой назначенной роли, назначаемой пользователем (или ролям, назначенным группам, в которых они являются членами). Запустите приложение с тестовой пользователем, чтобы убедиться, что утверждения присутствуют должным образом. При локальном тестировании с помощью пакета SDK Graph рекомендуется использовать новый сеанс браузера in-private/incognito для каждого теста, чтобы предотвратить cookieпомехи тестам. Дополнительные сведения см. в статье "Защита автономного приложения ASP.NET Core Blazor WebAssembly с помощью идентификатора Microsoft Entra.

На этом этапе можно применять подходы с авторизацией компонентов. Любой из механизмов авторизации в компонентах клиентского приложения может использовать роль Admin для авторизации пользователя:

• Компонент AuthorizeView

  <AuthorizeView Roles="Admin">
  

• Директива атрибута [Authorize] (AuthorizeAttribute)

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

• Процедурная логика

  var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
  var user = authState.User;
  
  if (user.IsInRole("Admin")) { ... }
  

Поддерживается тестирование с использованием нескольких ролей:

• Требовать, чтобы пользователь имел одну из ролей: AdminилиDeveloper при использовании компонента AuthorizeView:

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

• Требовать, чтобы пользователь имел обе роли: AdminиDeveloper при использовании компонента AuthorizeView:

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

  Дополнительные сведения о внутренней AuthorizeViewсреде см. в Context разделе ASP.NET Проверка подлинности и авторизация CoreBlazor.

• Требовать, чтобы пользователь имел одну из ролей: AdminилиDeveloper при использовании атрибута [Authorize]:

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

• Требовать, чтобы пользователь имел обе роли: AdminиDeveloper при использовании атрибута [Authorize]:

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

• Требовать, чтобы пользователь имел одну из ролей: AdminилиDeveloper при использовании процедурного кода:

  @code {
      private async Task DoSomething()
      {
          var authState = await AuthenticationStateProvider
              .GetAuthenticationStateAsync();
          var user = authState.User;
  
          if (user.IsInRole("Admin") || user.IsInRole("Developer"))
          {
              ...
          }
          else
          {
              ...
          }
      }
  }
  

• Требовать, чтобы пользователь имел обе роли: AdminиDeveloper при использовании процедурного кода, изменив условное ИЛИ (||) на условное И (&&) в предыдущем примере:

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

Любой из механизмов авторизации в контроллерах серверного приложения может использовать роль Admin для авторизации пользователя:

• Директива атрибута [Authorize] (AuthorizeAttribute)

  [Authorize(Roles = "Admin")]
  

• Процедурная логика

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

Поддерживается тестирование с использованием нескольких ролей:

• Требовать, чтобы пользователь имел одну из ролей: AdminилиDeveloper при использовании атрибута [Authorize]:

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

• Требовать, чтобы пользователь имел обе роли: AdminиDeveloper при использовании атрибута [Authorize]:

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

• Требовать, чтобы пользователь имел одну из ролей: AdminилиDeveloper при использовании процедурного кода:

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

• Требовать, чтобы пользователь имел обе роли: AdminиDeveloper при использовании процедурного кода, изменив условное ИЛИ (||) на условное И (&&) в предыдущем примере:

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

Так как сравнения строк .NET по умолчанию чувствительны к регистру, соответствующие имена ролей также учитывает регистр. Например, (верхний регистрA) не рассматривается как та же роль, Admin что admin и (строчная).a

Регистр Pascal обычно используется для имен ролей (например, BillingAdministrator), но использование регистра Pascal не является строгим требованием. Разрешены различные схемы регистра, такие как верблюдьи случаи, кебаб и змеиный случай. Использование пробелов в именах ролей также является необычным, но разрешенным. Например, billing administrator это необычный формат имени роли в приложениях .NET, но допустимый.

Дополнительные ресурсы

• Идентификаторы шаблонов ролей (документация по Записи)
• groupMembershipClaims атрибут (документация по Entra)
• Добавление ролей приложения в приложение и их получение в токене (документация по Entra)
• Роли приложения (документация по Azure)
• Авторизация на основе утверждений в ASP.NET Core
• Авторизация на основе ролей в ASP.NET Core
• Проверка подлинности и авторизация в Blazor ASP.NET Core