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

Thanks. I see your concern, I will describe you the problem in a different
way.

1. The WSE security assertions sign the response messages by default using
the client token received in the request message (Well, they actually use an
encrypted key token created from that client token).
2. Since WSE is receiving two client tokens in the request message, the
first error is generated.
3. Since the WSE assertion does not know what client token it has to use (It
is receiving two tokens) to sign the response message, the second error
message is generated. (The one the client application is receiving).

Does it make sense ?

Pablo.

"J. Dudgeon" <JDudgeon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0121A7D9-9C8F-40B5-B424-AFF9391FE5BA@xxxxxxxxxxxxxxxx
Thanks for the reply, I was hoping you would see this (love your blog by
the
way.)

The problem isn't that there are two security tokens - the client had a
configuration error on their side so WSE correct identified the error.
The
problem is that instead of the client receiving a SOAP fault containing:

WSE2007: More than one X509SecurityToken is present in the security header
of the incoming message, but only one was expected:

the client receives a SOAP fault containing:

WSE2133: An error occurred processing an outgoing fault response.

It looks like WSE 3 generates a SOAP fault for the correct exception
"WSE2007" but an exception occurs in the send pipeline when it tries to
send
the SOAP fault to the client. This results in the client receiving a
"WSE2133" error instead of the actual "WSE2007".

I can see where the exception is occurring in the OutputTrace file and the
cause, but I don't understand why that is happening and why the client
isn't
receiving the correct SOAP fault. It looks like the send pipeline is
failing
at:

Microsoft.Web.Services3.Design.MutualCertificate10Assertion+ServiceOutputFilter.SecureMessage(...)

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.

So the real SOAP fault that describes the "two security tokens" error gets
replaced by the generic "WSE2133: An error occurred processing an outgoing
fault response."

Any other ideas?

Thank you,

Joel

"Pablo Cibraro [MVP]" wrote:

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