C# .NET 4.0 WCF MessageSecurityException, "L'intestazione di sicurezza è vuota." quando si consuma un servizio

Question

Quando si utilizza WCF e C# in un progetto ottengo un'eccezione, MesssageSecurityException, con il messaggio "L'intestazione di sicurezza è vuota.". Qui di seguito la risposta (in base a MS Servizio Trace Viewer):

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing"> 
     <soapenv:Header> 
     <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="true"></wsse:Security> 
     <wsa:Action>_WHAT_I_DID_</wsa:Action> 
     <wsa:RelatesTo>_MSG_ID_OF_REQUEST_</wsa:RelatesTo> 
     </soapenv:Header> 
     <soapenv:Body> 
     _CORRECT_BODY_ 
     </soapenv:Body> 
    </soapenv:Envelope> 

In effetti, l'intestazione di protezione è "vuoto", ma è ancora corretta accprding alla definizione intestazione di protezione per quanto posso dire.

Ho anche provato a modificare i binding, ma questo non sembra essere di aiuto. Ho anche trovato un problema simile in cui abilitare EnableUnsecuredResponse sarebbe di aiuto, ma non qui.

Ecco la risposta in base alla SoapUI:

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing"> 
    <soapenv:Header> 
     <wsse:Security soapenv:mustUnderstand="true" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/> 
     <wsa:Action>_WHAT_I_DID_</wsa:Action> 
     <wsa:RelatesTo>_REQ_MSG_ID_</wsa:RelatesTo> 
    </soapenv:Header> 
    <soapenv:Body> 
     _CORRECT_BODY_ 
    </soapenv:Body> 
</soapenv:Envelope> 

Essi sono quasi identiche, tranne che per il modo in cui chiudono l'intestazione di sicurezza. Quale è interessante, ma non dovrebbe sollevare l'eccezione?

Ho trovato anche un similar problem in cui la soluzione era quella di creare un codificatore di messaggi personalizzato e rimuovere l'intera intestazione di sicurezza, anche se questo avrebbe funzionato è un passo aggiuntivo non necessario. È questo l'unico modo per farlo con .Net e WCF? WCF non può gestire le intestazioni di sicurezza senza contenuto?

MODIFICA: Chiarimento del problema, sta scrivendo un codificatore che elimina l'intestazione di sicurezza l'unico modo per ricevere e analizzare i messaggi SOAP con le intestazioni di sicurezza vuote usando WCF?

EDIT2: Aggiunta parte di conf:

<binding name="NinjaBinding"> 
     <security allowSerializedSigningTokenOnReply="true" enableUnsecuredResponse="true" 
     authenticationMode="UserNameOverTransport" requireDerivedKeys="false" 
     securityHeaderLayout="Lax" includeTimestamp="false" allowInsecureTransport="true" 
     keyEntropyMode="ClientEntropy" 
     messageProtectionOrder="SignBeforeEncryptAndEncryptSignature" 
    messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10" 
     requireSecurityContextCancellation="false"> 
     <localServiceSettings detectReplays="false" /> 
     <secureConversationBootstrap _IDENTICAL_TO_ABOVE_ 
     </secureConversationBootstrap> 
     </security> 
     <textMessageEncoding /> 
     <httpsTransport /> 
    </binding> 

Per quanto ne so, la sua configurazione da consentire praticamente tutto?

Answer 1

(Ora sto rispondendo alla mia domanda da quando sono stato in grado di suscitare un qualche tipo di risposta)

Insomma, no non è possibile utilizzare WCF "out of the box" (vale a dire attraverso *. config) con i server delle applicazioni che forniscono le intestazioni di sicurezza vuote nelle risposte. Devi implementare un codificatore che modifichi i messaggi in un formato accettabile dal framework WCF.

Per ulteriori informazioni leggere this blog che contiene una panoramica abbastanza buona dell'encoder e delle sue applicazioni. This blog (another blog) fornisce anche uno snippet di codice in grado di risolvere il mio problema, ovvero di modificare l'intestazione di sicurezza.

Mi chiedo perché i prodotti MS e Oracle non possono mai coesistere pacificamente: D