Architecture de référence d'une application Kerberos en cluster

L'architecture Access Gateway de cluster Kerberos représente un ensemble de composants nécessaires à l'authentification et à l'autorisation basées sur Kerberos avec Access Gateway et un cluster Kerberos redondant. Cette architecture représente un environnement qui offre une tolérance aux pannes à la fois pour Access Gateway et pour Kerberos.

Cette architecture est conçue pour répondre aux exigences suivantes :

Protéger un service basé sur Kerberos (Windows IIS).
Répondre aux besoins de base de la tolérance aux pannes et de la haute disponibilité pour Access Gateway
Respecter la tolérance de panne de base et la haute disponibilité pour le domaine Kerberos et le centre de distribution de clés (KDC).

Avantages et inconvénients

Avantages	Inconvénients
Peut être utilisé pour remplacer un VPN. 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 de la capacité. Charge équilibrée L'accès à l'instance administrateur se fait derrière le pare-feu. Le domaine Kerberos et le KDC sont tous les deux tolérants aux pannes et redondants.	Domaine Access Gateway complexe. Domaine Kerberos plus complexe. L'équilibreur de charge situé dans la DMZ, en amont d'Access Gateway doit prendre en charge l'affinité de session (sessions persistantes).

Avantages

Inconvénients

Peut être utilisé pour remplacer un VPN.
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 de la capacité.
Charge équilibrée
L'accès à l'instance administrateur se fait derrière le pare-feu.
Le domaine Kerberos et le KDC sont tous les deux tolérants aux pannes et redondants.

Domaine Access Gateway complexe.
Domaine Kerberos plus complexe.
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	Clients Web	Le navigateur client traditionnel accède à Access Gateway en utilisant les URL connues sous le nom de `[appN\|consumer-app1].example.com`.
	URL `consumer-app1.example.com` non affichées	URL représentant l'application qu'un client Web externe saisirait 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.
	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.
DMZ	Équilibreur de charge en amont d'Access Gateway.	Pré-équilibreur de charge Équilibre la charge entre les clients et le cluster. Positionné entre les clients et le cluster.
DMZ	Access Gateway	Le cluster Access Gateway, situé dans la DMZ, est utilisé pour fournir un accès aux applications utilisées par des clients Internet externes. Contient un service Kerberos et un fichier keytab. Consultez Créer un fichier keytab pour en savoir plus sur la création d'un fichier keytab. Consultez la section Ajouter un service Kerberos pour obtenir plus d'informations sur la définition d'un service Access Gateway Kerberos. 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.
Pare-feu	DMZ vers pare-feu interne	Pare-feu traditionnel entre la DMZ et le réseau interne.
Réseau interne	Service/application protégée	L'ensemble des ressources Web protégées, dans ce cas les services Microsoft, accessibles à l'aide des URL `consumer-app1.internal-example.com`. Versions prises en charge : Microsoft IIS IWA : IIS 7 ou version ultérieure. Microsoft OWA IWA : IIS 7 ou version ultérieure.
	Pré-équilibrage de charge du domaine Kerberos interne	Équilibreur de charge pour le cluster de services du domaine Kerberos.
	Cluster de services du domaine Microsoft avec le centre de distribution de clés (KDC)	Cluster de services du domaine contenant un centre de distribution de clés (KDC). Dans cette architecture, le service de domaine/KDC représente plusieurs instances agissant en tant que cluster.

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.

De plus, Access Gateway lui-même est généralement géré via un accès interne uniquement. En d'autres termes, les administrateurs accès généralement à Access Gateway lui-même derrière le pare-feu. Ceci est illustré dans d'autres architectures.