どのデータを「クレーム」として保存する必要がありますか？

ASP.Net Coreでは、Claims認証は具体的な方法ではないことがわかりました。我々は、何も追加することができますClaimTypeし、ClaimValueペアを。groups、firstname、lastname、brithdate、canAccessThisURI、isEditorなどです。ただし、この方法（クレームとして保存できるものはすべて保存）では、アプリケーションデータの50％を含む巨大なクレームテーブルが作成されます。

良い方法として、クレームとして保存する必要がある一般的なデータは何ですか？

クレームは、システム内の誰かを識別または承認するために潜在的に使用できるユーザーに関する事実です。これらの2つの制約は、クレームとして置くものを制限するのに十分なはずです。

クレームに関するいくつかのアイデアは次のとおりです。

• ユーザーID
• ユーザー名
• ユーザーのメール
• 役割
• グループメンバーシップ

ユーザーのメタデータは、ユーザー向けにアプリをパーソナライズし、ユーザーをデータに関連付けるために必要なものに限定する必要があります。ユーザーのIDは、ユーザーをデータに関連付けたり、監査証跡を提供したりするのに十分です。貪欲にならないでください。

ロールとグループメンバーシップは、承認の要求です。たとえば、アプリケーションにグループがある場合、ユーザーが属するグループのリストを使用すると、プライベートグループにアクセスできるかどうかをすばやく確認できます。ロールはもう少し細かく、ユーザーが持つ特権について話します。これらは通常アプリケーション固有であるため、適用する必要があるものだけを追加します。

多くのシステム、特にSTS /フェデレーションシステムがこのようにしています。

• ユーザーを一意に説明する1つのクレーム
• 彼ら（および他の人）がアクセスできる一般的な概念的な事柄を説明する一連のクレーム

アプリ内のユーザーの「プロファイル」データは、使用している認証ソースとの間で変換されない場合があり、同じエンドポイントを常にまたはすべてのユーザーで使用することはできません。

古いフォーム認証に精通している場合は、ユーザー名とロールのモデルに似ており、System.Security.Claims.ClaimTypesの名前とロールを適切に使用すると、多くの組み込み機能はまだそのように見えます。

古いモデルでも新しいモデルでも、クレームやロールの継承はほとんど必要ありませんが、それを実装することは特に難しくはなく、実装することで、要求から機能を維持するために必要なクレームやロールの量を削減できます。要求する。

アプリケーションが誕生日を追跡する必要があるが、それをセキュリティメカニズムで使用する必要がない場合、それをクレームコレクションに保持しても何のメリットもありません。別のプロファイルデータセットなどに配置します。

アプリケーションが別のシステムからのクレームとして誕生日を取得する必要がある場合は、federatedAuthenticationをカスタマイズしたり、追加のクレームを永続化したりすることなどを検討しています。