Architecture de référence des applications CIAM en cluster unique
Le cluster unique Access Gateway est une architecture qui représente les composants nécessaires à la protection de ressources Web uniques à l'aide d'Access Gateway. Elle étend l'architecture simple de l'instance Access Gateway en introduisant un cluster Access Gateway.
Cette architecture est conçue pour répondre aux exigences suivantes :
- Accès sécurisé à une application – Accessible depuis l'Internet externe.
- 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 |
|---|---|
|
|
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 |
| 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 | ||
| 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. |
|
| É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. |
|
| Access Gateway | L'instance Access Gateway, située dans la DMZ, est utilisée pour fournir un accès aux applications utilisées par des clients Internet externes. Il est généralement hébergé dans un environnement virtuel comme Amazon Web Services, MS Azure, Oracle OCI, etc. Consultez Gérer le déploiement Access Gateway. |
|
| Équilibreur de charge des application internes | Équilibre la charge entre le cluster Access Gateway et les applications protégées. Consultez À propos de l'équilibrage de charge Access Gateway. | |
comsumer-app1.example.com |
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.