The following excerpt is from chapter 7, Customizing the Security Architecture, of Inside Java 2 Platform Security, Second Edition: Architecture, API Design and Implementation, written by Li Gong, Gary Ellison and Mary Dageforde, and published by Addison-Wesley Professional Publishing Group.
This chapter demonstrates ways to augment the security architecture. We
explain how to develop custom implementations of the various security classes
that support either extensibility or substitution mechanisms. We also describe the mechanics of implementing a custom Permission class, extending the function-ality of the SecurityManager class, implementing a custom Policy provider,
and implementing a DomainCombiner interface.
7.1 Creating New Permission Types
Recall from Section 5.1 that J2SDK 1.2 introduced a new hierarchy of typed and parameterized access permissions, rooted by an abstract class, java.security.Permission. Other permissions are subclassed from either the Permission class or one of its subclasses and appear in relevant packages. For example, the FilePermission permission representing file system access is located in the java.io package. Other permission classes are:
java.net.SocketPermission for access to network resources
java.lang.RuntimePermission for access to runtime system resources,
such as class loaders and threads
java.lang.PropertyPermission for access to system properties
java.awt.AWTPermission for access to windowing resources
As this list illustrates, accesses to controlled resources, including properties and packages, are represented by the permission classes.
Applications are free to add new categories of permissions. However, it is
essential that, apart from official releases, no one extend the permissions that are built into the SDK, either by adding new functionality or by introducing additional keywords into a class such as java.lang.RuntimePermission. Refraining from doing this maintains compatibility.
When creating a new permission, it is advisable also to declare the permission
to be final. The rule of thumb is that if the permission will be granted in a security policy, it is probably best to declare it final. However, at times it may be necessary to create a class hierarchy for your custom permission. If this is the case, a couple of design heuristics are worth mentioning. First, if the abstract, or base, class of your permission or permission collection has a concrete implementation of the implies method, it is recommended that the implies method take the type of the permissions into consideration.
Read the rest of this chapter.
