Re: WSE 3: SOAP faults not being returned correctly from service.

Hi Joel,

This error seems to be the source of the other problems, "WSE2007: More than
one X509SecurityToken is present in the security header of
the incoming message, but only one was expected". Is this error being logged
on the client or service side ?.

Well, the error message is clear, your service or client is receiving more
than a X509 token but the WSE security assertion (MutualX509) is expecting
only one. WSE uses that token to authenticate the message, so if it receives
two X509 tokens, it does not know which one it has to use. If you want to
avoid that problem, you can develop a custom MutualX509 assertion. (That
assertion must be smart enough to use only one token and discard the another
one).

Regards,
Pablo Cibraro


"J. Dudgeon" <JDudgeon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B2A7FEE8-C565-467F-A300-268D5B2CE72B@xxxxxxxxxxxxxxxx
Hello,

I've been banging my head against the wall for a few hours now trying to
figure out what the problem is. I am working with a client on WS-Security
interop trying to get their Oracle/Java WS-Security implementation to talk
to
the .NET WSE 3 implementation. We're having an issue with too many
security
tokens being written to the security header but that is another issue.

My problem is that the client is usually getting the following SOAP fault
message back (I've ***removed*** the actor URL for privacy reasons):

<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>System.Web.Services.Protocols.SoapHeaderException:
Server unavailable, please try later ---> System.ApplicationException:
WSE2133: An error occurred processing an outgoing fault response.
--- End of inner exception stack trace ---</faultstring>
<faultactor>***removed***</faultactor>
</soap:Fault>

When I look through the trace file, the actual error is something
completely
different. It looks like the WSE stack generates a valid meaningful SOAP
fault, like:

<soap:Fault>
<faultcode
xmlns:prefix2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>prefix2:Security</faultcode>
<faultstring>Microsoft.Web.Services3.Security.SecurityFault:
WSE2007: More than one X509SecurityToken is present in the security header
of
the incoming message, but only one was expected.
at
Microsoft.Web.Services3.Design.MutualCertificate10Assertion.ServiceInputFilter.ValidateMessageSecurity(SoapEnvelope
envelope, Security security, MessageProtectionRequirements request)
at
Microsoft.Web.Services3.Security.SecureConversationServiceReceiveSecurityFilter.ValidateMessageSecurity(SoapEnvelope
envelope, Security security)
at
Microsoft.Web.Services3.Security.ReceiveSecurityFilter.ProcessMessage(SoapEnvelope
envelope)
at Microsoft.Web.Services3.Pipeline.ProcessInputMessage(SoapEnvelope
envelope)
at
Microsoft.Web.Services3.Messaging.SoapReceiver.FilterMessage(SoapEnvelope
envelope)
at
Microsoft.Web.Services3.Messaging.SoapReceiver.ProcessMessage(SoapEnvelope
message)</faultstring>
<faultactor>***removed***</faultactor>
</soap:Fault>

This is the real reason the Web service call failed. Looking a bit
further
in the processing pipeline, I see the following exception:

<processingStep description="Entering SOAP filter
Microsoft.Web.Services3.Design.MutualCertificate10Assertion+ServiceOutputFilter"
/>
<processingStep description="Exception thrown: WSE2011: In
MutualCertificate10Assertion, encrypted key token cannot be retrieved from
the request message. Encrypted key token from the request is required to
secure the response message from the service. "> at
Microsoft.Web.Services3.Design.MutualCertificate10Assertion.ServiceOutputFilter.SecureMessage(SoapEnvelope
envelope, Security security, MessageProtectionRequirements response)
at
Microsoft.Web.Services3.Security.SecureConversationServiceSendSecurityFilter.SecureMessage(SoapEnvelope
envelope, Security security)
at
Microsoft.Web.Services3.Security.SendSecurityFilter.ProcessMessage(SoapEnvelope
envelope)
at Microsoft.Web.Services3.Pipeline.ProcessOutputMessage(SoapEnvelope
envelope)
</processingStep>

This exception seems to cause the "misleading" SOAP fault message that the
client receives (WSE2133: An error occurred processing an outgoing fault
response.)

Another case is when the client attempts to send a message that isn't
secured, I see the following fault in the trace file:

<soap:Fault>
<faultcode
xmlns:prefix6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>prefix6:Security</faultcode>
<faultstring>Microsoft.Web.Services3.Security.SecurityFault:
Security requirements are not satisfied because the security header is not
present in the incoming message.
at
Microsoft.Web.Services3.Security.SecureConversationServiceReceiveSecurityFilter.ValidateMessageSecurity(SoapEnvelope
envelope, Security security)
at
Microsoft.Web.Services3.Security.ReceiveSecurityFilter.ProcessMessage(SoapEnvelope
envelope)
at Microsoft.Web.Services3.Pipeline.ProcessInputMessage(SoapEnvelope
envelope)
at
Microsoft.Web.Services3.Messaging.SoapReceiver.FilterMessage(SoapEnvelope
envelope)
at
Microsoft.Web.Services3.Messaging.SoapReceiver.ProcessMessage(SoapEnvelope
message)</faultstring>
<faultactor>***removed***</faultactor>
</soap:Fault>

Once again, an exception occurs further down the pipeline:

<processingStep description="Entering SOAP filter
Microsoft.Web.Services3.Design.MutualCertificate10Assertion+ServiceOutputFilter"
/>
<processingStep description="Exception thrown: Send security filter on
the server could not retrieve the operation protection requirements from
the
operation state."> at
Microsoft.Web.Services3.Security.SecureConversationServiceSendSecurityFilter.SecureMessage(SoapEnvelope
envelope, Security security)
at
Microsoft.Web.Services3.Security.SendSecurityFilter.ProcessMessage(SoapEnvelope
envelope)
at Microsoft.Web.Services3.Pipeline.ProcessOutputMessage(SoapEnvelope
envelope)
</processingStep>

Which, once again, causes the client to receive the somewhat misleading
"WSE2133: An error occurred processing an outgoing fault response."

Is this a bug? It seems that WSE 3 handles the original exception fine
and
generates the correct SOAP fault but when trying to send that fault, it
encounters futher errors.

Is there a way around this? I would rather the client receive:

"Security requirements are not satisfied because the security header is
not
present in the incoming message."

rather than:

"An error occurred processing an outgoing fault response"

as this makes it look like it is a problem on our side (resulting in phone
calls, etc.)

Any suggestions would be much appreciated!

Thank you in advance,

Joel


.

Relevant Pages

  • Re: WSE 3.0 CertSrv Request
    ... What would cause the security header not to be present in the message being ... Client OutputTrace looks clean. ... I have not found any good documentation on what type of certificates ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Damn damn damn
    ... It's your own fault for sticking ... Could it be because they consider me to be at fault for not taking the necessary security precautions? ... not have become a victim. ... eccentric criminal gang, and we planned a raid on your house, ...
    (uk.legal)
  • Re: Unrecogniszed SOAPAction?
    ... client side only. ... Security requirements are not satisfied because the security header is not ... HttpContext context, HttpRequest request, HttpResponse response, Boolean& ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Unrecogniszed SOAPAction?
    ... client side only. ... Security requirements are not satisfied because the security header is not ... HttpContext context, HttpRequest request, HttpResponse response, Boolean& ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: WSE 3: SOAP faults not being returned correctly from service.
    ... The WSE security assertions sign the response messages by default using ... encrypted key token created from that client token). ... problem is that instead of the client receiving a SOAP fault containing: ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
Loading