57 lines
5.1 KiB
HTML
57 lines
5.1 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
||
|
|
|
||
|
|
<title>Configure Java 2 security</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<BODY>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
||
|
|
|
||
|
|
<h3><a name="seccj2"></a>Configure Java 2 security</h3>
|
||
|
|
|
||
|
|
<p>Java 2 Security is a new feature in WebSphere Application Server - Express Version 5. It is a new programming model that is very pervasive and has a huge impact on application development. For more information, see <a href="java2.htm">Java 2 Security</a>.</p>
|
||
|
|
|
||
|
|
<p>Java 2 Security is disabled by default, but is enabled automatically when global security is enabled. However, it is independent of J2EE role-based security, you can disable or enable it separately of global security. Java 2 Security provides an extra level of access control protection in addition to J2EE role-based authorization. It particularly addresses the protection of system resources and APIs. The Java development kit has used Java 2 Security to protect sensitive APIs (such the API to exit the Java virtual machine) and APIs that utilize resources (for example, opening files for reading and writing) since the release of Java 2.</p>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> Java 2 Security only restricts Java programs that run in a Java virtual machine that has Java 2 Security enabled. It does not protect system resources if Java 2 Security is disabled, or if system resources are accessed from other programs or commands. Therefore, if you want to protect your iSeries system resources, you need to use iSeries security.</p>
|
||
|
|
|
||
|
|
<p>Here are some guidelines for when to use Java 2 Security:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>To prevent application code from calling destructive APIs. For example, calling System.exit() brings down the application server.</li>
|
||
|
|
<li>To prevent application code from obtaining privileged information (passwords) or gaining extra privileges (obtaining server credentials).</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>To ease the effort of enabling 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. See <a href="seccj2po.htm">Configure Java 2 policy files</a> for more information about was.policy and other Java 2 Security policy files.</p>
|
||
|
|
|
||
|
|
<p>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.policy policy file in addition to permissions that are defined in the Java development kit java.policy file that grant permissions to everyone. However, applications are denied permissions that are declared in the filter.policy file. Permissions that are declared in the filter.policy file are filtered out for applications during the permission check.</p>
|
||
|
|
|
||
|
|
<p>Define the required permissions for an application in a was.policy file and embed the was.policy file in the application EAR file in the META-INF subdirectory.</p>
|
||
|
|
|
||
|
|
<p>For more information about policy files, see <a href="seccj2po.htm">Configure Java 2 policy files</a>.</p>
|
||
|
|
|
||
|
|
<p>To enable Java 2 Security, perform these steps in the administrative console:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>In the navigation menu, expand <strong>Security</strong>. Click <strong>Global Security</strong>. The Global Security page appears.</li>
|
||
|
|
<li>Enable Java 2 Security by selecting <strong>Enforce Java 2 Security</strong>.</li>
|
||
|
|
<li>Click <strong>OK</strong> or <strong>Apply</strong> on the Global Security page. </li>
|
||
|
|
<li>Click <strong>Save</strong> to save the changes.</li>
|
||
|
|
<li>Restart the server for the changes to take effect.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
<p><strong>Tracing Java 2 Security</strong></p>
|
||
|
|
|
||
|
|
<p>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 <tt>com.ibm.ws.security.core.SecurityManager=all=enabled</tt> trace specification. When the exception is thrown, the trace dump provides hints to determine whether the application is missing permissions or the product runtime code or that third-party libraries used are not properly marked as privileged when accessing Java 2 protected resources.</p>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|
||
|
|
|