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
Content:
---------------------------------------------------------------------
h1. Running Tuscany with Java 2 Security Enabled
{color:blue}
[*Java Security*| http://vcasmo.com/video/beckerdo/2750] is available in Video,
use tuscany passcode
{color}
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;
};
{code}
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:
{code}
mvn test -P security
{code}
or
{code}
mvn "-Dtuscany.policy.file=file:///e:/tuscany.policy"
{code}
Here is the addition to the pom.xml file to run with security. You may
uncomment or add other modules to perform tests.
{code}
<profile>
<id>security</id>
<modules>
<!-- <module>demos</module> -->
<module>itest</module>
<module>vtest</module>
</modules>
<activation>
<property>
<name>tuscany.policy.file</name>
</property>
</activation>
<properties>
<tuscany.policy.file><Your tuscany.policy file
location></tuscany.policy.file>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<includes>
<include>**/*TestCase.java</include>
</includes>
<reportFormat>brief</reportFormat>
<useFile>false</useFile>
<forkMode>once</forkMode>
<!-- 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>
</configuration>
</plugin>
</plugins>
</build>
</profile>
{code}
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:
!EclipseAppConfig.png!
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:
{code}
grant codeBase "file:${eclipse.home}/-" {
permission java.net.SocketPermission "127.0.0.1:*", "connect,accept,resolve";
permission java.io.FilePermission "<<ALL FILES>>", "read";
permission java.util.PropertyPermission "*", "read";
};
{code}
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 servers.
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 servers.
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.
{code}
grant codeBase "file:${application}" {
permission java.utilPropertyPermission
"${was.install.root}${/}profiles${/}AppSrv01${/}installedAssets${/}vtestService.jar${/}1.0${/}vtestService.jar",
"read";
};
{code}
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]
article.
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.
---------------------------------------------------------------------
CONFLUENCE INFORMATION
This message is automatically generated by Confluence
Unsubscribe or edit your notifications preferences
http://cwiki.apache.org/confluence/users/viewnotifications.action
If you think it was sent incorrectly contact one of the administrators
http://cwiki.apache.org/confluence/administrators.action
If you want more information on Confluence, or have a bug to report see
http://www.atlassian.com/software/confluence
