セキュリティ:ASP.NET Web Forms および Blazor での認証と承認Security: Authentication and Authorization in ASP.NET Web Forms and Blazor

ASP.NET の Web フォームアプリケーションからに移行する Blazor 場合、アプリケーションで認証が構成されていることを前提として、ほとんどの場合、認証と承認の実行方法を更新する必要があります。Migrating from an ASP.NET Web Forms application to Blazor will almost certainly require updating how authentication and authorization is performed, assuming the application had authentication configured. この章では、ASP.NET Web フォームユニバーサルプロバイダーモデル (メンバーシップ、ロール、およびユーザープロファイルの場合) から移行する方法と、アプリから ASP.NET Core Id を使用する方法について説明し Blazor ます。This chapter will cover how to migrate from the ASP.NET Web Forms universal provider model (for membership, roles, and user profiles) and how to work with ASP.NET Core Identity from Blazor apps. この章では、大まかな手順と考慮事項について説明しますが、詳細な手順とスクリプトについては、参照されているドキュメントを参照してください。While this chapter will cover the high level steps and considerations, the detailed steps and scripts may be found in the referenced documentation.

ASP.NET ユニバーサルプロバイダーASP.NET universal providers

ASP.NET 2.0 以降、ASP.NET Web Forms platform は、メンバーシップなどのさまざまな機能のプロバイダーモデルをサポートしています。Since ASP.NET 2.0, the ASP.NET Web Forms platform has supported a provider model for a variety of features, including membership. ユニバーサルメンバーシッププロバイダーは、オプションのロールプロバイダーと共に、ASP.NET Web フォームアプリケーションと共に一般的にデプロイされます。The universal membership provider, along with the optional role provider, is very commonly deployed with ASP.NET Web Forms applications. 現在も引き続き正常に機能する認証と承認を管理するための、堅牢で安全な方法を提供します。It offers a robust and secure way to manage authentication and authorization that continues to work well today. これらのユニバーサルプロバイダーの最新のオファリングは、NuGet パッケージである、 Microsoftで提供されています。The most recent offering of these universal providers is available as a NuGet package, Microsoft.AspNet.Providers.

ユニバーサルプロバイダーは、、、、などのテーブルを含む SQL データベーススキーマを操作し aspnet_Applications aspnet_Membership aspnet_Roles aspnet_Users ます。The Universal Providers work with a SQL database schema that includes tables like aspnet_Applications, aspnet_Membership, aspnet_Roles, and aspnet_Users. aspnet_regsql.exe コマンドを実行して構成すると、基になるデータを操作するために必要なすべてのクエリとコマンドを提供するテーブルとストアドプロシージャがプロバイダーによってインストールされます。When configured by running the aspnet_regsql.exe command, the providers install tables and stored procedures that provide all of the necessary queries and commands necessary to work with the underlying data. データベーススキーマとこれらのストアドプロシージャは、新しい ASP.NET Identity および ASP.NET Core Id システムと互換性がないため、既存のデータを新しいシステムに移行する必要があります。The database schema and these stored procedures are not compatible with newer ASP.NET Identity and ASP.NET Core Identity systems, so existing data must be migrated into the new system. 図1は、ユニバーサルプロバイダー用に構成されたテーブルスキーマの例を示しています。Figure 1 shows an example table schema configured for universal providers.


ユニバーサルプロバイダーは、ユーザー、メンバーシップ、ロール、およびプロファイルを処理します。The universal provider handles users, membership, roles, and profiles. ユーザーにはグローバル一意識別子が割り当てられ、非常に基本的な情報 (userId、userName) がテーブルに格納され aspnet_Users ます。Users are assigned globally unique identifiers and very basic information (userId, userName) is stored in the aspnet_Users table. パスワード、パスワード形式、パスワード salt、ロックアウトカウンター、詳細などの認証情報は、テーブルに格納されます。 aspnet_MembershipAuthentication information, such as password, password format, password salt, lockout counters and details, etc. are stored in the aspnet_Membership table. ロールは、名前と一意の識別子の単純なもので構成され、アソシエーションテーブルを介してユーザーに割り当てられ aspnet_UsersInRoles 、多対多のリレーションシップを提供します。Roles consist simply of names and unique identifiers, which are assigned to users via the aspnet_UsersInRoles association table, providing a many-to-many relationship.

