Architectures de déploiement RADIUS

Les sections suivantes décrivent les architectures de déploiement RADIUS généralement recommandées.

Basculement actif-passif derrière un VPN comme Cisco ASA

Il s'agit du modèle de déploiement le plus simple. Il est suffisant pour les environnements qui n'ont pas de besoins particuliers en matière de haut débit par rapport à ce qu'un agent du serveur RADIUS Okta actif unique peut fournir.

Avec cette approche, configurez un agent du serveur RADIUS Okta en tant que serveur actif sur l'appareil VPN, ainsi qu'un autre serveur RADIUS Okta pour le basculement passif. Le débit total est plafonné selon les performances d'un agent du serveur RADIUS Okta unique.

Actif-actif derrière un équilibreur de charges (haut débit)

Certains exemples et termes où F5 est l'équilibreur de charge pour le client VPN Cisco ASA.

Pour un débit et une disponibilité accrus, nous vous recommandons de déployer deux ou plusieurs agents du serveur RADIUS Okta derrière votre équilibreur de charge. Cette approche permet une mise à l'échelle horizontale grâce à l'ajout d'agents du serveur RADIUS supplémentaires au pool d'équilibrage de charge et à la distribution homogène du volume de trafic entre eux. Le nombre d'agents du serveur RADIUS dépendra du volume anticipé ainsi que des transactions maximales par minute.

• Réseaux virtuels

  Configurez un serveur virtuel distinct pour chaque appareil qui envoie des requêtes à RADIUS. Créez un pool de serveurs distinct pour chaque serveur virtuel.

• Persistance de la session

  L'équilibrage de charge doit être effectué à l'aide de la persistance de la session (sessions permanentes) en fonction du client VPN ou de l'IP de l'utilisateur final afin d'optimiser les performances. Ceci est particulièrement important dans les situations où l'attente de l'entrée utilisateur pour une vérification par 2 facteurs d'authentification se fait hors bande (par exemple, Okta Verify avec push). L'agent du serveur RADIUS Okta gère la duplication des requêtes en provenance du client RADIUS d'origine. Toutefois, si elles sont réparties entre plusieurs agents, les duplications sont résolues côté service Okta, ce qui occasionne une charge superflue.

  La configuration recommandée pour l'adhérence correspond généralement à l'utilisation de Calling-Station-ID avec Framed-IP. Pour de nombreux VPN, Calling-Station-ID correspond à l'adresse IP du client d'origine. Si un autre attribut RADIUS conserve l'adresse IP du client, alors configurez l'équilibreur de charge de manière à utiliser l'attribut en question.

• Méthode d'équilibrage de charge

  Nous vous recommandons d'utiliser le paramétrage de la méthode d'équilibrage de charge qui correspond à Least Connections (Le moins de connexions), le cas échéant, afin de répartir la charge sur les agents du serveur RADIUS actifs.

• Contrôle d'intégrité

  Utilisez la fonction de contrôle d'intégrité de l'équilibreur de charge avec des identifiants synthétiques pour garantir un basculement direct qui aura peu d'impact sur l'utilisateur en cas de problème sur l'agent du serveur RADIUS. Chaque serveur virtuel doit disposer de son propre contrôle d'intégrité sur son port respectif. Pour configurer votre équilibreur de charge ou votre client RADIUS de manière à ce qu'il effectue des contrôles d'intégrité, créez un compte utilisateur qui ne sera utilisé qu'à cette fin. Okta recommande de procéder comme suit :

  1. Créez un compte utilisateur basique pour un utilisateur qui n'est affecté à aucun groupe, qui n'a accès à aucune application et qui ne dispose d'aucun privilège.
  2. Créez un mot de passe unique fort pour le compte utilisateur du contrôle d'intégrité.

     Remarque : le mot de passe et le nom d'utilisateur ne peuvent pas contenir le caractère dièse (#)

  3. Créez une application RADIUS personnalisée pour le triage de ce contrôle d'intégrité entrant.
  4. Affectez cet utilisateur à l'application RADIUS (en y permettant donc l'accès).

  Ce compte sert à confirmer que le client RADIUS peut accéder au service Okta et procéder à la demande d'authentification convenablement. En général, les contrôles d'intégrité impliquent uniquement l'authentification principale, car les transactions qui comportent un deuxième facteur nécessitent souvent une entrée utilisateur ou une réponse dynamique.

  Configurez l'équilibreur de charge pour supprimer le serveur RADIUS de la rotation après deux échecs consécutifs. Configurez l'équilibreur de charge pour réintégrer le serveur dans la rotation après une réponse positive de sa part.

• Haute disponibilité de l'équilibreur de charge

  Pour une meilleure disponibilité globale du système, envisagez une configuration redondante du système pour l'équilibreur de charge. Vous éviterez ainsi la présence d'un point de défaillance unique. Veuillez consulter la documentation relative aux fournisseurs d'équilibreur de charge pour obtenir des recommandations.

Pour des recommandations globales concernant F5 pour l'équilibrage de charge RADIUS, veuillez consulter la documentation concernant l'équilibrage de charge avec RADIUS F5. F5 prend en charge un iAPP pour la gestion du volume RADIUS. Cet IAPP prend également en charge les contrôles d'intégrité automatisés par l'intermédiaire de transactions synthétiques afin de garantir que les utilisateurs finaux peuvent s'authentifier.