Creating Your Own Code Access Permissions

The .NET Framework supplies a set of code access permission classes designed to help protect a specific set of resources and operations, focusing on those resources exposed by the .NET Framework. These permission classes are described briefly in the Permissions topic and in detail in the reference documentation for each permission class. For most environments, the built-in code access permissions are adequate. However, in some situations, it might make sense to define your own code access permission class. This topic discusses when, why, and how to define custom code access permission classes.

If you are defining a component or class library that accesses a resource that is not covered by the built-in permission classes but needs to be protected from unauthorized code, you should consider creating a custom code access permission class. If you want to be able to make declarative demands for your custom permission, you must also define an attribute class for the permission. Providing these classes and making demands for the permission from within your class library enables the runtime to prevent unauthorized code from accessing that resource and enables an administrator to configure access rights.

There are other situations in which a custom permission might be appropriate. When a built-in code access permission class protects a resource but does not sufficiently control access to that resource, you might need a custom code access permission. For example, an application might use personnel records for which each employee record is stored in a separate file; in such a case, read and write access could be controlled independently for different types of employee data. An internal management tool could be authorized to read certain sections of an employee's personnel file but not to modify those sections. In fact, it might not even be allowed to read some sections.

Custom code access permissions are also appropriate in cases where a built-in permission exists but is not defined in a way that enables it to protect the resource appropriately. For example, there might be a case in which there is UI functionality, such as the ability to create menus, that must be protected but is not protected by the built-in UIPermission class. In that case, you could create a custom permission to protect the ability to create menus.

Wherever possible, permissions should not overlap. Having more than one permission protecting a resource presents a significant problem for administrators, who must then be sure to deal appropriately with all the overlapping permissions every time they configure the rights to access that resource.

Implementing a custom code access permission involves the following steps, some of which are optional. Each step is described in a separate topic.

1. Design the Permission class.
2. Implement the IPermission and IUnrestrictedPermission interfaces.
3. Implement the ISerializable interface, if necessary for performance or to support special data types.
4. Handle XML encoding and decoding.
5. Add support for declarative security, by implementing an Attribute class.
6. Demand custom permission for your permission, where appropriate.
7. Update security policy to be aware of the custom permission.

See Also

Code Access Security | Permissions | Extending Metadata Using Attributes | FileIOPermission Class | UIPermission Class | Designing Permission | IPermission Interface | IUnrestrictedPermission Interface | ISerializable Interface | Adding Declarative Security Support | Demanding a Custom Permission | Updating Security Policy