Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• 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

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

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

Secure thread collaboration across protection domains

Build solid applications with the AccessControlContext and the GuardedObject classes

By Todd Sundsted, JavaWorld.com, 12/15/00

1. You're building an application with two threads, a server and a client,at its heart. The design requirements permit the server thread to access every file in the filesystem. However, they forbid the client thread from accessing files outside a small part of the filesystem. The server API defines a mechanism whereby a client thread can request the server thread to perform a sensitive operation on an arbitrary file. How do you ensure that the server thread carries out this operation only on files that the client can legitimately access?
2. Your application's threads consist of a producer and a consumer. The design requirements are the same as above -- the producer is the server, and the consumer is the client. When requested by the consumer thread, the producer thread creates a filesystem object, such as an instance of the FileInputStream class, and hands it to the consumer. The consumer can immediately use the resource, hold on to it, or hand it to another consumer. How do you ensure that the consumer thread doesn't use resources it should not have access to?

When confronted with situations like the two outlined above, you should develop solutions that take advantage of the security features provided by the Java programming language and class library. This will save you work and prevent you from making mistakes. This month I'll take you on a tour of the AccessControlContext and the GuardedObject classes, two tools that will help you solve problems like those above.

Java security in a couple of paragraphs

Although the two preceding problems differ slightly, both share a common characteristic. They both involve making security-related decisions outside the bounds of Java's standard security machinery.

In order to understand what that means, it's worth taking a few moments to learn about Java security. Let's dive in.

Every method is part of a class. Every class is associated with a protection domain. A protection domain is a collection of classes that share critical security-related features -- they originate from the same place, and the same entity signs them. Every protection domain is associated with a set of permissions that define the security-sensitive operations that classes in the protection domain can perform.

That makes up only part of the picture. The decision whether or not to allow a security-sensitive operation to proceed depends not only on the permissions held by the current method but also on the permissions held by the method that called the current method, and by the method that called the method that called the current method, and so on, all the way back to the first method invocation by the Java Virtual Machine (VM).

Figure 1. A thread's execution context

If you imagine the chain of method calls as a stack of blocks, it would look something like Figure 1, which I refer to as the execution context. Every thread has its own execution context.

By examining the execution context, the AccessController class decides whether or not to allow a method to execute a piece of security-critical code. More specifically, it makes the determination by examining the protection domains associated with the methods in the execution context. The AccessController class permits the operation if and only if every protection domain in the current execution context holds the appropriate permission. This "principle of least privilege" is a key characteristic of the Java security model.