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


  • This was first published in June 2003

    Dig deeper on Software Development Methodology

    Pro+

    Features

    Enjoy the benefits of Pro+ membership, learn more and join.

    0 comments

    Oldest 

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    -ADS BY GOOGLE

    SearchCloudSecurity

    SearchNetworking

    SearchCIO

    SearchConsumerization

    SearchEnterpriseDesktop

    SearchCloudComputing

    ComputerWeekly

    Close