In questi giorni mi trovo a litigare con header soap e standard WS -* vari. Uno dei problemi era di capire cosa wcf mette a disposizione.. beh ... un mare di roba!! 
Molti standard sono implementati out of the box , esempio : ws addressing, ws reliable messaging, ws atomic transaction, ws security ...e non li ho citati tutti (per una visione di insieme sui vari standard : Making Sense of all these Crazy Web Service Standards)
Per avere dei riferimenti sul mapping wcf /ws* potete leggere questo articolo davvero utile su topxml.
Non solo vi parla del mapping binding ma dà anche qualche dritta sugli switch di configurazione che permettono di configurare il wcf in modo che l'header soap esca nel formato desiderato.
Facciamo un esempio pratico, supponiamo di volere realizzare un'autenticazione consumer - service tramite scambio di certificati , senza entrare nel merito della configurazione (mi riprometto di scrivere qualcosa di completo su questo fra qualche giorno)
Nel codice del contratto mettiamo pure quello che vogliamo nell'ambito della decenza informatica :) basta non inserire codice per bypassare la configurazione.
Utilizzando in modo "normale" gli attributi (tipo l'esempio generato dal visual studio nella creazione di un servizio WCF ) usare servizi non protetti in basic http, piuttosto che protetti con token di vario genere e natura diventa solo un problema di configurazione totalmente trasparente a chi sviluppa il codice.
Mettiamo su la nostra infrastruttura di sicurezza :
Nel behaviour specifichiamo le credenziali con le quali il servizio si presenterà al client e il modo in cui il servizio autenticherà il client:
<serviceBehaviors>
<behavior name="CertBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="ChainTrust" revocationMode="NoCheck" />
</clientCertificate>
<serviceCertificate findValue="CN=DEVCER" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectDistinguishedName" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
Utilizziamo per il nostro endpoint il seguente Binding :
<wsHttpBinding>
<binding name="SecuredByCertificate">
<reliableSession enabled="false" />
<security>
<transport clientCredentialType="None" />
<message clientCredentialType="Certificate" negotiateServiceCredential="false" establishSecurityContext="false" />
</security>
</binding>
</wsHttpBinding>
Occhio alla parte in rosso ci servirà più avanti.. 
Il servizio sarà configurato cosi :
<service behaviorConfiguration="CertBehavior" name="WcfService1.Service1">
<endpoint address="" behaviorConfiguration="CustomBehav" binding="wsHttpBinding" bindingConfiguration="SecuredByCertificate" contract="WcfService1.IService1">
<identity>
<dns value="DEVCER" />
</identity>
</endpoint>
</service>
Questo è un estratto della policy di sicurezza nel wsdl ottenuto dal binding con i nostri switch impostati a false , ingrandendo l'immagine si nota che si utilizza un X509Token
Adesso invece reimpostiamo a true i nostri famosi flag di configurazione : "negotiateServiceCredential="true" establishSecurityContext="true"
Quello che otteniamo è un policy di sicurezza abbastanza diversa basata su SCT (security context token) ovvero stiamo applicando la policy di WS-SecureConversation
Sottolineo che se non avessimo spulciato il wsdl ( o l'header soap che evito di allegare perché un tantinello ingombrante ) e avessimo utilizzato un consumer .Net che abbiamo tranquillamente agganciato al servizio utilizzando l'add service reference di VS 2008, non ci saremmo minimamente accorti che il meccanismo di autenticazione utilizzato è sostanzialmente diverso(salvo sentire le imprecazioni del collega java che si aspettava un'altra policy di sicurezza ) : nel caso dell'X509 token fondamentalmente viene utilizzato un meccanismo di cifratura a chiave asimmetrica, mentre nel caso dell'sct si utilizza un meccanismo di cifratura a chiave simmetrica (più efficiente computazionalmente) ma che comporta una serie di chiamate in più per lo scambio in sicurezza della chiave simmetrica.
Grazie ai sopravvissuti arrivati fin qui nella lettura 
Ale
posted @ sabato 20 settembre 2008 06:17