Я некоторое время использовал 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 *")]
На первой итерации я буду статически создавать новый зависимый репозиторий .. в идеале я хотел бы, чтобы атрибут стиля aop имел встроенный репозиторий.
Если я подойду к новому, я, вероятно, перестану наследовать от CodeAccessSecurityAttribute - что скажут об этом парни из службы безопасности?
Кто-нибудь еще решил это, есть что-то в рамках, что я пропустил?