クレームベース認証は初めてです。私はいくつかの記事を調べましたが、クレームベース認証の正確な使用法を理解できませんでした。クレームベース認証について私が持っているいくつかの疑問を次に示します。
クレームベース認証を理解し、アプリケーションで使用できるように、誰かが私に説明を提供できますか?
さらに、クレームは認証とは関係ありません。
クレームベースまたはロールベースの認証などはありません。それは、アプリケーションが連携できる方法で ID をモデル化することです。
役割も (固定の true/false 値を持つ) クレームです。クレームは、キーと値のペアで表現力を高めるだけです。
最終的に、クレームを使用する主な利点は次のとおりです。
サービスに一貫したプログラミングモデルを提供します。特定のセキュリティメカニズムを実装する方法を知る必要はありません。あるサイトでは、ユーザー名とパスワードの認証/承認、別のActiveDirectoryを使用する場合があります。あなたがしているのはすべての場合にクレームを処理することだけなので、あなたのサービスはどちらの方法も気にしません。
セキュリティの実装について自分自身を気にする必要はありません。これはサードパーティによって行われます。
ドメインに合わせてクレームをカスタマイズし、それらを承認ロジックの拡張として扱うことができます。標準のセキュリティプロパティは通常、役割などの基本情報のみを提供します。もちろんこれを拡張することはできますが、より多くの作業を行うため、実装が困難になることがよくあります（たとえば、ADの拡張は技術的な課題ではなく、ポリシーの制約であることがよくあります。管理者は、特定のアプリケーションに対応するためにADスキーマを変更することを躊躇します。 ）。
相互運用可能-クレーム[形式]は標準に基づいているため、セキュリティの基盤となるテクノロジーが抽象化されるにつれて、異なる言語やドメインのサービス間で相互運用可能になります。
新しい.NET4.5WCFサービスを作成している場合、名前空間は以前のセキュリティ実装と下位互換性があるため、既にクレームの使用を開始できます。したがって、クレームが現在は適切でないと判断した場合でも、アップグレードするのに適した立場になります。後で。
私がここに書くことができるよりもはるかに多くの主張があり、主張を検討することが良いことかもしれないという追加の理由を持つ他の人がいると確信しています。
お役に立てれば。