What benefit does your code get if you decorate it with attributes that require specific security permissions?

Question

What benefit does your code get if you decorate it with attributes that require specific security permissions?

Answer 1

Most security permissions are especially useful when creating reusable libraries that are intended to be partially trusted. This way you can restrict access to certain functions when the calling assembly or AppDomain does not have the proper rights. For an application that works with full trust, most security permissions are not so useful.

However, there is one attribute that I use quite a lot, and that is PrincipalPermissionAttribute . When you decorate a class or function with this attribute, .NET will check every access whether the current flow principle has the correct rights. In other words, you can allow or deny access to this code based on the user's role (role-based security). Here is an example:

[PrincipalPermission(SecurityAction.Demand, Role = "Managers")] public static void ShowSalaryForEmployee(Employee employee) { // code here. } 

UPDATE 2017:

The answer above is completely out of date. I stopped using this particular attribute several years ago because it uses the CLR weaving technique, which makes it very difficult to test both single and integration, where you are not interested in a specific check of the code security aspect.

Instead, I was much better off defining my own attributes declaring operator permissions (usually defined by messages) and implementing infrastructure-level authorization (usually using a decorator) instead of relying on code transcoding.