既存のシステムがメンバーシップに加えてロールを使用している場合は、ユーザーアカウント、関連付けられているパスワード、ロール、およびロールメンバーシップを ASP.NET Core Id に移行する必要があります。If your existing system is using roles in addition to membership, you will need to migrate the user accounts, the associated passwords, the roles, and the role membership into ASP.NET Core Identity. また、通常は、if ステートメントを使用して、宣言型のフィルター、属性、またはタグヘルパーを利用することで、現在ロールチェックを実行しているコードを更新する必要があります。You will also most likely need to update your code where you're currently performing role checks using if statements to instead leverage declarative filters, attributes, and/or tag helpers. 移行に関する考慮事項の詳細については、この章の最後を参照してください。We will review migration considerations in greater detail at the end of this chapter.

Web フォームでの承認構成Authorization configuration in Web Forms

ASP.NET Web フォームアプリケーションで特定のページへの承認されたアクセスを構成するには、通常、匿名ユーザーが特定のページまたはフォルダーにアクセスできないように指定します。To configure authorized access to certain pages in an ASP.NET Web Forms application, typically you specify that certain pages or folders are inaccessible to anonymous users. これは web.config ファイルで行います。This is done in the web.config file:

<?xml version="1.0"?>
      <authentication mode="Forms">
        <forms defaultUrl="~/home.aspx" loginUrl="~/login.aspx"
          slidingExpiration="true" timeout="2880"></forms>

        <deny users="?" />

構成セクションでは、 authentication アプリケーションのフォーム認証を設定します。The authentication configuration section sets up forms authentication for the application. セクションは、 authorization アプリケーション全体の匿名ユーザーを許可しないために使用されます。The authorization section is used to disallow anonymous users for the entire application. ただし、場所ごとにより詳細な承認規則を提供したり、ロールベースの承認チェックを適用したりすることができます。However, you can provide more granular authorization rules on a per-location basis as well as apply role based authorization checks.

<location path="login.aspx">
      <allow users="*" />

上記の構成を最初の構成と組み合わせると、匿名ユーザーがログインページにアクセスできるようになり、認証されていないユーザーに対するサイト全体の制限が上書きされます。The above configuration, when combined with the first one, would allow anonymous users to access the login page, overriding the site-wide restriction on non-authenticated users.

<location path="/admin">
      <allow roles="Administrators" />
      <deny users="*" />

上記の構成を他の構成と組み合わせて使用すると、 /admin フォルダーとその中のすべてのリソースへのアクセスが "Administrators" ロールのメンバーに制限されます。The above configuration, when combined with the others, restricts access to the /admin folder and all resources within it to members of the "Administrators" role. これは、フォルダールート内に別のファイルを配置することでも適用でき web.config /admin ます。This could also be applied by placing a separate web.config file within the /admin folder root.

Web フォームでの認証コードAuthorization code in Web Forms

を使用してアクセスを構成するだけでなく web.config 、Web フォームアプリケーションのアクセスと動作をプログラムで構成することもできます。In addition to configuring access using web.config, you can also programmatically configure access and behavior in your Web Forms application. たとえば、特定の操作を実行する機能を制限したり、ユーザーのロールに基づいて特定のデータを表示したりすることができます。For instance, you can restrict the ability to perform certain operations or view certain data based on the user's role.

このコードは、分離コードロジックとページ自体の両方で使用できます。This code can be used both in codebehind logic as well as in the page itself:

<% if (HttpContext.Current.User.IsInRole("Administrators")) { %>
  <a href="/admin">Go To Admin</a>
<% } %>

