Before you begin
Java 2 security is a new feature in WebSphere Application Server Version
5. It is a new programming model that is very pervasive and has a huge impact
on application development. It is disabled by default, but is enabled automatically
when global security is enabled. However, Java 2 security is orthogonal to
J2EE role-based security; you can disable or enable it independently of Global
Security.
However, it does provide an extra level of access control protection
on top of the J2EE role-based authorization. It particularly addresses the
protection of system resources and APIs. Administrators should need to consider
the benefits against the risks of disabling Java 2 Security.
The following
recommendations are provided to help enable Java 2 security in a test or production
environment:
- Make sure the application is developed with the Java 2 security programming
model in mind. Developers have to know whether or not the APIs used in the
applications are protected by Java 2 security. It is very important that the
required permissions for the APIs used are declared in the policy file (was.policy),
or the application fails to run when Java 2 security is enabled. Developers
can reference the Web site for Development Kit APIs that are protected by
Java 2 security. See the Programming model and decisions section of the Security: Resources for learning article
to visit this Web site.
- Make sure that migrated applications from previous releases are given
the required permissions. Since Java 2 security is not supported or partially
supported in previous WebSphere Application Server releases, applications
developed prior to Version 5 most likely are not using the Java 2 security
programming model. There is no easy way to find out all the required permissions
for the application. Following are activities you can perform to determine
the extra permissions required by an application:
- Code review and code inspection
- Application documentation review
- Sandbox testing of migrated enterprise applications with Java 2 security
enabled in a pre-production environment. Enable tracing in WebSphere Java
2 security manager to help determine the missing permissions in the application
policy file. The trace specification is com.ibm.ws.security.core.SecurityManager=all=enabled.
- Use the com.ibm.websphere.java2secman.norethrow system property
to aid debuggging. This property should not be used in a production environment.
Refer to Java 2 security.
Note: The default permission set for applications
is the recommended permission set defined in the J2EE 1.3 Specification. The
default is declared in the config/cells/<cell_name>/nodes/<node_name>/app.policy policy
file with permissions defined in the Development Kit (${JAVA_HOME}/lib/security/java.policy)
policy file that grant permissions to everyone. However, applications are
denied permissions declared in the config/cells/cell_name/filter.policy filter
policy file. Permissions declared in the filter.policy file are filtered
for applications during the permission check.
Note: Define
the required permissions for an application in a was.policy file
and embed the was.policy file in the application enterprise archive
(EAR) file as YOURAPP.ear/META-INF/was.policy (see Configuring Java 2 security policy files for details).
Enable or disable Java 2 Security for an application server
Steps for this task
- Click Server > Application Servers in the navigation tree.
The Application Servers page appears.
- Click the application server name in the Name column
of the Application Server collection table. The configuration panel of the
application server selected appears.
- Click Server Security in the Additional Properties section.
The Server Security panel of the application server appears.
- Click Server Level Security in the Additional Properties
section. The Server Level Security panel of the application server appears.
- Enable Java 2 Security by selecting the option labeled Enforce
Java 2 Security (clear the check box to disable Java 2 Security). This
enables Java 2 Security for the selected application server.
- Click OK or Apply on the Server Level Security page.
- Save the changes and make sure a file sync is performed before
restarting the application server.
- Restart the application server for the changes to take effect.
Results
Java 2 Security is enabled and enforced for the servers. Java 2 Security
permission is checked when a Java 2 Security protected API is called.
When
to use Java 2 Security
- To enable protection on system resources. For example, when opening or
listening to a socket connection, reading or writing to operating system file
systems, reading or writing Java Virtual Machine system properties, and so
on.
- To prevent application code calling destructive APIs. For example, calling System.exit() brings
down the application server.
- To prevent application code obtaining privileged information (passwords)
or gaining extra privileges (obtaining Server Credentials).
What to do next
The WebSphere Java 2 Security Manager is enhanced to dump the Java
2 Security permissions granted to all classes on the call stack when an application
is denied access to a resource (the
java.security.AccessControlException exception
is thrown). The trace information is dumped to the configured server log files.
Check the server log files to access debugging information when an AccessControlException
is thrown. In addition, the product Java 2 Security Manager trace can be enabled
with the trace string,
com.ibm.ws.security.core.SecurityManager=all=enabled.
When the exception is thrown, the trace dump provides hints to determine whether
the application is missing permissions or the product run time code or third
party libraries used are not properly marked as
privileged when accessing
Java 2 protected resources. See the
Security
Problem Determination Guide for details.