What benefit does your code receive if you decorate it with attributes demanding specific Security permissions?

Question

What benefit does your code receive if you decorate it with attributes demanding specific Security permissions?

Answer 1

Most security permissions are especially useful when building reusable libraries that are designed to run in partial trust. This way you can restrict access to certain functions when an calling assembly or AppDomain does not have the proper rights configured. For an application that runs in full trust, most security permissions are not that useful.

However, there is one attribute that I tend to use quite a lot and that is the PrincipalPermissionAttribute. When you decorate a class or function with this attribute, .NET will check on every access whether the current thread's principle has the proper rights. In other words, you can allow or deny access to that code based on the role of a user (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 outdated. I stopped using this particular attribute a years ago, because it uses a CLR built-in code weaving technique, that makes it really hard to do both unit and integration testing where you're not interested in specifically testing the security aspect of the code.

Instead, I found it much better to define my own attributes that declare permissions on operstions (typically defined by messages) and implement authorization in the infrastructural level (typically using decorator) instead of relying on code weaving.