クレームベースの承認の使用
新しいASP.NET 4.5コードは、ASP.NET RoleProviderをClaimsProviderに「再ペアレント化」しました。
私が理解しようとしているのは、承認の「クレームベース」の例はどのように見えるでしょうか（MVC4が望ましい）。 Authorize属性はこの機能とどのように相互作用しますか？ WebSecurity and Roles APIは変更されていません。 「DoesUserHaveClaim（）」シグネチャはありません。同様に、Authorize属性がクレームとどのように相互作用するかは明確ではありません。
この「クレーム認証」機能は主にOAuthを対象としたものでしたか？もしそうなら、クレームはどのように私のアプリケーションに転送されますか？クッキー？または、このクレームプロバイダーの機能は、より広範な使用を目的としていましたか？
要するに、ClaimsPrincipalを使用するためのストーリーは何ですか？
私が見た中で最も意味のあるものに最も近いのは この議論 です。しかし、私はそれが日付を付けられていると思います-それはMVC4インターネットプロジェクトテンプレートが生成するものと比較されるべきです。それでも、セットアップでAuthorize属性を使用する方法は提案されていませんでした。
更新
私はこれらの情報源から私の質問への答えを見つけました：
- ClaimsPrincipalの備考セクション は、WebSecurity、Roles、およびAuthorizeAttribute APIが実際に必要に応じてクレームチェックを煮詰めることを説明しています。
- クレームベースのMVC4の例はここにあります （他のものと一緒に）。
- 基本的な SAMLストーリーはここに示されています 。
クレームベースのセキュリティは、セキュリティモデルをアプリケーションドメインから分離するのに役立ちます。クレームは、電子メール、電話番号、ユーザーがスーパーユーザーであるかどうかを示すフラグなど、ユーザーのIDに添付するものであれば何でもかまいません。これにより、承認プロセスの設定方法に究極の柔軟性がもたらされます。従来、ASP.NETアプリケーションでは、許可する役割を決定し、アプリケーションのプログラミング時にそれらを適用する必要がありました。次に、ユーザーがそれらを承認するロールにあるかどうかを確認します。これにより、セキュリティモデルとアプリケーションが混在します。クレームベースでは、はるかに柔軟性が高く、リソース（例：注文管理システムでの注文）と操作（例：読み取り、書き込み、実行）を入力パラメーターとして使用する承認スキームをセットアップする方が一般的です。アプリケーションからセキュリティを効果的に分離する承認プロセス。この手法の例については、 ClaimsPrincipalPermissionAttribute を参照してください。
OAuthでは、クレームベースのセキュリティが必要ですが、他の認証スキームでも同様に機能します。アプリケーションで使用するカスタムクレームには ClaimsPrincipal.Current からアクセスできます。 ASP.NETセキュリティパイプラインはデフォルトでこれを実行しませんが、この情報をCookieに保存する手法もあります。
あなたが言及している議論は、4.5で.NETの一部となったWindows Identity Foundation（WIF）に関するものであり、クレームベースのアイデンティティがファーストクラスの市民である理由です。 PrincipalタイプはすべてClaimsPrincipalから継承します。クレームベースのセキュリティの概要については、この無料の電子書籍「 クレームベースのIDとアクセス制御のガイド（第2版） 」を参照してください。この分野の真の専門家はドミニク・バイアーであり、 彼のブログ はこのトピックに関する有益な情報が満載です。また、Pluralsightで「 ASP.NET 4.5でのIDとアクセス制御 」と呼ばれる優れたオンライントレーニングコースを持っています。