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.
Alcune applicazioni server richiedono l'autenticazione client per accedere alle risorse e alle richieste HTTP del servizio. A partire dalla versione 2.0, l'API server HTTP esegue l'autenticazione lato server per l'applicazione. Nell'API server HTTP versione 1.0, l'applicazione server doveva implementare la propria autenticazione. Alcuni vantaggi dell'autenticazione eseguita dall'API server HTTP includono:
- Le applicazioni possono essere eseguite con privilegi limitati, riducendo così i rischi per la sicurezza.
- L'autenticazione viene eseguita in modalità kernel, riducendo così le transizioni dalla modalità utente alla modalità kernel durante l'autenticazione.
- L'autenticazione eseguita in modalità kernel consente l'esecuzione delle applicazioni server in account utente diversi. Nella versione 1.0, tutte le applicazioni nel computer devono essere eseguite con lo stesso account utente per l'autenticazione nel nome dell'entità servizio (SPN).
- L'handshake di autenticazione NTLM non viene reimpostato se un processo di lavoro viene riciclato mentre l'handshake è in corso.
Per sfruttare i vantaggi dell'autenticazione della versione 2.0, l'applicazione abilita gli schemi di autenticazione applicati dall'API server HTTP agli URL per cui l'applicazione è registrata. L'autenticazione può essere abilitata nella sessione del server o nel gruppo di URL. Il gruppo di URL eredita gli schemi di autenticazione abilitati dalla sessione del server se nessuno è impostato nel gruppo DI URL. L'API server HTTP supporta gli schemi seguenti:
- Negoziare
- NTLM
- Digerire
- Basico
L'applicazione server può anche implementare schemi di autenticazione non supportati dall'API server HTTP. L'API server HTTP invia richieste all'applicazione per schemi di autenticazione non supportati o per schemi non abilitati dall'applicazione.
Abilitazione dell'autenticazione
L'applicazione server abilita e configura l'autenticazione nella sessione del server o nel gruppo di URL con il HttpSetServerSessionProperty o HttpSetUrlGroupProperty funzioni come indicato di seguito:
- L'applicazione abilita l'autenticazione specificando HttpServerAuthenticationProperty nel parametro proprietà di HttpSetServerSessionProperty o HttpSetUrlGroupProperty.
- L'applicazione specifica i parametri di configurazione nella struttura HTTP_SERVER_AUTHENTICATION_INFO nel parametro pPropertyInformation di HttpSetServerSessionProperty o HttpSetUrlGroupProperty. L'applicazione specifica gli schemi di autenticazione abilitati, se la memorizzazione nella cache delle credenziali NTLM è disabilitata e fornisce i parametri Basic e Digest nella struttura HTTP_SERVER_AUTHENTICATION_INFO.
Procedura di autenticazione
Per avviare l'autenticazione del server HTTP, l'applicazione abilita la proprietà di autenticazione prima dell'arrivo della prima richiesta nella coda delle richieste. I passaggi seguenti sono il flusso di elaborazione comune per l'autenticazione di una richiesta.
L'applicazione abilita l'autenticazione. Vedere la sezione precedente "Abilitazione dell'autenticazione".
Nota
Il client invia una richiesta non autenticata. L'API server HTTP passa la richiesta all'applicazione server e consente di generare la richiesta iniziale 401. L'API server HTTP include la struttura di HTTP_REQUEST_AUTH_INFO incorporata con la struttura HTTP_REQUEST. Il membro AuthStatus indica HttpAuthStatusNotAuthenticated
L'applicazione esamina il membro AuthStatus della struttura HTTP_REQUEST_AUTH_INFO per determinare se la richiesta è stata autenticata. Se la richiesta non è stata autenticata, l'applicazione può eseguire la richiesta come anonima o inviare una richiesta di autenticazione iniziale 401.
Se l'applicazione gestisce la richiesta come anonima, gestisce la richiesta e invia la risposta finale all'applicazione client, come se l'autenticazione non fosse coinvolta.
Se invece l'applicazione richiede l'autenticazione, invia la richiesta di verifica iniziale 401 con una o più intestazioni WWW-Authenticate che indicano gli schemi disponibili al client. L'applicazione deve usare la struttura HTTP_MULTIPLE_KNOWN_HEADERS per compilare il set di intestazioni richiesto quando nella risposta vengono inviate più intestazioni di autenticazione.
Nota
Il client invia nuovamente la richiesta con l'intestazione di autorizzazione per uno schema selezionato dal set di schemi disponibili indicato dall'applicazione server nella risposta iniziale 401.
L'API server HTTP esamina l'intestazione di autorizzazione della richiesta di autorizzazione per determinare se lo schema è abilitato. In caso affermativo, l'API del server HTTP esegue l'autenticazione e gestisce tutti gli scambi di richieste provvisorie/401-risposta, fino a quando non viene finalizzato l'handshake di autenticazione.
Quando l'API server HTTP completa il tentativo di autenticazione, invia la richiesta all'applicazione con i risultati del tentativo di autenticazione nella struttura HTTP_REQUEST_AUTH_INFO restituita con la richiesta. Se il tentativo di autenticazione non riesce per uno dei motivi seguenti, l'API server HTTP non passa la richiesta all'applicazione:
- Se l'handshake di autenticazione non riesce a causa di un errore interno dell'API del server HTTP, ad esempio un errore di allocazione della memoria, l'API del server HTTP genera una risposta 503 (servizio non disponibile) e restituisce al client.
- Se si verifica un'intestazione di autorizzazione in formato non valido, ad esempio un'intestazione senza un nome di schema o una codifica Base64 non valida delle credenziali client, l'API del server HTTP genera una risposta 400 (richiesta non valida) e invia di nuovo al client.
L'applicazione server esamina il membro AuthStatus della struttura HTTP_REQUEST_AUTH_INFO per determinare se l'autenticazione è riuscita. Quando l'autenticazione non riesce, l'API del server HTTP include l'errore restituito da AcceptSecurityContext nel membro SecStatus della struttura HTTP_REQUEST_AUTH_INFO. Se il tentativo di autenticazione non riesce a causa di credenziali non valido, l'applicazione può generare un'altra richiesta di verifica 401 con l'intestazione di WWW-Authenticate desiderata oppure può decidere di gestire la richiesta come anonima.
Se l'autenticazione ha esito positivo, l'applicazione usa il token fornito nella struttura HTTP_REQUEST_AUTH_INFO per rappresentare il client e accedere alle risorse. L'handle del token di accesso restituito all'applicazione è valido purché l'ID richiesta sia valido, che in genere non viene completato fino al completamento della risposta alla richiesta. Il token può tuttavia scadere durante questo periodo e l'applicazione potrebbe dover inviare un'altra richiesta di verifica 401 al client.
L'applicazione invia la risposta 200 OK finale e deve chiudere l'handle al token di accesso.
Nota
L'API server HTTP aggiunge i dati di autenticazione reciproca alla risposta 200 OK finale, se ne è stato generato uno durante l'handshake di autenticazione.
Sessioni NTLM NULL
Si noti che una sessione NTLM NULL indicata nel contesto di sicurezza finale non viene considerata autenticata. In questo caso, la richiesta viene inviata all'applicazione con un errore HttpAuthStatusFailure nella struttura HTTP_REQUEST_AUTH_INFO e l'applicazione può inviare un'altra richiesta 401.
Autenticazione preemptive
In base al protocollo HTTP, dopo che il client ha stabilito l'autenticazione per una risorsa, può inviare in modo preliminare l'intestazione di autorizzazione corrispondente con le successive richieste consecutive per la risorsa senza attendere una richiesta 401 dal server. Se lo schema indicato nell'intestazione autorizzazione è ancora abilitato dall'applicazione e supportato dall'API server HTTP, il server HTTP tenta l'autenticazione senza inviare la richiesta all'applicazione. Quando questo tipo di richiesta autenticata viene ricevuta dall'applicazione, può scegliere di eliminare la richiesta e rigenerare la richiesta iniziale 401 o di gestire la richiesta come autenticata.
Autenticazione reciproca
I dati di autenticazione reciproca vengono generati quando lo schema di negoziazione viene usato durante l'handshake e viene risolto in Kerberos e il client ha richiesto l'autenticazione reciproca. I dati di autenticazione reciproca vengono inseriti automaticamente dall'API server HTTP nella risposta 200 OK finale inviata dall'applicazione server. Per impostazione predefinita, l'API server HTTP non passa i dati di autenticazione reciproca all'applicazione server, poiché gestisce automaticamente l'invio. Tuttavia, se l'applicazione server abilita il flag ReceiveMutualAuth nella struttura di HTTP_SERVER_AUTHENTICATION_INFO nella configurazione, i dati di autenticazione reciproca vengono passati all'applicazione nella struttura HTTP_REQUEST_AUTH_INFO incorporata con l'HTTP_REQUESTautenticato. In questo caso, l'applicazione deve inviare i dati di autenticazione reciproca con la risposta 200 OK finale. Nel caso in cui più siti vengano gestiti da un singolo computer, tutti i siti del computer usano le credenziali per l'account computer locale nel dominio per l'autenticazione reciproca.