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

Pour faciliter la tâche des employés, de nombreuses organisations ont développé des applications permettant d'utiliser Kerberos. Cela peut également être appelé SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism, ou Kerberos sur HTTPS), authentification intégrée Windows, ou encore authentification Windows Desktop ou SSO Windows. Cela permet à un employé connecté à son bureau Windows d'accéder facilement à une application sans avoir à saisir ses identifiants Active Directory (AD). De nombreuses autres applications tierces, de Microsoft et d'autres fournisseurs, ont également adapté leurs solutions afin d'utiliser Kerberos pour l'authentification. Bien que cela ait très bien fonctionné pendant de nombreuses années, les utilisateurs sont beaucoup plus mobiles dans les tâches actuelles. Ils utilisent divers appareils et emplacements, et ne sont pas toujours connectés à un appareil Windows connecté à un domaine AD. Access Gateway peut être utilisé pour combler le fossé entre la main-d'œuvre mobile moderne et ces applications construites autour de l'authentification Windows. Dans ce scénario, Okta connecte d'abord l'utilisateur, éventuellement en utilisant ses identifiants AD ou un jeton MFA, puis l'utilisateur accède via Access Gateway à l'application conçue pour l'authentification Kerberos Windows. Access Gateway contacte un cluster Kerberos Windows et, grâce à une approbation établie, peut demander au cluster Kerberos Windows de créer un jeton pour l'utilisateur, puis insérer ce jeton dans les en-têtes HTTP qui sont transmis à l'application. Le résultat est que l'application voit le jeton et identifie l'utilisateur, et l'application n'a pas besoin d'être modifiée lors de son ajout derrière Okta. De plus, les utilisateurs peuvent désormais accéder à cette application en utilisant des appareils non joints à un domaine, y compris des navigateurs mobiles. Si Access Gateway est déployé dans la DMZ et est accessible publiquement, ces utilisateurs n'ont pas besoin d'un VPN dans le réseau pour accéder à l'application.

Approche

Pour déployer Access Gateway sur des applications sécurisées dans un environnement décrit ci-dessus, il est préférable de commencer le déploiement d'une architecture de base, puis d'ajouter des fonctionnalités spécifiques selon les besoins. Cette méthodologie permettra à une organisation de commencer à avancer de manière agile et de ne pas s'enliser dans l'analyse des exigences. Les étapes clés pour déterminer une architecture globale sont les suivantes :

• Identifier comment les applications doivent être intégrées à Okta et à Access Gateway. les intégrations classiques incluent :
  • Application Kerberos/Windows IIS unique
  • Basé sur l'en-tête
  • SAML
  • Autres
• Identifiez le nombre d'utilisateurs qui accèdent aux applications et à quelle fréquence. Cela aidera à déterminer le nombre d'instances Access Gateway requises, le nombre d'équilibreurs de charge nécessaires et la manière dont les composants de l'architecture seront distribués en général.
• Identifier les applications qui doivent être accessibles via Access Gateway depuis Internet et celles qui doivent nécessiter que l'utilisateur ait accès au réseau interne. Généralement, il s'agit au début d'un sous-ensemble d'applications, qui se développe avec le temps.
• Identifiez et travaillez avec l'équipe AD pour obtenir les comptes système et les approbations/fichiers keytabs appropriés.
• Identifiez l'ensemble des infrastructures AD pour déterminer les connexions de Access Gateway à AD et à l'infrastructure de tickets Kerberos Windows.

Architectures Kerberos Access Gateway

Les installations Kerberos Access Gateway peuvent être déployées selon un nombre illimité de combinaisons possibles. Les architectures courantes sont les suivantes :

Décomposition des zones fonctionnelles de l'architecture