Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
L'autenticazione è il processo di identificazione dell'utente client, in genere per determinare se il client è idoneo ad accedere a una risorsa. Il protocollo HTTP supporta l'autenticazione come mezzo per negoziare l'accesso a una risorsa sicura.
La richiesta iniziale da un client è in genere una richiesta anonima, non contenente informazioni di autenticazione. Le app server HTTP possono negare la richiesta anonima mentre indica che è necessaria l'autenticazione. L'applicazione server invia intestazioni WWW-Authentication per indicare gli schemi di autenticazione supportati. Questo articolo descrive diversi schemi di autenticazione per HTTP e ne illustra il supporto in Windows Communication Foundation (WCF).
Schemi di autenticazione HTTP
Il server può specificare più schemi di autenticazione tra cui scegliere il client. La tabella seguente descrive alcuni degli schemi di autenticazione comunemente presenti nelle applicazioni Windows:
| Schema di autenticazione | Descrizione |
|---|---|
| Anonimo | Una richiesta anonima non contiene informazioni di autenticazione. Anonymous equivale a concedere a tutti l'accesso alla risorsa. |
| Fondamentale | L'autenticazione di base invia una stringa con codifica Base64 che contiene un nome utente e una password per il client. Base64 non è una forma di crittografia e deve essere considerata come l'invio del nome utente e della password in testo non crittografato. Se una risorsa deve essere protetta, è consigliabile usare uno schema di autenticazione diverso dall'autenticazione di base. |
| Sommario | L'autenticazione digest è uno schema di tipo sfida-risposta progettato per sostituire l'autenticazione di base. Il server invia una stringa di dati casuali denominata nonce al client come richiesta di verifica. Il client risponde con un hash che include il nome utente, la password e il nonce, tra le informazioni aggiuntive. La complessità di questo scambio introduce e l'hashing dei dati rende più difficile rubare e riutilizzare le credenziali dell'utente con questo schema di autenticazione. L'autenticazione digest richiede l'uso degli account di dominio di Windows. L'ambito digest è il nome di dominio di Windows. Pertanto, non è possibile usare un server in esecuzione in un sistema operativo che non supporta domini Windows, ad esempio Windows XP Home Edition, con l'autenticazione digest. Viceversa, quando il client viene eseguito in un sistema operativo che non supporta i domini Windows, è necessario specificare in modo esplicito un account di dominio durante l'autenticazione. |
| NTLM | L'autenticazione NT LAN Manager (NTLM) è uno schema challenge-response che costituisce una variante più sicura dell'autenticazione Digest. NTLM usa le credenziali di Windows per trasformare i dati di verifica anziché il nome utente e la password non codificati. L'autenticazione NTLM richiede più scambi tra il client e il server. Il server e i proxy intermedi devono supportare connessioni persistenti per completare correttamente l'autenticazione. |
| Negoziare | L'autenticazione negoziata seleziona automaticamente tra il protocollo Kerberos e l'autenticazione NTLM, a seconda della disponibilità. Il protocollo Kerberos viene usato se disponibile; in caso contrario, viene provato NTLM. L'autenticazione Kerberos migliora significativamente su NTLM. L'autenticazione Kerberos è sia più veloce di NTLM che consente l'uso dell'autenticazione reciproca e della delega delle credenziali ai computer remoti. |
| Windows Live ID | Il servizio HTTP Di Windows sottostante include l'autenticazione tramite protocolli federati. Tuttavia, i trasporti HTTP standard in WCF non supportano l'uso di schemi di autenticazione federati, ad esempio Microsoft Windows Live ID. Il supporto per questa funzionalità è attualmente disponibile tramite la sicurezza dei messaggi. Per altre informazioni, vedere Federazione e token emessi. |
Scegliere uno schema di autenticazione
Quando si selezionano i potenziali schemi di autenticazione per un server HTTP, alcuni elementi da considerare includono quanto segue:
Valutare se la risorsa deve essere protetta. L'uso dell'autenticazione HTTP richiede la trasmissione di più dati e può limitare l'interoperabilità con i client. Consentire l'accesso anonimo alle risorse che non devono essere protette.
Se la risorsa deve essere protetta, considerare gli schemi di autenticazione che forniscono il livello di sicurezza richiesto. Lo schema di autenticazione standard più debole descritto di seguito è l'autenticazione di base. L'autenticazione di base non protegge le credenziali dell'utente. Lo schema di autenticazione standard più sicuro è l'autenticazione Negotiate, con conseguente protocollo Kerberos.
Un server non deve presentare, ad esempio, nelle intestazioni WWW-Authentication, alcuno schema che non è pronto ad accettare o che non protegge adeguatamente la risorsa protetta. I client sono liberi di scegliere tra uno degli schemi di autenticazione presentato dal server. Per impostazione predefinita, alcuni client hanno uno schema di autenticazione debole o il primo schema di autenticazione nell'elenco del server.