ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable |
JACC:SPEC:2 | 1 | 1.4 | Legacy | true |
| false | technology | active | true |
JACC:SPEC:3 | 1 | 1.4 | Legacy | false |
| false | technology | active | false |
JACC:SPEC:4 | 1 | 1.4 | Each Policy provider that satisfies this contract must perform or
delegate to another provider all the permission evaluations
requested via its interface in the JRE; not just those made by the
container to implement J2EE security functionality.
| true |
| false | technology | active | true |
JACC:SPEC:5 | 1 | 1.4 | Each provider must export interfaces (defined by this contract) for
use by containers and or container deployment tools to create policy
statements within the policy store of the provider. These interfaces
must be used when an application or module is deployed in a
container.
| true |
| false | technology | active | true |
JACC:SPEC:6 | 1 | 1.4 | Each provider must export interfaces (defined by this contract) for
use by containers and or container deployment tools to create policy
statements within the policy store of the provider. These interfaces
must be used when an application or module is deployed in a
container.
| true |
| false | technology | active | true |
JACC:SPEC:7 | 1 | 1.4 | Each provider must satisfy all of the authorization requirements of
the EJB and Servlet specifications corresponding to the target
platform.
| true |
| false | technology | active | true |
JACC:SPEC:8 | 1 | 1.4 | In the case of Servlet resources, the provider must be able to
associate a distinct policy context with each context root
(including context roots created to support virtual hosting)
hosted by the server.
| true |
| false | technology | active | false |
JACC:SPEC:9 | 1 | 1.4 | In protecting Servlet resources, a provider must select the policy
statements that apply to a request according to the constraint
matching and servlet mapping rules defined by the Servlet
specification.
| true |
| false | technology | active | false |
JACC:SPEC:10 | 1 | 1.4 | To support this contract in a Servlet environment, a container or its
deployment tools must create policy statements as necessary to
support Servlet's default role-ref semantic.
| true |
| false | technology | active | true |
JACC:SPEC:11 | 1 | 1.4 | This contract must support providers that are unable to determine,
before returning from Policy.getPermissions(), all the permissions
that pertain to a subject/protection domain.
| true |
| false | technology | active | false |
JACC:SPEC:12 | 1 | 1.4 | For a container to support this contract, it must execute in an
environment controlled by a J2SE security manager.
| true |
| false | technology | active | true |
JACC:SPEC:13 | 1 | 1.4 | The evaluation of a permission corresponding to a resource must
identify the context of the resource's use such that different policy
can be applied to a resource used in different contexts (that is,
applications or instances of an application).
| true |
| false | technology | active | false |
JACC:SPEC:14 | 2 | 2.1 | The security property policy.provider may be used to replace the default
java.security.Policy implementation class. Similarly, the security
property auth.policy.provider may be used to replace the default
javax.security.auth.Policy implementation class.
| true |
| false | technology | active | true |
JACC:SPEC:15 | 2 | 2.5 | Each JRE of an application server must be provided with classes that implement
the PolicyConfigurationFactory class and PolicyConfiguration
interface. These classes must be compatible with the Policy implementation class
installed for use by the JRE.
| true |
| false | technology | active | true |
JACC:SPEC:16 | 2 | 2.5 | If the provider is seeking to replace the Policy implementation used by the
JRE, then the JRE must be provided with an environment specific Policy
implementation class. If the JRE is running a J2SE 1.4 security environment, then
it must be provided with an implementation of the java.security.Policy
class. If the JRE is running a J2SE 1.3 security environment, it must be provided
with an implementation of the javax.security.auth.Policy class (that is,
a JAAS Policy object).
| false |
| false | technology | active | true |
JACC:SPEC:17 | 2 | 2.5 | A replacement Policy object must assume responsibility for performing all
policy decisions within the JRE in which it is installed that are requested by way
of the Policy interface that it implements. A replacement Policy object may
accomplish this by delegating non-jakarta.security.jacc policy decisions to
the corresponding default system Policy implementation class.
| true |
| false | technology | active | false |
JACC:SPEC:18 | 2 | 2.5 | A replacement
Policy object that relies in this way on the corresponding default Policy
implementation class must identify itself in its installation instructions as a
delegating Policy provider.
| true |
| false | technology | active | false |
JACC:SPEC:19 | 2 | 2.5 | The standard security properties mechanism for replacing a default system
Policy implementation (see Section 2.1, Policy Implementation Class) should
not be used to replace a default system Policy provider with a delegating Policy
provider.
| true |
| false | technology | active | false |
JACC:SPEC:20 | 2 | 2.6 | A J2SE 1.4 provider may support replacement of
the JAAS Policy object if and only if all jakarta.security.jacc policy decisions
performed by the replacement JAAS Policy object return the same result as when
the java.security.Policy interface is used. To satisfy this requirement, the
replacement JAAS Policy object must be compatible with the implementations of
PolicyConfigurationFactory and PolicyConfiguration interface
provided for use with the java.security.Policy implementation class.
| false |
| false | technology | active | true |
JACC:SPEC:21 | 2 | 2.7 | An application server or container must bundle or install the
jakarta.security.jacc standard extension. This package must include the
abstract jakarta.security.jacc.PolicyConfigurationFactory class,
the jakarta.security.jacc.PolicyConfiguration and
jakarta.security.jacc.PolicyContextHandler interfaces, and
implementations of the
jakarta.security.jacc.PolicyContextException exception, the
jakarta.security.jacc Permission classes, and the
jakarta.security.jacc.PolicyContext utility class.
| true |
| false | technology | active | false |
JACC:SPEC:22 | 2 | 2.7 | To enable delegation of non-jakarta.security.jacc policy decisions to
default system Policy providers, all application servers must implement the
following Policy replacement algorithm.
For each JRE of a J2EE 1.4 application server, if the system property
jakarta.security.jacc.policy.provider is defined, the application server must
construct an instance of the class identified by the system property,
confirm that the resulting object is an instance of java.security.Policy,
and set, by calling the java.security.Policy.setPolicy, the resulting
object as the corresponding Policy object used by the JRE.
| true |
| false | technology | active | true |
JACC:SPEC:23 | 2 | 2.7 | For each JRE of a J2EE 1.4 application server, if the system property
jakarta.security.jacc.policy.provider is defined, the application
server must construct an instance of the class identified by the system property,
confirm that the resulting object is an instance of java.security.Policy,
and set, by calling the java.security.Policy.setPolicy method, the
resulting object as the corresponding Policy object used by the JRE.
An application server that chooses to support this contract in a J2SE 1.3
environment must perform the policy replacement algorithm described above
when the system property
jakarta.security.jacc.auth.policy.provider is defined. That is,
for each JRE of the application server, the server must construct an instance of the
class identified by the system property, confirm that the resulting object is an
instance of javax.security.auth.Policy, and set, by calling
javax.security.auth.Policy.setPolicy method, the resulting object
as the corresponding Policy object used by the JRE.
| true |
| false | technology | active | true |
JACC:SPEC:24 | 2 | 2.7.1 | A J2EE 1.3 application
server must install or bundle, such that it is used by every JRE of the application
server, a javax.security.auth.SubjectDomainCombiner whose
combine method returns protection domains constructed using the permission
collections returned by javax.security.auth.Policy.getPermisions.
It is recommended that this requirement also be satisfied by J2EE 1.4 application
servers in the case where javax.security.auth.Policy is being used (in
backward compatibility mode) by the SubjectDomainCombiner.
| true |
| false | technology | active | true |
JACC:SPEC:25 | 3 | 3.1 | The getPolicyConfigurationFactory method must be used in every JRE
to which the components of the application or module are being deployed to find
or instantiate PolicyConfigurationFactory objects.
| true |
| false | technology | active | true |
JACC:SPEC:26 | 3 | 3.1 | The getPolicyConfiguration method of the factories must be used to
find or instantiate PolicyConfiguration objects corresponding to the
application or modules being deployed.
| true |
| false | technology | active | true |
JACC:SPEC:27 | 3 | 3.1 | The declarative authorization policy statements derived from application or
module deployment descriptor(s) must be translated to create instances of the
corresponding jakarta.security.jacc Permission classes.
| true |
| false | technology | active | true |
JACC:SPEC:28 | 3 | 3.1 | Methods of the PolicyConfiguration interface must be used with the
permissions resulting from the translation to create policy statements within the
PolicyConfiguration objects.
| true |
| false | technology | active | true |
JACC:SPEC:29 | 3 | 3.1 | The PolicyConfiguration objects must be linked such that the same
principal-to-role mapping will be applied to all the modules of the application.
| true |
| false | technology | active | true |
JACC:SPEC:30 | 3 | 3.1 | Independent of this specification, Jakarta EE deployment tools must translate and
complete the declarative policy statements appearing in deployment descriptors
into a form suitable for securing applications on the platform.
| true |
| false | technology | active | false |
JACC:SPEC:31 | 3 | 3.1.1.1 | A policy context is in one of three states and all
implementations of the PolicyConfiguration interface must implement the state
semantics defined in this section.
- open
A policy context in the open state must be available for configuration by any
of the methods of the PolicyConfiguration interface. A policy context in the
open state must not be assimilated at Policy.refresh into the policy statements
used by the Policy provider in performing its access decisions.
- inService
A policy context in the inService state must be assimilated at Policy.refresh
into the policy statements used by its provider. When a provider's refresh
method is called, it must assimilate only policy contexts that are in the inService
state and it must ensure that the policy statements put into service for
each policy context are only those defined in the context at the time of the call
to refresh. A policy context in the inService state must be unavailable for
additional configuration. A policy context in the inService state must be transitioned
to the open state when it is returned as a result of a call to getPolicy-
Configuration. A policy context is transitioned to the inService state by
calling the commit method, and only a policy context in the open state may be
transitioned to the inService state.
- deleted
A policy context in the deleted state must be unavailable for configuration and
it must be unavailable for assimilation into its associated Provider. A policy
context in the deleted state must be transitioned to the open state when it is
returned as a result of a call to getPolicyConfiguration. A policy context is
transitioned to the deleted state by calling the delete method.
| true |
| false | technology | active | false |
JACC:SPEC:32 | 3 | 3.1.2 | A servlet container is responsible
for mapping the target name or address information of an HTTP request to the
appropriate hostname.
| true |
| false | technology | active | true |
JACC:SPEC:33 | 3 | 3.1.3 | A reference to a PolicyConfiguration object must be obtained by calling the
getPolicyConfiguration method on the
PolicyConfigurationFactory implementation class of the provider
configured into the container. The policy context identifier used in the call to the
getPolicyConfiguration method must be a String composed as
described in Section 3.1.2, Servlet Policy Context Identifiers, on page 18. The
value true must be passed as the second parameter in the call to
getPolicyConfiguration to ensure that any and all policy statements are
removed from the policy context associated with the returned
PolicyConfiguration.
| true |
| false | technology | active | true |
JACC:SPEC:34 | 3 | 3.1.3.1 | A WebResourcePermission and a WebUserDataPermission object must be
instantiated for each distinct url-pattern occurring in the securityconstraint
elements that contain an auth-constraint naming no roles (i.e
an excluding auth-constraint). The permissions must be constructed using
the qualified (as defined in Qualified URL Pattern Names) pattern as their name
and with actions defined by the union of the HTTP methods named or implied
by all of the collections containing the pattern and occurring in a constraint with
an excluding auth-constraint. The constructed permissions must be added to
the excluded policy statements by calling the addToExcludedPolicy method
on the PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:35 | 3 | 3.1.3.1 | A WebResourcePermission must be instantiated for each distinct combination
in the cross-product of url-pattern and role-name occurring in the
security-constraint elements that contain an auth-constraint
naming roles. When an auth-constraint names the reserved role-name,
"*", all of the patterns in the containing security-constraint must be
combined with all of the roles defined in the web application.
| true |
| false | technology | active | true |
JACC:SPEC:36 | 3 | 3.1.3.1 | Each WebResourcePermission object must be constructed using the qualified pattern as
its name and with actions defined by the union of the HTTP methods named or
implied by the collections containing the pattern and occurring in a constraint that
names (or implies via "*") the role to which the permission is being added. The
resulting permissions must be added to the corresponding roles by calling the
addToRole method on the PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:37 | 3 | 3.1.3.1 | The
resulting permissions must be added to the corresponding roles by calling the
addToRole method on the PolicyConfiguration object.
| true |
| false | technology | removed | true |
JACC:SPEC:38 | 3 | 3.1.3.1 | A WebResourcePermission must be instantiated for each distinct urlpattern
occurring in the security-constraint elements that do not
contain an auth-constraint. Each WebResourcePermission object must be
constructed using the qualified pattern as its name and with actions defined by the
union of the HTTP methods named or implied by the collections containing the
pattern and occurring in a security-constraint without an authconstraint.
The resulting permissions must be added to the unchecked policy
statements by calling the addToUncheckedPolicy method on the
PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:39 | 3 | 3.1.3.1 | The WebResourcePermission objects resulting from
the translation of a security-constraint that does not contain an authconstraint
must be added to the unchecked policy statements by calling
addToUncheckedPolicy on the PolicyConfiguration object.
| true |
| false | technology | removed | true |
JACC:SPEC:40 | 3 | 3.1.3.1 | The
WebResourcePermission objects resulting from the translation of a securityconstraint
containing an auth-constraint that named no roles must be
added to the excluded policy statements by calling addToExcludedPolicy on
the PolicyConfiguration object.
| false |
| false | technology | removed | true |
JACC:SPEC:41 | 3 | 3.1.3.1 | A WebUserDataPermission must be instantiated for each distinct combination
of url-pattern and acceptable connection type resulting from the processing
of the security-constraint elements that do not contain an excluding
auth-constraint. The mapping of security-constraint to acceptable
connection type must be as defined in Mapping Transport Guarantee to Connection
Type. Each WebUserDataPermission object must be constructed using the
qualified pattern as its name and with actions defined by appending a
representation of the acceptable connection type to the union of the HTTP
methods named or implied by the collections containing the pattern and occurring
in a security-constraint that maps to the connection type and that does not
contain an excluding auth-constraint. The resulting permissions must be
added to the unchecked policy statements by calling the
addToUncheckedPolicy method on the PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:42 | 3 | 3.1.3.1 | A transport-guarantee (in a user-data-constraint) of NONE, or a
security-constraint without a user-data-constraint, indicates that
the associated URL patterns and HTTP methods may be accessed over any
(including an unprotected) transport. A transport-guarantee of
INTEGRAL indicates that acceptable connections are those deemed by the
container to be integrity protected. A transport-guarantee of
CONFIDENTIAL indicates that acceptable connections are those deemed by the
container to be protected for confidentiality.
| true |
| false | technology | active | true |
JACC:SPEC:43 | 3 | 3.1.3.2 | For each security-role-ref appearing in the deployment descriptor a
corresponding WebRoleRefPermission must be created. The name used in the
construction of each WebRoleRefPermission must be the servlet-name in
whose context the security-role-ref is defined. The actions used to
construct the permission must be the value of the role-name (that is the
reference), appearing in the security-role-ref.
| true |
| false | technology | active | true |
JACC:SPEC:44 | 3 | 3.1.3.2 | The deployment tools must call the addToRole method on the
PolicyConfiguration object to add the WebRoleRefPermission object
resulting from the translation to the role identified in the role-link
appearing in the security-role-ref.
| true |
| false | technology | active | true |
JACC:SPEC:45 | 3 | 3.1.3.2 | For each servlet element in the deployment descriptor a WebRoleRefPermission must
be created for each security-role whose name does not appear as the rolename
in a security-role-ref within the servlet element. Each such
WebRoleRefPermission must be created with action (that is, reference)
corresponding to the role-name and added to the role with the same name (as
the reference) by calling the addToRole method on the
PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:128 | 3 | 3.1.3.2 |
If the any authenticated user role-name, **, occurs in an auth-constraint,
a WebResourcePermission must also be added to the ** role.
| true |
| false | technology | active | true |
JACC:SPEC:129 | 3 | 3.1.3.2 |
A WebResourcePermission must be instantiated for each distinct combination
in the cross-product of url-pattern and role-name occurring in the
security-constraint elements that contain an auth-constraint
naming roles. When an auth-constraint names the reserved role-name,
"*", all of the patterns in the containing security-constraint must be
combined with all of the roles defined in the web application; which must
not include the role "**" unless the application has defined an
application role named "**".
| true |
| false | technology | active | true |
JACC:SPEC:130 | 3 | 3.1.3.3 |
If the any authenticated user role-name, **, does not appear in a
security-role-ref within the servlet, a WebRoleRefPermission must also be added for it.
The name of each such WebRoleRefPermission must be the servlet-name
of the corresponding servlet element.
| true |
| false | technology | active | true |
JACC:SPEC:131 | 3 | 3.1.3.3 |
For each security-role defined in the deployment descriptor and the
any uthenticated user role, **, an additional WebRoleRefPermission
must be added to the corresponding role by calling the addToRole method
on the PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:132 | 3 | 3.1.3.2 |
A WebResourcePermission and a WebUserDataPermission must be obtained
for each url-pattern in the deployment descriptor and the default pattern, "/",
that is not combined by the web-resource-collection elements of the
deployment descriptor with every possible HTTP method value.
| true |
| false | technology | active | true |
JACC:SPEC:133 | 3 | 3.1.3.2 |
If a deny uncovered HTTP methods semantic is in effect for the web module associated with the
PolicyContext, the resulting permissions must be added to the excluded policy
statements by calling the addToExcludedPolicy method on the
PolicyConfiguration object. Otherwise, the permissions must be added to
the unchecked policy statements by calling the addToUncheckedPolicy
method on the PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:134 | 3 | 3.1.5.1 |
These addToRole calls must be made for any role-name used in the method-
permision which may include the role-name **; which, by default, is mapped to
any authenticated user.
| true |
| false | technology | active | true |
JACC:SPEC:135 | 3 | 3.1.5.3 |
If the any authenticated user role-name, **, does not appear in a
security-role-ref within the element, a EJBRoleRefPermission must also
be added for it. The name of each such EJBRoleRefPermission must be the value of the ejb-name
element within the element in which the security-role-ref elements could
otherwise occur.
| true |
| false | technology | active | true |
JACC:SPEC:136 | 3 | 3.2 |
For the any authenticated user role, **, and unless an
application specific mapping has been established for this role, the provider must
ensure that all permissions added to the role are granted to any authenticated user.
| true |
| false | technology | active | true |
JACC:SPEC:46 | 3 | 3.1.4 | an application server must establish EJB policy
context identifiers sufficient to differentiate all instances of the deployment of an
EJB jar on the application server, or on any other application server with which
the server may share the same policy statement repository.
| true |
| false | technology | active | false |
JACC:SPEC:47 | 3 | 3.1.5.1 | An EJBMethodPermission object must be created for each role-name or
unchecked element contained in each method-permission element
appearing in the deployment descriptor.
| true |
| false | technology | active | true |
JACC:SPEC:48 | 3 | 3.1.5.1 | The name of each EJBMethodPermission
must be the ejb-name as defined in the method element of the methodpermission
element. The actions used in the permission construction must be
obtained by translating the contents of the method element into a method
specification according to the methodSpec syntax defined in the documentation of
the EJBMethodPermission class.
| true |
| false | technology | active | true |
JACC:SPEC:49 | 3 | 3.1.5.1 | If the method-permission element contains the unchecked element,
then the deployment tools must call the addToUncheckedPolicy method to
add the permission resulting from the translation to the
PolicyConfiguration object.
Alternatively, if the method-permission
element contains one or more role-name elements, then the deployment tools
must call the addToRole method to add each of the permissions resulting from
the translation to the corresponding role of the PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:50 | 3 | 3.1.5.2 | An EJBMethodPermission object must be created for each method element
occurring in the exclude-list element of the deployment descriptor. The
name and actions of each EJBMethodPermission must be established as described
in Section 3.1.5.1, Translating EJB method-permission Elements.
The deployment tools must use the addToExcludedPolicy method to add
the EJBMethodPermission objects resulting from the translation of the
exclude-list to the excluded policy statements of the
PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:51 | 3 | 3.1.5.3 | For each security-role-ref element appearing in the deployment
descriptor, a corresponding EJBRoleRefPermission must be created. The name of
each EJBRoleRefPermission must be obtained as described for
EJBMethodPermission objects. The actions used to construct the permission must
be the value of the role-name (that is the reference), appearing in the
security-role-ref. The deployment tools must call the addToRole
method on the PolicyConfiguration object to add a policy statement
corresponding to the EJBRoleRefPermission to the role identified in the rolelink
appearing in the security-role-ref.
| true |
| false | technology | active | true |
JACC:SPEC:52 | 3 | 3.1.6 | The application server's deployment tools must translate the declarative
authorization policy appearing in the application or module deployment
descriptor(s) into policy statements within the Policy providers used by the
containers to which the components of the application or module are being
deployed.
| true |
| false | technology | active | true |
JACC:SPEC:53 | 3 | 3.1.6 | When a module is deployed, its policy context must be linked to the policy
context of every other module with which it must share the same principal-to-role
mapping. When an application is deployed, the policy contexts of every module of
the application must be linked to the policy contexts of every other module of the
application with which it shares a common Policy provider. Policy contexts are
linked by calling the linkConfiguration method on the PolicyConfiguration
objects of the provider.
| true |
| false | technology | active | true |
JACC:SPEC:54 | 3 | 3.1.6 | Once the translation, linking, and committing has occurred, a call must be
made to Policy.refresh on the Policy provider used by each of the containers
to which the application or module is being deployed. The calls to
Policy.refresh must occur before the containers will accept requests for the
deployed resources.
| true |
| false | technology | active | false |
JACC:SPEC:55 | 3 | 3.1.6 | The policy context identifiers corresponding to the deployed application or
module must be recorded in the application server so that they can be used by
containers to establish the policy context as required by Section 4.6, Setting the
Policy Context of the Policy Decision and Enforcement Subcontract, and such
that the Deployer may subsequently remove or modify the corresponding policy
contexts as a result of the undeployment or redeployment of the application.
| true |
| false | technology | active | false |
JACC:SPEC:56 | 3 | 3.1.7 | A
deployment tool indicates that a policy context is to be removed from service
either by calling getPolicyConfiguration with the identifier of the policy context
on the provider's PolicyConfigurationFactory or by calling delete on the
corresponding PolicyConfiguration object. If the getPolicyConfiguration method
is used, the value true should be passed as the second argument to cause the
corresponding policy statements to be deleted from the context.
| true |
| false | technology | active | true |
JACC:SPEC:57 | 3 | 3.1.7 | To ensure that there is not a period during undeployment when the removal of
policy statements on application components renders what were protected
components unprotected, the application server must stop accepting requests for
the application's components before undeploying an application or module.
| true |
| false | technology | active | false |
JACC:SPEC:58 | 3 | 3.1.7 | After the policy
contexts are marked for removal from service, a call must be made to
Policy.refresh on all of the Policy providers from which at least one module
of the application or module was marked for removal from service.
| true |
| false | technology | active | false |
JACC:SPEC:59 | 3 | 3.1.7 | To facilitate redeployment to an existing policy configuration, container
deployment tools may also support a mode in which they do not delete the
PolicyConfiguration objects associated with the application or module
being undeployed.
| false |
| false | technology | removed | false |
JACC:SPEC:60 | 3 | 3.1.8 | Containers are not required to deploy to an existing policy configuration.
Containers that chose to provide this functionality must satisfy the following
requirements.
To associate an application or module with an existing set of linked policy
contexts, the identifiers of the existing policy contexts must be applied by the
relevant containers in fulfilling their obligations as defined in the Policy Decision
and Enforcement Subcontract. The policy contexts should be verified for
existence, by calling the inService method of the
PolicyConfigurationFactory of the Policy providers of the relevant
containers. The deployment tools must call Policy.refresh on the Policy
provider of each of the relevant containers, and the containers must not accept
requests for the deployed resources until these calls have completed.
| false |
| false | technology | active | true |
JACC:SPEC:61 | 3 | 3.1.9 | Containers are not required to implement redeployment functionality. | false |
| false | technology | active | false |
JACC:SPEC:62 | 3 | 3.1.9 | Containers
that chose to provide this functionality must satisfy the following requirements.
To ensure redeployment does not create a situation where the removal of
policy statements on application components renders what were protected
components unprotected, the application server must stop accepting requests for
the application's components before redeployment begins. The application server
must not resume processing requests for the application's components until after
the calls to Policy.refresh, described below, have completed.
To redeploy a module, the deployment tools must indicate at all of the Policy
providers to which the module is to be redeployed that the policy context
associated with the module is to be removed from service. If the module is to be
redeployed to the same policy context at a provider, all policy statements must be
removed from the policy context at the provider.
After the policy contexts have been marked for removal from service and emptied of policy statements (as
necessary), the deployment tools must translate the declarative authorization
policy appearing in the module's deployment descriptor into PolicyConfiguration
objects within the Policy providers at which the module is being redeployed.
After the translation, the PolicyConfiguration objects must be linked, as
necessary, to the policy context of every other module in the same provider with
which the module must share the same principal-to-role mappings.
After the module is linked, the commit method must be called on the
PolicyConfiguration objects. After commit has been called, a call must be
made to Policy.refresh on the Policy provider used by each of the containers
to which the module has been redeployed.
| false |
| false | technology | active | true |
JACC:SPEC:63 | 3 | 3.2 | the provider must include an implementation of the
jakarta.security.jacc.PolicyConfigurationFactory class along
with a matched implementation of a class that implements the
jakarta.security.jacc.PolicyConfiguration interface.
| true |
| false | technology | active | true |
JACC:SPEC:64 | 3 | 3.2 | In addition to
providing a PolicyConfiguration interface for integration with the
application server deployment tools, the provider must also include a
management interface for policy administrators to use to grant the collections of
permissions that comprise roles, to principals. This interface need not be
standardized.
| true |
| false | technology | active | false |
JACC:SPEC:65 | 3 | 3.2 | The provider must ensure that all of the permissions added to a role in a policy
context are granted to any principal mapped to the role by the policy
administrator. The provider must ensure that the same principal-to-role mappings
are applied to all linked policy contexts.
| true |
| false | technology | active | true |
JACC:SPEC:66 | 3 | 3.2 | The provider must ensure that excluded policy statements take precedence
over overlapping unchecked policy statements, and that both excluded and
unchecked policy statements take precedence over overlapping role based policy
statements.
| true |
| false | technology | active | true |
JACC:SPEC:67 | 3 | 3.3 | The getPolicyConfigurationFactory, and inService methods of the
abstract factory class,
jakarta.security.jacc.PolicyConfigurationFactory, must throw a
SecurityException when called by an AccessControlContext that has not been
granted the setPolicy SecurityPermission.
The getPolicyConfiguration method of all implementations of the
PolicyConfigurationFactory abstract class must throw a
SecurityException when called by an AccessControlContext that has not been
granted the setPolicy SecurityPermission.
| true |
| false | technology | active | true |
JACC:SPEC:68 | 3 | 3.3 | All of the public methods of all of the concrete implementations of the
PolicyConfiguration interface must throw a SecurityException when called
by an AccessControlContext that has not been granted the setPolicy
SecurityPermission.
| true |
| false | technology | active | true |
JACC:SPEC:69 | 3 | 3.3 | In cases where a required permission is not held by a caller, the
implementation must return without changing the state of the policy statement
repository.
| true |
| false | technology | active | false |
JACC:SPEC:70 | 3 | 3.3 | The containers of an application server must be granted the getPolicy
SecurityPermission and the setPolicy SecurityPermission.
| true |
| false | technology | active | false |
JACC:SPEC:71 | 4 | 4.1.1 | The Servlet container must construct (or reuse) a WebUserDataPermission object
using the request URI minus the context path as the name and with actions
composed from the HTTP method of the request and a protection value describing
the transport layer protection of the connection on which the request arrived.
The protection value used in the permission construction must be
determined as follows:
- If the request arrived on a connection deemed by the container to be protected
for confidentiality, a protection value of :CONFIDENTIAL must be used.
- If the request arrived on a connection deemed by the container to be protected
for integrity (but not confidentiality), a protection value of :INTEGRAL must be used.
- If the request arrived on a connection deemed by the container to be unprotected,
the actions used in the permission construction must contain only the HTTP
method of the request.
The Servlet container must use one of the methods described in Section 4.7,
Checking AccessControlContext Independent Grants to test if access to the
resource using the method and connection type encapsulated in the
WebUserDataPermission is permitted. If a SecurityException is thrown in the
permission determination, it must be caught, and the result of the determination
must be that access to the resource using the method and connection type is not
permitted. If access is not permitted, the request must be redirected as defined by
the Servlet Specification. If access is permitted, the request must be subjected to a
pre-dispatch decision.
| true |
| false | technology | active | true |
JACC:SPEC:72 | 4 | 4.1.2 | The Servlet container must construct (or reuse) a WebResourcePermission object
using the request URI minus the context path as the name and with actions
corresponding to the HTTP method of the request.
| true |
| false | technology | active | true |
JACC:SPEC:73 | 4 | 4.1.2 | If a SecurityException is thrown in the permission determination, it
must be caught, and the result of the determination must be that the permission is
not granted to the caller. The Servlet container may only dispatch the request to
the web resource if theWebResourcePermission is determined to be granted to the
caller. Otherwise the request must be rejected with the appropriate HTTP error
message as defined by the Servlet Specification.
| true |
| false | technology | active | true |
JACC:SPEC:74 | 4 | 4.1.2 | Before it dispatches a call to a web resource, the container must associate with
the call thread an AccessControlContext containing the principals of (only) the
target component runAs identity (as defined in Section 4.5, Component runAs
Identity).
| true |
| false | technology | active | true |
JACC:SPEC:75 | 4 | 4.1.3 | When a call is made from a web resource to isUserInRole(String
roleName) the implementation of this method must construct (or reuse) a
WebRoleRefPermission object using the servlet-name of the calling web resource
as the name and with actions equal to the roleName used in the call.
| true |
| false | technology | active | true |
JACC:SPEC:76 | 4 | 4.1.3 | If a
SecurityException is thrown in the permission determination, it must be caught,
and the result of the determination must be that the permission is not granted to
the caller. If it is determined that the WebRoleRefPermission has been granted to
the caller, isUserInRole must return true. Otherwise the return value must be false.
| true |
| false | technology | active | true |
JACC:SPEC:77 | 4 | 4.2.2 | The policy statements of the identified PolicyConfiguration are filtered to
select the set of statements that refer to a permission of the same type as the
checked permission and that have as their name the url-pattern that is the bestmatch
to the name of the checked permission. The algorithm for determining the
best matching url-pattern is described in Section 4.2.2.1, Servlet URL-Pattern
Matching Rules. The resulting policy statements are then reduced to the set
whose actions match the actions of the checked permission. If the resulting set is
empty, the evaluation may terminate, and the result of the evaluation must be that
the checked permission is determined to be unconstrained and thus implicitly
granted.
| true |
| false | technology | removed | true |
JACC:SPEC:78 | 4 | 4.2.2 | If the resulting set is not empty, and it contains one or more excluded policy
statements, the evaluation may terminate and the checked permission must be
determined not to be granted.
Otherwise, if the set contains one or more unchecked policy statements,
the evaluation may terminate and the checked permission must be
determined to be granted. If the resulting set contained neither
excluded or unchecked policy statements, then the access control context may
only be determined to have been granted the checked permission if it has been
accorded a permission with name equal to the best-matching pattern, and with
actions equal to the actions of the checked permission.
| true |
| false | technology | removed | true |
JACC:SPEC:79 | 4 | 4.2.2.1 | URL pattern matching must be guided by pattern type such that exact patterns
(those not ending with * or /, or beginning with *.) must match better than
path prefix patterns (those ending with /*)
and such that path prefix patterns must match better than extension patterns
(those beginning with *.),
and suchthat extension patterns must match better than the universal pattern /).
Among path prefix matches, longer string length patterns must match better than shorter
patterns.
| true |
| false | technology | removed | true |
JACC:SPEC:80 | 4 | 4.3 | EJB containers must enforce the authorization policies established for EJB
resources as a result of the deployment of application modules containing EJB
resources.
| true |
| false | technology | active | true |
JACC:SPEC:81 | 4 | 4.3.1 | The EJB container must construct (or reuse) an EJBMethodPermission object with
name corresponding to the ejb-name of the target resource. The actions used in the
permission construction must completely specify the method of the EJB by
identifying the method interface, method name, and method signature as defined
for a methodSpec in the documentation of the EJBMethodPermission class.
| true |
| false | technology | active | true |
JACC:SPEC:82 | 4 | 4.3.1 | If a SecurityException is
thrown in the permission determination, it must be caught, and the result of the
determination must be that the permission is not granted to the caller. The EJB
container may only dispatch the request to the EJB resource, if the
EJBMethodPermission is determined to be granted to the caller. Otherwise the
request must be rejected with the appropriate RMISecurityException, as defined
by the EJB specification.
Before it dispatches a call to an EJB, the container must associate with the call
thread an AccessControlContext containing the principals of only the target EJB
runAs identity (as defined in Section 4.5, Component runAs Identity).
| true |
| false | technology | active | true |
JACC:SPEC:83 | 4 | 4.3.2 | When an EJB makes a call to isCallerInRole(String roleName) the
implementation of this method must construct (or reuse) an
EJBRoleRefPermission object using the ejb-name of the EJB making the call as
the name and with the value of the roleName as actions.
| true |
| false | technology | active | true |
JACC:SPEC:84 | 4 | 4.3.2 | If a
SecurityException is thrown in the permission determination, it must be caught,
and the result of the determination must be that the permission is not granted to
the caller. If it is determined that the EJBRoleRefPermission has been granted to
the caller, then isCallerInRole must return true. Otherwise the return value must
be false.
| true |
| false | technology | active | true |
JACC:SPEC:85 | 4 | 4.4.1 | The policy statements of the PolicyConfiguration identified by calling the
getContextID method on the PolicyContext utility class must be tested to
determine if they match the permission being evaluated.
| true |
| false | technology | removed | true |
JACC:SPEC:86 | 4 | 4.4.1 | If one or more excluded
policy statements match the checked permission, the evaluation may terminate
and the checked permission must be determined not to be granted.
| true |
| false | technology | removed | true |
JACC:SPEC:87 | 4 | 4.4.1 | if one or more unchecked policy statements match the checked permission, the
checked permission must be determined to be granted independent of access
control context. If neither of the excluded or unchecked comparisons yield a
match, then the access control context may only be determined to have been
granted the checked permission if a matching permission has been accorded to the
access control context.
| true |
| false | technology | removed | true |
JACC:SPEC:88 | 4 | 4.4.2 | An excluded or unchecked policy statement matches a checked permission if the
policy statement satisfies the rules for matching a granted permission to the
checked permission.
| true |
| false | technology | removed | true |
JACC:SPEC:89 | 4 | 4.4.2 | A granted EJBMethodPermission matches a checked EJBMethodPermission
if their names are equivalent, and if the method specification in the actions of the
grnted permission matches the method specification in the actions of the che?ked
permission (as described in the definition of the EJBMethodPermission class).
| true |
| false | technology | removed | true |
JACC:SPEC:90 | 4 | 4.4.2 | One or more granted EJBRoleRefPermission objects match a checked
EJBRoleRefPermission if their names and actions are equivalent to the name of
the checked permission.
| true |
| false | technology | removed | true |
JACC:SPEC:91 | 4 | 4.5 | By default (and unless otherwise specified in the EJB or Servlet
specifications), components are configured such that they are assigned the identity
of their caller (such as it is) as their runAs identity. Alternatively, a Deployer may
choose to assign an environment specific identity as a component runAs identity.
In this case, the container must establish the specified identity as the component
runAs identity independent of the identity of the component caller.
| true |
| false | technology | active | true |
JACC:SPEC:92 | 4 | 4.5 | When a Deployer configures an environment specific component identity
based on a deployment descriptor specification that the component run with an
identity mapped to a role, those responsible for defining the principal-to-role
mapping must ensure that the specified identity is mapped to the role.
| true |
| false | technology | active | true |
JACC:SPEC:93 | 4 | 4.5 | A container establishes a component's runAs identity by associating an
AccessControlContext with the component's thread of execution. The container
must ensure that the AccessControlContext includes a SubjectDomainCombiner;
and the container must protect the AccessControlContext associated with a
running component such that, by default, the component is not granted
permissions sufficient to modify the AccessControlContext.
| true |
| false | technology | active | true |
JACC:SPEC:94 | 4 | 4.6 | A policy context identifier is set on a thread by calling the setContextID method
on the PolicyContext utility class. The value of a thread policy context identifier
is null until the setContextID method is called. Before invoking policy to evaluate
a transport guarantee or to perform a pre-dispatch decision, and before
dispatching into a Servlet or EJB component, a container must ensure that the
thread policy context identifier identifies the policy context corresponding
to the instance of the module or application for which the operation is being
performed.
Containers must be granted the setPolicy SecurityPermission independent
of policy context identifier (or in all policy contexts) as they need this permission
to set the policy context identifier.
| true |
| false | technology | active | false |
JACC:SPEC:95 | 4 | 4.6.1 | This specification requires that containers register policy context handlers with
the PolicyContext utility class such that Policy providers can invoke these
handlers to obtain additional context to apply in their access decisions. Policy
context handlers are objects that implement the PolicyContextHandler interface.
| true |
| false | technology | active | false |
JACC:SPEC:96 | 4 | 4.6.1 | All of the required context handlers must
return the value null when activated outside of the scope of a container's
processing of a component request. Policy providers must not call methods on or
modify the objects returned by the context handlers if these actions will cause the
container to fail in its processing of the associated request..
| true |
| false | technology | active | false |
JACC:SPEC:97 | 4 | 4.6.1.1 | All EJB and Servlet containers must register a PolicyContextHandler whose
getContext method returns a javax.security.auth.Subject object when invoked with
the key javax.security.auth.Subject.container. When this handler is activated
as the result of a policy decision performed by a container before dispatch
into a component, this handler must return a Subject containing the principals
| true |
| false | technology | active | false |
JACC:SPEC:98 | 4 | 4.6.1.2 | All EJB containers must register a PolicyContextHandler whose getContext
method returns a jakarta.xml.soap.SOAPMessage object when invoked with the
key jakarta.xml.soap.SOAPMessage. If the request being processed by the
container arrived as a SOAP request at the ServiceEndpoint method interface, the
container must return the SOAP message object when this handler is activated.
Otherwise, this handler must return the value null.
| true |
| false | technology | active | false |
JACC:SPEC:99 | 4 | 4.6.1.3 | All Servlet containers must register a PolicyContextHandler whose getContext
method returns a jakarta.servlet.http.HttpServletRequest object when invoked with
the key jakarta.servlet.http.HttpServletRequest. When this handler is activated,
the container must return the HttpServletRequest object corresponding to the
component request being processed by the container.
| true |
| false | technology | active | false |
JACC:SPEC:100 | 4 | 4.6.1.4 | All EJB containers must register a PolicyContextHandler whose getContext
method returns a jakarta.ejb.EnterpriseBean object when invoked with the key
jakarta.ejb.EnterpriseBean. When this handler is activated, the container must
return the EnterpriseBean object corresponding to theEJB component request being
processed by the container.
| true |
| false | technology | active | false |
JACC:SPEC:101 | 4 | 4.6.1.5 | All EJB containers must register a PolicyContextHandler whose getContext
method returns an array of objects (Object[]) containing the arguments of the EJB
method invocation (in the same order as they appear in the method signature)
when invoked with the key jakarta.ejb.arguments. The context handler must
return the value null when called in the context of a SOAP request that arrived at
the ServiceEndpoint method interface. Otherwise, the context handler must return
the array of objects corresponding to the parameters of the EJB component
invocation. If there are no parameters in the method signature, the context handler
must return an empty array of Object (i.e. Object[0]).
| true |
| false | technology | active | false |
JACC:SPEC:102 | 4 | 4.7 | A container must use one of the following techniques to check an instance of a
permission for which policy is defined independent of AccessControlContext.
- The container calls AccessControlContext.checkPermission with
the permission being checked as argument. The call to checkPermission
may be made on any AccessControlContext. If checkPermission throws
an AccessControlException, the permission is not granted. Otherwise the
permission is granted.
- The container calls AccessController.checkPermission with the
permission being checked. The value of the current thread?s
AccessControlContext is irrelevant in the access determination. If
checkPermission throws an AccessControlException, the checked
permission is not granted. Otherwise the permission is not granted.
- The container calls SecurityManager.checkPermission with the
permission being checked. If checkPermission throws an
AccessControlException, the checked permission is not granted. Otherwise the
permission is granted.
- The container calls Policy.implies with two arguments; the
permission being checked and a ProtectionDomain that need not be
constructed with principals. The checked permission is granted if
Policy.implies returns true. Otherwise, the permission is not granted.
- The container calls
java.security.Policy.getPermissions with a ProtectionDomain
that need not be constructed with principals. The container must call the
implies method on the returned PermissionCollection using the permission
being checked as argument. The checked permission is granted if the
PermissionCollection implies it. Otherwise, the permission is not granted. This
technique is supported but not recommended.
Prior to using any of the techniques described in this section, the container
must have established a policy context identifier as defined in Section 4.6,
Setting the Policy Context.
| true |
| false | technology | active | true |
JACC:SPEC:103 | 4 | 4.8 | A container must determine if the caller has been granted a permission by
evaluating the permission in the context of an AccessControlContext,
ProtectionDomain, or Subject containing the principals of (only) the caller. If the
caller's identity has been asserted or vouched for by a trusted authority (other than
the caller), the principals of the authority must not be included in the principals of
the caller.A container must use one of the following techniques to determine if a
permission has been granted to the caller.
The container calls AccessControlContext.checkPermission with
the permission as argument. The call to checkPermission must be made on
an AccessControlContext that contains the principals of the caller. If
checkPermission throws an AccessControlException, the permission is not
granted to the caller. Otherwise the permission is granted.
The container calls AccessController.checkPermission with the
permission as argument. The AccessControlContext associated with the thread
on which the call to checkPermission is made must contain the principals
of the caller. If checkPermission throws an AccessControlException, the
permission is not granted to the caller. Otherwise the permission is granted.
The container calls SecurityManager.checkPermission with the
permission as argument. The AccessControlContext associated with the thread
on which the call to checkPermission is made must contain the principals
of the caller. If checkPermission throws an AccessControlException, the
permission is not granted to the caller. Otherwise the permission is granted.
The container calls Policy.implies with two arguments; the
permission being checked and a ProtectionDomain constructed with the
principals of the caller. The boolean result returned by Policy.implies
indicates whether or not the permission has been granted to the caller.
The container calls
java.security.Policy.getPermissions with an argument
ProtectionDomain that was constructed with the principals of the caller. The
container must call the implies method on the returned
PermissionCollection using the permission being checked as argument. If the
PermissionCollection implies the permission being tested, the permission has
been granted to the caller. Otherwise it has not. This technique is supported but
not recommended.
| true |
| false | technology | active | true |
JACC:SPEC:104 | 4 | 4.9 | A Policy provider must return that a tested permission has not been granted if it
acquires a non-null policy context identifier by calling getContextID on the
PolicyContext class and the inService method of the
PolicyConfigurationFactory associated with the provider would return
false if called with the policy context identifier.
| true |
| false | technology | active | true |
JACC:SPEC:105 | 4 | 4.10 | A Policy provider must include the policy statements of the default policy
context in every access determination it performs.A Policy provider that either
does not call PolicyContext.getContexdID, or does so and acquires the identifier
of the default policy context, must use only the policy statements of the default
policy context to perform its access determination.
| true |
| false | technology | active | true |
JACC:SPEC:106 | 4 | 4.11 | To be compatible with this contract, all of the JRE of an application
server must perform all of the policy decisions defined by this contract by
interacting with the java.security.Policy instance available in the JRE
via the java.security.Policy.getPolicy method.
| true |
| false | technology | active | false |
JACC:SPEC:107 | 4 | 4.11 | Legacy
| false |
| false | technology | active | true |
JACC:SPEC:108 | 2 | 2.7 | Once an application server has used either of the system properties defined in
this section to replace a Policy object used by a JRE, the application server must
not use setPolicy to replace the corresponding Policy object of the running JRE
again.
| true |
| false | technology | active | false |
JACC:SPEC:109 | 4 | 4.2.1 | A Policy provider must use the combined policy statements of the default policy
context (as defined in Section 4.10, Default Policy Context) and of the policy
context identified by calling PolicyContext.getContextID to determine if they
imply the permission being checked. If one or more excluded policy statements
imply the checked permission, the evaluation may terminate and the checked
permission must be determined not to be granted. Otherwise, if one or more
unchecked policy statements imply the checked permission, the checked
permission must be determined to be granted independent of
AccessControlContext. If the status of the checked permission is not resolved by
the excluded and unchecked evaluations, it must be determined if a permission
that implies the checked permission has been granted to the
AccessControlContext being tested for the permission. The checked permission
may only be determined to be granted if a permission that implies the checked
permission has been granted to the AccessControlContext. Otherwise the
permission must be determined not to be granted.
| true |
| false | technology | active | true |
JACC:SPEC:110 | 4 | 4.2.1.1 | The URLPatternSpec syntax is defined as
follows:
URLPatternList ::= URLPattern | URLPatternList colon URLPattern
URLPatternSpec ::= URLPattern | URLPattern colon URLPatternList
name ::= URLPatternSpec
Given this syntax, A reference URLPatternSpec matches an argument
URLPatternSpec if all of the following are true.
- The first URLPattern in the argument URLPatternSpec is matched by the first
URLPattern in the reference URLPatternSpec.
-The first URLPattern in the argument URLPatternSpec is NOT matched by
any URLPattern in the URLPatternList of the reference URLPatternSpec.
- If the first URLPattern in the argument URLPatternSpec matches the first
URLPattern in the reference URLPatternSpec, then every URLPattern in the
URLPatternList of the reference URLPatternSpec must be matched by a
URLPattern in the URLPatternList of the argument URLPatternSpec.
The comparisons described above are case sensitive, and all matching is
according to the rules defined in Section 3.1.3.3, Servlet URL-Pattern Matching
Rules.
| true |
| false | technology | active | true |
JACC:SPEC:111 | 4 | 4.2.1.2 | A reference WebResourcePermission implies an argument permission if all of the
following are true.
- The argument permission is an instanceof WebResourcePermission.
- The name of the argument permission is matched by the name of the reference
permission according to the rules defined in Section 4.2.1.1, Matching Qualified
URL Pattern Names.
- The HTTP methods in the actions of the argument permission are a subset of
the HTTP methods in the actions of the reference permission.
The comparisons described above are case sensitive.
| true |
| false | technology | active | true |
JACC:SPEC:112 | 4 | 4.2.1.3 | A reference WebRoleRefPermission implies an argument permission if all of the
following are true.
- The argument permission is an instanceof WebRoleRefPermission.
- The name of the argument permission is equivalent to the name of the reference
permission.
- The actions (i.e role reference) of the argument permission is equivalent to the
actions (i.e role reference) of the reference permission.
The comparisons described above are case sensitive.
| true |
| false | technology | active | true |
JACC:SPEC:113 | 4 | 4.2.1.4 | A reference WebUserDataPermission implies an argument permission if all of the
following are true.
- The argument permission is an instanceof WebUserDataPermission.
- The name of the argument permission is matched by the name of the reference
permission according to the rules defined in Section 4.2.1.1, Matching Qualified
URL Pattern Names.
- The HTTP methods in the actions of the argument permission are a subset of
the HTTP methods in the actions of the reference permission.
- The transportType in the actions of the reference permission either corresponds
to the value "NONE", or equals the transportType in the actions of the
argument permission.
The comparisons described above are case sensitive.
| true |
| false | technology | active | true |
JACC:SPEC:113 | 4 | 4.2.1.4 | A reference WebUserDataPermission implies an argument permission if all of the
following are true.
- The argument permission is an instanceof WebUserDataPermission.
- The name of the argument permission is matched by the name of the reference
permission according to the rules defined in Section 4.2.1.1, ?Matching Qualified
URL Pattern Names.
- The HTTP methods in the actions of the argument permission are a subset of
the HTTP methods in the actions of the reference permission.
- The transportType in the actions of the reference permission either corresponds
to the value "NONE", or equals the transportType in the actions of the
argument permission.
The comparisons described above are case sensitive.
| true |
| false | technology | active | true |
JACC:SPEC:114 | 4 | 4.4.1 | A Policy provider must employ the policy decision semantics described in
Section 4.2.1, Servlet Policy Decision Semantics in the Processing of EJB
Policy decisions.
| true |
| false | technology | active | true |
JACC:SPEC:115 | 4 | 4.4.1.1 | A reference EJBMethodPermission implies an argument permission, if all of the
following are true.
- The argument permission is an instanceof EJBMethodPermission.
- The name of the argument permission is equivalent to the name of the reference
permission.
- The methods to which the argument permission applies (as defined in its actions)
must be a subset of the methods to which the reference permission applies
(as defined in its actions). This rule is satisfied if all of the following
conditions are met.
- The method name of the reference permission is null, the empty
string, or equivalent to the method name of the argument
permission.
- The method interface of the reference permission is null, the empty
string, or equivalent to the method interface of the argument
permission.
- The method parameter type list of the reference permission is null,
the empty string, or equivalent to the method parameter type list of
the argument permission.
The comparisons described above are case sensitive.
| true |
| false | technology | active | true |
JACC:SPEC:116 | 4 | 4.4.1.2 | A reference EJBRoleRefPermission implies an argument permission, if all of the
following are true.
- The argument permission is an instanceof EJBRoleRefPermission.
- The name of the argument permission is equivalent to the name of the reference
permission.
- The actions (i.e role reference) of the argument permission is equivalent to the
actions (i.e role reference) of the reference permission.
The comparisons described above are case sensitive.
| true |
| false | technology | active | true |
JACC:SPEC:117 | 3 | 3.1.3.1 | A WebResourcePermission and a WebUserDataPermission must be
instantiated for each url-pattern in the deployment descriptor and the default
pattern, "/", that is not combined by the web-resource-collection elements
of the deployment descriptor with every HTTP method value. The permission
objects must be constructed using the qualified pattern as their name and with
actions defined by the subset of the HTTP methods that do not occur in
combination with the pattern.The resulting permissions must be added to the
unchecked policy statements by calling the addToUncheckedPolicy method
on the PolicyConfiguration object.
| true |
| false | technology | active | true |
JACC:SPEC:118 | 3 | 3.1.3.1 | The WebResourcePermission and WebUserDataPermission objects resulting
from the translation of a Servlet deployment descriptor must be constructed with
name produced by qualifying the URL pattern. The rules for qualifying a URL
pattern are dependent on the rules for determining if one URL pattern matches
another as defined in Section 3.1.3.3, Servlet URL-Pattern Matching Rules, and
are described as follows:
- If the pattern is a path prefix pattern, it must be qualified by every path-prefix
pattern in the deployment descriptor matched by and different from the pattern
being qualified. The pattern must also be qualified by every exact pattern
appearing in the deployment descriptor that is matched by the pattern being
qualified.
- If the pattern is an extension pattern, it must be qualified by every path-prefix
pattern appearing in the deployment descriptor and every exact pattern in the
deployment descriptor that is matched by the pattern being qualified.
- If the pattern is the default pattern, "/", it must be qualified by every other pattern
except the default pattern appearing in the deployment descriptor.
- If the pattern is an exact pattern, its qualified form must not contain any qualifying
patterns.
URL patterns are qualified by appending to their String representation, a
colon separated representation of the list of patterns that qualify the pattern.
Duplicates must not be included in the list of qualifying patterns, and any
qualifying pattern matched by another qualifying pattern may be dropped from
the list.
QualifyingPatternList ::=
empty string | colon QualifyingPattern |
QualifyingPatternList colon QualifyingPattern
QualifiedPattern ::= Pattern QualifyingPatternList
Any pattern, qualified by a pattern that matches it, is overridden and made
irrelevant (in the translation) by the qualifying pattern. Specifically, all extension
patterns and the default pattern are made irrelevant by the presence of the path
prefix pattern "/*" in a deployment descriptor. Patterns qualified by the "/*"
pattern violate the URLPatternSpec constraints of WebResourcePermission and
WebUserDataPermission names and must be rejected by the corresponding
permission constructors.
| true |
| false | technology | active | true |
JACC:SPEC:119 | 3 | 3.1.3.1 | This URL pattern matches another pattern if they are related, by case sensitive
comparison, as follows:
- their pattern values are String equivalent, or
- this pattern is the path-prefix pattern "/*", or
- this pattern is a path-prefix pattern (that is, it starts with "/" and ends with
"/*") and the other pattern starts with the substring of this pattern, minus its
last 2 characters, and the next character of the other pattern, if there is one, is
"/", or
- this pattern is an extension pattern (that is, it starts with "*.") and the other
pattern ends with this pattern, or
- this pattern is the special default pattern, "/", which matches all other patterns.
| true |
| false | technology | active | true |
JACC:SPEC:120 | 3 | 3.1.6 | After the PolicyConfiguration objects are linked, the commit method
must be called on all the PolicyConfiguration objects to place them in
service such that their policy statements will be assimilated by the corresponding
Policy providers.
| true |
| false | technology | active | false |
JACC:SPEC:121 | 1 | 1.5 |
The following list defines changes to this contract that
apply to containers running without a Java SE 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.3,
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.
| true |
| false | technology | active | false |
JACC:SPEC:122 | 3 | 3.0 |
This subcontract also applies to the translation of
authorization policy annotations that have an equivalent
representation in Jakarta EE deployment descriptor policy
constructs(i.e security-constraint, method-permission,
security-role-ref, and exclude-list elements)
| true |
| false | technology | active | true |
JACC:SPEC:123 | 3 | 3.1 |
Independent of this specification, Jakarta EE deployment tools must translate and complete the declarative policy
statements appearing in deployment descriptors into a form suitable for securing applications on the platform.
These deployment tools must combine policy annotations in Java code with policy statements appearing in deployment
descriptors to yield complete representations of authorization policy suitable for securing applications on the platform.
The rules for combining authorization policy annotations with declarative policy statements are described in the
Jakarta Enterprise Beans, Jakarta Servlet, and Jakarta EE platform specifications. Independent of whether annotations
factor in the translation, the resulting policy statements may differ in form from the policy statements appearing
in the deployment descriptors.
| true |
| false | technology | active | true |
JACC:SPEC:124 | 3 | 3.1.2 |
When an application is composed of multiple web modules, a separate
policy context must be defined per module. This is necessary to ensure
that url-pattern based and servlet name based policy statements
configured for one module do not interfere with those configured
for another.
| true |
| false | technology | active | true |
JACC:SPEC:125 | 3 | 3.1.4 |
When an application is composed of multiple EJB jars, no two jars
that share at least one ejb-name value in common may share the same
policy context identifiers.
| true |
| false | technology | active | false |
JACC:SPEC:126 | 4 | 4.1.1 |
Permission Names for Transport and Pre-Dispatch Decisions
The name of the permission checked in a transport or pre-dispatch
decision must be the value that would result from applying the Servlet
welcome file processing rules to the unqualified request URI minus the
context path.
For the special case where this transformation of the request URI
yields the URLPattern /, the empty string URLPattern, , must be
used as the permission name. The welcome file processing rules are
defined in the Servlet specification. For the special case where the
empty string must be substituted for the / pattern in the permission
evaluation, all target related processing (including servlet mapping,
filter mapping, and form based login processing) must be performed
using the original pattern, /.
| true |
| false | technology | active | true |
JACC:SPEC:127 | 4 | 4.6.1.4 |
The EnterpriseBean object must only be returned when this handler
is activated within the scope of a container's processing of a
business method of the EJB Remote, Local, or ServiceEndpoint
interfaces of the EnterpriseBean object. The value null must be
returned if the bean implementation class does not implement the
jakarta.ejb.EnterpriseBean interface.
| true |
| false | technology | active | false |