Problem solve Get help with specific problems with your technologies, process and projects.

Customizing the Security Architecture

This chapter demonstrates ways to augment the security architecture, including how to develop custom implementations of the various security classes.

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, 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 package. Other permission classes are:

  • 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.

  • This was last published in June 2003

    Dig Deeper on Secure software development

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.