Consider upgrading to WSS4J 3.0.0.
jezovuk opened this issue · 13 comments
As far as I can tell, WSS4J version currently required by spring-ws is 2.4.1. According to WSS4J web site and release notes, 3.0.0 is the first "Jakartified" version.
See actual commit implementing the change in WSS4J for additional details. In light of #1213 and general push away from javax and towards jakarta API-s, upgrade seems like a reasonable thing to do (if I'm not missing something, which I might be, since I'm not a heavy spring-ws user).
Hi @gregturn, afaik spring-boot 3.2 release is scheduled for this autumn - imo this issue alone would justify a 4.1.0 release. I would really like to see spring-boot 3.2 dependency management picking this up.
For starters, I have tested Spring WS against WSS4j 3.0.0, and it seems to work with no changes. As for creating another Spring WS release version, I'm not yet convinced we need that. A single 3rd party dependency's major feature upgrade isn't quite enough for that.
And to clarify, Spring Boot 3.2 is currently based on Spring WS 4.0.x.
If we include testing against "wss4j-next" in our CI solution, then that may offer enough confidence for you to simply exclude Wss4j from your own build and supplant it with 3.0.0 instead.
Hi @gregturn. I'm not sure I understand your position completely.
Are you suggesting that spring-ws will continue using WSS4J 2.4.x for foreseeable future (instead of switching to 3.x) or merely that there will be no dedicated spring-ws release just for the sake of WSS4J upgrade?
If everything works ok with WSS4J 3.x (as your testing results indicate), why not switch to that version as required dependency (whenever it fits the spring-ws release schedule, not necessarily in a dedicated spring-ws release)?
IIUC, WSS4J 3.x uses jakarta namespaces, so it would be in line with #1213 to (eventually) switch to that version.
Spring WS has yet to see a reason to launch 4.1.x line at this point in time. We don't have any sweeping changes at this point to make.
If Wss4j 2.4 is using pre-Jakarta EE 9 stuff, we haven' heard (yet) of that. I don't know if that either means its mostly used internally, or if people using Spring WS with Wss4j haven't made the jump. But either way, it passes our testing.
To maintain binary compatibility, we typically don't make a switch to a new major version (2.4 -> 3.0) without a minor version change in Spring WS (4.0 -> 4.1). Part of the reason for coming out with Spring WS 4.0 was to bump other libraries that were vital to pick up Jakarta EE 9.
This would be the first time I've heard of Wss4j having issues with Jakarta EE 9. Perhaps our testing doesn't expose it? If you were to procure a test scenario that exposed such a situation where Spring WS 4.0 combined with Wss4j 3.0 caused a Jakarta EE 9 issue, that would give us grounds to solve such a problem.
But as things currently stand, it looks like simply upgrading a project to use Wss4j 3.0 won't run into any issues with Spring WS 4.0.
I should have explained in more depth why I think spring-ws should pick up wss4j 3.0.0, even at the cost of a new minor release.
The main reason I still think this would justify a new minor release line of spring-ws (4.1.x) is to complete the JakartaEE migration. Ideally, wss4j 3.0.0 would have have been part of spring-ws 4.0.x, probably it was a near miss. Now that it is available upgrade spring-ws and take advantage of the upcoming spring-boot minor release in order to pick it up. Many projects have yet to migrate to spring-boot 3 / JakartaEE9+. Possible future issues like #1360 could be avoided in the first place.
Another reason is plain dependency management. Wss4j 2.4.1 has transitive dependencies which have serious security issues (BouncyCastle, for example). In the meantime, wss4j 2.4.2 and 3.0.2 have been released. It would be great value for spring-ws users to get regular dependency updates by simply using a current spring-boot parent or spring-boot-dependencies bom.
@gregturn Thanks for the answer.
I mostly agree with what @cachescrubber wrote. I do not have an explicit problem using spring-ws 4.0.x with wss4j 2.4.1, but judging from wss4j jakarta upgrade changes it seems quite possible that there some problematic use cases might exist.
@cachescrubber I have discussed this issue with the Spring Boot team. Since there is no autoconfiguration nor version management that involves Wss4j, they are open to the possibility of an upgrade to a major version of Wss4j in a service release of Spring WS.
I think the criteria under which to make such a move in Spring WS would require exposing that Wss4j 2.4 does NOT work properly with Jakarta EE 8 but DOES work with Jakarta EE 9. Right now, it may be that we don't see this due to all method signatures and return types are not based upon Jakarta EE, but instead on interfaces that are still present in the JDK (e.g. javax.security and javax.xml.namespace), hence we can't see the issue.
Spring WS Security has lots of test cases concerning Wss4j. If you were to help us write a test case that exposed this Jakarta EE 9 lack of support, it would help us very much work toward making this transition.
Hi @gregturn thanks for coming back to this.
I actually have no spring-ws-security use case which breaks because of not having Jakarta EE 9+ version of wss4j. (We are using securement and validation-actions=Signature).
My main concern are transitive dependencies introduced by Wss4j 2.4.x that are incompatible with spring-boot >= 3.0.0.
#1360 for example - and I just spotted another possible issue. wss4j has a dependency to ehcache 3.10.8 which should be declared using the jakarta qualifier.
[INFO] | | \- org.ehcache:ehcache:jar:3.10.8:runtime
[INFO] | | \- javax.cache:cache-api:jar:1.1.1:runtime
Using 3.0.1 this would be (note the classifier)
[INFO] | \- org.ehcache:ehcache:jar:jakarta:3.10.8:runtime
[INFO] | \- javax.cache:cache-api:jar:1.1.1:runtime
An upgrade to wss4j 3.0.x. would eliminate all those potential issues.
I personally would use the possibility of the upcoming spring-boot minor release to get 4.1 out - so nobody could be surprised by the major update of wss4j. Doing so in a service release would be fine for me (in this special case) but I cannot really produce a test case to ensure this works for everyone.
At the minimum, could you upgrade to wss4j 2.4.3? 2.4.1 brings in org.bouncycastle:bcprov-jdk15on with at least 5 vulnerabilities. 2.4.3 already uses the newer org.bouncycastle:bcprov-jdk18on
I recently received a security alert for a vulnerability on bcprov-jdk15on: CVE-2024-29857. bcprov-jdk15on does not seem to be maintain anymore, so inn the end, I simply upgraded WSS4J to 3.0.3 and that got rid of the alert; the process in itself was quite smooth at runtime, but I had to fight a little bit with transitive dependencies. The chain is
org.bouncycastle:bcprov-jdk18on:1.72 -> 1.78
\--- org.opensaml:opensaml-security-api:4.3.0
+--- org.opensaml:opensaml-saml-impl:4.3.0
| +--- org.apache.wss4j:wss4j-ws-security-common:3.0.3
| | \--- org.apache.wss4j:wss4j-ws-security-dom:3.0.3
| | \--- org.springframework.ws:spring-ws-security:4.0.10
The problem is that opensaml-saml-impl is not published on maven central but on shibboleth (easy fix, just adding one more repo): https://mvnrepository.com/artifact/org.opensaml/opensaml-saml-impl/4.3.0
Probably not much you can really do from a SpringWS perspective, but something to be concerned about should you decide to upgrade (which I would still be inclined to "ask" for, moving away from bcprov-jdk15on still seems to be a pretty good idea)
Hi @corneil - could you please have a look into this issue? I boils down to a decision whether to
- continue to ignore wss4j > 3.x (4.x is already on it's way AFAIK)
- upgrade to wss4j 3.x - within the current 4.0.x line (which might be feasible, see #1358 (comment))
- upgrade to wss4j 3.x - with a new minor release of spring-ws to honor semantic versioning rules.
Most attention to this subject seems to be security related, as there are quite some CVEs related to wss4j, xmlsec or their transitive dependencies (opensaml, bouncy castle, etc). All mentioned project are actively maintained and It would be very valuable for spring-ws-security users to upgrade these dependencies on a regular schedule.
FWIMC. I think currently the most effective way for an application using spring-ws-security to use up to date, consistent and secure wss4j dependencies, would be to add a maven dependencyManagement section (omitted here) for the following libraries and versions:
<properties>
<wss4j.version>3.0.3</wss4j.version>
<xmlsec.version>3.0.4</xmlsec.version>
<guava.version>32.1.2-jre</guava.version>
<bouncycastle.version>1.78.1</bouncycastle.version>
</properties>
This would ensure
- current version of wss4j
- current version of xmlsec
- no dependency convergence issues
- no transitive vulnerabilities
Spring Ws Security could use the same, but unfortunately there is no central dependency management for alle those web service security related dependencies. Current situation is that most ws-security related dependencies are unmanaged, so applications depending on spring-ws-security have to declare them by them self. For the framework, this leads to the large number of excluded transitive dependencies (dependency hell), especially in the spring-ws-security pom. Ideally, spring-ws could provide these dependency management by a new module, spring-ws-security-dependencies which could then be shared between the framework and applications.
As said by @cachescrubber you need to include the following dependencies to mitigate any CVEs:
implementation("org.apache.wss4j:wss4j-ws-security-dom:3.0.3")
implementation("org.bouncycastle:bcprov-jdk18on:1.78.1")
implementation("org.bouncycastle:bcpkix-jdk18on:1.78.1")
implementation("com.google.guava:guava:33.3.0-jre")
There is no need to overwrite xmlsec. It already comes in 3.0.4 (check dependency tree)
If you get any dependencies which can't be resolved you need to add the shibboleth repository to your repository list:
repositories {
mavenCentral()
maven("https://build.shibboleth.net/maven/releases")
}