Claim の定義方法を理解するのに苦労しています。クレームの作成に関する情報はウェブ上にたくさんありますが、どれも同意していないようです。異なる投稿でクレームの 4 つの属性を見つけました。
ユーザーが User オブジェクトを編集する権限を持っていることを示すクレームを作成するシナリオを考えると、これらの属性を設定する正しい方法は何ですか?
また、WIF には "Right" 属性のプロパティがないようです。「正しい」は WCF のコンテキストでのみ使用されますか?
私は混乱しています、助けてください！
編集：
ご回答ありがとうございます。これをもう少し具体的にするために、現在、カスタム クレームに次の 2 つのオプションがあります。
1-ClaimType=編集、ClaimValue=ユーザー
2-ClaimType=アクション、ClaimValue=EditUser
オプション1はより「クレームベース」のようで、オプションはより「ロールベース」のようです。考え？
Claim.Net には 2 つの異なるタイプがあります。1 つは WIF ( Microsoft.IdentityModel.Claims) にあり、もう 1 つSystem.IdentityModel.Claimsは WCF 以前の WIF で使用されていました (ただし、実際には WCT の一部ではありません)。あなたが言及したように、だけSystem.IdentityModel.Claims.Claimがプロパティを持っています。Right
私は WCF と ASP.Net でクレーム アプローチを使用し、WIF を使用した場合と使用しなかった場合を比較しましたが、WIF プログラミング モデルの方が間違いなくシンプルです。
あなたが説明するユーザー編集シナリオでは、適切な名前の役割を定義します。UserEditor は問題ないかもしれませんが、非常に具体的に聞こえます。これらのユーザーに付与するすべてのアクセス許可のコレクションを調べて、適切な要約名 (おそらく UserAdministrator?) を考え出す必要があります。
これらのユーザーについては、ロール クレーム (つまり、タイプhttp://schemas.microsoft.com/ws/2008/06/identity/claims/roleまたはMicrosoft.IdentityModel.Claims.ClaimTypes.Role) を追加する必要があります。ID プロバイダーがアプリケーションの外部にあり、それが発行するクレームを制御できない場合はClaimsAuthenticationManager、新しいロール クレームを追加して、発行されたクレーム セットを変換するカスタムを実装する必要があります。
次に、アクセスを許可する操作を次のように装飾できますPrincipalPermissionAttribute。
[PrincipalPermission(SecurityAction.Demand, Role = "UserAdministrator")]
このフレームワークは非常に柔軟で、ASP.Net、WCF、または通常の .Net 開発でさまざまな方法で使用できます。あなたの質問は、例を含む非常に具体的な回答を可能にするための多くのコンテキストを提供していません。
クレームには適切なプロパティが必要であるとどこで読んだのかわかりませんが、それは概念の誤用だと思います。
一連のクレームだけでは、ユーザーの権利は伝達されません。それよりも：
クレーム セット +ポリシー= ユーザー権利。
通常、クレーム ベースのアプリケーションは、一連の着信ユーザー クレームにポリシーを適用して、承認の決定を行います。ロール ベースのアクセスが最も一般的であるため、これらの決定は User.IsInRole("Manager") と同じくらい簡単です。これは、ユーザーが ClaimType="http://schemas.microsoft.com/ の要求を持っているかどうかを確認するだけです。 ws/2008/06/identity/claims/role" および ClaimValue="Manager".
オンラインの酒屋では、ユーザーが 21 歳以上である必要がある場合があります。その場合は、年齢の表示を確認します。ただし、年齢制限が 18 歳であるこの Web サイトのカナダ版では、別のポリシーを設定することになります。そのような「権利」がクレーム自体を介して伝達された場合、この種のポリシーの柔軟性は実現できません。