Claus Ibsen created CAMEL-23773:
-----------------------------------
Summary: camel-cxf - separate ws-security into its own module to
avoid opensaml/shibboleth dependency
Key: CAMEL-23773
URL: https://issues.apache.org/jira/browse/CAMEL-23773
Project: Camel
Issue Type: Improvement
Components: camel-cxf
Reporter: Claus Ibsen
The camel-cxf-soap module has a compile-scope dependency on cxf-rt-ws-security,
which transitively pulls in the entire org.opensaml stack (13+ JARs). These
artifacts are hosted on build.shibboleth.net, a third-party Maven repository
that has proven unreliable and causes intermittent CI and build failures.
Most Camel CXF users do not need WS-Security / SAML support. The ws-security
usage in camel-cxf-soap is minimal:
- Only DefaultCxfBinding.java uses wss4j (3 imports: WSSecurityEngineResult,
WSHandlerConstants, WSHandlerResult)
- A single private method addInboundX509CertificatesToSubject() extracts X.509
certs from WS-Security results
- The ws-security test suite lives in camel-cxf-spring-soap (test scope)
Proposal:
1. Remove the hard cxf-rt-ws-security compile dependency from camel-cxf-soap
2. Refactor DefaultCxfBinding.addInboundX509CertificatesToSubject() to make
wss4j optional (e.g. classpath detection via reflection) so it gracefully skips
cert extraction when wss4j is absent
3. Create a new camel-cxf-soap-ws-security module that depends on
camel-cxf-soap + cxf-rt-ws-security and provides the WS-Security integration
4. Move ws-security tests from camel-cxf-spring-soap into the new module
This way normal CXF users avoid the opensaml/shibboleth transitive dependency
entirely, and only users who explicitly need WS-Security pull it in.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