ユーザーロールのメンバーシップを確認するだけでなく、認証されているかどうかを判断することもできます (ただし、上記の場所ベースの構成を使用することをお勧めします)。In addition to checking user role membership, you can also determine if they are authenticated (though often this is better done using the location-based configuration covered above). このアプローチの例を次に示します。Below is an example of this approach.

protected void Page_Load(object sender, EventArgs e)
    if (!User.Identity.IsAuthenticated)
    if (!Roles.IsUserInRole(User.Identity.Name, "Administrators"))
        MessageLabel.Text = "Only administrators can view this.";
        SecretPanel.Visible = false;

上のコードでは、ロールベースのアクセス制御 (RBAC) を使用して、ページの特定の要素 (など) が SecretPanel 現在のユーザーのロールに基づいて表示されるかどうかを判断します。In the code above, role-based access control (RBAC) is used to determine whether certain elements of the page, such as a SecretPanel, are visible based on the current user's role.

通常、ASP.NET Web フォームアプリケーションは、ファイル内のセキュリティ web.config を構成した後、 .aspx ページとそれに関連する分離コードファイルに必要なチェックを追加し .aspx.cs ます。Typically, ASP.NET Web Forms applications configure security within the web.config file and then add additional checks where needed in .aspx pages and their related .aspx.cs codebehind files. ほとんどのアプリケーションは、多くの場合、追加の役割プロバイダーを使用して、ユニバーサルメンバーシッププロバイダーを利用します。Most applications leverage the universal membership provider, frequently with the additional role provider.

ASP.NET Core IDASP.NET Core Identity

認証と承認を行っていても、ASP.NET Core Id では、ユニバーサルプロバイダーと比較して、異なる抽象化と仮定を使用します。Although still tasked with authentication and authorization, ASP.NET Core Identity uses a different set of abstractions and assumptions when compared to the universal providers. たとえば、新しい Id モデルはサードパーティの認証をサポートしているため、ユーザーはソーシャルメディアアカウントまたは他の信頼された認証プロバイダーを使用して認証を行うことができます。For example, the new Identity model supports third party authentication, allowing users to authenticate using a social media account or other trusted authentication provider. ASP.NET Core Id は、ログイン、ログアウト、登録など、一般的に必要なページの UI をサポートします。ASP.NET Core Identity supports UI for commonly needed pages like login, logout, and register. データアクセスには EF Core を利用し、EF Core の移行を使用して、そのデータモデルをサポートするために必要なスキーマを生成します。It leverages EF Core for its data access, and uses EF Core migrations to generate the necessary schema required to supports its data model. ASP.NET Core での idの概要では、ASP.NET Core id に含まれるものの概要と、その使用方法について説明します。This introduction to Identity on ASP.NET Core provides a good overview of what is included with ASP.NET Core Identity and how to get started working with it. アプリケーションとそのデータベースに ASP.NET Core Id をまだ設定していない場合は、開始するのに役立ちます。If you haven't already set up ASP.NET Core Identity in your application and its database, it will help you get started.

役割、要求、およびポリシーRoles, claims, and policies

ユニバーサルプロバイダーと ASP.NET Core Id の両方で、ロールの概念がサポートされています。Both the universal providers and ASP.NET Core Identity support the concept of roles. ユーザーのロールを作成し、ユーザーをロールに割り当てることができます。You can create roles for users and assign users to roles. ユーザーは任意の数のロールに属することができ、承認実装の一部としてロールのメンバーシップを確認できます。Users can belong to any number of roles, and you can verify role membership as part of your authorization implementation.

ロールに加えて、ASP.NET Core id では、信頼性情報とポリシーの概念がサポートされています。In addition to roles, ASP.NET Core identity supports the concepts of claims and policies. ロールは、そのロールのユーザーがアクセスできる必要がある一連のリソースに特に対応する必要がありますが、要求は単にユーザーの id の一部になります。While a role should specifically correspond to a set of resources a user in that role should be able to access, a claim is simply part of a user's identity. クレームは、サブジェクトの内容を表す名前と値のペアであり、サブジェクトが実行できる内容ではありません。A claim is a name value pair that represents what the subject is, not what the subject can do.

