WSHttpBinding

Il WSHttpBinding è un binding pensato per supportare le specifiche WS-Security, Ws-SecureConversation e tutte le altre che sono correlate a queste due. Va detto, che queste sono specifiche rilasciate dall'organismo OASIS (consorzio a cui partecipano le aziende leader in questo mercato come Microsoft, Sun, IBM e molte altre) e che quindi rappresentano uno standard de facto nel mondo dei servizi garantendo così l'interoperabilità tra sistemi eterogenei. Le specifiche WS-Security indicano come un messaggio deve essere protetto tra i vari punti della comunicazione, quindi, il rispetto di queste garantisce che già a livello di dati la sicurezza sia stata rispettata (Message Security) indipendetemente dall'uso di una protezione anche a livello di trasporto. Proprio per il suo supporto nativo alle specifiche WS-* per la sicurezza, questo binding è sicuro per default. Quando si utilizza questo binding, le informazioni contenute nell'intestazione del messaggio ed in quella degli indirizzi, vengono firmate per garantire l'identità, mentre il corpo del messaggio viene prima cifrato e poi convertito in formato Base64 per garantire piena sicurezza dei dati. Ovviamente, Message Security e Transport security sono tranquillamente utilizzabili contemporaneamente quindi si può, ad esempio, inviare le credenziali di autenticazione direttamente all'interno del messaggio delegando il meccanismo di trasporto per quanto riguarda la garanzia dell'integrità e della confidenzialità dei messaggi.

Prima di Windows Communication Foundation, Microsoft aveva già rilasciato un pacchetto, noto con il nome di Web Services Enhancement (WSE) e giunto alla versione 3.0, per costruire da subito Web Services che rispettassero tali specifiche. Il WSHttpBinding rappresenta la naturale evoluzione di WSE permettendo un porting delle applicazioni in maniera semplice poiché ingloba tutti gli scenari cosiddetti "TurnKey" presenti in WSE e che coprono la maggior parte delle casistiche:

• Un primo caso è rappresentato dallo scenario AnonymousOverCertificate dove la sicurezza dei dati viene garantita da un certificato X509 rilasciato dal server mentre il client è anonimo. In questo modo, qualunque client in possesso della chiave publica del certificato può colloquiare con il servizio. Un esempio di servizio che sfrutta questo meccanismo è quello che permette di prenotare un volo aereo dove l'importante non è autenticare il client, ma semplicemente assicurare che i dati siano protetti.
  <security mode="Message">
    <message clientCredentialType="Certificate" negotiateServiceCredential="false"/>
</security>
• Il secondo scenario è UsernameOverCertificate dove i dati vengono protetti sempre tramite certificato digitale, ma le credenziali di accesso UserName e Password vengono inserite nel messaggio. Questa configurazione può essere usata da un client che cerca di accedere ad un servizio bancario dove è fondamentale identificare il cliente al fine di fornirgli i suoi dati personali.
  <security mode="Message">
    <message clientCredentialType="UserName" negotiateServiceCredential="false"/>
</security>
• Il terzo caso da prendere in considerazione è lo scenario Kerberos (o Windows). In questo caso sia il service che il client si trovano all'interno dello stesso dominio Windows e sfruttano l'infrastruttura esistente per garantire la sicurezza. Quando si esegue l'autenticazione, Kerberos rilascia un ticket che poi i peer della comunicazione utilizzano per criptare i messaggi. Visto che client e server devono essere nello stesso dominio, questa modalità è adatta per servizi interni ad un'azienda come la stesura di un rapportino o la gestione delle procedure standard ISO.
  <security mode="Message">
    <message clientCredentialType="Windows" negotiateServiceCredential="false"/>
</security>
• La quarta opzione prevede l'utilizzo dello scenario MutualCertificate dove entrambe le parti sono in possesso di un certificato digitale pr criptare lo scambio di messaggi. Un tipico utilizzo di questa tecnica è in un ambiente "Business to Business" dove client e servizio hanno una loro identità.
  <security mode="Message">
    <message clientCredentialType=?Certificate" negotiateServiceCredential="false"/>
</security>
• L'ultima scelta è rappresentata dallo scenario UserNameOverTransport. In questo caso, la sicurezza dei dati è garantita dal trasporto (SSL nella maggior parte dei casi) all'interno del quale vengono spedite anche le credenziali di accesso UserName e Password.
  <security mode=" TransportWithMessageCredential">
    <transport clientCredentialType="Username" />
</security>

Contenuti dell'articolo

• Pagina 1
  • Binding HTTP Predefiniti
  • BasicHttpBinding
• Pagina 4
  • WSHttpBinding
• Pagina 5
  • WsDualHttpBinding
  • Conclusioni