## Jakarta Security 1.0 - 1.0
Specification Assertion Detail

Totals | Total | Active | Deprecated | Removed
# of Assertions | 53 | 53 | 0 | 0
# of Required Assertions | 53 | 53 | 0 | 0
# of Optional Assertions | 0 | 0 | 0 | 0

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