.netクレームベースのIDフレームワーク
たとえば、特定のアカウント＃123456でユーザーが操作（表示または編集）を実行することを制限したい場合（銀行口座などの事業体について話している）、クレームを作成することをお勧めします。アカウントごとに、表示または編集できますか？
セットに多くのクレームがあることの不利な点はありますか？システム管理者は、システム内のすべてのアカウントにアクセスできるため、数百のクレームが作成される可能性があります（アカウントごとに複数のクレームが作成される可能性があります）。
大規模なクレーム セットの最も直接的な結果は、ネットワーク上のすべての関連システム間でトークンがやり取りされるため、パフォーマンスが低下することです。たとえば、既定では、WIF はトークンをシリアル化し、それらを Cookie に入れます。したがって、実際には、そこに保存できるデータの量も制限されます。これに対処する方法は他にもありますが、根本的な問題は解決していません。
2 番目の考慮事項は、ユーザーとアカウントの関連付けを誰がどこで管理するかです。それがアプリケーション固有のものである場合、それらの関連付けを中央の STS (クレームの発行者) にプッシュすることはほとんどありません。その結果、2 つの STS が作成されます。ユーザー (および ID プロバイダー: IdP) を識別するものと、IdP によって発行されたトークンをアプリが管理するもの (特定のユーザーのアカウント リストを含む) に変換するアプリケーション固有の STS です。
そうは言っても、ユーザーとそのアカウントの間の関連付けは、多くのアプリケーションで再利用可能なものである可能性があり、それを特殊な STS の背後に配置することは理にかなっているかもしれません。
3 つ目の考慮事項として、不必要な情報開示の可能性があります。アプリケーションは、ユーザー X がアカウント 123 にアクセスできるかどうかだけを知る必要がある場合があります。ユーザー X がアクセスできるすべてのアカウントのリストを提供することで、必要な情報をさらに開示できます。
一般的なガイドラインとして、クレームは「粗粒度」属性の方が優れています。「きめの細かい」アクセス制御は、インフラストラクチャの最適化を使用できるアプリ内で処理する方がおそらく適切です。
極端な例を次に示します。ファイル システムを想像してみてください。ユーザーがアクセスできるファイルの名前をクレームとしてエンコードしますか? 数百万になる可能性があるため、可能性は低いです...
別の極端な例: データベースに行レベル セキュリティを実装する場合。各ユーザーのrow_idをクレームとしてエンコードしますか? 多くの可能性があるため、これは非常にアプリケーション固有であり、データベースクエリを使用して行フィルタリングを解決する方がおそらく簡単 (かつはるかに効率的) であるため、可能性は低いです (これはインフラストラクチャの最適化の例です)。