Aller au contenu principal

2.3 Proxy

2.3. Proxy

Avec le proxy RADIUS, un serveur RADIUS reçoit une demande d'authentification (ou de comptabilité) d'un client RADIUS (tel qu'un NAS), transmet la demande à un serveur RADIUS distant, reçoit la réponse du serveur distant et envoie cette réponse au client, éventuellement avec des modifications pour refléter la politique administrative locale. Une utilisation courante du proxy RADIUS est l'itinérance (roaming). L'itinérance permet à deux entités administratives ou plus de permettre aux utilisateurs de chacune de se connecter au réseau de l'une ou l'autre entité pour le service.

Le NAS envoie sa demande d'accès RADIUS au "serveur de transfert" qui la transmet au "serveur distant". Le serveur distant envoie une réponse (Access-Accept, Access-Reject ou Access-Challenge) au serveur de transfert, qui la renvoie au NAS. L'attribut User-Name PEUT contenir un Network Access Identifier [8] pour les opérations de proxy RADIUS. Le choix du serveur qui reçoit la demande transférée DEVRAIT être basé sur le "domaine" (realm) d'authentification. Le domaine d'authentification PEUT être la partie domaine d'un Network Access Identifier (un "domaine nommé"). Alternativement, le choix du serveur qui reçoit la demande transférée PEUT être basé sur tout autre critère que le serveur de transfert est configuré pour utiliser, tel que Called-Station-Id (un "domaine numéroté").

Un serveur RADIUS peut fonctionner à la fois comme serveur de transfert et comme serveur distant, servant de serveur de transfert pour certains domaines et de serveur distant pour d'autres domaines. Un serveur de transfert peut agir comme transmetteur pour n'importe quel nombre de serveurs distants. Un serveur distant peut avoir n'importe quel nombre de serveurs lui transmettant des demandes et peut fournir l'authentification pour n'importe quel nombre de domaines. Un serveur de transfert peut transmettre à un autre serveur de transfert pour créer une chaîne de proxies, bien qu'il faille faire attention à éviter d'introduire des boucles.

Le scénario suivant illustre une communication proxy RADIUS entre un NAS et les serveurs RADIUS de transfert et distant:

  1. Un NAS envoie sa demande d'accès au serveur de transfert.

  2. Le serveur de transfert transmet la demande d'accès au serveur distant.

  3. Le serveur distant renvoie un access-accept, access-reject ou access-challenge au serveur de transfert. Pour cet exemple, un access-accept est envoyé.

  4. Le serveur de transfert envoie l'access-accept au NAS.

Le serveur de transfert DOIT traiter tous les attributs Proxy-State déjà présents dans le paquet comme des données opaques. Son fonctionnement NE DOIT PAS dépendre du contenu des attributs Proxy-State ajoutés par des serveurs précédents.

S'il y a des attributs Proxy-State dans la demande reçue du client, le serveur de transfert DOIT inclure ces attributs Proxy-State dans sa réponse au client. Le serveur de transfert PEUT inclure les attributs Proxy-State dans l'access-request lorsqu'il transmet la demande, ou PEUT les omettre dans la demande transférée. Si le serveur de transfert omet les attributs Proxy-State dans l'access-request transféré, il DOIT les attacher à la réponse avant de l'envoyer au client.

Le serveur de transfert PEUT ajouter un attribut Proxy-State à la demande avant de la transmettre. Si le serveur de transfert ajoute un attribut Proxy-State à une demande, il DOIT être placé après tous les autres attributs Proxy-State déjà présents dans le paquet. Le serveur de transfert DOIT s'attendre à ce que l'attribut Proxy-State qu'il a ajouté soit présent dans la réponse et DOIT l'enlever de la réponse avant de la transmettre au client NAS.

Bien que le serveur de transfert PUISSE modifier des attributs (autres que Proxy-State) dans un message qu'il transmet, il ne DEVRAIT pas modifier des attributs dans une réponse à moins de comprendre l'intention de ces attributs et que les règles de politique locale n'exigent leur modification. L'ajout d'un attribut Proxy-State en violation de ce principe pourrait entraîner une défaillance de l'algorithme de retour (fallback) des serveurs de transfert intermédiaires et l'utilisation d'un serveur distant inapproprié.

Si le serveur de transfert ne transmet pas la demande à un serveur distant, alors il DOIT envoyer une réponse appropriée au client NAS.