У меня проблема с cxf, который не генерирует правильный блок Soap Security для аутентификации с использованием SAML 1.1. Я работал над этим несколько дней, и я новичок в этой технологии. Буду признателен за любую помощь:
Я подключаюсь к службе, использующей токены SAML 1.1, и могу успешно подключиться и получить токен saml из службы аутентификации. Но при следующем вызове службы я получаю от сервера ошибки аутентификации. Я получил пример запроса мыла от хоста (который, похоже, использует weblogic) для сравнения с моим выводом cxf, и обнаружил разницу:
В рабочем примере элемент wsse:SecurityTokenReference является прямым потомком элемента wsse:Security. Другими словами, путь в конверте: /env:Header/wsse:Security/wsse:SecurityTokenReference.
Этот SecurityTokenReference содержит элемент KeyIdentifier, который указывает на SAMLAssertionID saml. Позже, в блоке dsig:Signature, есть dsig:Reference URI, указывающий на SecurityTokenReference.
Я предположительно использую тот же документ политики, что и поставщик услуг, но cxf не создает этот дочерний элемент. Из унаследованного кода других организаций я обнаружил, что они сами написали весь заголовок безопасности, и, пройдя PolicyBasedWSS4JOutInterceptor, я думаю, что мог бы использовать Аспект для записи элемента STR непосредственно в вызове AssymetricBindingHandler.handleBinding(). Но это кажется бессмысленным, потому что элемент является частью спецификации WS-Security 1.0 и xsd, поэтому, по-видимому, wss4j и cxf должны иметь возможность его сгенерировать.
Я подумал, что, возможно, этот вывод будет вызван чем-то в политике, и после просмотра нескольких документов спецификации WS- * я наткнулся на тег sp:RequireKeyIdentifierReference, но поместил его в свою тестовую версию политики после того, как элементы sp:WssSAMLV11Token10 не возымели эффекта.
Я упускаю что-то очевидное?
Заранее спасибо!
