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

Yes, you are completely right regarding the encryption issue, sorry about
that. The client token is not used to sign any message
WSE should only use the client token to encrypt the response message (Using
an encrypted key).
If the <fault> protection element is configured not to encrypt SOAP faults,
as you said, it should not fail. We both are missing something :), I think
I should take a look the assertion in order to find out what is really
happening behind doors.

Pablo.

"J. Dudgeon" <JDudgeon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:862D117A-2835-46BE-A2B3-60DB6FF8D699@xxxxxxxxxxxxxxxx
Note: We are using WS-Security 1.0 / mutualCertificate10Security

My understanding is that the <EncryptedKey> element contains a symmetric
key
encrypted with the public key of the destination. This allows the
destination to use its private key so that it can decrypt the
<CipherValue>
block to get the symmetric key for decrypting the SOAP body. The signed
portions of the SOAP message are done using the sender's private key.
When
WSE receives a request, it stores the client token so that, when it sends
the
response, it can use that token's public key to encrypt the outgoing
message.
I didn't think WSE used the client token to *sign* the response message.

Therefore, with regards to (1) & (3), when sending a response, doesn't the
service *sign* the response message using the service's private key? The
service's private key should be available. Since I've configured the
<fault>
protection element to not encrypt the SOAP fault response, there should be
no
need for a client token.

If this was a SOAP response and not a SOAP fault, I would agree that WSE
would be confused as to which client token to use to *encrypt* the
response,
because it wouldn't know which of the client's public keys to use. But
the
service is failing to send a fault, not a "response".

This leads me back to my problem. If the <fault> protection element is
configured not to encrypt SOAP faults, why does WSE look for a client
token
to encrypt the response? To my understanding, the signature of the SOAP
fault should be generated using service's private key, which should always
be
available. Perhaps I am missing something...

Hopefully that makes sense. Thanks for the continuing the discussion.

Joel

"Pablo Cibraro [MVP]" wrote:

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.




.

Relevant Pages

  • WSE 3.0 Policy and Encrypting Custom Headers (XML Encryption Spec)
    ... I am curious if WSE 3.0 policy or any other features of WSE 3.0 make it ... easier to encrypt custom soap headers to conform to the Xml Encryption Spec. ... but you can't speciy any part of the soap header to be ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: WSE 3.0 Policy and Encrypting Custom Headers (XML Encryption Spec)
    ... >I am curious if WSE 3.0 policy or any other features of WSE 3.0 make it ... > easier to encrypt custom soap headers to conform to the Xml Encryption ... > localization header, etc). ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Encryption
    ... RSA is used extensively by CF WSE. ... -i verify a message from them with their public key. ... -i encrypt a message to them with their public key. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Can WSE 3.0 do this for me?
    ... So if use UsernameOverTransport to do the authentication once then can I also ... use message layer encryption rather than transport layer. ... Cause in the WSE ... must encrypt at the transport layer. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Shared Secret (or Equivalent) + WSE 2.0
    ... Thanks Dilip. ... and it requires a certificate. ... >> something that will encrypt and properly decrypt on the other side, ... >> functionality in V1.0 of WSE was great for this and it worked nicely. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
Loading