.NET Core での認証管理分析

0x00 問題の原因

新しい .NET Core Web プロジェクトを作成するときは、[個人ユーザーアカウントを使用する] を選択してユーザーを作成し、権限管理プロジェクトを作成しますユーザー登録やログインなど多くのページが用意されており、AuthorizeAttributeを使って様々な権限を管理することもでき、とても便利そうです。しかし、生成されたコードが何をするのかわかりません。生成されたデータテーブルを見ると、関数は非常に複雑です。実際には、ユーザーとロールに基づいた認証管理が必要であり、ユーザー情報は既存のライブラリを使用しますが、.NET Core に付属の認証コンポーネントを使用するには EF に依存する必要があり、多くのテーブル構造が一致しないため、学習が必要です。組み込みの認証コンポーネントを実装し、Identity コンポーネントを置き換える独自の認証サービスを作成しました。同時に、Cookie は組み込みの Cookie ミドルウェアを使用し、認証に AuthorizeAttribute を使用できます。まだ複雑な要件に遭遇したことがないので、ここで学びました。このブログでは、最も単純なケースにおけるユーザーおよびロールベースの認証に焦点を当てます。 .NET Core の組み込み認証コンポーネントの基本的な使用方法については、http://www.php.cn/ を参照してください。

0x01 .NET Core における認証管理

認証管理というと首相が思い浮かべるのは、ユーザーの登録、ログイン、ログアウト、ユーザーのロールの追加削除です。ユーザー情報、ロール情報などはすべてデータベースに保存されます。したがって、これには主にデータベース操作とログインビジネスロジックの 2 つの部分が含まれています。ログインビジネスロジックレベルでは、.NET Core は主に 3 つのコアクラス UserManager、RoleManager、および SigninManager (Microsoft.AspNetCore.Identity アセンブリ内) を通じて管理されます。その中で:

UserManager は主に、ユーザーの認証、登録、変更、削除、ユーザー関連のロール、トークン、クレームなどの管理を担当します。
RoleManager は、ロールとロール関連のステートメントの管理を担当します。
SigninManager は、ログイン、ログアウト、およびその他の関連操作を担当します。ユーザー操作が関係する場合 (ログイン時のユーザー検証など)、操作を実行するために UserManager が呼び出されます。

データベースを操作するとき、これらの 3 つのコアクラスは、データベースレベルで UserStore と RoleStore を使用して操作します (Microsoft.AspNetCore.Identity.EntityFrameworkCore アセンブリ内)。ビジネス上の関係を以下の図に示します。

私たちは、認証関連の機能を開発する際のほとんどのニーズを満たすために、これら 3 つのコアクラスを使用します。これらのコアクラスのオブジェクトを使用する場合、それらは依存関係の注入を通じて取得されます。では、これらの関連する依存関係はいつ注入されるのでしょうか。 Startup の ConfigureServices メソッドには AddIdentity 拡張メソッドがあり、必要な依存関係がすべて追加されます。

0x02 ログインとログアウト

Identity コンポーネントの全体的な役割分担を理解した後、ログインとログアウトの操作の詳細をいくつか見てみましょう。 SigninManager は主にログインとログアウトのプロセスを担当します。まずログインプロセスを見てみましょう。

ログインに成功すると、応答の Header には

Set

-Cookie、Cookie のが含まれます。キー Cookie ミドルウェアに設定されている復号化する Cookie のキーと一致する必要があります。スクリーンショットでは、この Cookie のキーは IdentityCookie です。 Cookie を設定し、ログインページへの 302 リダイレクトを返します。

ログインページにリダイレクトされると、リクエストにはキーが IdentityCookie に設定された Cookie がすでに含まれています。

ログアウトプロセスは比較的単純です。このとき、HttpContext.Authentication.SignOutAsync メソッドを呼び出してログアウトしますが、その内容は HttpContext.Response に追加されます。は空です。

0x03 Cookie を通じてユーザーを識別する

