|
The changes documented on this page resolve issues raised by
reviewers and implementors of the current specification (dated November
24, 2003) and have been presented, discussed, and resolved on the JSR
115 Expert Group mailing list.
Each of the proposed changes are described with respect to a page in
the current specification and include a hyperlink to a representation
of the page (with change bars) that would result from applying the
changes to the page.
To Policy Configuration Subcontract:
• Page 24: added requirement to
“Translating Servlet security-role-ref Elements" for extra
WebRoleRefePermission objects to be created to support calls to
isUserInRole from unmapped JSPs.
To Policy Enforcement Subcontract:
• Page 37: added requirement to
“Application Embedded Privilege Test" to support calling isUserInRole
from an unmapped (to servlet) web resource.
• page 47: added footnote to “Checking
the Caller for a Permission" to act as a forward reference to
optimization by reuse of unauthenticated results as allowed for by new
text added to “Optimization of Permission Evaluations". This
optimization allows a container to optimize authorization checks on
unprotected resources.
• Page 50: added new clarifying text to
“Optimization of Permission Evaluations" to support performance
optimization based on reuse of evaluation results. In addition to reuse
of equivalent evaluations, added text to support reuse of
unauthenticated evaluations to authorize evaluations independent of
caller identity. Described a common practice that could be implemented
by containers and providers, and that would cause containers to be
notified by providers of policy changes. By following the suggested
practice providers would be able to tell when containers expect to be
notified, for containers to determine if they will be notified, and for
containers to determine if their provider has other properties
necessary to sustain reuse.
To API:
• Page 87: Clarified Description of
WebRoleRefPermission class.
• Page 88: Modified description of name
parameter of WebRoleRefPermission constructor to describe use of
empty-string name.
To Appendix B: Issues:
• Page 105: removed sentence from
description of resolution of issue B19, “Calling isUserInRole from JSP
not mapped to a Servlet", that had indicated that the resolution would
NOT be adopted until the Servlet spec was changed. As a result of this
errata, the resolution to issue B19 has been fully integrated.
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.
|
