37

新しいASP.NET4.5コードは、ASP.NETRoleProviderをClaimsProviderに「再ペアレント化」しました。

私が理解しようとしているのは、「クレームベース」の承認の例はどのように見えるでしょうか(できればMVC4で)?私のAuthorize属性は、この機能とどのように相互作用するか、または相互作用しませんか?WebSecurity andRolesAPIは変更されていません。「DoesUserHaveClaim()」署名はありません。同様に、Authorize属性がクレームとどのように相互作用するかは明確ではありません。

この「承認の請求」機能は、主にOAuthを対象としていましたか?もしそうなら、クレームはどのように私のアプリケーションに転送されますか?クッキー?それとも、このクレームプロバイダー機能は幅広い用途を対象としていましたか?

要するに、ClaimsPrincipalを使用するための話は何ですか?

私が見た中でちょっと意味のあるものに最も近いのは、この議論です。しかし、それは時代遅れだと思います。MVC4インターネットプロジェクトテンプレートが生成するものと比較する必要があります。それでも、セットアップでAuthorize属性を使用する方法は提案されていませんでした。

アップデート

私はこれらの情報源から私の質問に対する答えを見つけました:

  1. ClaimsPrincipalの備考セクションでは、WebSecurity、Roles、およびAuthorizeAttribute APIは、実際には必要に応じてクレームチェックに要約されると説明しています。
  2. クレームベースのMVC4の例が(他の人と一緒に)ここにあります。
  3. 基本的なSAMLストーリーをここに示します
4

1 に答える 1

33

クレームベースのセキュリティは、セキュリティモデルをアプリケーションドメインから切り離すのに役立ちます。クレームは、電子メール、電話番号、またはユーザーがスーパーユーザーであるかどうかを示すフラグなど、ユーザーのIDに添付するものであれば何でもかまいません。これにより、承認プロセスの設定方法に究極の柔軟性がもたらされます。従来、ASP.NETアプリケーションでは、許可する役割を決定し、アプリケーションをプログラミングするときにそれらを適用する必要がありました。次に、ユーザーがそれらを承認する役割を持っているかどうかを確認します。これにより、セキュリティモデルがアプリケーションと混ざり合います。クレームベースでは、柔軟性がはるかに高く、リソース(例:注文管理システムの注文)と操作(例:読み取り、書き込み、実行)を入力パラメーターとして受け取る承認スキームを設定するのが一般的です。承認プロセス、アプリケーションからセキュリティを効果的に切り離します。見るこの手法の例については、ClaimsPrincipalPermissionAttributeを参照してください。

OAuthにはクレームベースのセキュリティが必要ですが、他の承認スキームでもうまく機能します。アプリケーションで使用するカスタムクレームには、ClaimsPrincipal.Currentからアクセスできます。ASP.NETセキュリティパイプラインはデフォルトではこれを行いませんが、この情報をCookieに保存する手法もあります。

参照するディスカッションは、4.5で.NETの一部となったWindows Identity Foundation(WIF)に関するものであり、クレームベースのIDが第一級市民である理由です。すべてのプリンシパルタイプはClaimsPrincipalから継承します。クレームベースのセキュリティの概要については、この無料の電子ブック「クレームベースのIDとアクセス制御のガイド(第2版)」を参照してください。この分野の真の専門家はドミニク・ベイヤーであり、彼のブログはこのトピックに関する有用な情報でいっぱいです。彼はまた、「ASP.NET4.5のIDとアクセス制御」と呼ばれるPluralsightに関する優れたオンライントレーニングコースを持っています。

于 2012-11-19T19:45:33.790 に答える