Composants
Access Gateway dispose d'un grand nombre de composants et de niveaux d'architecture. Le diagramme suivant présente une vue d'ensemble détaillée de l'architecture d'Access Gateway, ainsi que les ports et protocoles utilisés.
Niveau supérieur
Le niveau supérieur contient l'accès à Internet traditionnel, généralement exposé à l'aide d'un équilibreur de charge. Les utilisateurs accèdent à l'équilibreur de charge via des URL spécifiques à chaque application. Ces URL les dirigent ensuite vers un nœud travailleur Access Gateway dans un cluster haute disponibilité.
Niveau intermédiaire
Le niveau intermédiaire contient le cluster,Access Gateway exécuté au sein d'un environnement virtuel comme Amazon EC2, Microsoft Azure, VMWare, etc. Un cluster Access Gateway se composé des éléments suivants :
La configuration suivante est la configuration minimale recommandée pour un cluster Access Gateway haute disponibilité.
- Un équilibreur de charge visible depuis l'Internet externe et le cluster Access Gateway.
- Un nœud administrateur qui gère toutes les définitions d'application et prend en charge les infrastructures telles que les banques de données et d'autres configurations.
- Trois nœuds travailleurs ou plus qui gèrent toutes les requêtes d'applications, interagissent avec un Tenant Okta à des fins d'autorisation, fournissent des contrôles d'accès granulaires et d'autres comportements. Si Access Gateway peut fonctionner avec moins de trois nœuds travailleur, pour la haute disponibilité, la taille de cluster recommandée est de trois (plus un nœud administrateur).
Le cluster Access Gateway se trouve généralement derrière un pare-feu et est uniquement accessible au Tenant Okta, à l'équilibreur de charge, aux services de support et aux ressources d'applications Web protégées sous-jacentes. En outre, Access Gateway doit également pouvoir accéder à certains sites bien définis, tels que :
-
www.okta.com: utilisé pour la configuration initiale et les tests du réseau. -
yum.oag.okta.com: utilisé pour la mise à niveau d'Access Gateway. - Autres ports, le cas échéant pour les accès DNS, Kerberos et Syslog.
Les administrateurs doivent pouvoir accéder à la console de gestion de ligne de commande en utilisant Secure Shell (SSH) sur le port 22, et à l'Admin Console en HTTPS sur le port 443. Généralement, ces outils sont exclusivement utilisés par les administrateurs à l'intérieur du pare-feu. Veillez à ne pas ouvrir le port 22 à l'extérieur du pare-feu.
Lorsque vous configurez pour la première fois un cluster à haute disponibilité, les membres du cluster communiquent via le protocole HTTPS sur le port 443. Faites preuve de vigilance quand vous configurez une haute disponibilité où des proxys sont utilisés. Consultez Référence de la console de gestion en ligne de commande pour obtenir des informations sur la configuration des proxys et des listes de contournement de proxy.
Niveau de l'application
Les applications Web protégées, qui s'exécutent généralement dans un centre de données client, représentent le niveau le plus bas de l'architecture. Ces applications doivent être accessibles à Access Gateway, mais ne doivent pas être accessibles au monde externe. La séparation des applications s'effectue généralement à l'aide d'un mécanisme de DNS divisé où les ressources internes, telles que les applications Web protégées, les bases de données et d'autres types de support indispensables, sont visibles uniquement par Access Gateway et les ressources nécessaires du centre de données. En outre, un pare-feu sépare généralement Access Gateway de l'équilibreur de charge au niveau de l'application. Access Gateway prend en charge l'utilisation d'interfaces réseau supplémentaires, qui peuvent être utilisées pour séparer les différents aspects du trafic du centre de données vers Access Gateway.
Rubriques connexes
À propos des équilibreurs de charge
À propos des interfaces réseau
À propos des banques de données d'application