Programming .NET Components, 2nd Edition

Principal-Based Security

As stated at the beginning of this chapter, .NET component-based security isn’t a cure-all. There is still a need to verify that the user (or the account) under which the code executes has permission to perform the operation. In .NET, the user is referred to as the security principal . It’s impractical to program access permissions for each individual user (although it’s technically possible); instead, it is better to grant permissions to roles users play in the application domain. A role is a symbolic category of users who share the same security privileges. When you assign a role to an application resource, you are granting access to that resource to whomever is a member of that role. Discovering the roles users play in your business domain is part of your application-requirement analysis and design, as is factoring components and interfaces. By interacting with roles instead of particular users, you isolate your application from changes made in real life, such as adding new users, moving existing users between positions, promoting users, or users leaving their jobs. .NET allows you to apply role-based security both declaratively and programmatically, if the need to verify role membership is based on a dynamic decision.

Declarative Role-Based Security

Apply declarative role-based security using the attribute PrincipalPermissionAttribute , defined in the System.Security.Permissions namespace:

 [AttributeUsage(AttributeTargets.Class|AttributeTargets.Method ...