JSR 196 определяет модель безопасности сообщений, отправляемых между клиентом и сервером, в которой отправитель сообщения «защищает» его, а получатель его «проверяет». Детали того, как сообщения защищаются и проверяются, не определены моделью. Поддержка защиты и проверки определённых типов сообщений обеспечивается «модулями аутентификации» — реализациями интерфейсов JASPIC ClientAuthModule и ServerAuthModule, которые поддерживают конкретные протоколы или типы сообщений и которые подключены к платформе JASPIC. (Обратите внимание, что клиенту и серверу не обязательно использовать JASPIC, если обе стороны корректно обрабатывают сообщения для данного протокола.)

JASPIC определяет два «профиля» для интеграции модулей аутентификации JASPIC в контейнеры Java EE: профиль контейнера сервлета и профиль SOAP. Каждый из них определяет, как обработка сообщений JASPIC должна быть интегрирована в поток обработки запросов соответствующего контейнера для проверки входящих запросов и защиты исходящих ответов.

В случае профиля контейнера сервлета, если ServerAuthModule настроен/доступен для данного контекста приложения, то метод validateRequest() модулей должен быть вызван (и успешно выполнен) перед авторизацией доступа и вызовом целевого сервлета, перед вызовом необходимо вызвать метод secureResponse() модуля. Как правило, ServerAuthModule, записанный для профиля контейнера сервлета, ищет учётные данные пользователя или токены во входящем запросе, а затем использует их для аутентификации вызывающего субъекта и установления его личности. ServerAuthModule может также участвовать в протоколе вызова/ответа с клиентом или взаимодействовать с третьей стороной для установления/проверки личности клиента.

Как и в случае с профилем контейнера сервлета, профиль SOAP требует, чтобы validateRequest() был вызван и успешно завершён, прежде чем продолжить авторизацию доступа и любую дальнейшую обработку входящего сообщения, и что secureResponse() вызывается для ответа перед его отправкой. В отличие от профиля контейнера сервлета, обработка validateRequest() для сообщений SOAP обычно включает проверку подписей на подписанных элементах, дешифрование зашифрованных элементов и/или установление личности субъекта SOAP на основе токена, включённого в сообщение, в то время как secureResponse() обычно включает в себя подписывание и/или шифрование элементов исходящего сообщения.

JASPIC не определяет никаких стандартных или встроенных модулей ServerAuthModules. Они должны предоставляться либо приложением, использующим модуль, либо как нестандартное расширение продукта Java EE разработчиком. Иногда ServerAuthModules могут быть напрямую сконфигурированы для приложения в зависимости от поставщика, но стандартный механизм обеспечения доступности ServerAuthModule для приложения заключается в регистрации соответствующего AuthConfigProvider в глобальный AuthConfigFactory. AuthConfigProvider делает ServerAuthModule доступным для контейнера через серию промежуточных объектов для обработки сообщений во время выполнения.

JSR 375 определяет следующие связанные с аутентификацией SPI плагина:

Реализации этих интерфейсов SPI являются компонентами CDI, и, как таковые, приложения могут предоставлять реализации, которые поддерживают механизмы аутентификации конкретного приложения, или проверять учётные данные пользователя по хранилищам идентификаторов конкретного приложения, просто включив их в архив компонентов, который является частью развёрнутого приложения. Существует также несколько стандартных встроенных реализаций HttpAuthenticationMechanism и IdentityStore, которые обеспечивают настраиваемую поддержку общих случаев использования аутентификации и проверки учётных данных без необходимости написания пользовательских реализаций.

Поскольку эти SPI, связанные аннотации и механизм развёртывания CDI являются частью стандартного Java EE, реализации являются полностью переносимыми (в той степени, в которой они не зависят внутренне от API или библиотек, специфичных для платформы) и могут быть развёрнуты путём переноса на любой сервер Java EE.