I've been using PrincipalPermission for a while in wcf services. [PrincipalPermission(SecurityAction.Demand, Role = SecurityRoles.CanManageUsers)]
Our roles are prefixed with: Can* and is how we achieve fine grained actions control with the built in asp.net membership system.
This makes it hard to know as a business unit what fine grained roles we can give to a user.
Here is my new approach and wanted to see if anyone can provide feedback, code review before i implement my suggestion.
1) aspnet_roles - business unit role
2) Extend the asp.net membership system by creating a permission table and Role_Permission table and User_Permission table (many to many)
3) create custom CodeAccessSecurityAttribute + that looks at new tables [CustomPermissionCheck(Security.Demand, HasPermission="can*")] first iteration i'll statically new the dependent repository.. ideally i would like an aop style attribute that has repository injected IPermissionRepository.HasPermission(...);
If i approach new aop way i probably will stop inheriting from CodeAccessSecurityAttribute -- what do the security guys have to say about this?
has anyone else solved this, is there something in the framework that i've missed?