Jakarta Authorization - 1.5
Specification Assertion Detail

TotalsTotalActiveDeprecatedRemoved
# of Assertions 136123013
# of Required Assertions 127116011
# of Optional Assertions 9702

IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
JACC:SPEC:211.4J2EE 1.4 platforms must implement the contract defined by this JSR.true
falsetechnologyactivetrue
JACC:SPEC:311.4Support for the contract by J2EE 1.3 platforms is optional. (OPTIONAL)false
falsetechnologyactivefalse
JACC:SPEC:411.4Each 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
falsetechnologyactivetrue
JACC:SPEC:511.4Each 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
falsetechnologyactivetrue
JACC:SPEC:611.4Each 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
falsetechnologyactivetrue
JACC:SPEC:711.4Each provider must satisfy all of the authorization requirements of the EJB and Servlet specifications corresponding to the target platform. true
falsetechnologyactivetrue
JACC:SPEC:811.4In 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
falsetechnologyactivefalse
JACC:SPEC:911.4In 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
falsetechnologyactivefalse
JACC:SPEC:1011.4To 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
falsetechnologyactivetrue
JACC:SPEC:1111.4This 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
falsetechnologyactivefalse
JACC:SPEC:1211.4For a container to support this contract, it must execute in an environment controlled by a J2SE security manager. true
falsetechnologyactivetrue
JACC:SPEC:1311.4The 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
falsetechnologyactivefalse
JACC:SPEC:1422.1The 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
falsetechnologyactivetrue
JACC:SPEC:1522.5Each 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
falsetechnologyactivetrue
JACC:SPEC:1622.5If 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
falsetechnologyactivetrue
JACC:SPEC:1722.5A 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-javax.security.jacc policy decisions to the corresponding default system Policy implementation class. true
falsetechnologyactivefalse
JACC:SPEC:1822.5A 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
falsetechnologyactivefalse
JACC:SPEC:1922.5The 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
falsetechnologyactivefalse
JACC:SPEC:2022.6A J2SE 1.4 provider may support replacement of the JAAS Policy object if and only if all javax.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
falsetechnologyactivetrue
JACC:SPEC:2122.7An application server or container must bundle or install the javax.security.jacc standard extension. This package must include the abstract javax.security.jacc.PolicyConfigurationFactory class, the javax.security.jacc.PolicyConfiguration and javax.security.jacc.PolicyContextHandler interfaces, and implementations of the javax.security.jacc.PolicyContextException exception, the javax.security.jacc Permission classes, and the javax.security.jacc.PolicyContext utility class. true
falsetechnologyactivefalse
JACC:SPEC:2222.7To enable delegation of non-javax.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 javax.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
falsetechnologyactivetrue
JACC:SPEC:2322.7For each JRE of a J2EE 1.4 application server, if the system property javax.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 javax.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
falsetechnologyactivetrue
JACC:SPEC:2422.7.1A 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
falsetechnologyactivetrue
JACC:SPEC:2533.1The 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
falsetechnologyactivetrue
JACC:SPEC:2633.1The getPolicyConfiguration method of the factories must be used to find or instantiate PolicyConfiguration objects corresponding to the application or modules being deployed. true
falsetechnologyactivetrue
JACC:SPEC:2733.1The declarative authorization policy statements derived from application or module deployment descriptor(s) must be translated to create instances of the corresponding javax.security.jacc Permission classes. true
falsetechnologyactivetrue
JACC:SPEC:2833.1Methods of the PolicyConfiguration interface must be used with the permissions resulting from the translation to create policy statements within the PolicyConfiguration objects. true
falsetechnologyactivetrue
JACC:SPEC:2933.1The PolicyConfiguration objects must be linked such that the same principal-to-role mapping will be applied to all the modules of the application. true
falsetechnologyactivetrue
JACC:SPEC:3033.1Independent of this specification, J2EE 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
falsetechnologyactivefalse
JACC:SPEC:3133.1.1.1A 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
falsetechnologyactivefalse
JACC:SPEC:3233.1.2A servlet container is responsible for mapping the target name or address information of an HTTP request to the appropriate hostname. true
falsetechnologyactivetrue
JACC:SPEC:3333.1.3A 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
falsetechnologyactivetrue
JACC:SPEC:3433.1.3.1A 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
falsetechnologyactivetrue
JACC:SPEC:3533.1.3.1A 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
falsetechnologyactivetrue
JACC:SPEC:3633.1.3.1Each 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
falsetechnologyactivetrue
JACC:SPEC:3733.1.3.1 The resulting permissions must be added to the corresponding roles by calling the addToRole method on the PolicyConfiguration object. true
falsetechnologyremovedtrue
JACC:SPEC:3833.1.3.1A 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
falsetechnologyactivetrue
JACC:SPEC:3933.1.3.1The 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
falsetechnologyremovedtrue
JACC:SPEC:4033.1.3.1The 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
falsetechnologyremovedtrue
JACC:SPEC:4133.1.3.1A 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
falsetechnologyactivetrue
JACC:SPEC:4233.1.3.1A 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
falsetechnologyactivetrue
JACC:SPEC:4333.1.3.2For 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
falsetechnologyactivetrue
JACC:SPEC:4433.1.3.2The 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
falsetechnologyactivetrue
JACC:SPEC:4533.1.3.2For 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
falsetechnologyactivetrue
JACC:SPEC:12833.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
falsetechnologyactivetrue
JACC:SPEC:12933.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
falsetechnologyactivetrue
JACC:SPEC:13033.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
falsetechnologyactivetrue
JACC:SPEC:13133.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
falsetechnologyactivetrue
JACC:SPEC:13233.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
falsetechnologyactivetrue
JACC:SPEC:13333.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
falsetechnologyactivetrue
JACC:SPEC:13433.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
falsetechnologyactivetrue
JACC:SPEC:13533.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
falsetechnologyactivetrue
JACC:SPEC:13633.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
falsetechnologyactivetrue
JACC:SPEC:4633.1.4an 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
falsetechnologyactivefalse
JACC:SPEC:4733.1.5.1An EJBMethodPermission object must be created for each role-name or unchecked element contained in each method-permission element appearing in the deployment descriptor. true
falsetechnologyactivetrue
JACC:SPEC:4833.1.5.1The 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
falsetechnologyactivetrue
JACC:SPEC:4933.1.5.1If 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
falsetechnologyactivetrue
JACC:SPEC:5033.1.5.2An 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
falsetechnologyactivetrue
JACC:SPEC:5133.1.5.3For 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
falsetechnologyactivetrue
JACC:SPEC:5233.1.6The 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
falsetechnologyactivetrue
JACC:SPEC:5333.1.6When 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
falsetechnologyactivetrue
JACC:SPEC:5433.1.6Once 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
falsetechnologyactivefalse
JACC:SPEC:5533.1.6The 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
falsetechnologyactivefalse
JACC:SPEC:5633.1.7A 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
falsetechnologyactivetrue
JACC:SPEC:5733.1.7To 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
falsetechnologyactivefalse
JACC:SPEC:5833.1.7After 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
falsetechnologyactivefalse
JACC:SPEC:5933.1.7To 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
falsetechnologyremovedfalse
JACC:SPEC:6033.1.8Containers 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
falsetechnologyactivetrue
JACC:SPEC:6133.1.9Containers are not required to implement redeployment functionality.false
falsetechnologyactivefalse
JACC:SPEC:6233.1.9Containers 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
falsetechnologyactivetrue
JACC:SPEC:6333.2the provider must include an implementation of the javax.security.jacc.PolicyConfigurationFactory class along with a matched implementation of a class that implements the javax.security.jacc.PolicyConfiguration interface. true
falsetechnologyactivetrue
JACC:SPEC:6433.2In 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
falsetechnologyactivefalse
JACC:SPEC:6533.2The 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
falsetechnologyactivetrue
JACC:SPEC:6633.2The 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
falsetechnologyactivetrue
JACC:SPEC:6733.3The getPolicyConfigurationFactory, and inService methods of the abstract factory class, javax.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
falsetechnologyactivetrue
JACC:SPEC:6833.3All 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
falsetechnologyactivetrue
JACC:SPEC:6933.3In 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
falsetechnologyactivefalse
JACC:SPEC:7033.3The containers of an application server must be granted the getPolicy SecurityPermission and the setPolicy SecurityPermission. J2EE 1.3 Containers that choose to support this contract must be granted the getPolicy AuthPermission and the setPolicy AuthPermission. true
falsetechnologyactivefalse
JACC:SPEC:7144.1.1The 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
falsetechnologyactivetrue
JACC:SPEC:7244.1.2The 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
falsetechnologyactivetrue
JACC:SPEC:7344.1.2If 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
falsetechnologyactivetrue
JACC:SPEC:7444.1.2Before 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
falsetechnologyactivetrue
JACC:SPEC:7544.1.3When 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
falsetechnologyactivetrue
JACC:SPEC:7644.1.3If 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
falsetechnologyactivetrue
JACC:SPEC:7744.2.2The 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
falsetechnologyremovedtrue
JACC:SPEC:7844.2.2If 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
falsetechnologyremovedtrue
JACC:SPEC:7944.2.2.1URL 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
falsetechnologyremovedtrue
JACC:SPEC:8044.3EJB containers must enforce the authorization policies established for EJB resources as a result of the deployment of application modules containing EJB resources. true
falsetechnologyactivetrue
JACC:SPEC:8144.3.1The 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
falsetechnologyactivetrue
JACC:SPEC:8244.3.1If 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
falsetechnologyactivetrue
JACC:SPEC:8344.3.2When 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
falsetechnologyactivetrue
JACC:SPEC:8444.3.2If 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
falsetechnologyactivetrue
JACC:SPEC:8544.4.1The 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
falsetechnologyremovedtrue
JACC:SPEC:8644.4.1If 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
falsetechnologyremovedtrue
JACC:SPEC:8744.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
falsetechnologyremovedtrue
JACC:SPEC:8844.4.2An 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
falsetechnologyremovedtrue
JACC:SPEC:8944.4.2A 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
falsetechnologyremovedtrue
JACC:SPEC:9044.4.2One or more granted EJBRoleRefPermission objects match a checked EJBRoleRefPermission if their names and actions are equivalent to the name of the checked permission. true
falsetechnologyremovedtrue
JACC:SPEC:9144.5By 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
falsetechnologyactivetrue
JACC:SPEC:9244.5When 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
falsetechnologyactivetrue
JACC:SPEC:9344.5A 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
falsetechnologyactivetrue
JACC:SPEC:9444.6A 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
falsetechnologyactivefalse
JACC:SPEC:9544.6.1This 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
falsetechnologyactivefalse
JACC:SPEC:9644.6.1All 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
falsetechnologyactivefalse
JACC:SPEC:9744.6.1.1All 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
falsetechnologyactivefalse
JACC:SPEC:9844.6.1.2All EJB containers must register a PolicyContextHandler whose getContext method returns a javax.xml.soap.SOAPMessage object when invoked with the key javax.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
falsetechnologyactivefalse
JACC:SPEC:9944.6.1.3All Servlet containers must register a PolicyContextHandler whose getContext method returns a javax.servlet.http.HttpServletRequest object when invoked with the key javax.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
falsetechnologyactivefalse
JACC:SPEC:10044.6.1.4All EJB containers must register a PolicyContextHandler whose getContext method returns a javax.ejb.EnterpriseBean object when invoked with the key javax.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
falsetechnologyactivefalse
JACC:SPEC:10144.6.1.5All 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 javax.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
falsetechnologyactivefalse
JACC:SPEC:10244.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 J2EE 1.4 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 J2EE 1.4 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. - The J2EE 1.3 container calls javax.security.auth.Policy.getPermissions to determine the collection of permissions granted independent of AccessControlContext. The Subject in the call to getPermissions may be null. 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
falsetechnologyactivetrue
JACC:SPEC:10344.8A 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 J2EE 1.4 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 J2EE 1.4 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. The J2EE 1.3 container calls javax.security.auth.Policy.getPermissions with an argument Subject containing 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. 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
falsetechnologyactivetrue
JACC:SPEC:10444.9A 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
falsetechnologyactivetrue
JACC:SPEC:10544.10A 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
falsetechnologyactivetrue
JACC:SPEC:10644.11To be compatible with this contract, all of the JRE of a J2EE 1.4 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
falsetechnologyactivefalse
JACC:SPEC:10744.11All of the JRE of a J2EE 1.3 application server must perform all of the policy decisions defined by this contract by interacting with the javax.security.auth.Policy instance available in the JRE via the javax.security.auth.getPolicy method. false
falsetechnologyactivetrue
JACC:SPEC:10822.7Once 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
falsetechnologyactivefalse
JACC:SPEC:10944.2.1A 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
falsetechnologyactivetrue
JACC:SPEC:11044.2.1.1The 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
falsetechnologyactivetrue
JACC:SPEC:11144.2.1.2A 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
falsetechnologyactivetrue
JACC:SPEC:11244.2.1.3A 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
falsetechnologyactivetrue
JACC:SPEC:11344.2.1.4A 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
falsetechnologyactivetrue
JACC:SPEC:11344.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
falsetechnologyactivetrue
JACC:SPEC:11444.4.1A 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
falsetechnologyactivetrue
JACC:SPEC:11544.4.1.1A 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
falsetechnologyactivetrue
JACC:SPEC:11644.4.1.2A 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
falsetechnologyactivetrue
JACC:SPEC:11733.1.3.1A 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
falsetechnologyactivetrue
JACC:SPEC:11833.1.3.1The 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
falsetechnologyactivetrue
JACC:SPEC:11933.1.3.1This 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
falsetechnologyactivetrue
JACC:SPEC:12033.1.6After 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
falsetechnologyactivefalse
JACC:SPEC:12111.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
falsetechnologyactivefalse
JACC:SPEC:12233.0 This subcontract also applies to the translation of authorization policy annotations that have an equivalent representation in Java EE deployment descriptor policy constructs(i.e security-constraint, method-permission, security-role-ref, and exclude-list elements) true
falsetechnologyactivetrue
JACC:SPEC:12333.1 Independent of this specification, J2EE deployment tools must translate and complete the declarative policy statements appearing in deployment descriptors into a form suitable for securing applications on the platform. On versions of the Java EE platform that require support for authorization policy annotations, the 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 versions of the EJB, Servlet, and Java EE platform specifications that require support for the annotations. 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
falsetechnologyactivetrue
JACC:SPEC:12433.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
falsetechnologyactivetrue
JACC:SPEC:12533.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
falsetechnologyactivefalse
JACC:SPEC:12644.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
falsetechnologyactivetrue
JACC:SPEC:12744.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 javax.ejb.EnterpriseBean interface. true
falsetechnologyactivefalse