.NET Core は CookieAuthenticationMiddleware ミドルウェアを使用して HttpContext 内の認証関連の Cookie を識別し、それによってユーザーの検証および承認情報を追加します。最も重要なのは、ユーザーの認証と承認の情報を記録する ClaimsPrincipal オブジェクトです (もちろん、上記のログインプロセスからわかるように、成功後のその他の情報も含めることができます)。ログイン、ユーザーの認証および承認情報を ClaimsPrincipal オブジェクトに保存し (実際には、この Cookie のキーと値のペアの認証情報は ClaimsIdentity として保存され、ClaimsPrincipal には複数の ClaimsIdentity を含めることができます)、HttpContext のヘッダーに Set-Cookie を追加します。 .Response、キーは Cookie ミドルウェア内にあります。指定された CookieName と Value は、このオブジェクトの暗号化された string です。将来、HttpContext はこの Cookie を持ち、Cookie ミドルウェアはこの CookieName に一致する Cookie を取り出し、それを復号して ClaimsPrincipal オブジェクトに復元し、HttpContext.User をこのオブジェクトに設定します。その後、MVCミドルウェアが対応するControllerとActionにルーティングするときに、Authorize機能で指定された認証とロールに従ってHttpContext.Userをチェックできます。チェックが満たされない場合はジャンプします。該当ページへ。したがって、Cookie ミドルウェアは MVC ミドルウェアの前に配置する必要があることに注意する必要があります。

ここで ClaimsPrincipal について話す必要があります。 ClaimsPrincipal オブジェクトには 1 つ以上の ClaimsIdentity オブジェクトが含まれます。 ClaimsIdentity オブジェクトは通常、Cookie 内の特定のキーと値のペアに対応します (個人的な理解です)。 Cookie ミドルウェアと ClaimsIdentity は、AuthenticationScheme を通じて接続されます。後で独自の認証サービスを作成するときに、Cookie ミドルウェアの AuthenticationScheme と、作成された ClaimsIdentity との一貫性も確保します。したがって、ClaimsIdentity にはユーザー認証とアクセス許可のクレームが含まれているのに対し、ClaimsPrincipal には複数の ClaimsIdentity を含めることができると言ったほうが正確です。パイプライン内に複数の Cookie ミドルウェアがある場合、それらは AuthenticationScheme によって区別されます。

ClaimsIdentity には、AuthenticationScheme に加えて、UserType と roleType という 2 つの重要なプロパティがあります。ここで、UserType はユーザー検証タイプを指定し、RoleType はロール検証タイプを指定します。これは、RoleType を「RoleName」として指定した場合、ロールの認証中に、Claims で Type「RoleName」のすべての値を検索し、Authorize で指定された RoleName が含まれているかどうかを確認することを意味します。ただし、.NET Core には ClaimTypes が付属しており、直接使用できます。たとえば、ロールの種類は ClaimTypes.Role です。ロールを追加するときに組み込みの ClaimTypes.Role が使用される場合、ClaimsIdentity を作成するときに、RoleType を明示的に指定する必要はありません。デフォルトのロール認証では ClaimTypes.Role が使用されます。

Cookieミドルウェアの追加については、スタートアップのConfigureメソッドのapp.UseIdentity拡張メソッドを通じて実装されます。この拡張メソッドにより、実際にはさまざまな Cookie 識別メソッドが追加されます。後で独自のユーザー認証管理を作成するときに 1 つだけ使用します。

0x04 独自のユーザー認証管理を作成する

ユーザー認証プロセスを理解した後、Identity コンポーネントを置き換える独自の認証管理を作成できます。これもデータベース操作と認証ビジネスロジックに分かれています。データベースについては多くは言いませんが、データベースはすべて IdentityRepository クラスで記述されており、非常に単純なデータ操作しかありません。便宜上、Dapper を使用し、データベースは Sqlite です。プログラムは起動時にデータベーステーブルをチェックし、チェックされない場合は空のテーブルを自動的に作成します。

認証サービスも比較的単純で、登録とログインの操作を提供するため、アクションに直接記述されます。便宜上、ロール管理ページは提供されていません。ロール認証機能をテストする場合は、データベースにロールを手動で追加してから、UserRoles のユーザーにロールを追加する必要があります。

ログイン:

登録:

ログアウト:

論理的な問題。たとえば、ユーザーのパスワードは次の場所に保存されます。クリアテキスト。プロセスに注目してください:)

0x05 最後に書いています

私はWebアプリケーションに触れるのが初めてで、多くの概念がよくわかりません。 Cookie 認証ユーザーを例に挙げます。私は以前、Cookie を介してユーザーを識別する方法しか知りませんでした。Cookie を受け取った後は、データベースまたはキャッシュから対応する許可情報を見つける必要があると常に考えていました。しかし、組み込みの Cookie ミドルウェアコードを読んだ後、認証情報は Cookie に直接保存されているため、復号化して逆シリアル化するだけで済むことがわかりました。 Identity アセンブリには他の多くのアセンブリ (セキュリティ、HttpAbstraction など) が含まれているため、最終的には理解できましたが、記事の内容の一部はコードに基づいています。、個人的な理解に基づいている部分もありますので、間違いがあってもご容赦ください。

以上が.NET Core 認定管理分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。