0

確かに、WIFについて読むほど、物事のやり方について混乱します。物事を楽にするはずだったものについては、それがなければどうなるか想像できません。シナリオが多すぎて、自分に合ったシナリオを見つけるのに苦労していると思います。

いくつかの（私の観点からは良いが、おそらく悪い）理由で、公式のSTS（ADFSまたは）を避けてから、物事を単純ACSにするために自分で作成したいと思います！

私が探しているのは、ユーザー（AD IDからラップする）、ユーザーのグループ（カスタム）、およびユーザー/グループを割り当てるロール（カスタム）を処理できることです。

クライアント側のメソッドをClaimsPrincipalPermissionAttribute（または同等の宣言型）で装飾して、現在のユーザーが必要な役割を持っているかどうかを確認したいと思います。WindowsクライアントアプリケーションまたはIIS/WASでホストされているサービスからそれを使用できるようにしたいWCF（Net.tcpがバインディングの私の優先選択です）。

WIFソリューションの形成方法を改善せずに資料を読むのに疲れているので、いくつかのガイダンスは大歓迎です。

ありがとうございました ！

4

1 に答える 1

1

つまり、まず第一に、単純なSTSのようなものはありません。STSは批判的なセキュリティインフラストラクチャであり、おそらく最初のWIFプロジェクトではないことをご理解いただければ幸いです。オープンソースのSTSを調べてアイデアを得たい場合は、http：//thinktecture.github.com/Thinktecture.IdentityServer.v2/を参照してください。

次のauthZはサーバー側で発生します（クライアント側はユーザビリティです）。単純に、役割のチェックはPrincipalPermissionを使用して行われます。ClaimsPrincipalPermissionは、サービスコードとセキュリティコードを分離することをお勧めします。詳細については、ClaimsAuthorizationManagerを参照してください。

于 2013-02-18T08:29:54.910 に答える