Re: The message must contain a wsa:To header

How can I check that the WSE is running? My code is using the WSE2 assembly
and is successfully calling my service? I did install WSE3 first, then later
down the road had to install WSE 2 SP3...so both are running but that should
not be a problem. I also made sure that all my WSE2 code is running under
framework 1.1 in IIS.

Puzzled.

"Pablo Cibraro" wrote:

mmm, that is strange. If a trace file is not being generated, perhaps WSE is
not running at all.
No, WSDL does not say anything about the WS-* stack, that's why the
WS-Policy spec was designed. However, only WCF implements that spec for the
moment.

Regards,
Pablo Cibraro.

"Chris Fink" <ChrisFink@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6A45BFC1-8903-4929-B480-F333E4C45F95@xxxxxxxxxxxxxxxx
My client app is not generating a trace file. In fact, I have been able
to
create a service and a test client that consumes this service using WSE2
SP3
and client side certs and it works fine, but still no trace file in either
app. The web.config looks fine to me, and permission wise their should be
no
problem. The event log is also empty. So I need to divert and fix that
problem before I can see if the header is missing in the trace....

... <microsoft.web.services2>
<security>
<x509 storeLocation="CurrentUser" allowTestRoot="true" />
</security>
<diagnostics>
<trace enabled="true" input="InputTrace.webinfo"
output="OutputTrace.webinfo" />
<policyTrace enabled="true" input="ReceivePolicy.webinfo"
output="SendPolicy.webinfo" />
</diagnostics>
<policy>
<cache name="policyCache.config" />
</policy>
</microsoft.web.services2>
</configuration>

I would assume that my problem with the missing wsa header is that the
client is not setup the same way as the service (response/response
signing/encryption). I'll need to talk to the customer to understand what
options I should select while going through the WSE 2 wizard.

Off topic, but shouldn't all this information be part of the web service
contract (WSDL)? Be nice if I could just read my customer's WSDL to get
all
this information.


"Pablo Cibraro" wrote:

Hi Chris,

Did you check if the wsa:To header is being sent to the server ? (Using
the
trace file).
Maybe, the client is not applying the WSE policy at all because of an
difference in the mapping.

Regards,
Pablo Cibraro
http://weblogs.asp.net/cibrax
[MVP - Connected Systems Developer]

"Chris Fink" <ChrisFink@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3D0B2021-2FFB-4D24-B567-930580AC74C3@xxxxxxxxxxxxxxxx
I am using WSE 2 SP3 and receiving the following error from my client
calling
a secure service using client certificates. When I setup the policy, I
required signing and encryption for the request and response.

System.Web.Services.Protocols.SoapException: Server was unable to
process
request. ---> The message must contain a wsa:To header.
at
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage
message, WebResponse response, Stream responseStream, Boolean
asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodName, Object[] parameters)
at ApplicationMessagingWS.Dispatch(String messageType, String
correlationId, String messageBody, String userName, String
applicationName,
String instance, String postBackUrl)
at DellWSE2SP3.ConsumeDellMSS.Dispatch(String messageType, String
correlationId, String messageBody, String userName, String
applicationName,
String instance, String postBackUrl)

