Affects Version/s: 2.4.0
Fix Version/s: None
We're using a WSS4JSecurityInterceptor to validate incoming messages and sign outgoing messages:
When using the interceptor this way, a lot of EHCache threads named "wss4j%002etimestamp%002ecache-e%0058ga%0058l%0058%004b%0057g%004ah%0050w==.data" (and similar) start to appear, one for each request that has been made.
I believe this happens because of the way the Wss4jSecurityInterceptor initializes the WSS4J RequestData structure in initializeRequestData and initializeValidationRequestData. By default the RequestData class has caching enabled for detecting various replay attacks. However the default implementation is to just create one cache per RequestData structure using the ReplayCacheFactory.newInstance() method.
Now when you send a request and this is validated, this at some point calls WSS4J's SignatureProcessor class, which in turn calls RequestData.getTimestampReplayCache() which by default creates a new EHCache instance (if EHCache happens to be on the classpath which it is for our project).
I found out about this issue reading through http://apache-xml-project.6118.n7.nabble.com/nonce-cache-thread-proliferation-td42797.html for a similar problem. The recommended solution is to either disable replay caches or to properly initialize them by calling the setXXXReplayCache methods when creating the RequestData structure.
So since the current implementation wouldn't detect replay attacks either (because having one cache per request basically disables replay attack checks, albeit in a very expensive manner), i would suggest changing the implementation of the Wss4jSecurityInterceptor initializeRequestData and initializeValidationRequestData methods and to append these lines before returning the RequestData structure: