ASP.NET MVC 5 認証の新しいビットを見ていると、すべてがClaimsIdentityになっていることに気付きました。これらの値がどこに保存されているのか疑問に思っていました:
セッション、キャッシュ、または Cookie 自体。
Cookie に格納されている場合、Cookie のサイズ制限を超える前に格納できるクレームの数には明らかな制限があります。
ASP.NET MVC 5 認証の新しいビットを見ていると、すべてがClaimsIdentityになっていることに気付きました。これらの値がどこに保存されているのか疑問に思っていました:
セッション、キャッシュ、または Cookie 自体。
Cookie に格納されている場合、Cookie のサイズ制限を超える前に格納できるクレームの数には明らかな制限があります。
前述のように、さまざまなソースからのクレームは、デフォルトで OWIN の認証プロセス中に作成される Cookie を介して、セッション間で保持できます。これは通常、\App_Start\Startup.Auth.cs で構成されます。Cookie の有効期限、スライド式の有効期限 (Cookie のタイムアウトは再訪問時に更新される) が必要かどうか、認証/承認エンドポイントの場所などを設定できます。後の部分では、ClaimsPrincipal 中に追加の Claim を提供するようにフックできます。 ClaimsIdentity 作成プロセス。適切な有効期限があれば、ユーザー セッションに対してこれを 1 回だけ行う必要があります。その後サイトに戻ると、OWIN ミドルウェアは Cookie を解析し、このステップのすべてのクレームを再作成します。
Cookie のサイズについて心配する必要はありません。また、新しい OWIN 認証ミドルウェアは Cookie のチャンクを実装しています (現在、プレリリース ソースから入手できます - 安定版はチャンクしません)。
これを社内に実装し、複数のクレーム ソースを用意しています。内部シングル サインオン サービス、アクティブ ディレクトリ、独自のアプリケーション データベース (追跡対象のユーザーに関する役割と追加プロパティ用)。
ClaimsIdentity 自体にはストレージ メカニズムがありません。ただし、OWIN Cookie ミドルウェアを使用する場合、はい、Cookie に保存されます。はい、制限があります。