Java 2 security is a programming
model that is very pervasive and has a huge impact on application
development.
Before you begin
Java 2
security is orthogonal to Java Platform,
Enterprise Edition (Java EE)
role-based security; you can disable or enable it independently of
administrative security.
However, it does provide
an extra level of access control protection on top of the Java EE role-based authorization. It particularly
addresses the protection of system resources and application programming
interfaces (API). Administrators 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. Developers have to know whether or not
the APIs that are 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 website for Development Kit APIs that are protected by Java 2 security. See the Programming model and
decisions section of the Security: Resources for Learning topic to
visit this website.
- Make sure that migrated applications from previous releases are
given the required permissions. Because 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. No easy way
to find out all the required permissions for the application is available.
The following are activities you can perform to determine the extra
permissions that are 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 preproduction 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 debugging. Do not use this property in a production environment.
Refer to Java 2 security
The default permission set for applications
is the recommended permission set that is defined in the J2EE 1.3
Specification. The default is declared in the app_server_root/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 that are declared in the profiles/profile_name/config/cells/cell_name/filter.policy file.
Permissions that are declared in the filter.policy file are
filtered for applications during the permission check.
The default permission set for applications is
the recommended permission set defined in the J2EE 1.3 Specification.
The default is declared in the
profile_root/config/cells/cell_name/nodes/node_name/app.policy policy
file with permissions defined in the Development Kit policy file that
grants permissions to everyone. The
java.policy file
is located in the
java_home directory
depending on the Java virtual machine (JVM) that is enabled for the
profile.
Note: Only Java SE 6 has a JRE.(for example, /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/lib/ext).
For
all Java virtual machines, the
java.policy file is used system-wide.
Do not edit the
java.policy file on the server. Applications
are denied permissions that are declared in the
profile_root/config/cells/cell_name/filter.policy file.
Permissions declared in the
filter.policy file are filtered
for applications during the permission check.
Use
the
showVariables command of the AdminTask object
to retrieve JAVA_HOME for the node associated with the server's profile.
For example, if the node is myNode:
- Enter QShell.
- cd to profile_root/bin
- Run the following command:
wsadmin -conntype NONE -c '$AdminTask showVariables {-scope Node=myNode -variableName JAVA_HOME}'
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, Express
What to do next
You can enforce Java 2 security on the server level for
WebSphere Application Server, Network Deployment by completing
the following steps.
Note: Changes to Java 2
security settings on the server level override the settings on the
cell level.
- Click Servers > Application servers > server_name.
- Under Security, click Server security.
- Select the Security settings for this server override cell
settings option.
- Select the Use Java 2
security to restrict application access to local resources option.
- Click OK or Apply.
- Click Save to save the changes.
- Restart the server for the changes to take effect.
The Java 2
security manager is enhanced to dump the Java 2
security permissions that are granted to all classes on the call stack
when an application is denied access to a resource. The java.security.AccessControlException
exception is created. However, this tracing capability is disabled
by default. You can enable this capability by specifying the server
trace service with the
com.ibm.ws.security.core.SecurityManager=all=enabled trace
specification. When the exception is created, the trace dump provides
hints to determine whether the application is missing permissions
or the product runtime code or the third-party libraries that are
used are not properly marked as
privileged when accessing Java 2 security-protected resources.
See the Security Problem Determination Guide for details.