Before you begin
Java 2 security is a 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 Java 2 Platform, Enterprise Edition (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 application programming interfaces (API). 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 profiles/profile_name/config/cells/cell_name/nodes/node_name/app.policy policy
file with permissions defined in the Development Kit (JAVA_HOME/jre/lib/security/java.policy)
policy file that grant permissions to everyone. However, applications are
denied permissions declared in the profiles/profile_name/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).
The following
steps describe how to enforce Java 2 security on the cell level for WebSphere
Application Server Network Deployment and the server level for WebSphere Application
Server and WebSphere Application Server Express:
What to do next
You can enforce Java 2 security on the server
level for WebSphere Application Server Network Deployment completing the following
steps:
- Click Servers > Application servers > server_name.
- Under Security, click Server security.
- Under Additional properties, click Server-level security.
- Select the Enforce Java 2 security option.
- Click OK or Apply.
- Click Save to save the changes.
- Restart the server for the changes to take effect.
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). However, this tracing capability is disabled by default. You can
enable it by specifying the server trace service with the
com.ibm.ws.security.core.SecurityManager=all=enabled trace
specification. 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.