Java EE Security API
Security API 1.0 - 1.0
Specification Assertion Detail

TotalsTotalActiveDeprecatedRemoved
# of Assertions 535300
# of Required Assertions 535300
# of Optional Assertions 0000

IDChapterSectionDescriptionRequiredDependencyImplementation SpecificDefined byStatusTestable
Security:SPEC:2.2-122validateRequest() will be invoked before the doFilter() method of any servlet filter or the service() method of any servlet in the application for requeststrue
falsetechnologyactivetrue
Security:SPEC:2.2-222in addition, in response to application code calling the authenticate() method on the HttpServletRequest.true
falsetechnologyactivetrue
Security:SPEC:2.2-322secureResponse() 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
falsetechnologyactivetrue
Security:SPEC:2.2-422cleanSubject() will be invoked in response to the application calling the logout() method on the HttpServletRequesttrue
falsetechnologyactivetrue
Security:SPEC:2.2-522The 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
falsetechnologyactivetrue
Security:SPEC:2.2-622After 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
falsetechnologyactivetrue
Security:SPEC:2.3-123An HttpAuthenticationMechanism must be a CDI bean.true
falsetechnologyactivetrue
Security:SPEC:2.3-223An HttpAuthenticationMechanism is assumed to be normal scoped.true
falsetechnologyactivetrue
Security:SPEC:2.3-323It MUST be possible for the definition of an HttpAuthenticationMechanism to exist within the application archive. true
falsetechnologyactivetrue
Security:SPEC:2.3-423The 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
falsetechnologyactivetrue
Security:SPEC:2.3-523The container MUST supply a "bridge" ServerAuthModule that integrates HttpAuthenticationMechanism with JASPIC.true
falsetechnologyactivetrue
Security:SPEC:2.3-623The bridge module MUST look up the correct HttpAuthenticationMechanism using CDI, then delegate to the HttpAuthenticationMechanism when the bridge module’s methods are invoked.true
falsetechnologyactivetrue
Security:SPEC:2.3-723Since 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
falsetechnologyactivetrue
Security:SPEC:2.4-124BASIC - 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
falsetechnologyactivetrue
Security:SPEC:2.4-224FORM - 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
falsetechnologyactivetrue
Security:SPEC:2.4-324Custom 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
falsetechnologyactivetrue
Security:SPEC:2.4-424All of these beans MUST have the qualifier @Default and the scope @ApplicationScoped, as defined by the CDI specification.true
falsetechnologyactivetrue
Security:SPEC:2.4-524All of the built-in beans MUST support authentication using IdentityStoretrue
falsetechnologyactivetrue
Security:SPEC:2.4.6-124.6AutoApplySession Annotationtrue
falsetechnologyactivetrue
Security:SPEC:2.5-125This 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
falsetechnologyactivetrue
Security:SPEC:2.5-225Specifically 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
falsetechnologyactivetrue
Security:SPEC:3.1-131 The IdentityStoreHandler interface defines a mechanism for invoking on IdentityStore to validate a user credential. true
falsetechnologyactivetrue
Security:SPEC:3.1-231 An IdentityStoreHandler can also orchestrate an authentication across multiple IdentityStore instances, returning an aggregated result. true
falsetechnologyactivetrue
Security:SPEC:3.1-331 A default IdentityStoreHandler implementation is supplied by the container true
falsetechnologyactivetrue
Security:SPEC:3.1-431 but applications can also supply their own implementation. true
falsetechnologyactivetrue
Security:SPEC:3.2-132An 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() methodtrue
falsetechnologyactivetrue
Security:SPEC:3.2.1-132.1Only the caller principal is required to be present for a successful validation.true
falsetechnologyactivetrue
Security:SPEC:3.2.1-232.1VALID: Validation succeeded and the user is authenticated. The caller principal and groups (if any) are available ONLY with this result status.true
falsetechnologyactivetrue
Security:SPEC:3.2.1-332.1INVALID: Validation failed. The supplied Credential was invalid, or the corresponding user was not found in the user store.true
falsetechnologyactivetrue
Security:SPEC:3.2.1-432.1NOT_VALIDATED: Validation was not attempted, because the IdentityStore does not handle the supplied Credential type.true
falsetechnologyactivetrue
Security:SPEC:3.2.1-532.1for example, validate(Credential) would delegate to the following method of ExampleIdentityStore if passed a UsernamePasswordCredentialtrue
falsetechnologyactivetrue
Security:SPEC:3.2.2-132.2The 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
falsetechnologyactivetrue
Security:SPEC:3.2.2-232.2Note 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
falsetechnologyactivetrue
Security:SPEC:3.2.2-432.2As 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
falsetechnologyactivetrue
Security:SPEC:3.2.3-132.3The 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
falsetechnologyactivetrue
Security:SPEC:3.2.3-232.3The validationTypes() method returns a Set of enum constants of type ValidationType, indicating the purposes for which an IdentityStore should be usedtrue
falsetechnologyactivetrue
Security:SPEC:3.2.4-132.4The purpose of the IdentityStoreHandler is to allow for multiple identity stores to logically act as a single IdentityStore to the HttpAuthenticationMechanism.true
falsetechnologyactivetrue
Security:SPEC:3.2.4-232.4A 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
falsetechnologyactivetrue
Security:SPEC:3.2.4-332.4If a call to validate() returns a result with status INVALID, remember it, in case no IdentityStore returns a VALID result.true
falsetechnologyactivetrue
Security:SPEC:3.2.4-432.4If a call to validate() returns a result with status VALID, remember this result and stop calling validate().true
falsetechnologyactivetrue
Security:SPEC:3.2.4-532.4If a result was previously returned with status INVALID, return that result.true
falsetechnologyactivetrue
Security:SPEC:3.2.4-632.4Otherwise, return a result with status NOT_VALIDATED.true
falsetechnologyactivetrue
Security:SPEC:3.2.4-732.4Add 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
falsetechnologyactivetrue
Security:SPEC:3.2.4-832.4Call 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
falsetechnologyactivetrue
Security:SPEC:3.3-133Installation 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
falsetechnologyactivetrue
Security:SPEC:3.3-233It MUST be possible for the definition of an IdentityStore to exist within the application archive.true
falsetechnologyactivetrue
Security:SPEC:3.4-134LDAP—Supports caller data that is stored in an external LDAP server. This bean is activated and configured via the @LdapIdentityStoreDefinition annotationtrue
falsetechnologyactivetrue
Security:SPEC:3.4-234Database — 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
falsetechnologyactivetrue
Security:SPEC:3.4-334Each of these beans MUST have the qualifier @Default and the scope @ApplicationScoped, as defined by the CDI specification.true
falsetechnologyactivetrue
Security:SPEC:4.2-132The getCallerPrincipal() method retrieves the Principal representing the caller.true
falsetechnologyactivetrue
Security:SPEC:4.2-242The 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
falsetechnologyactivetrue
Security:SPEC:4.3-143The 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
falsetechnologyactivetrue
Security:SPEC:4.4-144The authenticate() method allows an application to signal to the container that it should start the authentication process with the caller. true
falsetechnologyactivetrue