WCF - Implementing client which requires encryption of one soap:body element, how?

I've been looking all over for this, and its not looking promising so far, trying to get a client app written that is consuming a 3rd party service(sample request below, from java client). The one gotcha is that it is expecting one element in the body to be encrypted.

Ideally this would be a WCF solution, although I've read a few places about using WSE1/2/3 to get close to this(not really wanted since WSE is stagnant), has anyone had to tackle this type of issue?

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://editedURL">
  <soap:Header>
    <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
            wsu:Id="Timestamp-2d960151-fc35-4522-a8cd-b463025209d8">
        <wsu:Created>2010-11-23T16:17:36Z</wsu:Created>
      </wsu:Timestamp>
      <wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" 
            EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" 
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
            wsu:Id="SecurityToken-68e70781-8ff5-4e08-b066-8b9c6badef37"><!--token was here --></wsse:BinarySecurityToken>
      <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <wsse:SecurityTokenReference>
            <wsse:Reference URI="#SecurityToken-68e70781-8ff5-4e08-b066-8b9c6badef37" 
            ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
          </wsse:SecurityTokenReference>
        </KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue><!--cypher was here --></xenc:CipherValue>
        </xenc:CipherData>
        <xenc:ReferenceList>
          <xenc:DataReference URI="#Enc-5293b4f0-9aa5-4c37-ad1c-7c55c7d9ded1"/>
        </xenc:ReferenceList>
      </xenc:EncryptedKey>
    </wsse:Security>
  </soap:Header>
  <soap:Body>
    <tns:Authenticate>
      <authIn>
        <authID><!-- user id was here plaintext --></authID>
        <authPwd wsu:Id="Id-8bac7fa6-fac9-4ce4-8a5e-3b221c64ca76" 
                xmlns:wsu="htt开发者_运维知识库p://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
          <xenc:EncryptedData Id="Enc-5293b4f0-9aa5-4c37-ad1c-7c55c7d9ded1" Type="http://www.w3.org/2001/04/xmlenc#Content" 
                                mlns:xenc="http://www.w3.org/2001/04/xmlenc#">
            <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
            <xenc:CipherData>
              <xenc:CipherValue><!-- encrypted password was here --></xenc:CipherValue>
            </xenc:CipherData>
          </xenc:EncryptedData>
        </authPwd>
        <authServer><!-- domain was here plaintext --></authServer>
      </authIn>
    </tns:Authenticate>
  </soap:Body>
</soap:Envelope>

The pain point is the authPwd element in the soap:Body, thanks for any insight

I had a bad news for you. Out of the box security implementation is not able to do this and I'm not sure how to extend WCF to support that unless you write all WS-Security stuff from scratch. WCF is very extensible except scenarios where you want to extend already implemented protocols - those classes are mostly sealed / internal and cannot be reused.

The whole problem whould be completely different if those elements were SOAP headers instead of body elements.

Edit:

I checked again whole SOAP message you provided I found two other problems.

• I doubt about level of security your service provides. It doesn't show the plain text password but it can be all. Hiding password is not only security you need because if security is not correctly implemented attacker can simply take your whole message (encrypted as is) and send it from his computer again. If service is configured incorrectly it will process that request as any other. This is called replay attack and the main defense against this attack is timestamp but because your message is not signed attacker can change timestamp value as he wish. There can be additional defence mechanism in EncryptedKey element but that is hard to say from the message itself.
• WCF will most probably not be able to process the message even if the service encrypts the whole body. Out of the box security requires signitures - timestamp must be signed (because of the reason mentioned above) and message parts can be either sign or encrypted and sign but not only encrypted. Signing encrypted part will ensure that attacker will not replace posted data with another one.