I do not know if anybody else have got this exception but I did and am stuck in such a way that I may have to leave all the benefits of WSE just for the workaround to this problem/exception.
So here is the problem,
I am receiving a SoapMessage which has some custom soap headers and these headers are signed using X509Security token (WSS). SoapInputFilter of WSE is processing these headers and throws exception with message WSE502: Cannot find target element referenced by URI "msgHdr". When I look into the SoapMessage there is a custom header which has an
attribute by the name of "id" with value "msgHdr". [Please note that "id" has a lowercase "i"]
I investigated more and here are my findings.
WSE is looking for elements which contains the attribute by the local name of "Id" and which has the type ID (xml schema datatype) and then comparing the URI of Refererence element of Signature element to the value of this "Id" attribute. If they match WSE is happy and verify the signature.
Seeing this behavior I thought why WSE is looking for "Id" only, I could have a custom header where I define an attribute which has a name "id" or "itsMyId" which has xml schema type ID. Why would WSE only entertain "Id. ?
I started looking at the OASIS WSS profile (oasis-200401-wss-soap-message-security-1.0) and found out section 4 has
something which explains the WSE behavior. Section 4 says that since the SoapClients or intermediaries may not know the xml schema of the elements they are processing for signature verification, it would be good if SoapProcessor presume that the element being referenced by Siganture\Reference has an attribute wsu:Id whose type is ID.
I think this is what WSE follows and hence the response.
But .. there is a big but here. WSS talks about wsu:Id as an optimization and helper and it does not exclude the possibility of having "id" or "itsMyId".
Here the SoapClient needs to tell WSE that this is the schema I am using for the Soap message in response and this is the attribute for a given element that should be used while SecurityInputFilter is processing the signature. How to do that ?..... I could not find any way to specify this.