SoftwareMaker (William T) has a long entry on multiple security headers. Here's how we thought about the problem for WSE2:
In general, you cannot have 2 security headers that target the same node, even if they have different s:Actor values; i.e., one has s:Actor missing and one has s:Actor of next. This is because headers can be re-ordered in messages leading to problems verifying signatures or decrypting elements. This is a simple extension of the highlighted text that is quoted from the WS-Security specification:
"Message security information targeted for different recipients MUST appear in different header blocks. This is due to potential processing order issues (e.g. due to possible header re-ordering)."
The extension being that security information targeted for the same recipient MUST appear in the same header block: the re-ordering problem also applies when any 2 security headers target the same node. This is the reason, IMHO, that intermediaries should be allowed to add new elements to an existing wsse:Security header, provided that they do it correctly. I therefore believe that the text in the OASIS specification is incorrect and that the text from the original specification is more likely correct: it makes little sense for an intermediary to be able to add security information to a header that is targeted at that intermediary.
I also don't agree with this:
"John is definitely right in saying that I shouldnt be touching the security Headers meant for any other actor. It could be signed anyways."
Signatures go inside wsse:Security headers, not outside them. To sign the wsse:Security header and place the resulting signature in that same header is an operation that creates a cyclic dependency: you cannot sign the header until the signature is in it, but you can't generate the signature until you have the complete header. The rules regarding removal of processed soap headers don't apply to the contents of an individual header like wsse:Security.
Note that encrypting complete headers as SoftwareMaker appears to have done:
"The CanProcessHeader method will definitely fail as it cannot find the actorless security header referenced security token without decrypting it"
is also not a good thing to do. It is potentially confusing to soap processors to have operations associated with one header uncover new headers that need to be processed at the same node. #Content encryption may also cause schema validation problems by changing the inner content of a header. Indeed, OASIS WS-Security is expected to add a new construct in the near future to allow for this case: EncryptedHeader.
Posted by herveyw at November 27, 2004 10:05 AMThanks for your thoughts. Gotta further evaluate and digest these thoughts before commenting.
Another point for correction, what John actually meant was that [In most cases, the security element(s) targeted for the final destination will be signed. Therefore, providing access via the object model doesn't make sense because manipulating these headers would invalidate the digital signature.]
Posted by: Softwaremaker at November 27, 2004 03:58 PMThe only way to sign the Security header itself and not create a cyclic dependency is to use an enveloped signature. This would sign the contents of the header minus the signature and prevent intermediaries from modifying the header. This may be possible with WSE2 (I haven't tried it), but it's not one of the default options. If an enveloped signature isn't used; i.e. a normal signature is used, then an intermediary can safely add more tokens and more signatures to a Security header targeted at another node on the message path.
Signatures are not as fragile as people think: the canonicalization process alleviates a number of the problems that can occur if an intermediary deserializes and re-serializes a signature - indeed, the WSE2 intermediary does do this by loading the message into a DOM and then saving it back out when the message is forwarded.
Posted by: Hervey at November 27, 2004 06:25 PMI believe there is some sort of misunderstanding.
1) [The CanProcessHeader method will definitely fail as it cannot find the actorless security header referenced security token without decrypting (it)]
The (it) I am referring to is the messsage. I believe processing the actorless sec header first (it appears first in the message) will fail as the message is processed last by the intermediary. In this case, the latest security header should be processed first (actor next).
Of course, I was assuming that the endpoint can process multiple security headers (which you are saying it should not)
Posted by: Softwaremaker at November 27, 2004 06:59 PMCorrect, but only if WSE allowed more than one wsse:Security header at any node and there were strict rules regarding the processing order of SOAP headers (i.e. rules similar to the processing order of entries inside the wsse:Security header).
Posted by: Hervey at November 28, 2004 01:50 AM