私は wcf サービスでしばらく PrincipalPermission を使用しています。[PrincipalPermission(SecurityAction.Demand, Role = SecurityRoles.CanManageUsers)]
私たちの役割には接頭辞 Can* が付いており、組み込みの asp.net メンバーシップ システムを使用してきめ細かいアクション コントロールを実現する方法です。
これにより、ビジネス ユニットとして、ユーザーにどのような細かい役割を与えることができるかを知ることが難しくなります。
これが私の新しいアプローチであり、私の提案を実装する前に、誰かがフィードバックやコードレビューを提供できるかどうかを確認したかった.
1) aspnet_roles - ビジネス ユニットの役割
2) 権限テーブルと Role_Permission テーブルと User_Permission テーブル (多対多) を作成して、asp.net メンバーシップ システムを拡張します。
3) 新しいテーブルを参照するカスタム CodeAccessSecurityAttribute + を作成します [CustomPermissionCheck(Security.Demand, HasPermission="can*")] 最初の反復では、依存リポジトリを静的に新しくします。 IPermissionRepository.HasPermission(...);
私が新しい aop の方法にアプローチする場合、おそらく CodeAccessSecurityAttribute からの継承をやめるでしょう - セキュリティ担当者はこれについて何を言わなければなりませんか?
他の誰かがこれを解決しましたか、私が見逃したフレームワークに何かありますか?