「申し立て」として保存する必要があるデータはどれですか？
ASP.Net Coreでは、Claims承認は非常に具体的な方法ではないことがわかりました。 ClaimTypeとClaimValueのペアとして何でも追加できます。 groups、firstname、lastname、brithdate、canAccessThisURI、isEditorなどです。ただし、この方法（クレームとして保存できるものはすべて保存）では、アプリケーションデータの50％を含む巨大なクレームテーブルが作成されます。
良い方法として、クレームとして保存する必要がある一般的なデータは何ですか？
クレームは、システムの誰かidentifyまたはauthorizeに使用される可能性があるユーザーに関する事実です。これらの2つの制約は、クレームとして置くものを制限するのに十分なはずです。
クレームのいくつかのアイデアは次のとおりです。
- ユーザーID
- ユーザー名
- ユーザーのメール
- 役割
- グループメンバーシップ
ユーザーのメタデータは、ユーザー向けにアプリをパーソナライズし、ユーザーをデータに関連付けるために必要なものに限定する必要があります。ユーザーのIDは、ユーザーをデータに関連付けたり、監査証跡を提供したりするのに十分です。貪欲にならないでください。
ロールとグループメンバーシップは、承認の要求です。たとえば、アプリケーションにグループがある場合、ユーザーが属するグループのリストを使用すると、プライベートグループにアクセスできるかどうかをすばやく確認できます。役割はもう少し細かく、ユーザーが持つ特権について話します。これらは通常アプリケーション固有なので、適用する必要があるものだけを追加します。
多くのシステム、特にSTS /フェデレーションシステムがこのようにしています。
- ユーザーを一意に説明する1つのクレーム
- 彼ら（および他の人）がアクセスできる一般的な概念的な事項を説明するさまざまなクレーム
アプリ内のユーザーの「プロファイル」データは、使用している認証ソースとの間で変換されない場合があり、同じエンドポイントを常にまたはすべてのユーザーで使用することはできません。
古いフォーム認証に精通している場合は、ユーザー名とロールのモデルに似ており、System.Security.Claims.ClaimTypesの名前とロールを適切に使用すると、多くの組み込み機能はまだそのように見えます。
古いモデルでも新しいモデルでも、クレームやロールの継承はほとんど必要ありませんが、それを実装することは特に難しくはなく、実装することで、要求から機能を維持する必要があるクレームやロールの量を削減できます。要求する。
アプリケーションで誕生日を追跡する必要があるが、それをセキュリティメカニズムで使用する必要がない場合、それをクレームコレクションに保持しても何のメリットもありません。別のプロファイルデータセットなどに配置します。
アプリケーションで誕生日を別のシステムからのクレームとして取得する必要がある場合は、federatedAuthenticationのカスタマイズや追加のクレームの永続化を許可するようなものを検討しています。