1. Autenticazione di accesso (Access Authentication)
1.1 Dipendenza dalla specifica HTTP/1.1 (Reliance on the HTTP/1.1 Specification)
Questa specifica è un documento complementare alla specifica HTTP/1.1 [2]. Utilizza la notazione BNF aumentata della sezione 2.1 di quel documento e si basa sia sui non-terminali definiti in quel documento sia su altri aspetti della specifica HTTP/1.1.
1.2 Framework di autenticazione di accesso (Access Authentication Framework)
HTTP fornisce un semplice meccanismo di autenticazione sfida-risposta (Challenge-Response Authentication Mechanism) che un server può utilizzare per sfidare una richiesta del client e che il client può utilizzare per fornire informazioni di autenticazione. Utilizza un token (Token) estensibile e non sensibile alle maiuscole per identificare lo schema di autenticazione (Authentication Scheme), seguito da un elenco separato da virgole di coppie attributo-valore che trasportano i parametri necessari per ottenere l'autenticazione tramite quello schema.
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
Il server di origine (Origin Server) utilizza un messaggio di risposta 401 (Unauthorized) per sfidare l'autorizzazione dell'user agent. Questa risposta deve includere un campo header WWW-Authenticate contenente almeno una sfida applicabile alla risorsa richiesta. Un proxy (Proxy) utilizza un messaggio di risposta 407 (Proxy Authentication Required) per sfidare l'autorizzazione del client e deve includere un campo header Proxy-Authenticate contenente almeno una sfida proxy applicabile alla risorsa richiesta.
challenge = auth-scheme 1*SP 1#auth-param
Nota: Se il valore del campo header WWW-Authenticate o Proxy-Authenticate contiene più sfide, o se vengono forniti più campi header WWW-Authenticate, l'user agent deve prestare particolare attenzione durante l'analisi, poiché il contenuto della sfida stessa può contenere un elenco separato da virgole di parametri di autenticazione.
Il parametro di autenticazione realm (dominio) è definito per tutti gli schemi di autenticazione:
realm = "realm" "=" realm-value
realm-value = quoted-string
La direttiva realm (non sensibile alle maiuscole) è richiesta per tutti gli schemi di autenticazione che emettono una sfida. Il valore realm (sensibile alle maiuscole), in combinazione con l'URL radice canonico (l'absoluteURI per il server il cui abs_path è vuoto; vedere sezione 5.1.2 di [2]) del server a cui si accede, definisce lo spazio di protezione (Protection Space). Questi realm consentono di suddividere le risorse protette su un server in un insieme di spazi di protezione, ciascuno con il proprio schema di autenticazione e/o database di autorizzazione. Il valore realm è una stringa, generalmente assegnata dal server di origine, che può avere una semantica aggiuntiva specifica dello schema di autenticazione. Si prega di notare che possono esistere più sfide con lo stesso auth-scheme ma realm diversi.
Un user agent che desidera autenticarsi con un server di origine -- di solito, ma non necessariamente, dopo aver ricevuto un 401 (Unauthorized) -- può farlo includendo un campo header Authorization con la richiesta. Un client che desidera autenticarsi con un proxy -- di solito, ma non necessariamente, dopo aver ricevuto un 407 (Proxy Authentication Required) -- può farlo includendo un campo header Proxy-Authorization con la richiesta. Sia il valore del campo Authorization che il valore del campo Proxy-Authorization consistono in credenziali (Credentials), contenenti le informazioni di autenticazione del client per il realm della risorsa richiesta. L'user agent deve scegliere di utilizzare la sfida con l'auth-scheme più forte che comprende e richiedere credenziali all'utente in base a quella sfida.
credentials = auth-scheme #auth-param
Nota: Molti browser riconoscono solo l'autenticazione di base (Basic) e richiedono che sia il primo auth-scheme presentato. I server dovrebbero includere l'autenticazione di base solo quando è lo standard minimo accettabile.
Lo spazio di protezione determina il dominio in cui le credenziali possono essere applicate automaticamente. Se una richiesta precedente è stata autorizzata, le stesse credenziali possono essere riutilizzate per tutte le altre richieste all'interno di quello spazio di protezione per un periodo di tempo determinato dallo schema di autenticazione, dai parametri e/o dalle preferenze dell'utente. A meno che non sia definito diversamente dallo schema di autenticazione, un singolo spazio di protezione non può estendersi oltre il suo server.
Se il server di origine non desidera accettare le credenziali inviate con una richiesta, dovrebbe restituire una risposta 401 (Unauthorized). La risposta deve includere un campo header WWW-Authenticate contenente almeno una sfida (possibilmente nuova) applicabile alla risorsa richiesta. Se un proxy non accetta le credenziali inviate con una richiesta, dovrebbe restituire un 407 (Proxy Authentication Required). La risposta deve includere un campo header Proxy-Authenticate contenente una sfida (possibilmente nuova) applicabile alla risorsa richiesta.
Il protocollo HTTP non limita le applicazioni a questo semplice meccanismo sfida-risposta per l'autenticazione di accesso. Possono essere utilizzati meccanismi aggiuntivi, come la crittografia a livello di trasporto o tramite incapsulamento dei messaggi, e con campi header aggiuntivi che specificano informazioni di autenticazione. Tuttavia, questi meccanismi aggiuntivi non sono definiti da questa specifica.
I proxy devono essere completamente trasparenti riguardo all'autenticazione dell'user agent con il server di origine. Cioè, devono inoltrare gli header WWW-Authenticate e Authorization invariati e seguire le regole nella sezione 14.8 di [2]. Sia i campi header Proxy-Authenticate che Proxy-Authorization sono header hop-by-hop (Hop-by-Hop Headers) (vedere sezione 13.5.1 di [2]).