Dopo aver gestito l'integrità e la riservatezza dei dati, è arrivato il momento dell'autenticazione; l'autenticazione viene effettuata in base alle credenziali con cui il client si presenta. Ogni credenziale è composta da diverse parti: innanzitutto ci sono i Claims, che sono le informazioni che identificano chi esegue la richiesta, poi c'è l'Issuer, che rappresenta chi ha inviato le informazioni, ed infine c'è la cosiddetta Proof of Possession, che non è altro che la prova che i dati relativi ai Claims e all'Issuer sono validi.

Prendendo come caso di studio la patente di guida, i Claims sono i dati personali sulla patente, l'Issuer è l'ente che rilascia la patente di guida, mentre la Proof Of Possession è il timbro della prefettura che si trova sulla patente che ne garantisce la validità.

Usando il TransportMode, il client può inviare le proprie credenziali in diversi modi come avviene già adesso.

Queste modalità sono settabili direttamente da file di configurazione tramite Binding e sono:

• None. Equivalente dell'accesso anonimo;
• Basic o Digest;
• NTLM;
• Windows. Utilizza la kerberos authentication per ambienti Windows;
• Certficate. Il client utilizza un certificato digitale come sistema di autenticazione.

Adottando il MessageMode, la situazione cambia in quanto le credenziali sono inviate all'interno del messaggio. Le modalità possibili sono:

• None. Equivalente all'accesso anonimo;
• Windows. In questo caso lo scambio di messaggi avviene nel contesto dell'utente windows;
• Username. Vengono utilizzati UserName e Password per autenticare l'utente. Le informazioni non sono criptate quindi è importante che a livello di trasporto ci sia una protezione dei dati (SSL);
• Certificate. Viene inserito nel messaggio una firma digitale per rappresentare il certificato del client;
• InfoCard. Il client si autentica tramite una InfoCard.

Come già detto, queste informazioni sono impostabili direttamente tramite file di configurazione permettendo così di modificare il comportamento dei peer senza dover modificare alcuna riga di codice; questo avviene grazie ai bindings della quale abbiamo parlato nell'articolo introduttivo. WCF ha già diversi bindings predefiniti per molte esigenze, dal servizio completamente aperto, al servizio iperprotetto che richiede SSL e sicurezza anche sul messaggio. Qui sotto sono riportati alcuni scenari classici con la relativa configurazione:

Questa configurazione utilizza il basicHttpBinding che non effettua alcuna crittografia dei dati, ne effettua alcuna autenticazione quindi si tratta di un servizio completamente insicuro. Questo scenario è molto comune, basta pensare ai servizi di informazione meteo, o a siti che offrono risultati sportivi online, ecc.

Contenuti dell'articolo

• Pagina 1
  • Introduzione
  • Transfer Security
• Pagina 4
  • Access Control
• Pagina 6
  • Auditing
  • Conclusioni