Architecture de référence des applications CIAM en multi cluster

L'architecture multi-cluster Access Gateway représente les composants nécessaires à la protection de plusieurs ensembles de ressources Web, avec des exigences différentes, à l'aide de Access Gateway. Elle étend l'architecture en cluster unique Access Gateway en utilisant plusieurs clusters Access Gateway répartis dans plusieurs environnements virtuels. Cette architecture est conçue pour répondre aux exigences suivantes :

Accès sécurisé à plusieurs applications – Accessible depuis l'Internet externe.
Fournir une prise en charge pour les applications, avec des conditions de charge diverses et variables, distribuées sur plusieurs zones ou zones géographiques.
Fournir une tolérance aux pannes – Mettre en place des instances supplémentaires d'Access Gateway, en tant que nœuds de travail du cluster, de manière à ce que, si l'un d'entre eux n'est pas disponible, le cluster continue de fonctionner normalement.
Gérer la capacité – Fournir des instances supplémentaires d'Access Gateway pour gérer la charge attendue.

Avantages et inconvénients

Avantages	Inconvénients
Prend en charge plusieurs applications, avec des besoins différents dans plusieurs zones géographiques. Fournit une tolérance de base aux pannes et une prise en charge des capacités Peut être étendu avec des travailleurs supplémentaires si nécessaire pour ajouter une capacité supplémentaire Charge équilibrée	Très complexe Environnements virtuels multiples Nécessite plusieurs équilibreurs de charge L'équilibreur de charge situé dans la DMZ, en amont d'Access Gateway doit prendre en charge l'affinité de session (sessions persistantes).

Architecture

Composants

Emplacement	Composant	Description
Internet externe	Client Web	Le navigateur client traditionnel accède à Access Gateway en utilisant les URL connues sous le nom de `[appN\|consumer-app1].example.com`.
	Org Okta	Votre org Okta, qui fournit des services d'identité.
	Universal Directory Org Okta	Okta Universal Directory, hébergé au sein d'une org Okta, contenant des utilisateurs en dehors des autres implémentations LDAP ou Active Directory. Il s'agit généralement d'autres comptes clients, de comptes partenaires, etc.
Pare-feu	Internet externe vers DMZ	Pare-feu traditionnel entre l'Internet externe et l'hébergement DMZ Access Gateway.
Réseau interne
	Équilibreur de charge en amont d'Access Gateway	Équilibre la charge entre les clients et le cluster Access Gateway. Positionné entre les clients et le cluster Access Gateway.
	Administrateur Access Gateway	Le nœud d'administrateur Access Gateway, dans n'importe quel centre de données qui s'occupe de la configuration, des sauvegardes de configuration, du transfert de journal, etc. Accès par des administrateurs au sein du réseau interne.
	Environnement un Access Gateway	Les instances Access Gateway, situées dans la DMZ, sont utilisées pour servir l'application CIAM 1.
	Environnement deux Access Gateway	Les instances Access Gateway, situées dans la DMZ, sont utilisées pour servir l'application CIAM 2.
	Environnement trois Access Gateway	Les instances Access Gateway situées dans la DMZ utilisées pour servir l'application CIAM 3 et 4. Généralement hébergées dans un environnement virtuel comme Amazon Web Services, MS Azure, Oracle OCI ou un environnement similaire. Consultez Gérer le déploiement Access Gateway.
	Équilibreurs de charge en amont de l'application Access Gateway interne	Access Gateway en tant qu'équilibreur de charge entre le cluster Access Gateway et les applications protégées. Configuré pour chaque application CIAM. Consultez À propos de l'équilibrage de charge Access Gateway.
	consumer-app1.example.com (non affiché)	URL représentant l'une des applications qu'un client Web doit saisir pour accéder à l'une des applications sécurisées par Access Gateway. Généralement, toutes les URL de cette nature sont fournies par l'instance Access Gateway et se résolvent vers cette dernière.
	Application protégée	L'ensemble des ressources Web protégées, accessibles à l'aide des URL `consumer-app1.internal-example.com`. L'application classique ou historique avec laquelle Access Gateway interagit utilise le champ Ressource Web protégée dans chaque définition d'application.

Autres considérations

Le DNS est généralement partagé entre les domaines externes et internes. Toutes les URL externes, telles que [appN|consumer-app1].example.com, seront servies en externe et pointeront vers l'instance Access Gateway. Les URL internes utilisées par Access Gateway, comme [protd-N|consumer-app1].internal-example.com, seront servies par un DNS interne.

La plupart des architectures transfèrent les événements du journal à un composant de journal système externe. Okta recommande fortement qu'un serveur de journalisation soit configuré pour tous les environnements Access Gateway. Consultez Configurer des redirecteurs de journaux.

Cette architecture ne montre pas les centres de données où sont hébergés ses composants.