Last updated: 3 March 2005
J2EE 1.4 Platform Specification Errata Java Authorization Contract for Containers 1.0 Errata March 18, 2004 J2EE defines a security model and requirements that cover both access to the services and applications in a J2EE application server, as well as the security environment in which J2EE applications execute. The security environment is controlled by the Java security manager and the permissions granted to applications. The J2EE spec defines a set of security permissions that applications can expect. The spec also allows a vendor of a J2EE product, as well as users of the product, to control the exact set of permissions available to an application, either more or less than the minimum set, as long as it's possible to grant the application at least the minimum set. This has provided the operational flexibility that customers require to choose the appropriate security policy for their needs. J2EE 1.4 added the following requirement (section 6.2.1, page 88): To ensure the integrity of J2EE containers, all J2EE containers must install a security manager and must prevent applications from replacing or overriding the security manager. It has been pointed out that this requirement is in conflict with the intent of the J2EE spec to allow customers to choose the security policy for their needs. It's also in conflict with current practice which routinely allows applications to run with no security manager at all. In some environments the protections provided by a security manager are less important than the performance cost of using a security manager. Customers demand the ability to make these tradeoffs between protection and performance. The clear majority opinion of the J2EE 1.4 expert group was that the addition of this requirement was a mistake and should be removed. This errata corrects this conflict in the J2EE spec by removing the above quoted requirement. JSR-115 (Java Authorization Contract for Containers) has echoed this requirement in its specification. That specification must be corrected as well to eliminate this conflict. In particular, the following changes to the JSR-115 specification are required: Requirement #9 in section 1.4 is changed to: 9. For a container to support this contract, it must execute in an environment controlled by a J2SE SecurityManager. Containers may also execute in environments that are not controlled by a J2SE SecurityManager. Section 1.5, "Running Without a SecurityManager" defines changes to this contract that apply to containers running without a J2SE SecurityManager. Section 1.5 is added: 1.5 Running Without a SecurityManager The following list defines changes to this contract that apply to containers running without a J2SE SecurityManager. 1. The restrictions defined in Section 3.3, "Permission to Configure Policy" need not be enforced. Also, the containers of the application server must not be denied permission to perform any operation that would have been permitted in the presence of a SecurityManager. 2. Such containers are not required (before dispatching a call) to associate an AccessControlContext with the call thread (as otherwise required by Section 4.1.2, "Pre-dispatch Decision" and Section 4.3.1, "EJB Pre-dispatch Decision"). 3. When performing the operations defined in Section 4.7, "Checking AccessControlContext Independent Grants" and in Section 4.8, "Checking the Caller for a Permission", such containers must not employ the SecurityManager.checkPermission and AccessControlContext.checkPermission techniques defined in these sections. Changes to a specification after final release must always be done with the greatest care, even when correcting an error in the spec. The impact of the change on vendors and customers must be taken into account. In this case, the risk of this change appears relatively low. This change will not require any vendor to make any change to an existing product implementing this specification. It will not require any changes to the J2EE CTS. It is extremely unlikely that it will disrupt any existing customer applications. (It's possible, but unlikely, that an application could depend on a security manager always being installed, even though most existing products do not do so.) This change allows vendors to continue to deliver J2EE 1.4 products in the same way they have delivered J2EE 1.3 products, with optional use of a security manager. Vendors who prefer to enforce more rigorous security requirements will continue to be free to do so.