2. Operation
2. Operation (Fonctionnement)
Lorsqu'un client est configuré pour utiliser RADIUS, tout utilisateur du client présente des informations d'authentification au client. Cela peut se faire avec une invite de connexion personnalisable, où l'utilisateur est censé entrer son nom d'utilisateur et son mot de passe. Alternativement, l'utilisateur peut utiliser un protocole de tramage de liaison tel que le Point-to-Point Protocol (PPP), qui possède des paquets d'authentification qui transportent ces informations.
Une fois que le client a obtenu de telles informations, il peut choisir de s'authentifier en utilisant RADIUS. Pour ce faire, le client crée un "Access-Request" contenant des attributs tels que le nom de l'utilisateur, le mot de passe de l'utilisateur, l'ID du client et l'ID de port auquel l'utilisateur accède. Lorsqu'un mot de passe est présent, il est masqué en utilisant une méthode basée sur l'algorithme de condensé de message RSA MD5 [3].
L'Access-Request est soumis au serveur RADIUS via le réseau. Si aucune réponse n'est retournée dans un délai donné, la demande est renvoyée un certain nombre de fois. Le client peut également transférer les demandes à un ou plusieurs serveurs alternatifs dans le cas où le serveur principal est hors service ou inaccessible. Un serveur alternatif peut être utilisé soit après qu'un certain nombre de tentatives au serveur principal ont échoué, soit de manière circulaire (round-robin). Les algorithmes de nouvelle tentative et de basculement sont un sujet de recherche actuel et ne sont pas spécifiés en détail dans ce document.
Une fois que le serveur RADIUS reçoit la demande, il valide le client émetteur. Une demande d'un client pour lequel le serveur RADIUS n'a pas de secret partagé DOIT être rejetée silencieusement. Si le client est valide, le serveur RADIUS consulte une base de données d'utilisateurs pour trouver l'utilisateur dont le nom correspond à la demande. L'entrée utilisateur dans la base de données contient une liste d'exigences qui doivent être satisfaites pour permettre l'accès à l'utilisateur. Cela inclut toujours la vérification du mot de passe, mais peut également spécifier le(s) client(s) ou le(s) port(s) auxquels l'utilisateur est autorisé à accéder.
Le serveur RADIUS PEUT faire des demandes à d'autres serveurs afin de satisfaire la demande, auquel cas il agit en tant que client.
Si des attributs Proxy-State étaient présents dans l'Access-Request, ils DOIVENT être copiés non modifiés et dans l'ordre dans le paquet de réponse. D'autres attributs peuvent être placés avant, après ou même entre les attributs Proxy-State.
Si une condition n'est pas satisfaite, le serveur RADIUS envoie une réponse "Access-Reject" indiquant que cette demande d'utilisateur est invalide. Si désiré, le serveur PEUT inclure un message texte dans l'Access-Reject qui PEUT être affiché par le client à l'utilisateur. Aucun autre attribut (sauf Proxy-State) n'est autorisé dans un Access-Reject.
Si toutes les conditions sont satisfaites et que le serveur RADIUS souhaite émettre un défi auquel l'utilisateur doit répondre, le serveur RADIUS envoie une réponse "Access-Challenge". Il PEUT inclure un message texte à afficher par le client à l'utilisateur pour demander une réponse au défi, et PEUT inclure un attribut State.
Si le client reçoit un Access-Challenge et prend en charge challenge/response, il PEUT afficher le message texte, s'il y en a un, à l'utilisateur, puis inviter l'utilisateur à donner une réponse. Le client soumet alors à nouveau son Access-Request original avec un nouvel ID de demande, avec l'attribut User-Password remplacé par la réponse (chiffrée), et incluant l'attribut State de l'Access-Challenge, s'il y en a un. Seules 0 ou 1 instances de l'attribut State DEVRAIENT être présentes dans une demande. Le serveur peut répondre à ce nouvel Access-Request avec soit un Access-Accept, un Access-Reject, ou un autre Access-Challenge.
Si toutes les conditions sont satisfaites, la liste des valeurs de configuration pour l'utilisateur est placée dans une réponse "Access-Accept". Ces valeurs incluent le type de service (par exemple: SLIP, PPP, Login User) et toutes les valeurs nécessaires pour fournir le service souhaité. Pour SLIP et PPP, cela peut inclure des valeurs telles que l'adresse IP, le masque de sous-réseau, le MTU, la compression souhaitée et les identifiants de filtre de paquets souhaités. Pour les utilisateurs en mode caractère, cela peut inclure des valeurs telles que le protocole et l'hôte souhaités.