Microsoft Entra (ME-ID) グループ、管理者ロール、アプリロール (.NET 5 から .NET 7)

[アーティクル]
11/12/2024

Note

これは、この記事の最新バージョンではありません。現在の ASP.NET Core リリースについては、Microsoft Entra ID グループとロールを含む最新バージョンの ASP.NET Core Blazor WebAssembly をご覧ください。

この記事では、Microsoft Entra ID のグループとロールを使用するように Blazor WebAssembly を構成する方法を説明します。

Microsoft Entra (ME-ID) には、ASP.NET Core Identity と組み合わせることができる承認方法がいくつか用意されています。

グループ
- セキュリティ
- Microsoft 365
- 配布
役割
- ME-ID 管理者ロール
- アプリロール

この記事のガイダンスは、次のトピックで説明されている Blazor WebAssembly ME-ID デプロイシナリオに適用されます。

この記事のガイダンスでは、クライアントとサーバーのアプリについて説明します。

クライアント: スタンドアロン Blazor WebAssembly アプリ、またはホストされた Blazorソリューションの Client アプリ。
サーバー: ASP.NET Core サーバー API または Web API アプリ、またはホストされた Blazor ソリューションの Server アプリ。スタンドアロン Blazor WebAssembly アプリについては、記事全体を通してサーバーのガイダンスを無視できます。

この記事の例では、新しい .NET/C# の機能を利用します。この例に .NET 7 以前を使用する場合は、若干の変更が必要です。ただし、ME-ID と Microsoft Graph の操作に関連するテキストとコードの例は、ASP.NET Core のすべてのバージョンで同じです。

前提条件

この記事のガイダンスでは、「ASP.NET Core Blazor WebAssembly で Graph API を使用する」の Graph SDK のガイダンスに従って Microsoft Graph API を実装します。 Graph SDK の実装ガイダンスに従ってアプリを構成し、アプリがテストユーザーアカウントの Graph API データを取得できることをテストして確認します。さらに、Graph API 記事のセキュリティに関する記事のクロスリンクを参照して、Microsoft Graph のセキュリティの概念を確認してください。

Graph SDK をローカル環境でテストする場合は、残っている Cookie がテストに干渉しないよう、テストのたびに新しいプライベートまたはシークレットブラウザーセッションを使うことをお勧めします。詳しくは、「Microsoft Entra ID を使用して、ASP.NET Core Blazor WebAssembly スタンドアロンアプリをセキュリティで保護する」をご覧ください。

スコープ

Microsoft Graph API によるユーザープロファイル、ロールの割り当て、グループメンバーシップデータの呼び出しを許可するには:

