tuscany-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Tuscany: Running Tuscany with Java 2 Security Enabled (page edited)
Date Thu, 21 Aug 2008 07:11:00 GMT
Running Tuscany with Java 2 Security Enabled (TUSCANY) edited by haleh mahbod
      Page: http://cwiki.apache.org/confluence/display/TUSCANY/Running+Tuscany+with+Java+2+Security+Enabled
   Changes: http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=92356&originalVersion=1&revisedVersion=2


h1. Running Tuscany with Java 2 Security Enabled
[*Java Security*| http://vcasmo.com/video/beckerdo/2750] is available in Video, use tuscany

h2. Overview of Java 2 Security

*Apache Tuscany* promotes the Java 2 security model by allowing one to run Service Component
Architecture (SCA) applications in a secured environment. By default, with Java 2 security
disabled, Java application code and the Tuscany runtime code base run in an unsecure environment
with no security manager. This gives the Java application and Tuscany runtime 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.

With Java 2 security enabled, the user contribution to the SCA domain has very tight security
restrictions. This ensures that the user SCA application does not introduce mischevious code
(for instance with a user-provided custom classloader) or perform unprotected investigations
(such as when a user-provided application starts snooping around the file system looking for
interesting files.) The Tuscany runtime is also forced to abide by these tight security resitrictions,
but the runtime has been fitted and tested with privileged code to check for proper access
permissions before performing any sensitive operations. Because of this privileged code which
obeys the Java 2 security architecture, the Tuscany runtime acts as a proxy and performs sensitive
operations on behalf of the user application.

The purpose of this article is to show how one can run Apache Tuscany and SCA applications
in various environments while enabling Java 2 security and ensuring the application is running
in a secured environment. Tuscany users and deployers and administrators should read this
article. More in-depth runtime developers should also proceed onto the associated article
[Security Aware Programming in Tuscany].

h2. Enabling Java 2 Security from a Command Line

The most basic way to run Tuscany applications is from a command line window or shell. You
may enable security in this environment by running your Tuscany application with the java.exe
{{-Djava.security.manager}} option on the command line. This enables the default Java security
manager which 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"}}
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. The format of the java.security.policy is a URL, which
can contain any of the legal URL protocols such as file: or http: protocol.

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.
An example of a granting all permission to an unsigned Tuscany code base is given here:
{code:title=security.policy example|borderStyle=solid}
grant codeBase "file:$/{{user.home}}/tuscany/java/sca/-" {
  permission java.security.AllPermission;
This example grant statement is quite a broad bludgeon. Namely it says that all Tuscany code
has been granted all permissions. This seems like this is not very secure as it provides all
permissions to Tuscany, however, it is still a step up from running with no security policy.
In this case Tuscany is provided with privileged access, while user application are not. In
practice, a user policy might want much finer-grained permissions towards the Tuscany code
and allow only specific pieces of the code to have privileged access. An example [^tuscany.policy]
is attached to this article.

Notice that the URL in this example supports the substitution of system properties. You can
also provide other property names such as tuscany.home or whatever property you provide to
the command line. Additionally you may end the URL with '*' which includes all JARs and class
files in the current location or '-' which includes all JAR and class file recursively below
this location. Additional information on Java application security architecture and features
is given at [Java Security|http://java.sun.com/javase/6/docs/technotes/guides/security/overview/jsoverview.html].

h2. Enabling Java 2 Security Using Maven

JIRA TUSCANY-2339 allows *Maven* to run all Tuscany itests and vtests with Java 2 security
enabled.  To run this Maven profile, you must provide a tuscany.policy file in your java.home
/lib/security directory (default location) or provide a tuscany.policy.file property to provide
a local file URL, or copy the contents of tuscany.policy to another policy file. As the tuscany.policy
file is written, you must have system properties tuscany.home and maven.repos defined, or
you must hard code the location of these code bases.

Run the Tuscany test profile with Maven by naming the security profile name explicitly or
my providing a tuscany.policy.file property:
mvn test -P security


mvn "-Dtuscany.policy.file=file:///e:/tuscany.policy"

Here is the addition to the pom.xml file to run with security. You may uncomment or add other
modules to perform tests.
                <!-- <module>demos</module> -->
                <tuscany.policy.file><Your tuscany.policy file location></tuscany.policy.file>
                            <!-- Place tuscany.policy in your Java home security directory.
Alternatively, hardcode the file location here. -->
                            <argLine>-Djava.security.manager -Djava.security.policy=${tuscany.policy.file}
                               -Dpolicy.allowSystemProperty=true -Djava.security.debug=policy</argLine>

One gotcha in this environment is that the security profile adds a bit more memory requirements
for the test run. You may need to increase the Java heap max size {{-Xmx1024m}} or increase
the Maven {{MAVEN_OPTS=-XX:MaxPermSize=512m}} if you see memory related errors when you run
in this environment.

h2. Enabling Java 2 Security in Eclipse

Many users import Tuscany projects into *Eclipse* or other Integrated Development Environment
and run or develop applications in this type of environment. Whether you are running your
own SCA application, or one of the many Tuscany samples or demos, the process for running
with Java 2 security enabled is the same. Your application or sample has build and runtime
dependencies on the Tuscany code, and the application is run with a security profile.

Eclipse provides a run dialog that determines how a project is run. For instance, many Tuscany
samples are run as Java applications. The Tuscany samples also provide many test cases that
may be run in a JUnit test suite. In either case, you specify Java 2 security options in a
similar way. You create a 'run' configuration for your type of code (Java application, Java
applet, JUnit test case, etc.). The run dialog has a 'Arguments' tab where you can provide
Java Virtual Machine options. You provide the Java 2 security options in the 'Program Arguments'
text box.

An example of this configuration is shown here:

There are two small gotchas to be aware of in this environment. Once again the location of
the policy file is a URL. If you specify the policy with no file or http prefix, the default
location will be location of the project in the workspace. So in this example, a simple *-Djava.security.policy=tuscany.policy*
requires a tuscany policy file in the sample-calculator project in your Eclipse workspace.
Since this is URL, you can put the policy file anywhere in your file system. Secondly, some
of the Tuscany demos and samples use privileged code (such as load classes dynamically, read
system properties, read the file system, or connect to various server sockets). These example
do this to demonstrate various SCA features. However, these applications may throw a security
exception because they are given proper access. In this case you may want to add access for
Eclipse or application code. An example is given here:
grant codeBase "file:${eclipse.home}/-" {
  permission java.net.SocketPermission "*", "connect,accept,resolve";
  permission java.io.FilePermission "<<ALL FILES>>", "read";
  permission java.util.PropertyPermission "*", "read";  
Grant this access when you are developing in Eclipse. When you are ready to deploy and run
these application in the real world, read the next section as to how to run on popular application

h2. Security Tips for Popular Application Servers

When Tuscany is run by an application server (whether it be WebSphere, Geronimo, or other),
the policy of the application server will form the starting point for Tuscany's security policy.
This section gives an overview to the Java 2 security policies of several popular application

h4. WebSphere Application Server

There are several different ways to run Tuscany applications on *IBM WebSphere Application
Server*. In either case you may run your Tuscany application as a Java application or a Java
Extended Edition applicaiton, depending on which container features you need. Obviously if
you use web application features you should run in a web server container. If you are using
servlet or persistence features you should run in an applicaiton server container. You may
run your Tuscany application and include any Tuscany runtime prerequisite JARs in the package.
Another way is to run your Tuscany application without internal runtime prereqs and use IBM's
Service Oriented Architecture Feature Pack (SOA FeP) to provide an SCA runtime. In any case
running your application with security enabled will be the same.

WAS provides security policy information in a number of places. First there are three locations
that provide static security plicy info that may be changed by a system administrator when
installing or configuring a server:
    * app_server_root/java/jre/lib/security/java.policy
    * app_server_root/properties/server.policy
    * profile_root/config/cells/cell_name/nodes/node_name/app.policy

The first of these files will permanently change security policy by all users of the system
JVM. The second of these files will change the security policy for all servers in this installation.
The third file app.policy includes policy that applies to all enterprise applications on the
node to which the app.policy file belongs. All of these policy files are static and used for
general system-wide infrastructure. It is suggested that you use these files with care.

For instance, let's say wish to allow certain JARs to read system properties on WAS. This
would be the entry to add to app.policy.
grant codeBase "file:${application}" {
 permission java.utilPropertyPermission "${was.install.root}${/}profiles${/}AppSrv01${/}installedAssets${/}vtestService.jar${/}1.0${/}vtestService.jar",

A final location to provide Java 2 Security is in the was.policy file of the JAR, WAR, or
EAR file that you are deploying. This location provides the fine-grained application-level
security control, but the permission needs to be granted in each was.policy file for each
application deployed on WAS. Additional details on WebSphere security are provided at the

[WAS Info Center|http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/csec_rsecmgr2.html].

h4. Apache Geronimo

Running on *Apache Geronimo* has similar considerations to running on other application servers.
A user may choose to run the SCA application as a standalone SCA application with no container
requirements, a web application with dependencies on a web server container, or a full blown
JEE application with a need for servlets, JSPs, and other application server requirements.

There is a *Geronimo* plugin that will help with deploying and running a Tuscany application.
Additional details are provided in a
[Tuscany Geronimo Integration|http://cwiki.apache.org/TUSCANYWIKI/tuscany-geronimo-integration.html]

h2. Conclusion

This article provides a number of tips when running Java 2 Security with Tuscany in different
environments. Feel free to contact the author or add your own environment tips to this articles.
Comments and corrections are appreciated.

This message is automatically generated by Confluence

Unsubscribe or edit your notifications preferences

If you think it was sent incorrectly contact one of the administrators

If you want more information on Confluence, or have a bug to report see

View raw message