|Apache Tuscany > Home > SCA Overview > SCA Java > Java SCA Documentation Menu > Security Aware Programming in Tuscany||User List | Dev List | Issue Tracker|
As you develop software for the Apache Tuscany project, it is important to be aware and maintain the security features of the Java platform. Java's success is promoted by its security architecture and relative absence from security problems. Similarly, Tuscany will benefit as a platform if the developers take care to keep it secure and free from ill-intentioned users.
This article focuses on the security manager and access control mechanisms in the Java platform and the Tuscany code base. The focus here is not on SCA applications and samples, but rather contributions that affect the Tuscany runtime including any contributions or additions such as new bindings, implementations, or data bindings. Taking advantage of the security manager and limiting access to secure areas of the code base are the primary defense against unsafe operation of Tuscany's SCA platform. And since Tuscany code is available for anyone to read, it is important to prevent any unprivileged access to the system on which Tuscany is running. This requires that developers understand application runtime and server policies and how to guard the system resources. Here is a good overview of Java Security.
By default, Java application code and the Tuscany code base run in an unsecure environment with no security manager. This gives the Java application access to all system resources. The application may read and write all system properties, open and read any system files, and do all sorts of unprotected actions. All Tuscany code will run unhindered in this environment. And all malicious Tuscany users will also run unhindered in this environment.
You may turn security on by running your Tuscany application with the -Djava.security.manager option on the command line. The default security manager delegates access control decisions to java.security.AccessController. The AccessController determines access authority for your Java code by consulting the permissions in a java.security.Policy class usually specified in the default security.policy file.
There is only one Policy object installed into a Java runtime at any given time. The default behavior for Java is to load the authorization data from one or more security policy files, but Tuscany users may add to or replace the policy by running with additional policy information on the command line. For instance "-Djava.security.manager -Djava.security.policy=tuscany.policy -Dpolicy.allowSystemProperty=true" will add the permissions in the tuscany.policy file to the default Java permissions. If you specify "-Djava.security.policy==tuscany.policy" you replace the default policy with those specified in the Tuscany policy file. When Tuscany is run by an application server (whether it be WebSphere, Geronimo, or other), the policy of the server will form the starting point for Tuscany's security policy.
Each policy file will contain a list of grant statements. A grant tells the runtime where the code came from (a URL specifying the code base), who signed the code (a list of signer certificates), and what permissions are given. The permissions can be read write permissions to the file system, access to system properties, or class loading privileges.
This example grant statement is quite a broad bludgeon. Namely it says that all Tuscany code has been granted all permissions. This is not much different that running without a security manager. In practice, a user policy will want much finer-grained permissions towards the Tuscany code and allow only specific pieces of the code to have privileged access. The remainder of this article shows how to locate those permissions and how to enable secure checks for them.
In summary, with security on, Tuscany class XYZ can access a secured resource only if the security manager's AccessController has determined the proper permissions are available in the security policy. Tuscany code that calls a protected Java API will only work with an AccessController doPrivileged block and the proper permissions in place. Otherwise, the Tuscany code will not run properly with security on, and it will throw SecurityExceptions left and right. Many times these SecurityExceptions will be passed back to the Tuscany runtime and then be wrappered in a ServiceRuntimeException and presented to the user. Not good.
What are some of the Java APIs that might cause your Tuscany code to produce a SecurityException? In the Java API Reference, any Java API that throws a SecurityException is a candidate.
Whenever you use one of these security enabled Java APIs (any API with a "throws SecurityException" suffix), you must do two things to ensure your code will run with security on:
To be a little more concrete to Tuscany developers, let's go through some common API groups that they are likely to use.
This list is just a general overview. Once again, any API that throws a SecurityException is something that your Tuscany code should be privileged and permitted to use.
The final step of making your code security enabled is to add AccessController privileged blocks around your enabled code. You must be careful here. You cannot put a privileged block with a wide scope. That is similar to running with security turned off. You also must be careful not to grant privilege code that a malicious user could use. Be very careful of granting privilege to any public API that a user can use with malicious parameters. Here is a more in-depth article.
The type of coding pattern you use is based primarily on three considerations:
In the simplest case, let's say you use a checked Java API that throws no exceptions other than SecurityException. (Recall that SecurityException is thrown by all of these APIs.) For instance, your brand new Tuscany "Blatz" extension needs to load the "blatz" library before it runs.
Notice that the code is using the Java type safe syntax to ensure the proper casting of the method run return type. The class in the <class specification> should always match the return type class type.
In the next example, let us examine how a Java API with a boolean return type is handled. Notice that we are using the autoboxing feature of Java to convert from boolean to Boolean.
Using this succinct anonymous class, you must make sure any input parameters are final instances. This is a requirement of the Java syntax. If you have a parameter that has undergone multiple assignments, you can easily create a final version of that input parameter and pass it into the block.
Finally, if your checked Java API throws an exception, such as the IOException shown here, you need to catch it and cast it to match any checked exceptions on your method, or you need to add the PrivilegedActionException to the throws signature of your method.
This article shows just a few techniques that cover many of the security issues that arise in the Tuscany code base. If you are aware of the Java security architecture and how to control access to guarded resources, you can guard against malicious users who might use the Tuscany code base for no good.