ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable |
Security:SPEC:2.2-1 | 2 | 2 | validateRequest() will be invoked before the doFilter() method of any servlet filter or the service() method of any servlet in the application for requests | true |
| false | technology | active | true |
Security:SPEC:2.2-2 | 2 | 2 | in addition, in response to application code calling the authenticate() method on the HttpServletRequest. | true |
| false | technology | active | true |
Security:SPEC:2.2-3 | 2 | 2 | secureResponse() will be invoked after the doFilter() method of any servlet filter or the service() method of any servlet in the application for requests to constrained as well as to unconstrained resources, but only if any of these two methods have indeed been invoked. | true |
| false | technology | active | true |
Security:SPEC:2.2-4 | 2 | 2 | cleanSubject() will be invoked in response to the application calling the logout() method on the
HttpServletRequest | true |
| false | technology | active | true |
Security:SPEC:2.2-5 | 2 | 2 | The validateRequest() method is provided to allow a caller to authenticate. An implementation of this method can inspect the HTTP request to extract a credential or other information, or it can write to the HTTP response to, for example, redirect a caller to an OAuth provider, or return an error response. | true |
| false | technology | active | true |
Security:SPEC:2.2-6 | 2 | 2 | After a credential has been obtained and validated, the result of the validation can be communicated to the container using the HttpMessageContext parameter, which is described in more detail below. | true |
| false | technology | active | true |
Security:SPEC:2.3-1 | 2 | 3 | An HttpAuthenticationMechanism must be a CDI bean. | true |
| false | technology | active | true |
Security:SPEC:2.3-2 | 2 | 3 | An HttpAuthenticationMechanism is assumed to be normal scoped. | true |
| false | technology | active | true |
Security:SPEC:2.3-3 | 2 | 3 | It MUST be possible for the definition of an HttpAuthenticationMechanism to exist within the application archive. | true |
| false | technology | active | true |
Security:SPEC:2.3-4 | 2 | 3 | The container MAY override an application’s chosen HttpAuthenticationMechanism with one selected by the container, but SHOULD do so only if explicitly configured to.
If the container does not override the application, it MUST place in service any HttpAuthenticationMechanism that is provided, either directly or via annotation, by the application. | true |
| false | technology | active | true |
Security:SPEC:2.3-5 | 2 | 3 | The container MUST supply a "bridge" ServerAuthModule that integrates HttpAuthenticationMechanism with JASPIC. | true |
| false | technology | active | true |
Security:SPEC:2.3-6 | 2 | 3 | The bridge module MUST look up the correct HttpAuthenticationMechanism using CDI, then delegate to the HttpAuthenticationMechanism when the bridge module’s methods are invoked. | true |
| false | technology | active | true |
Security:SPEC:2.3-7 | 2 | 3 | Since the method signatures and return values of the two interfaces are similar, but not the same, the bridge module MUST convert back and forth. | true |
| false | technology | active | true |
Security:SPEC:2.4-1 | 2 | 4 | BASIC - Authenticates according to the mechanism as described in 13.6.1, "HTTP Basic Authentication", in [SERVLET31]. See also RFC 7617, "The 'Basic' HTTP Authentication Scheme" [RFC7617]. This bean is activated and configured via the @BasicAuthenticationMechanismDefinition annotation. | true |
| false | technology | active | true |
Security:SPEC:2.4-2 | 2 | 4 | FORM - Authenticates according to the mechanism as described in 13.6.3, "Form Based Authentication", in [SERVLET31]. This bean is activated and configured via the @FormAuthenticationMechanismDefinition annotation. | true |
| false | technology | active | true |
Security:SPEC:2.4-3 | 2 | 4 | Custom FORM - A variant on FORM, with the difference that continuing the authentication dialog as described in [SERVLET31], section 13.6.3, step 3, and further clarified in section 13.6.3.1, does not happen by posting back to j_security_check, but by invoking SecurityContext.authenticate() with the credentials the application collected. This bean is activated and configured via the @CustomFormAuthenticationMechanismDefinition annotation. | true |
| false | technology | active | true |
Security:SPEC:2.4-4 | 2 | 4 | All of these beans MUST have the qualifier @Default and the scope @ApplicationScoped, as defined by the CDI specification. | true |
| false | technology | active | true |
Security:SPEC:2.4-5 | 2 | 4 | All of the built-in beans MUST support authentication using IdentityStore | true |
| false | technology | active | true |
Security:SPEC:2.4.6-1 | 2 | 4.6 | AutoApplySession Annotation | true |
| false | technology | active | true |
Security:SPEC:2.5-1 | 2 | 5 | This specification mandates that when a ServerAuthModule is called by the Servlet container, CDI services (such as the BeanManager) MUST be fully available, and all scopes that are defined to be active during the service() method of a servlet, or during the doFilter() method of a servlet filter, MUST be active. | true |
| false | technology | active | true |
Security:SPEC:2.5-2 | 2 | 5 | Specifically this means that the request, session, and application scopes MUST be active, and that a ServerAuthModule method such as validateRequest() MUST be able to obtain a reference to the CDI BeanManager programmatically (for example, by doing a JNDI lookup), and MUST be able to use that reference to obtain a valid request-scoped, session-scoped, or application-scoped bean. | true |
| false | technology | active | true |
Security:SPEC:3.1-1 | 3 | 1 | The IdentityStoreHandler interface defines a mechanism for invoking on IdentityStore to validate a user credential.
| true |
| false | technology | active | true |
Security:SPEC:3.1-2 | 3 | 1 | An IdentityStoreHandler can also orchestrate an authentication across multiple IdentityStore instances, returning an aggregated result.
| true |
| false | technology | active | true |
Security:SPEC:3.1-3 | 3 | 1 | A default IdentityStoreHandler implementation is supplied by the container
| true |
| false | technology | active | true |
Security:SPEC:3.1-4 | 3 | 1 | but applications can also supply their own implementation.
| true |
| false | technology | active | true |
Security:SPEC:3.2-1 | 3 | 2 | An implementation of IdentityStore can choose to handle either or both of these methods, depending on its capabilities and configuration. It indicates which methods it handles through the set of values returned by its validationTypes() method | true |
| false | technology | active | true |
Security:SPEC:3.2.1-1 | 3 | 2.1 | Only the caller principal is required to be present for a successful validation. | true |
| false | technology | active | true |
Security:SPEC:3.2.1-2 | 3 | 2.1 | VALID: Validation succeeded and the user is authenticated. The caller principal and groups (if any) are available ONLY with this result status. | true |
| false | technology | active | true |
Security:SPEC:3.2.1-3 | 3 | 2.1 | INVALID: Validation failed. The supplied Credential was invalid, or the corresponding user was not found in the user store. | true |
| false | technology | active | true |
Security:SPEC:3.2.1-4 | 3 | 2.1 | NOT_VALIDATED: Validation was not attempted, because the IdentityStore does not handle the supplied Credential type. | true |
| false | technology | active | true |
Security:SPEC:3.2.1-5 | 3 | 2.1 | for example, validate(Credential) would delegate to the following method of ExampleIdentityStore if passed a UsernamePasswordCredential | true |
| false | technology | active | true |
Security:SPEC:3.2.2-1 | 3 | 2.2 | The getCallerGroups() method supports aggregation of identity stores, where one identity store is used to authenticate users, but one or more other stores are used to retrieve additional groups. In such a scenario, it is necessary to query identity stores without validating the caller’s credential against the stores. | true |
| false | technology | active | true |
Security:SPEC:3.2.2-2 | 3 | 2.2 | Note that getCallerGroups() is not intended as a general purpose API for retrieving user groups. It should be called only by an IdentityStoreHandler, in the course of orchestrating a validate() call across multiple identity stores. | true |
| false | technology | active | true |
Security:SPEC:3.2.2-4 | 3 | 2.2 | As a result, it is never necessary to call getCallerGroups() when there is only one IdentityStore, because the same groups are returned by the validate() method. | true |
| false | technology | active | true |
Security:SPEC:3.2.3-1 | 3 | 2.3 | The priority() method allows an IdentityStore to be configured with an ordinal number indicating the order in which it should be consulted when multiple IdentityStores are present (more precisely, when multiple enabled CDI Beans with type IdentityStore are available). Lower numbers represent higher priority, so an IdentityStore with a lower priority value is called before an IdentityStore with a higher priority value. | true |
| false | technology | active | true |
Security:SPEC:3.2.3-2 | 3 | 2.3 | The validationTypes() method returns a Set of enum constants of type ValidationType, indicating the purposes for which an IdentityStore should be used | true |
| false | technology | active | true |
Security:SPEC:3.2.4-1 | 3 | 2.4 | The purpose of the IdentityStoreHandler is to allow for multiple identity stores to logically act as a
single IdentityStore to the HttpAuthenticationMechanism. | true |
| false | technology | active | true |
Security:SPEC:3.2.4-2 | 3 | 2.4 | A compliant implementation of this specification MUST provide a default implementation of the IdentityStoreHandler that is an enabled CDI bean with qualifier @Default, and scope @ApplicationScoped, as defined by the CDI specification. | true |
| false | technology | active | true |
Security:SPEC:3.2.4-3 | 3 | 2.4 | If a call to validate() returns a result with status INVALID, remember it, in case no IdentityStore returns a VALID result. | true |
| false | technology | active | true |
Security:SPEC:3.2.4-4 | 3 | 2.4 | If a call to validate() returns a result with status VALID, remember this result and stop calling validate(). | true |
| false | technology | active | true |
Security:SPEC:3.2.4-5 | 3 | 2.4 | If a result was previously returned with status INVALID, return that result. | true |
| false | technology | active | true |
Security:SPEC:3.2.4-6 | 3 | 2.4 | Otherwise, return a result with status NOT_VALIDATED. | true |
| false | technology | active | true |
Security:SPEC:3.2.4-7 | 3 | 2.4 | Add any groups returned in the CredentialValidationResult to the set of groups, if and only if the identity store that returned the VALID result declared the PROVIDE_GROUPS validation type. | true |
| false | technology | active | true |
Security:SPEC:3.2.4-8 | 3 | 2.4 | Call the getCallerGroups() method on all available IdentityStore beans that declared only the PROVIDE_GROUPS validation type, in the order induced by the return value of the getPriority() method of each IdentityStore, passing in the CredentialValidationResult obtained during the previous phase. Add the groups returned by each call to the set of accumulated groups. | true |
| false | technology | active | true |
Security:SPEC:3.3-1 | 3 | 3 | Installation of an IdentityStore depends on the CDI specification. That is, an IdentityStore is considered installed and available for usage when it’s available to the CDI runtime as an enabled Bean. An IdentityStore is assumed to be normal scoped. | true |
| false | technology | active | true |
Security:SPEC:3.3-2 | 3 | 3 | It MUST be possible for the definition of an IdentityStore to exist within the application archive. | true |
| false | technology | active | true |
Security:SPEC:3.4-1 | 3 | 4 | LDAP—Supports caller data that is stored in an external LDAP server. This bean is activated and
configured via the @LdapIdentityStoreDefinition
annotation | true |
| false | technology | active | true |
Security:SPEC:3.4-2 | 3 | 4 | Database — Supports caller data that is stored in an external database accessible via a DataSource bound to JNDI. This bean is activated and configured via the @DataBaseIdentityStoreDefinition annotation. | true |
| false | technology | active | true |
Security:SPEC:3.4-3 | 3 | 4 | Each of these beans MUST have the qualifier @Default and the scope @ApplicationScoped, as defined by the CDI specification. | true |
| false | technology | active | true |
Security:SPEC:4.2-1 | 3 | 2 | The getCallerPrincipal() method retrieves the Principal representing the caller. | true |
| false | technology | active | true |
Security:SPEC:4.2-2 | 4 | 2 | The isCallerInRole() method takes a String argument that represents the role that is to be tested for. It is undefined by this specification how the role determination is made, but the result MUST be the same as if the corresponding container-specific call had been made (i.e., HttpServletRequest.isUserInRole(), EJBContext.isCallerInRole()), | true |
| false | technology | active | true |
Security:SPEC:4.3-1 | 4 | 3 | The hasAccessToWebResource() method determines if the caller has access to the specified web resource for the specified HTTP methods, as determined by the security constraints configured for the application. | true |
| false | technology | active | true |
Security:SPEC:4.4-1 | 4 | 4 | The authenticate() method allows an application to signal to the container that it should start the authentication process with the caller. | true |
| false | technology | active | true |