Bugzilla – Bug 2178
Any SOAP headers used for dispatching need to be secured
Last modified: 2005-06-02 14:04:10
You need to
before you can comment on or make changes to this bug.
The current security solution does not secure any of the SOAP headers used for
dispatching to the right service/operation/resource. This opens the way for a
third party intercepting the message and maliciously redirecting it to a
Code to sign headers used for dispatch has been committed to trunk.
The addressing specification defines which headers should be signed. And also
the signing of headers needs to happen on both sides and replies can be
redirected to another place.
All headers specified in "secureHeaders" message property are signed now in the
case of both request and response. The feature has been added only for secure
message authentication. Once rework of secure conversation is completed,
signing of headers needs to added for this mechanism
Dispatch headers are now secured in the case of secure conversation also.
Moreover, framework to enforce that headers used in dispatch are secured has
been added. A message context property with list of headers used in dispatch
needs to be populated - Jarek is working on that.
I updated the AddressingHandler to pass the list of headers to be verified if
specified. That includes the To, ReplyTo, and FaultTo headers. It does not
however include the header that contains the key since this handler doesn't
know which header it is.
I guess we still need a way of passing the key header to that list of headers
to be verified.
This also needs to be done on the C side, so please reassign to me before
Added resource key header to the list of headers that need to be secured.
*** Bug 2408 has been marked as a duplicate of this bug. ***
The C WS-Secure Message handler has been committed to the gt 4.0 trunk. This
handler adds the appropriate security attributes and headers to secure the