This is the policy file
<?xml version="1.0" encoding="utf-8"?>
<policyDocument
xmlns="http://schemas.microsoft.com/wse/2003/06/Policy";>
<mappings xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy";>
<!--The following policy describes the policy requirements for the
service: http://xxxx/mss/webservices/ApplicationMessagingWS.asmx .-->
<endpoint
uri="http://xxxx/mss/webservices/ApplicationMessagingWS.asmx";>
<defaultOperation>
<request policy="#Sign-X.509-Encrypt-X.509" />
<response policy="#Sign-X.509-Encrypt-X.509-1" />
<fault policy="" />
</defaultOperation>
</endpoint>
</mappings>
<policies
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy";
xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext";
xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy";
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing";>
<wsp:Policy wsu:Id="Sign-X.509-Encrypt-X.509">
<!--MessagePredicate is used to require headers. This assertion
should
be used along with the Integrity assertion when the presence of the
signed
element is required. NOTE: this assertion does not do anything for
enforcement (send-side) policy.-->
<wsp:MessagePredicate wsp:Usage="wsp:Required"
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()
wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID)
wse:Timestamp()</wsp:MessagePredicate>
<!--The Integrity assertion is used to ensure that the message is
signed with X.509. Many Web services will also use the token for
authorization, such as by using the <wse:Role> claim or specific X.509
claims.-->
<wssp:Integrity wsp:Usage="wsp:Required">
<wssp:TokenInfo>
<!--The SecurityToken element within the TokenInfo element
describes which token type must be used for Signing.-->
<wssp:SecurityToken>

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>
<wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>
<wssp:Claims>
<!--By specifying the SubjectName claim, the policy system
can
look for a certificate with this subject name in the certificate store
indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the
correct
values for this field.-->
<wssp:SubjectName MatchType="wssp:Exact">CN=
HBTClient</wssp:SubjectName>
<wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">u1lEv47jqXyrb0gujx/GRPFUrjw=</wssp:X509Extension>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:TokenInfo>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()
wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From)
wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo)
wsp:Header(wsa:ReplyTo)
wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
</wssp:Integrity>
<!--The Confidentiality assertion is used to ensure that the SOAP
Body
is encrypted.-->
<wssp:Confidentiality wsp:Usage="wsp:Required">
<wssp:KeyInfo>
<!--The SecurityToken element within the KeyInfo element
describes
which token type must be used for Encryption.-->
<wssp:SecurityToken>

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>
<wssp:TokenIssuer>O= Inc., CN= Inc. Enterprise Utility
CA1</wssp:TokenIssuer>
<wssp:Claims>
<!--By specifying the SubjectName claim, the policy system
can
look for a certificate with this subject name in the certificate store
indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the
correct
values for this field.-->
<wssp:SubjectName MatchType="wssp:Exact">C=US, S=TX,
L=Austin,
O= Inc., OU=Information Technology, CN=MSS Spore, E=webfarm@
.com</wssp:SubjectName>
<wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">rrRD87efOO5bpHFLxT+psuYqMKM=</wssp:X509Extension>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:KeyInfo>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()</wssp:MessageParts>
</wssp:Confidentiality>
</wsp:Policy>
<wsp:Policy wsu:Id="Sign-X.509-Encrypt-X.509-1">
<!--MessagePredicate is used to require headers. This assertion
should
be used along with the Integrity assertion when the presence of the
signed
element is required. NOTE: this assertion does not do anything for
enforcement (send-side) policy.-->
<wsp:MessagePredicate wsp:Usage="wsp:Required"
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()
wsp:Header(wsa:To) wsp:Header(wsa:Action) wsp:Header(wsa:MessageID)
wse:Timestamp()</wsp:MessagePredicate>
<!--The Integrity assertion is used to ensure that the message is
signed with X.509. Many Web services will also use the token for
authorization, such as by using the <wse:Role> claim or specific X.509
claims.-->
<wssp:Integrity wsp:Usage="wsp:Required">
<wssp:TokenInfo>
<!--The SecurityToken element within the TokenInfo element
describes which token type must be used for Signing.-->
<wssp:SecurityToken>

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>
<wssp:TokenIssuer>O= Inc., CN= Inc. Enterprise Utility
CA1</wssp:TokenIssuer>
<wssp:Claims>
<!--By specifying the SubjectName claim, the policy system
can
look for a certificate with this subject name in the certificate store
indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the
correct
values for this field.-->
<wssp:SubjectName MatchType="wssp:Exact">C=US, S=TX,
L=Austin,
O= Inc., OU=Information Technology, CN=MSS Spore, E=webfarm@
.com</wssp:SubjectName>
<wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">rrRD87efOO5bpHFLxT+psuYqMKM=</wssp:X509Extension>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:TokenInfo>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()
wsp:Header(wsa:Action) wsp:Header(wsa:FaultTo) wsp:Header(wsa:From)
wsp:Header(wsa:MessageID) wsp:Header(wsa:RelatesTo)
wsp:Header(wsa:ReplyTo)
wsp:Header(wsa:To) wse:Timestamp()</wssp:MessageParts>
</wssp:Integrity>
<!--The Confidentiality assertion is used to ensure that the SOAP
Body
is encrypted.-->
<wssp:Confidentiality wsp:Usage="wsp:Required">
<wssp:KeyInfo>
<!--The SecurityToken element within the KeyInfo element
describes
which token type must be used for Encryption.-->
<wssp:SecurityToken>

<wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>
<wssp:TokenIssuer>CN=Root Agency</wssp:TokenIssuer>
<wssp:Claims>
<!--By specifying the SubjectName claim, the policy system
can
look for a certificate with this subject name in the certificate store
indicated in the application's configuration, such as LocalMachine or
CurrentUser. The WSE X.509 Certificate Tool is useful for finding the
correct
values for this field.-->
<wssp:SubjectName MatchType="wssp:Exact">CN=
HBTClient</wssp:SubjectName>
<wssp:X509Extension OID="2.5.29.14"
MatchType="wssp:Exact">u1lEv47jqXyrb0gujx/GRPFUrjw=</wssp:X509Extension>
</wssp:Claims>
</wssp:SecurityToken>
</wssp:KeyInfo>
<wssp:MessageParts
Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part";>wsp:Body()</wssp:MessageParts>
</wssp:Confidentiality>
</wsp:Policy>
</policies>
</policyDocument>

and the web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="microsoft.web.services2"
type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration,
Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</configSections>
<system.web>
<!-- DYNAMIC DEBUG COMPILATION
Set compilation debug="true" to enable ASPX debugging.
Otherwise,
setting this value to
false will improve runtime performance of this application.
Set compilation debug="true" to insert debugging symbols (.pdb
information)
into the compiled page. Because this creates a larger file
that
executes
more slowly, you should set this value to true only when
debugging
and to
false at all other times. For more information, refer to the
documentation about
debugging ASP.NET files.
-->
<compilation defaultLanguage="c#" debug="true" />
.

Relevant Pages

  • Re: The message must contain a wsa:To header
    ... options I should select while going through the WSE 2 wizard. ... at ApplicationMessagingWS.Dispatch(String messageType, String ... be used along with the Integrity assertion when the presence of the ... look for a certificate with this subject name in the certificate store ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • The message must contain a wsa:To header
    ... When I setup the policy, ... at ApplicationMessagingWS.Dispatch(String messageType, String ... be used along with the Integrity assertion when the presence of the signed ... look for a certificate with this subject name in the certificate store ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: X509MutualCertSecurity with manual Assertion Config
    ... WSE definately needs to work on documentation. ... purposes) with the values I extracted using the "WSE X.509 Certificate ... Tool" for the Client and Service Certificates. ... client but not sure how to get the Assertion started. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: The message must contain a wsa:To header
    ... When I setup the policy, ... at ApplicationMessagingWS.Dispatch(String messageType, String ... be used along with the Integrity assertion when the presence of the signed ... look for a certificate with this subject name in the certificate store ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: The message must contain a wsa:To header
    ... My client app is not generating a trace file. ... the client is not applying the WSE policy at all because of an ... at ApplicationMessagingWS.Dispatch(String messageType, String ... look for a certificate with this subject name in the certificate store ...
    (microsoft.public.dotnet.framework.webservices.enhancements)