Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java security evolution and concepts, Part 2

Discover the ins and outs of Java security

By Raghavan N. Srinivas, JavaWorld.com, 07/28/00

Page 4 of 6

Many access-control decisions are based in part on this property.

Permissions

Permission classes are at the very core of Java security and represent access to various system resources such as files, sockets, and so on. A collection of permissions can be construed as a customizable security policy for an installation.

For example, permission may be given to read and write files in the /tmp directory. Permission classes are additive in that they represent approvals, but not denials. It's possible to explicitly permit the reading of a particular file, but not to explicitly deny the reading of that file.

A number of permission classes are subclasses of the abstract java.security.Permission class, examples of which include FilePermission, AWTPermission, and even customized protections like SendMailPermission. For an exhaustive list of permissions, see Resources for a link to Li Gong's Inside Java 2 Platform Security.

Protection domains

It's possible to associate permissions with classes; however, it's more flexible to group classes into protection domains and associate permissions with those domains. A class's mapping to a domain occurs before the class is usable and is immutable thereafter. For instance, system classes can be effectively grouped under the system domain.

This relationship between the class and the permissions via the protection domain provides for flexible implementation mechanisms.

Policy

The numerous mappings of permissions to classes are collectively referred to as policy. A policy file is used to configure the policy for a particular implementation. It can be composed by a simple text editor or using policytool, a tool bundled with the Software Development Kit (SDK), which we'll discuss in a future article.

SecurityManager

As seen in Figure 4, the class java.lang.SecurityManager is at the focal point of authorization -- the implementation of the sandbox model in JDK 1.0 is a good example.

Prior to Java 2, SecurityManager was abstract; vendors had to create concrete implementations. In Java 2, SecurityManager is concrete, with a public constructor and appropriate checks in place to ensure that it can be invoked in an authorized manner. SecurityManager consists of a number of check methods. For example, checkRead (String file) can determine read access to a file. The checkPermission (Permission perm, Object context) method can check to see if the requested access has the given permission based on the policy. This method is relegated to the access controller in the default implementation. The access controller will raise an exception if the requested permission cannot be granted. Refer to the "Sidebar 2: Security exceptions" for an overview of security exceptions.

AccessController

The java.security.AccessController class is used for three purposes:

• To decide whether access to a critical system resource should be allowed or denied, based on the security policy currently in effect
• To mark code as privileged, thus affecting subsequent access determinations
• To obtain a snapshot of the current calling context, so access-control decisions from a different context can be made with respect to the saved context

While the SecurityManager can be overridden, the static methods in AccessController are always available. If you wish a particular security check to always be invoked, regardless of which security manager is in vogue, the AccessController methods should be called.