Группы Microsoft Entra (ME-ID), роли администратора и роли приложений (.NET 5 до .NET 7)

Статья
11/12/2024

Примечание.

Это не последняя версия этой статьи. Сведения о текущем выпуске ASP.NET Core см. в последней версии ASP.NET Core Blazor WebAssembly с группами и ролями идентификаторов Microsoft Entra.

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

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

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

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

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

Клиент: отдельные приложения Blazor WebAssembly или приложение Client размещенного Blazorрешения .
SERVER: ASP.NET основные приложения API сервера или веб-API или Server приложение размещенного Blazor решения. Инструкции ПО 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 областью () в портал Azure так как доступ к данным пользователя определяется областями, предоставленными (https://graph.microsoft.com/User.Readделегированными) отдельным пользователям.
Приложение SERVER настраивается с областью приложения GroupMember.Read.All (https://graph.microsoft.com/GroupMember.Read.All) в портал Azure так как доступ предназначен для получения сведений о членстве в группах, а не на основе авторизации отдельных пользователей для доступа к данным о членах группы.

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

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

Разрешения и области означают то же самое и используются взаимозаменяемо в документации по безопасности и портал Azure. Если текст не ссылается на портал Azure, в этой статье используются /области областей при обращении к разрешениям Graph.

Области являются нечувствительными к регистру, поэтому User.Read они совпадают user.read. Вы можете использовать любой формат, но мы рекомендуем согласованный выбор в коде приложения.

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

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

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

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

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

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

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

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

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

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

Roles: массив ролей приложений ME-ID (в разделе "Роли приложений ")
Wids: роли администратора ME-ID в утверждениях известных идентификаторов (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рассматриваются в разделе " Роли приложений ").
Утверждения роли администратора ME-ID (directoryRole).
Пример утверждений данных профиля пользователя для номера мобильного телефона пользователя (mobilePhone) и расположения офиса (officeLocation).
Утверждения группы ME-ID (directoryGroup).
logger(ILogger) для удобства в случае, если вы хотите регистрировать сведения или ошибки.

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

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

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

Утверждение wids (и таким образом directoryRole утверждение) со значением b79fbf4d-3ef9-4689-8143-76b194e85509 существует для не гостевых учетных записей клиента. Он не ссылается на идентификатор шаблона роли администратора ME-ID.

В клиентском приложении настройте проверку подлинности 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"] ??
            "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);

wwwroot/appsettings.json:

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

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

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

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

Полный список идентификаторов для ролей администратора ME-ID см. в документации по шаблонам ролей. Дополнительные сведения о политиках авторизации см. в статье Авторизация на основе политик в 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.";
        }
    }
}

Используя приведенные выше подходы, можно также создать доступ на основе политик для ролей приложения, где GUID, используемый для политики, задается в элементе манифеста приложения в appRoles портал Azure и группах безопасности, где GUID, используемый для политики, соответствует идентификатору объекта группы в области групп портал Azure Групп.

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

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

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

Полный список идентификаторов ролей администратора ME-ID см. в документации 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 приложения или пары автономных приложений (автономного Blazor WebAssembly приложения и приложения ASP.NET core server API или веб-APIappRoles), свойство манифеста как клиента, так и сервера, портал Azure регистрации приложений, должно включать те же настроенные роли. Установив роли в манифесте клиентского приложения, скопируйте их целиком в манифест серверного приложения. Если вы не отражаете манифест appRoles между регистрацией клиентских и серверных приложений, утверждения роли не устанавливаются для прошедших проверку подлинности пользователей серверного API или веб-API, даже если их маркер доступа содержит правильные записи в утверждениях роли.

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

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

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

{ADMIN GUID} {DEVELOPER GUID} Для заполнителей, приведенных в предыдущем примере, можно создать идентификаторы GUID с помощью генератора GUID в Интернете (результат поиска Google для "генератор guid") .

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

Перейдите к корпоративным приложениям в области "ME-ID" портал Azure.
Выберите приложение. Выберите "Управление пользователями и группами>" на боковой панели.
Установите флажок для одной или нескольких учетных записей пользователей.
В меню над списком пользователей выберите "Изменить назначение".
Для записи "Выбор роли" выберите "Нет".
Выберите роль из списка и нажмите кнопку "Выбрать ", чтобы выбрать ее.
Нажмите кнопку "Назначить " в нижней части экрана, чтобы назначить роль.

На портале 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, но допустимый.

Поделиться через

Группы Microsoft Entra (ME-ID), роли администратора и роли приложений (.NET 5 до .NET 7)

Предварительные требования

Области

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

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

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

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

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

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

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