Navigation

Search

Categories

On this page

WSE502 : Cannot find the target element
Writing a generic SoapClient using WSE

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Sign In
Pick a theme:

 Tuesday, March 15, 2005
Tuesday, March 15, 2005 9:49:38 AM (Central Standard Time, UTC-06:00) ( )
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.
 Thursday, March 10, 2005
Thursday, March 10, 2005 5:39:50 PM (Central Standard Time, UTC-06:00) ( )
A typical SoapClient class looks like this:
 
public class MyClient : SoapClient{
   public MyClient(EndpointReference ref) : base(ref) { }
 
    public SoapEnvelope MyMethod(SoapEnvelope envelope){
        return base.SendRequestResponse("MyServerMethod",envelope);
    }
}
 
The problem of this approach is that it gives you a flexibility of specifying endpointreference but not the SoapAction. Your client could have been talking to many web services and I felt it would have been good to have one client, so I wrote ....
 
public class MyGenericClient : SoapClient{
    private string soapAction;
    public MyClient(string soapAction,EndpointReference ref) : base(ref) {
      this. soapAction = soapAction;
    }
 
    public SoapEnvelope InvokeService(SoapEnvelope envelope){
        return base.SendRequestResponse( soapAction,envelope);
    }
}
 
Pretty easy huh......what I figured out looking into WSE was that if you specify SoapMethod attribute then the value of attribute is considered to be a SoapAction and if you do not then WSE takes the first parameter of SendRequestResponse and put that as the SoapAction.