2.3 Proxy
2.3. Proxy
Con il proxy RADIUS, un server RADIUS riceve una richiesta di autenticazione (o accounting) da un client RADIUS (come un NAS), inoltra la richiesta a un server RADIUS remoto, riceve la risposta dal server remoto e invia quella risposta al client, possibilmente con modifiche per riflettere la politica amministrativa locale. Un uso comune per il proxy RADIUS è il roaming. Il roaming consente a due o più entità amministrative di permettere reciprocamente agli utenti dell'altra di connettersi alla rete di entrambe le entità per il servizio.
Il NAS invia la sua richiesta di accesso RADIUS al "forwarding server" (server di inoltro) che la inoltra al "remote server" (server remoto). Il server remoto invia una risposta (Access-Accept, Access-Reject o Access-Challenge) indietro al forwarding server, che la invia indietro al NAS. L'attributo User-Name PUÒ contenere un Network Access Identifier [8] per le operazioni di Proxy RADIUS. La scelta di quale server riceve la richiesta inoltrata DOVREBBE essere basata sul "realm" (dominio) di autenticazione. Il realm di autenticazione PUÒ essere la parte realm di un Network Access Identifier (un "named realm", dominio nominato). In alternativa, la scelta di quale server riceve la richiesta inoltrata PUÒ essere basata su qualsiasi altro criterio con cui il forwarding server è configurato per utilizzare, come Called-Station-Id (un "numbered realm", dominio numerato).
Un server RADIUS può funzionare sia come forwarding server che come remote server, servendo come forwarding server per alcuni realm e come remote server per altri realm. Un forwarding server può agire come forwarder per qualsiasi numero di server remoti. Un server remoto può avere qualsiasi numero di server che inoltrano ad esso e può fornire autenticazione per qualsiasi numero di realm. Un forwarding server può inoltrare a un altro forwarding server per creare una catena di proxy, anche se bisogna fare attenzione ad evitare l'introduzione di loop.
Il seguente scenario illustra una comunicazione proxy RADIUS tra un NAS e i server RADIUS di inoltro e remoti:
-
Un NAS invia la sua richiesta di accesso al forwarding server.
-
Il forwarding server inoltra la richiesta di accesso al server remoto.
-
Il server remoto invia un access-accept, access-reject o access-challenge indietro al forwarding server. Per questo esempio, viene inviato un access-accept.
-
Il forwarding server invia l'access-accept al NAS.
Il forwarding server DEVE trattare qualsiasi attributo Proxy-State già presente nel pacchetto come dati opachi. Il suo funzionamento NON DEVE dipendere dal contenuto degli attributi Proxy-State aggiunti dai server precedenti.
Se ci sono attributi Proxy-State nella richiesta ricevuta dal client, il forwarding server DEVE includere quegli attributi Proxy-State nella sua risposta al client. Il forwarding server PUÒ includere il proprio attributo Proxy-State in qualsiasi Access-Request al server remoto. Se un attributo Proxy-State è aggiunto all'Access-Request, il forwarding server DEVE includere quell'attributo Proxy-State in qualsiasi Access-Challenge, Access-Accept o Access-Reject ricevuto dal server remoto.
Il forwarding server NON DEVE modificare gli attributi Proxy-State esistenti. Il forwarding server DEVE trattare qualsiasi attributo ricevuto come un attributo opaco e NON DEVE interpretare, modificare o eliminare gli attributi di autenticazione o autorizzazione. Le eccezioni sono gli attributi Vendor-Specific che sono aggiunti, modificati o rimossi per implementare una politica locale. I dettagli dell'implementazione di tale politica locale sono al di fuori dello scopo di questo documento, ma può includere la modifica, l'aggiunta o la rimozione di Vendor-Specific o altre attributi nella richiesta o nella risposta.