[SWS-884] Wss4jSecurityInterceptor, don't remove Security Header. Created: 11/Dec/14  Updated: 18/Feb/15  Resolved: 18/Feb/15

Status: Closed
Project: Spring Web Services
Component/s: Security
Affects Version/s: 2.2.0.RELEASE
Fix Version/s: 2.2.1

Type: Improvement Priority: Minor
Reporter: Jimmy Selgen Nielsen Assignee: Greg Turnquist
Resolution: Complete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When Wss4jSecurityInterceptor.validateMessage successfully validates an incoming message, it automatically removes the Security element from the SOAP header.

It would be nice to have an option to disable this functionality, so that the Security Element is left intact, so that the elements contained within (mainly X.509 certificates) can be accessed later on.

There's one line of code to "change" - Wss4jSecurityInterceptor.java:634:
soapMessage.getEnvelope().getHeader().removeHeaderElement(WS_SECURITY_NAME);



 Comments   
Comment by jaminh [ 17/Dec/14 ]

You should be able to access that from the MessageContext like so, messageContext.getProperty(WSHandlerConstants.RECV_RESULTS);

That will return a List<WSHandlerResult>. Each WSHandlerResult contains a List<WSSecurityEngineResult>. You will need to go through each WSSecurityEngineResult and find one that contains a key of WSSecurityEngineResult.TAG_BINARY_SECURITY_TOKEN. The value associated with that key should get you the X509 certificate you are looking for. It is kind of a convoluted way of getting it but that should work for you.

Comment by Jimmy Selgen Nielsen [ 18/Dec/14 ]

I guess my real problem is, that when I try to fetch the WS-Security header, Apache Camel has taken over, and the messageContext is nowhere to be found. It has been replaced by an Exchange object, which is created from the messageContext.
I guess I should raise the issue with Apache Camel instead.

Thanks.

Comment by Greg Turnquist [ 12/Jan/15 ]

@Jimmy I can put in a flag that lets you disable this default behavior and leave the security header intact. Would that help, or is Apache Camel still an issue?

Comment by Jimmy Selgen Nielsen [ 12/Jan/15 ]

@Greg I'm currently getting around this issue by using my own Wss4JSecurityInterceptor, where I've commented out that line, The only thing I need from the header is access to the embedded X.509v3 certificate, so that I can pass it along with the message, so yes, it would solve it for me, but I'm not in a position to say if its the right way of doing it.

Camel removes the WSHandlerResult list when it creates its CamelContext from the MassageContext, and ive raised an issue with Camel on this.

Comment by Greg Turnquist [ 12/Jan/15 ]

I've coded a patch to hold onto the security header, and asked Arjen to review my edits when possible.

Comment by Greg Turnquist [ 18/Feb/15 ]

Added option to configure Wss4jSecurityInterceptor to hold onto security headers.

Generated at Thu Dec 14 15:00:29 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.