クライアント アプリは、Azure portal で "委任された" User.Read スコープ (https://graph.microsoft.com/User.Read) を使用して構成されます。これは、ユーザーデータの読み取りアクセス権は個々のユーザーに付与 (委任) されたスコープによって決まるためです。
サーバー アプリは、Azure portal で "アプリケーション" GroupMember.Read.All スコープ (https://graph.microsoft.com/GroupMember.Read.All) を使用して構成されます。これは、アクセスはアプリがグループメンバーシップに関する情報を取得するために行われ、グループメンバーに関するデータにアクセスするための個々のユーザー承認に基づかないことが理由です。

上記のスコープが、前述の記事で説明した ME-ID のデプロイシナリオで必要なスコープ (「Microsoft アカウントによるスタンドアロン」、「ME-ID によるスタンドアロン」、「ME-ID によるホスティング」) に加えて必要です。

詳細については、「Microsoft identity プラットフォームでのアクセス許可と同意の概要」および「Microsoft Graph のアクセス許可の概要」をご覧ください。

アクセス許可とスコープは、同じことを意味し、セキュリティドキュメントと Azure portal で意味の区別なく使用されます。この記事では、本文が Azure portal を参照していない限り、Graph のアクセス許可を参照するときにスコープ/を使用します。

スコープでは大文字と小文字が区別されないため、User.Read は user.read と同じです。どちらの形式でも自由に使用できますが、アプリケーションコード間で一貫した選択肢をお勧めします。

グループメンバーシップ要求の属性

クライアントおよびサーバー アプリに対する Azure portal のアプリマニフェストで、groupMembershipClaims 属性を DirectoryRole に設定します。 DirectoryRole の値を設定すると、ME-ID が既知の ID 要求 (wids) のサインインしているユーザーのロールのすべてを送信します。

アプリの Azure portal の登録を開きます。
サイドバーで [管理]>[マニフェスト] を選択します。
groupMembershipClaims 属性を見つけます。
値を DirectoryRole に設定します ("groupMembershipClaims": "DirectoryRole")。
変更を加えた場合は、[保存] ボタンを選択します。

クライアントおよびサーバー アプリに対する Azure portal のアプリマニフェストで、groupMembershipClaims 属性を All に設定します。 All の値を設定すると、ME-ID が既知の ID 要求 (wids) のサインインしているユーザーのセキュリティグループ、配布グループ、ロールのすべてを送信します。

アプリの Azure portal の登録を開きます。
サイドバーで [管理]>[マニフェスト] を選択します。
groupMembershipClaims 属性を見つけます。
値を All に設定します ("groupMembershipClaims": "All")。
変更を加えた場合は、[保存] ボタンを選択します。

カスタムユーザーアカウント

Azure portal で ME-ID セキュリティグループと ME-ID 管理者ロールにユーザーを割り当てます。

この記事の例では:

サーバー API データへのアクセスを認可するために、ユーザーが Azure portal ME-ID テナントの ME-ID 課金管理者ロールに割り当てられているとします。
認可ポリシーを使用して、クライアントおよびサーバー アプリ内でアクセスを制御します。

クライアント アプリで、RemoteUserAccount を拡張して次のプロパティを含めます。

Roles: ME-ID アプリロールの配列 (「アプリロール」セクションで説明します)
Wids: 既知の ID 要求 (wids) の ME-ID 管理者ロール
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; }
}

パッケージ参照を Microsoft.Graph の CLIENT アプリに追加します。

Note

.NET アプリへのパッケージの追加に関するガイダンスについては、「パッケージ利用のワークフロー」 (NuGet ドキュメント) の "パッケージのインストールと管理" に関する記事を参照してください。 NuGet.org で正しいパッケージバージョンを確認します。

記事「ASP.NET Core Blazor WebAssembly で Graph API を使用する」の Graph SDK のガイダンスにある Graph SDK ユーティリティクラスと構成を追加します。記事のサンプル wwwroot/appsettings.json ファイルで示されているように、アクセストークンの User.Read スコープを指定します。

次のカスタムユーザーアカウントファクトリをクライアント アプリに追加します。カスタムユーザーファクトリは、以下を確立するために使用されます。

