| Groups | Blog | Home |
dotnet web services enhancements : The message must contain a wsa:To header
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
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] [quoted text, click to view] "Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
news:3D0B2021-2FFB-4D24-B567-930580AC74C3@microsoft.com... >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
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. [quoted text, click to view] "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@discussions.microsoft.com> wrote in message > news:3D0B2021-2FFB-4D24-B567-930580AC74C3@microsoft.com... > >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>
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. [quoted text, click to view] "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@discussions.microsoft.com> wrote in message > news:6A45BFC1-8903-4929-B480-F333E4C45F95@microsoft.com... > > 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@discussions.microsoft.com> wrote in message > >> news:3D0B2021-2FFB-4D24-B567-930580AC74C3@microsoft.com... > >> >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
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. [quoted text, click to view] "Chris Fink" <ChrisFink@discussions.microsoft.com> wrote in message
news:6A45BFC1-8903-4929-B480-F333E4C45F95@microsoft.com... > 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@discussions.microsoft.com> wrote in message >> news:3D0B2021-2FFB-4D24-B567-930580AC74C3@microsoft.com... >> >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)
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |