JSR-196 defines a model for securing messages sent between a client and server in which the sender of a message "secures" it, and the receiver "validates" it. The details of how messages are secured and validated are undefined by the model; support for securing and validating particular types of messages is provided by "auth modules" — implementations of the JASPIC ClientAuthModule and ServerAuthModule interfaces — that support particular protocols or message types, and that plug in to the JASPIC framework. (Note that it is not necessary for a client and server to both use JASPIC, as long as both sides process messages correctly for a given protocol.)

JASPIC defines two "profiles" for integrating JASPIC auth modules into Java EE containers: the Servlet Container Profile, and the SOAP Profile. Each specifies how JASPIC message processing must be integrated into the request processing flow of the container in question to validate incoming requests and secure outgoing responses.

In the case of the Servlet Container Profile, if a ServerAuthModule is configured/available for a given application context, then the modules’s validateRequest() method must be invoked (and succeed) before authorizing access and calling the target servlet, and the module’s secureResponse() method must be called before returning a response. Typically, a ServerAuthModule written for the Servlet Container Profile looks for user credentials or tokens in an incoming request, and then uses them to authenticate the caller and establish the caller’s identity. A ServerAuthModule may also engage in a challenge/response protocol with the client, or negotiate with a third party to establish/verify the client’s identity.

As with the Servlet Container Profile, the SOAP Profile requires that validateRequest() be called and succeed before proceeding to authorize access and perform any further processing of an incoming message, and that secureResponse() is called for the response before it is sent. In contrast to the Servlet Container Profile, validateRequest() processing for SOAP messages typically involves verifying signatures on signed elements, decrypting encrypted elements, and/or establishing the identity of a SOAP actor based on a token included in the message, while secureResponse() typically involves signing and/or encrypting elements of the outbound message.

JASPIC does not define any standard or built-in ServerAuthModules; they must be provided either by the application using the module, or as a non-standard extension of a particular vendor’s Java EE product. ServerAuthModules can sometimes be directly configured for an application in a vendor-specific way, but the standard mechanism for making a ServerAuthModule available to an application is to register a corresponding AuthConfigProvider with the global AuthConfigFactory. An AuthConfigProvider makes a ServerAuthModule available to the container, via a series of intermediary objects, for runtime message processing.

JSR-375 defines the following authentication-related plugin SPIs:

Implementations of these SPI interfaces are CDI beans, and, as such, applications can provide implementations that support application-specific authentication mechanisms, or validate user credentials against application-specific identity stores, simply by including them in a bean archive that is part of the deployed application. There are also several standard, built-in implementations of HttpAuthenticationMechanism and IdentityStore that provide configurable support for common authentication and credential validation use cases, without the need to write custom implementations.

Because these SPIs, related annotations, and the CDI deployment mechanism are all part of standard Java EE, implementations are completely portable (to the extent they do not rely internally on platform-specific APIs or libraries) and can be portably deployed to any Java EE server.