JAAS не определяет, как должна выглядеть информация аутентификации в SOAP, но WS-Security определяет, какие стандартизированные токены можно использовать во время обмена клиент-сервер (Username +пароль токена / сертификат X.509 / SAML токен / Kerberos токен).
РЕДАКТИРОВАТЬ: Относительно Метро Стек WebService, который вам нужен (шаги взяты из здесь и здесь ):
- Внедрить обработчик, который реализует
javax.xml.ws.handler.soap.SOAPHandler
в обработчик JAX-WSЦепочка либо программно через ((BindingProvider)port).getBinding().setHandlerChain(Collections.singletonList(handler))
, либо декларативно путем добавления аннотации @HandlerChain(file = "handlers.xml")
к интерфейсу конечной точки WS. - Обработчик должен создать экземпляр
XWSSProcessor
, используя XWSSProcessorFactory
, которому передается обработчик обратного вызова, реализующий javax.security.auth.callback.CallbackHandler
. - Например, обработчик обратного вызова определяет валидатор для обратного вызова (зависит от типа обратного вызова).
Это то же самое, что «делать вручную» (так как 1-й шаг - этов любом случае пересекают SOAP-сообщение)ч немного сахара WSS сверху.Но WSIT (и CXF) используют JAAS API и предоставляют стандартные реализации для различных токенов аутентификации.Их включение требует определенных усилий по настройке / кодированию, но выгода заключается в том, что если впоследствии вы решите переключиться с обычного текста на аутентификацию Kerberos, вам не нужно много кодировать.Кроме того, «делать вручную» означает, что вам нужно иметь дело с информацией для аутентификации на уровне XML, и вам нужно реализовать один из стандартов.
Я предлагаю использовать Apache CXF , который базируетсяна WSS4J - реализация WS-Security от Apache.Вы можете легко найти учебники (например, здесь и здесь для имени пользователя + пароль, здесь и здесь для SAML), которые показывают для определения callback / interceptors для проверки информации аутентификации.Преимущество CXF в том, что он имеет хорошую интеграцию с Spring.