Я некоторое время использую PrincipalPermission в службах wcf. [PrincipalPermission(SecurityAction.Demand, Role = SecurityRoles.CanManageUsers)]
Наши роли имеют префикс: Can*, и именно так мы достигаем детального контроля действий с помощью встроенной системы членства asp.net.
Из-за этого бизнес-подразделению трудно понять, какие детализированные роли мы можем дать пользователю.
Вот мой новый подход, и я хотел узнать, может ли кто-нибудь предоставить отзыв, проверить код, прежде чем я реализую свое предложение.
1) aspnet_roles - роль бизнес-подразделения
2) Расширьте систему членства asp.net, создав таблицу разрешений, таблицу Role_Permission и таблицу User_Permission (многие ко многим)
3) создайте пользовательский атрибут CodeAccessSecurityAttribute +, который просматривает новые таблицы [CustomPermissionCheck(Security.Demand, HasPermission="can*")] на первой итерации я буду статически новым зависимым репозиторием. IPermissionRepository.HasPermission(...);
Если я подойду к новому пути aop, я, вероятно, перестану наследовать CodeAccessSecurityAttribute — что скажут по этому поводу специалисты по безопасности?
кто-нибудь еще решил это, есть ли что-то в рамках, что я пропустил?