Bonnes pratiques concernant la persistance de session RADIUS

Persistance de la session

Lorsque vous déployez l'agent du serveur RADIUS Okta avec un équilibreur de charge, Okta préconise l'utilisation de la persistance de session (autrement appelée « affinité de session »). La persistance de la session est importante lorsque l'entrée utilisateur pour les demandes de facteurs est gérée de manière asynchrone. Les demandes multifactorielles asynchrones génèrent plusieurs requêtes ou une duplication des requêtes (p. ex. lors de l'utilisation d'Okta Verify avec les notifications Push).

L'agent du serveur RADIUS Okta gère plusieurs requêtes en provenance du client RADIUS d'origine. Toutefois, si les requêtes sont réparties entre plusieurs agents en raison d'un manque de persistance dans la session, elles sont gérées uniquement du côté d'Okta. Cela provoque une charge inutile à la fois pour les agents du serveur RADIUS et pour le service Okta. Cette charge superflue est également prise en compte dans le débit maximal du service Okta.

Afin d'optimiser les performances, basez la persistance de la session sur le client VPN ou l'adresse IP de l'utilisateur final. La configuration recommandée pour la persistance de la session consiste à utiliser Calling-Station-ID en association avec la valeur de Framed-IP. Pour la plupart des VPN, Calling-Station-ID est l'adresse IP du client d'origine.

Si vous utilisez un autre attribut RADIUS pour stocker les adresses IP du client, configurez l'équilibreur de charge de manière à ce qu'il utilise cet attribut.

Inconvénients et limites

Bien qu'Okta recommande l'utilisation d'un équilibreur de charge pour une disponibilité élevée et une mise à l'échelle horizontale, il est possible de déployer l'agent du serveur RADIUS derrière un équilibreur de charge sans persistance de session. L'utilisation de l'équilibrage de charge sans la persistance de session renonce à l'avantage fourni par l'agent du serveur RADIUS (à savoir la réduction des doublons de requêtes).

RADIUS utilise le protocole UDP sans connexion. La plupart des clients renvoient les requêtes à un intervalle périodique jusqu'à la réception d'une réponse en provenance de l'agent du serveur RADIUS. Si ces tentatives sont envoyées vers différents agents du serveur RADIUS, alors chaque agent tente simultanément de formuler la requête. Le premier à recevoir une réponse d'Okta répond au client, pendant que les autres agents assurent uniquement une gestion de tâche ordinaire.

En général, le premier agent du serveur RADIUS à recevoir une nouvelle requête est le premier à y répondre, car cet agent procède à l'appel et reçoit la réponse avant que le client ne génère de requête de nouvelle tentative. Toutefois, lors de l'utilisation d'Okta Verify avec facteur par notification Push, l'agent du serveur RADIUS qui reçoit la requête sonde Okta jusqu'à ce que l'utilisateur confirme ou rejette la demande. Au cours de cette période, le client RADIUS est susceptible d'envoyer de nouvelles tentatives pour la même requête. Dans ce scénario, où les requêtes sont envoyées au même agent du serveur RADIUS, l'agent reconnaît les doublons et les supprime.

Cependant, si une nouvelle tentative est acheminée vers un autre agent du serveur RADIUS, cet agent traite la requête comme une nouvelle requête et renvoie la notification Push. Pour minimiser les effets de ce comportement, Okta vous recommande de définir l'intervalle des nouvelles tentatives du client RADIUS sur 30 secondes ou plus lors du déploiement de l'environnement à charge équilibrée sans persistance de session. Cette approche permet à l'utilisateur final de recevoir la notification et d'y répondre avant que le client RADIUS initie de nouvelles tentatives. Faute de persistance de session au niveau de l'équilibreur de charge, un agent du serveur RADIUS est susceptible d'enregistrer des retards en raison d'une vaste file d'attente de requêtes. Cela peut provoquer une condition de concurrence.

Les conditions de concurrence peuvent aussi survenir si trop peu de threads de travail sont configurés pour l'agent ou si tous les threads sont utilisés par des requêtes à exécution longue. Les requêtes à exécution longue peuvent provenir d'une opération Okta Verify avec notification Push en attente car la réponse du service Okta est trop lente. Le service Okta doit pouvoir accéder à l'Active Directory Agent local afin d'authentifier l'utilisateur. Les nouvelles tentatives constituent un problème ici, car si l'équilibrage des charges les renvoie vers d'autres agents, leur gestion dépend du premier agent qui traitera la requête. Bien qu'il s'agisse généralement d'un scénario sûr, quel que soit l'agent qui renvoie un résultat, ces conditions de concurrence rendent le débogage du système difficile.