アプリロールの要求 (appRole) (「アプリロール」セクションで説明します)。
ME-ID 管理者ロールの要求 (directoryRole)。
ユーザーの携帯電話番号 (mobilePhone) と勤務先所在地 (officeLocation) に対するユーザープロファイルデータ要求の例。
ME-ID グループ要求 (directoryGroup)。
ILogger (logger) (情報やエラーをログする必要がある場合に便利なように)。

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 管理者ロール (#microsoft.graph.directoryRole の種類) であるグループメンバーシップの要求 (groups) が無視されます。これは、ME-ID によって返される GUID 値が、ロール テンプレート ID ではなく管理者ロールのエンティティ ID であるためです。エンティティ ID はテナント間で一定ではないため、アプリでユーザーの認可ポリシーを作成するために使用しないでください。 wids 要求によって提供される ME-ID 管理者ロールのテンプレート ID を常に使用してください。

b79fbf4d-3ef9-4689-8143-76b194e85509 の値を持つ wids 要求 (したがって、directoryRole 要求) は、テナントの非ゲストアカウントに対して存在します。 ME-ID 管理者ロールテンプレート ID は参照されません。

クライアント アプリで、カスタムユーザーアカウントファクトリを使用するように MSAL 認証を構成します。

Program ファイルで Microsoft.AspNetCore.Components.WebAssembly.Authentication 名前空間が使われていることを確認します。

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;

AddMsalAuthentication 呼び出しを次のように更新します。 Blazor フレームワークの RemoteUserAccount は、MSAL 認証とアカウント要求プリンシパルファクトリに対してアプリの CustomUserAccount に置き換えられていることに注意してください。

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

「ASP.NET Core Blazor WebAssembly で Graph API を使用する」の記事で説明されている Graph SDK コードが存在し、wwwroot/appsettings.json の構成が Graph SDK のガイダンスに従って正しいことを確認します。

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

承認の構成

クライアント アプリの Program ファイルで、各アプリロール、ME-ID 管理者ロール、またはセキュリティグループに対してポリシーを作成します。次の例では、ME-ID の組み込み課金管理者ロールに対するポリシーを作成します。

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

ME-ID 管理者の役割 ID に関する完全な一覧については、Entra ドキュメントの「ロールテンプレート 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 は Azure portal アプリのマニフェストの appRoles 要素に設定され、セキュリティグループでは、ポリシーに使用される GUID が Azure portal グループ ペインのグループ オブジェクト ID と一致します。

サーバー API または Web API のアクセスを承認する

サーバー API アプリでは、アクセストークンに groups、wids、role の要求が含まれている場合に、セキュリティグループ、ME-ID 管理者ロール、およびアプリロールに対する認可ポリシーを使用して、セキュリティで保護された API エンドポイントにアクセスすることをユーザーに許可できます。次の例では、Program ファイルで wids (既知の ID またはロールテンプレート ID) 要求を使用して、ME-ID 課金管理者ロールに対するポリシーを作成しています。

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

ME-ID 管理者ロールの ID の完全な一覧については、Azure ドキュメントの「ロールテンプレート ID」を参照してください。承認ポリシーの詳細については、「ASP.NET Core でのポリシーベースの認可」を参照してください。

サーバー アプリのコントローラーへのアクセスは、[Authorize] 属性とポリシー名の使用に基づいて行うことができます (API ドキュメント:AuthorizeAttribute)。

次の例では、BillingDataController からの課金データへのアクセスを、BillingAdministrator というポリシー名を持つ Azure 課金管理者に制限しています。

using Microsoft.AspNetCore.Authorization;

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

詳細については、「ASP.NET Core でのポリシーベースの認可」を参照してください。

アプリロール

Azure portal で、アプリをアプリロールメンバーシップ要求を提供するように構成するには、Entra ドキュメントの、「アプリケーションにアプリロールを追加し、それらをトークンで受け取る」を参照してください。

以下の例では、クライアントとサーバー アプリが 2 つのロールを使用して構成されていること、およびロールがテストユーザーに割り当てられていることを前提としています。

Admin
Developer

Note

ホストされている Blazor WebAssembly アプリ、またはスタンドアロンアプリ (スタンドアロンの Blazor WebAssembly アプリおよび ASP.NET Core サーバー API または Web API アプリ) のクライアントとサーバーのペアを開発する場合、クライアントとサーバー両方の Azure portal アプリ登録の appRoles マニフェストプロパティには、同じ構成されたロールを含める必要があります。クライアントアプリのマニフェストでロールを確立したら、それら全体をサーバーアプリのマニフェストにコピーします。クライアントとサーバーのアプリ登録の間でマニフェスト appRoles をミラー化しないと、サーバー API または Web API の認証済みユーザーに対して、そのアクセストークンに適切なエントリがあったとしても、ロール要求は確立されません。

Microsoft Entra ID Premium アカウントがないとグループにロールを割り当てることはできませんが、Standard Azure アカウントを使用してユーザーにロールを割り当て、ユーザーに対するロール要求を受け取ることができます。このセクションのガイダンスでは、ME-ID Premium アカウントは必要ありません。

規定のディレクトリを使用する場合は、「アプリケーションにアプリロールを追加してトークンで受け取る」のガイダンスに従い、割り当てるロールを構成します。既定のディレクトリを使用していない場合は、Azure portal でアプリのマニフェストを編集し、マニフェストファイルの appRoles エントリでアプリのロールを手動で確立します。 Admin ロールと Developer ロールを作成する appRoles エントリの例を次に示します。これらのロールの例は、このセクションの例の後半でコンポーネントレベルでアクセス制限を実装するために使用されます。

"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 を生成できます。

ユーザー (または Premium レベルの Azure アカウントがある場合はグループ) にロールを割り当てるには:

Azure portal の ME-ID 領域で [エンタープライズアプリケーション] に移動します。
アプリを選びます。サイドバーから [管理]>[ユーザーとグループ] を選択します。
1 つ以上のユーザーアカウントのチェックボックスをオンにします。
ユーザーの一覧の上にあるメニューから、[割り当ての編集] を選択します。
[ロールを選択する] エントリに対して、[選択されていません] を選択します。
一覧からロールを選択し、[選択] ボタンを使用して選択します。
画面の下部にある [割り当て] ボタンを使用して、ロールを割り当てます。

Azure portal で各追加ロール割り当てに対して ユーザーを再追加する ことにより、複数のロールを割り当てます。ユーザーの一覧の上部にある [ユーザーまたはグループの追加] ボタンを使用して、ユーザーを再追加します。前の手順を使用して、ユーザーに別のロールを割り当てます。このプロセスを必要な回数だけ繰り返して、ユーザー (またはグループ) にロールを追加できます。

「カスタムユーザーアカウント」セクションで示されている CustomAccountFactory は、JSON 配列値を持つ role 要求に対して動作するように設定されています。「カスタムユーザーアカウント」セクションで示されているように、クライアント アプリに CustomAccountFactory を追加して登録します。元の role 要求はフレームワークによって自動的に削除されるため、それを削除するためのコードを提供する必要はありません。

クライアント アプリの Program ファイルで、ClaimsPrincipal.IsInRole のチェック用にロール要求として "appRole" という名前の要求を指定します。

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

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

Note

directoryRoles 要求 (管理者ロールの追加) を使用したい場合は、"directoryRoles" を RemoteAuthenticationUserOptions.RoleClaim に代入します。

サーバー アプリの Program ファイルで、ClaimsPrincipal.IsInRole のチェック用にロール要求として "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" という名前の要求を指定します。

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

Note

1 つの認証スキームが登録されると、認証スキームがアプリの既定のスキームとして自動的に使用され、スキームを AddAuthentication に指定、または AuthenticationOptions 経由にする必要はありません。詳細については、「ASP.NET Core の認証の概要」と ASP.NET Core のお知らせ (aspnet/Announcements #490) を参照してください。

Note

wids 要求 (管理者ロールの追加) を使用したい場合は、"wids" を TokenValidationParameters.RoleClaimType に代入します。

前の手順を完了してロールを作成し、ユーザー (または、Premium レベルの Azure アカウントを持っている場合はグループ) に割り当て、前述のこの記事と「ASP.NET Core Blazor WebAssembly で Graph API を使用する」で説明されているように Graph SDK で CustomAccountFactory を実装したら、サインインしているユーザーが割り当てられている各割り当て済みロール (またはユーザーが所属しているグループに割り当てられているロール) の appRole 要求が表示されます。テストユーザーを使ってアプリを実行し、要求が期待どおりに存在することを確認します。 Graph SDK をローカル環境でテストする場合は、残っている Cookie がテストに干渉しないよう、テストのたびに新しいプライベートまたはシークレットブラウザーセッションを使うことをお勧めします。詳しくは、「Microsoft Entra ID を使用して、ASP.NET Core Blazor WebAssembly スタンドアロンアプリをセキュリティで保護する」をご覧ください。

この時点でコンポーネントの承認方法が機能しています。 クライアント アプリのコンポーネント内のすべての認可メカニズムで、Admin ロールを使用してユーザーを承認できます。

AuthorizeView コンポーネント
```
<AuthorizeView Roles="Admin">
```
[Authorize] 属性ディレクティブ (AuthorizeAttribute)
```
@attribute [Authorize(Roles = "Admin")]
```

手続き型ロジック

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

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

複数のロールテストがサポートされています。

AuthorizeView コンポーネントを使用して、ユーザーが Admin または Developer ロールのいずれかであることを要求します。
```
<AuthorizeView Roles="Admin, Developer">
    ...
</AuthorizeView>
```
AuthorizeView コンポーネントを使用して、ユーザーが Admin および Developer ロールの両方であることを要求します。
```
<AuthorizeView Roles="Admin">
    <AuthorizeView Roles="Developer" Context="innerContext">
        ...
    </AuthorizeView>
</AuthorizeView>
```
内部 AuthorizeView の Context に関する詳細情報については、「ASP.NET Core Blazor 認証および許可」を参照してください。
[Authorize] 属性を使用して、ユーザーが Admin または Developer ロールのいずれかであることを要求します。
```
@attribute [Authorize(Roles = "Admin, Developer")]
```
[Authorize] 属性を使用して、ユーザーが Admin および Developer ロールの両方であることを要求します。
```
@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 ロールの両方であることを要求します。それには、前の例の条件付き OR (||) を条件付き AND (&&) に変更します。
```
if (user.IsInRole("Admin") && user.IsInRole("Developer"))
```

サーバー アプリのコントローラー内のすべての認可メカニズムで、Admin ロールを使用してユーザーを承認できます。

[Authorize] 属性ディレクティブ (AuthorizeAttribute)
```
[Authorize(Roles = "Admin")]
```
手続き型ロジック
```
if (User.IsInRole("Admin")) { ... }
```

複数のロールテストがサポートされています。

[Authorize] 属性を使用して、ユーザーが Admin または Developer ロールのいずれかであることを要求します。
```
[Authorize(Roles = "Admin, Developer")]
```
[Authorize] 属性を使用して、ユーザーが Admin および Developer ロールの両方であることを要求します。
```
[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 ロールの両方であることを要求します。それには、前の例の条件付き OR (||) を条件付き AND (&&) に変更します。
```
if (User.IsInRole("Admin") && User.IsInRole("Developer"))
```

.NET 文字列の比較は既定では大文字と小文字が区別されるため、ロール名の照合でも大文字と小文字が区別されます。たとえば、Admin (大文字 A) は、admin (小文字 a) と同じロールとして扱われません。

通常、パスカルケースはロール名に使用されますが (例: BillingAdministrator)、パスカルケースの使用は厳密な要件ではありません。キャメルケース、ケバブケース、スネークケースなど、さまざまなケーススキームが許可されています。ロール名でのスペースの使用も通常とは異なりますが、許可されています。たとえば、billing administrator は .NET アプリでは通常とは異なるロール名の形式ですが、有効です。

次の方法で共有

Microsoft Entra (ME-ID) グループ、管理者ロール、アプリロール (.NET 5 から .NET 7)

前提条件

スコープ

グループメンバーシップ要求の属性

カスタムユーザーアカウント

承認の構成

サーバー API または Web API のアクセスを承認する

アプリロール

その他のリソース

その他のリソース

次の方法で共有

Microsoft Entra (ME-ID) グループ、管理者ロール、アプリ ロール (.NET 5 から .NET 7)

前提条件

スコープ

グループ メンバーシップ要求の属性

カスタム ユーザー アカウント

承認の構成

サーバー API または Web API のアクセスを承認する

アプリ ロール

その他のリソース

その他のリソース

Microsoft Entra (ME-ID) グループ、管理者ロール、アプリロール (.NET 5 から .NET 7)

グループメンバーシップ要求の属性

カスタムユーザーアカウント

アプリロール