ユーザーの要求を直接検査し、ユーザーにリソースへのアクセス権を付与する必要があるかどうかに基づいて判断することができます。It is possible to directly inspect a user's claims and determine based on these whether a user should be given access to a resource. ただし、多くの場合、このようなチェックは繰り返し、システム全体にわたって分散されます。However, such checks are often repetitive and scattered throughout the system. より優れたアプローチは、 ポリシーを定義することです。A better approach is to define a policy.

承認ポリシーは、1つまたは複数の要件で構成されます。An authorization policy consists of one or more requirements. ポリシーは、のメソッドで承認サービス構成の一部として登録され ConfigureServices Startup.cs ます。Policies are registered as part of the authorization service configuration in the ConfigureServices method of Startup.cs. たとえば、次のコードスニペットでは、"Can" という名前のポリシーを構成しています。このポリシーでは、ユーザーが "カナダ" の値を持つ国の要求を持っている必要があります。For example, the following code snippet configures a policy called "CanadiansOnly" which has the requirement that the user have the Country claim with the value of "Canada".

services.AddAuthorization(options =>
    options.AddPolicy("CanadiansOnly", policy => policy.RequireClaim(ClaimTypes.Country, "Canada"));

カスタムポリシーの作成方法の詳細については、ドキュメントを参照してください。You can learn more about how to create custom policies in the documentation.

ポリシーまたはロールを使用しているかどうかにかかわらず、アプリケーションの特定のページで、 Blazor 属性を持つロールまたはポリシーが [Authorize] ディレクティブで適用されている必要があることを指定でき @attribute ます。Whether you're using policies or roles, you can specify that a particular page in your Blazor application require that role or policy with the [Authorize] attribute, applied with the @attribute directive.

ロールが必要:Requiring a role:

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

ポリシーが満たされている必要があります。Requiring a policy be satisfied:

@attribute [Authorize(Policy ="CanadiansOnly")]

コード内のユーザーの認証状態、ロール、または要求にアクセスする必要がある場合、これを実現するには主に2つの方法があります。If you need access to a user's authentication state, roles, or claims in your code, there are two primary ways to achieve this. 1つ目は、認証状態をカスケード型パラメーターとして受け取ることです。The first is to receive the authentication state as a cascading parameter. 2つ目は、挿入されたを使用して状態にアクセスすることです AuthenticationStateProviderThe second is to access the state using an injected AuthenticationStateProvider. これらの各方法の詳細については、 Blazor セキュリティのドキュメントを参照してください。The details of each of these approaches are described in the Blazor Security documentation.

次のコードは、をカスケード型 AuthenticationState パラメーターとして受け取る方法を示しています。The following code shows how to receive the AuthenticationState as a cascading parameter:

private Task<AuthenticationState> authenticationStateTask { get; set; }

このパラメーターを使用すると、次のコードを使用してユーザーを取得できます。With this parameter in place, you can get the user using this code:

var authState = await authenticationStateTask;
var user = authState.User;

次のコードは、を挿入する方法を示してい AuthenticationStateProvider ます。The following code shows how to inject the AuthenticationStateProvider:

@using Microsoft.AspNetCore.Components.Authorization
@inject AuthenticationStateProvider AuthenticationStateProvider

プロバイダーを配置すると、次のコードを使用してユーザーにアクセスできます。With the provider in place, you can gain access to the user with the following code:

AuthenticationState authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
ClaimsPrincipal user = authState.User;

if (user.Identity.IsAuthenticated)
  // work with user.Claims and/or user.Roles

注:AuthorizeViewこの章の後半で説明するコンポーネントは、ユーザーがページまたはコンポーネントに表示する内容を宣言的に制御する方法を提供します。Note: The AuthorizeView component, covered later in this chapter, provides a declarative way to control what a user sees on a page or component.

(サーバーアプリケーションで) ユーザーと要求を操作するに Blazor は、 UserManager<T> IdentityUser ユーザーの要求を列挙および変更するために使用できる (既定で使用する) を挿入することも必要になる場合があります。To work with users and claims (in Blazor Server applications) you may also need to inject a UserManager<T> (use IdentityUser for default) which you can use to enumerate and modify claims for a user. 最初に型を挿入し、それをプロパティに割り当てます。First inject the type and assign it to a property:

@inject UserManager<IdentityUser> MyUserManager

次に、それを使用してユーザーの要求を処理します。Then use it to work with the user's claims. 次のサンプルは、ユーザーにクレームを追加して永続化する方法を示しています。The following sample shows how to add and persist a claim on a user:

private async Task AddCountryClaim()
    var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
    var user = authState.User;
    var identityUser = await MyUserManager.FindByNameAsync(user.Identity.Name);

    if (!user.HasClaim(c => c.Type == ClaimTypes.Country))
        // stores the claim in the cookie
        ClaimsIdentity id = new ClaimsIdentity();
        id.AddClaim(new Claim(ClaimTypes.Country, "Canada"));

        // save the claim in the database
        await MyUserManager.AddClaimAsync(identityUser, new Claim(ClaimTypes.Country, "Canada"));

ロールを使用する必要がある場合は、同じアプローチに従います。If you need to work with roles, follow the same approach. RoleManager<T> IdentityRole ロール自体の一覧表示と管理には、(既定の型に使用) を挿入する必要がある場合があります。You may need to inject a RoleManager<T> (use IdentityRole for default type) to list and manage the roles themselves.

**注:**BlazorWebassembly では、これらの操作を実行するためにサーバー api を提供する必要があります (またはを直接使用するので UserManager<T> はなく RoleManager<T> )。Note: In Blazor WebAssembly projects, you will need to provide server APIs to perform these operations (instead of using UserManager<T> or RoleManager<T> directly). BlazorWebassembly アプリケーションは、この目的のために公開されている API エンドポイントを安全に呼び出すことによって、信頼性情報や役割を管理します。A Blazor WebAssembly client application would manage claims and/or roles by securely calling API endpoints exposed for this purpose.

移行ガイドMigration guide

ASP.NET Web フォームとユニバーサルプロバイダーから ASP.NET Core Id に移行するには、いくつかの手順を実行する必要があります。Migrating from ASP.NET Web Forms and universal providers to ASP.NET Core Identity requires several steps:

  1. ASP.NET Core Id データベーススキーマを転送先データベースに作成するCreate ASP.NET Core Identity database schema in destination database
  2. ユニバーサルプロバイダースキーマから ASP.NET Core Id スキーマにデータを移行するMigrate data from universal provider schema to ASP.NET Core Identity schema
  3. 構成を web.config からミドルウェアおよびサービスに移行する (通常は) Startup.csMigrate configuration from web.config to middleware and services, typically in Startup.cs
  4. コントロールと条件を使用して個々のページを更新し、タグヘルパーと新しい id Api を使用します。Update individual pages using controls and conditionals to use tag helpers and new identity APIs.

以下のセクションでは、これらの各手順について詳しく説明します。Each of these steps is described in detail in the following sections.

ASP.NET Core Id スキーマの作成Creating the ASP.NET Core Identity schema

ASP.NET Core Id に使用される必要なテーブル構造を作成するには、いくつかの方法があります。There are several ways to create the necessary table structure used for ASP.NET Core Identity. 最も簡単なのは、新しい ASP.NET Core Web アプリケーションを作成することです。The simplest is to create a new ASP.NET Core Web application. [Web アプリケーション] を選択し、個々のユーザーアカウントを使用するように認証を変更します。Choose Web Application and then change Authentication to use Individual User Accounts.


コマンドラインからを実行すると、同じことを行うことができ dotnet new webapp -au Individual ます。From the command line, you can do the same thing by running dotnet new webapp -au Individual. アプリが作成されたら、それを実行し、サイトに登録します。Once the app has been created, run it and register on the site. 次のようなページをトリガーする必要があります。You should trigger a page like the one shown below:

[移行の適用] ページ

[移行の適用] ボタンをクリックすると、必要なデータベーステーブルが作成されます。Click on the "Apply Migrations" button and the necessary database tables should be created for you. また、次のように、移行ファイルがプロジェクトに表示されます。In addition, the migration files should appear in your project, as shown:


次のコマンドラインツールを使用して、web アプリケーションを実行せずに、自分で移行を実行できます。You can run the migration yourself, without running the web application, using this command line tool:

dotnet ef database update

新しいスキーマを既存のデータベースに適用するスクリプトを実行する場合は、コマンドラインからこれらの移行をスクリプト化することができます。If you would rather run a script to apply the new schema to an existing database, you can script these migrations from the command line. 次のコマンドを実行して、スクリプトを生成します。Run this command to generate the script:

dotnet ef migrations script -o auth.sql

これにより、出力ファイルに SQL スクリプトが生成され、 auth.sql 任意のデータベースに対して実行できるようになります。This will produce a SQL script in the output file auth.sql which can then be run against whatever database you like. コマンドの実行で問題が発生した場合は、 dotnet ef EF Core ツールがシステムにインストールされていることを確認してください。If you have any trouble running dotnet ef commands, make sure you have the EF Core tools installed on your system.

ソーステーブルに列が追加されている場合は、新しいスキーマでこれらの列の最適な場所を特定する必要があります。In the event you have additional columns on your source tables, you will need to identify the best location for these columns in the new schema. 一般に、テーブルで見つかった列は aspnet_Membership テーブルにマップする必要があり AspNetUsers ます。Generally, columns found on the aspnet_Membership table should be mapped to the AspNetUsers table. の列 aspnet_Roles をにマップする必要があり AspNetRoles ます。Columns on aspnet_Roles should be mapped to AspNetRoles. テーブルのその他の列 aspnet_UsersInRoles がテーブルに追加され AspNetUserRoles ます。Any additional columns on the aspnet_UsersInRoles table would be added to the AspNetUserRoles table.

また、将来の移行では、既定の id スキーマのカスタマイズを考慮する必要がないように、別のテーブルに追加の列を配置することも検討してください。It's also worth considering putting any additional columns on separate tables, so that future migrations won't need to take into account such customizations of the default identity schema.

ユニバーサルプロバイダーから ASP.NET Core Id へのデータの移行Migrating data from universal providers to ASP.NET Core Identity

変換先テーブルスキーマを配置したら、次の手順では、ユーザーとロールのレコードを新しいスキーマに移行します。Once you have the destination table schema in place, the next step is to migrate your user and role records to the new schema. スキーマの相違点 (どの列がどの新しい列にマップされているかなど) の完全な一覧については、 こちらを参照してください。A complete list of the schema differences, including which columns map to which new columns, can be found here.

メンバーシップから新しい id テーブルにユーザーを移行するには、 ドキュメントに記載されている手順に従う必要があります。To migrate your users from membership to the new identity tables, you should follow the steps described in the documentation. 次の手順とスクリプトを実行した後、ユーザーは次回ログインするときにパスワードを変更する必要があります。After following these steps and the script provided, your users will need to change their password the next time they log in.

ユーザーのパスワードを移行することはできますが、プロセスはさらに複雑になります。It is possible to migrate user passwords but the process is much more involved. 移行プロセスの一環としてユーザーがパスワードを更新する必要があり、新しい一意のパスワードを使用するように勧めることは、アプリケーションの全体的なセキュリティを強化することです。Requiring users to update their passwords as part of the migration process, and encouraging them to use new, unique passwords, is likely to enhance the overall security of the application.

web.config から Startup.cs へのセキュリティ設定の移行Migrating security settings from web.config to Startup.cs

前述のように、ASP.NET のメンバーシップとロールプロバイダーは、アプリケーションの web.config ファイルで構成されます。As noted above, ASP.NET membership and role providers are configured in the application's web.config file. ASP.NET Core アプリは IIS に関連付けられていないため、構成に別のシステムを使用するため、これらの設定は別の場所で構成する必要があります。Since ASP.NET Core apps are not tied to IIS and use a separate system for configuration, these settings must be configured elsewhere. ほとんどの場合、ASP.NET Core Id はファイルで構成され Startup.cs ます。For the most part, ASP.NET Core Identity is configured in the Startup.cs file. (Id テーブルスキーマを生成するために) 前に作成した web プロジェクトを開き、そのファイルを確認し Startup.cs ます。Open the web project that was created earlier (to generate the identity table schema) and review its Startup.cs file.

既定の ConfigureServices メソッドは、EF Core と Id のサポートを追加します。The default ConfigureServices method adds support for EF Core and Identity:

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
    services.AddDbContext<ApplicationDbContext>(options =>

    services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)


AddDefaultIdentity拡張メソッドは、既定のとフレームワークの型を使用するように id を構成するために使用され ApplicationDbContext IdentityUser ます。The AddDefaultIdentity extension method is used to configure Identity to use the default ApplicationDbContext and the framework's IdentityUser type. カスタムを使用している場合は IdentityUser 、ここでその型を指定してください。If you're using a custom IdentityUser, be sure to specify its type here. これらの拡張メソッドがアプリケーションで動作していない場合は、適切な using ステートメントがあることと、必要な NuGet パッケージ参照があることを確認してください。If these extension methods aren't working in your application, check that you have the appropriate using statements and that you have the necessary NuGet package references. たとえば、プロジェクトにはいくつかのバージョンのおよびパッケージが参照されている必要があり Microsoft.AspNetCore.Identity.EntityFrameworkCore Microsoft.AspNetCore.Identity.UI ます。For example, your project should have some version of the Microsoft.AspNetCore.Identity.EntityFrameworkCore and Microsoft.AspNetCore.Identity.UI packages referenced.

また、 Startup.cs サイトに必要なミドルウェアが構成されていることがわかります。Also in Startup.cs you should see the necessary middleware configured for the site. 具体的には、 UseAuthentication とは UseAuthorization 適切な場所に設定されている必要があります。Specifically, UseAuthentication and UseAuthorization should be set up, and in the proper location.

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    if (env.IsDevelopment())
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.




    app.UseEndpoints(endpoints =>

ASP.NET Identity は、からの場所への匿名またはロールベースのアクセスを構成しません Startup.csASP.NET Identity does not configure anonymous or role-based access to locations from Startup.cs. ASP.NET Core のフィルターには、場所固有の承認構成データを移行する必要があります。You will need to migrate any location-specific authorization configuration data to filters in ASP.NET Core. このような更新が必要なフォルダーとページをメモしておきます。Make note of which folders and pages will require such updates. これらの変更は、次のセクションで行います。You will make these changes in the next section.

ASP.NET Core Id の抽象化を使用するように個々のページを更新するUpdating individual pages to use ASP.NET Core Identity abstractions

ASP.NET Web フォームアプリケーションで、匿名ユーザーに特定のページまたはフォルダーへのアクセスを拒否する設定を web.config した場合は、次の [Authorize] ようなページに属性を追加するだけで、それらを移行できます。In your ASP.NET Web Forms application, if you had web.config settings to deny access to certain pages or folders to anonymous users, you would migrate these by simply adding the [Authorize] attribute to such pages:

@attribute [Authorize]

特定のロールに属しているユーザー以外のアクセスを拒否した場合は、ロールを指定する属性を追加してこれを移行することもできます。If you further had denied access except to those users belonging to a certain role, you would likewise migrate this by adding an attribute specifying a role:

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

属性は、 [Authorize] @page ルーター経由で到達したコンポーネントでのみ機能することに注意して Blazor ください。Note that the [Authorize] attribute only works on @page components that are reached via the Blazor Router. 属性は子コンポーネントでは使用できませんが、代わりにを使用する必要があり AuthorizeView ます。The attribute does not work with child components, which should instead use AuthorizeView.

特定のユーザーにコードを表示するかどうかを判断するためのロジックがページマークアップ内にある場合は、これをコンポーネントで置き換えることができ AuthorizeView ます。If you have logic within page markup for determining whether to display some code to a certain user, you can replace this with the AuthorizeView component. Authorizeview コンポーネントは、ユーザーが表示を許可されているかどうかに応じて、UI を選択的に表示します。The AuthorizeView component selectively displays UI depending on whether the user is authorized to see it. また、 context ユーザー情報へのアクセスに使用できる変数も公開されています。It also exposes a context variable that can be used to access user information.

        <h1>Hello, @context.User.Identity.Name!</h1>
        <p>You can only see this content if you are authenticated.</p>
        <h1>Authentication Failure!</h1>
        <p>You are not signed in.</p>

Task<AuthenticationState属性を使用して構成されたからユーザーにアクセスすることにより、手続き型ロジック内の認証状態にアクセスでき [CascadingParameter] ます。You can access authentication state within procedural logic by accessing the user from a Task<AuthenticationState configured with the [CascadingParameter] attribute. これにより、ユーザーにアクセスできるようになります。ユーザーは、認証されているかどうか、および特定のロールに属しているかどうかを判断できます。This will get you access to the user, which can let you determine if they are authenticated and if they belong to a particular role. ポリシー procedurally を評価する必要がある場合は、のインスタンスを挿入 IAuthorizationService し、そのインスタンスでメソッドを呼び出すことができ AuthorizeAsync ます。If you need to evaluate a policy procedurally, you can inject an instance of the IAuthorizationService and calls the AuthorizeAsync method on it. 次のサンプルコードは、ユーザー情報を取得し、承認されたユーザーがポリシーによって制限されたタスクを実行することを許可する方法を示して content-editor います。The following sample code demonstrates how to get user information and allow an authorized user to perform a task restricted by the content-editor policy.

@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService AuthorizationService

<button @onclick="@DoSomething">Do something important</button>

@code {
    private Task<AuthenticationState> authenticationStateTask { get; set; }

    private async Task DoSomething()
        var user = (await authenticationStateTask).User;

        if (user.Identity.IsAuthenticated)
            // Perform an action only available to authenticated (signed-in) users.

        if (user.IsInRole("admin"))
            // Perform an action only available to users in the 'admin' role.

        if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
            // Perform an action only available to users satisfying the
            // 'content-editor' policy.

は、 AuthenticationState このようなカスケード型パラメーターにバインドする前に、まずカスケード値として設定する必要があります。The AuthenticationState does first need to be setup as a cascading value before it can be bound to a cascading parameter like this. 通常、これはコンポーネントを使用し CascadingAuthenticationState ます。That's typically done using the CascadingAuthenticationState component. 通常は、次の App.razor 操作を行います。This is typically done in App.razor:

    <Router AppAssembly="@typeof(Program).Assembly">
        <Found Context="routeData">
            <AuthorizeRouteView RouteData="@routeData"
                DefaultLayout="@typeof(MainLayout)" />
            <LayoutView Layout="@typeof(MainLayout)">
                <p>Sorry, there's nothing at this address.</p>


Blazor では、ASP.NET Core Id である ASP.NET Core と同じセキュリティモデルを使用します。Blazor uses the same security model as ASP.NET Core, which is ASP.NET Core Identity. カスタマイズが元のデータスキーマに適用されていないと仮定すると、ユニバーサルプロバイダーから ASP.NET Core Id への移行は比較的簡単です。Migrating from universal providers to ASP.NET Core Identity is relatively straightforward, assuming not too much customization was applied to the original data schema. データが移行されると、アプリでの認証と承認の使用に Blazor ついて詳しく説明されています。また、ほとんどのセキュリティ要件をプログラムでサポートすることもできます。Once the data has been migrated, working with authentication and authorization in Blazor apps is well-documented, with configurable as well as programmatic support for most security requirements.