Posted on: 5/26/2011 1:08:59 AM | Views : 572

I have read a lot about abstracting to privileges rather than directly using roles.  So "isAuthorizedToEdit(UserId, ArticleId)" rather than a lengthy set of IsInRole("Author") and/or IsInRole("Editor") stuff.  That keeps all the complexity in one place ( a set of privilege classes), so makes perfect sense.
However, I have recently been using decorations on classes, like:
<PrincipalPermission (SecurityAction.Demand, Role="Author")> That's not going to work if I want to check a privilege rather than a role.  So, I think, two questions:
Can I extend something, somewhere to define another flavour of security attribute - allowing me to demand "privilege" rather than "role"? If I can do that, can I make that attribute take parameters - for example an Article Id? I guess the third question falls out of the first two - and it's whether I'm better just coding the necessary checks rat ...

Go to the complete details ...