Architectures de déploiement d’applications proxy

L’orchestrateur d’identité Maverics est conçu pour permettre de résoudre un éventail de problèmes liés à l’identité, et peut donc être déployé selon différents modèles afin de solutionner au mieux le problème en question. Cet article détaille les architectures de déploiement les plus courantes, ainsi que les avantages et les inconvénients qui leur sont propres.

Réserve centrale

Avec ce modèle de déploiement, une réserve centralisée d’instances d’orchestrateurs est utilisée pour protéger les applications. Ce modèle est bien adapté aux équipes qui sont en mesure d’apporter des modifications au réseau et qui préfèrent éviter d’être en contact régulier avec les équipes chargées de l’application.

Avantages

• Gestion centralisée de la configuration.
• Le propriétaire de l’application est très peu sollicité.
• Empreinte contenue des orchestrateurs.

Inconvénients

• Les applications sont susceptibles de faire l’objet d’un trafic latéral, à moins que des mesures d’atténuation ne soient mises en place.
• Modifications du réseau nécessaires.
• Temps de latence supplémentaire, bien que le delta soit généralement inférieur à une seconde.

Proxy local

Le modèle de proxy local place l’orchestrateur sur le même hôte que l’application. Ce modèle est bien adapté aux applications basées sur des en-têtes, ou aux équipes chargées des applications qui contrôlent le flux d’authentification de leurs applications.

Avantages

• Aucune infrastructure supplémentaire n’est requise.
• Aucune modification du réseau n’est nécessaire.
• Impact minime sur les performances de l’application.

Inconvénients

• Le propriétaire de l’application est sollicité.
• Charge supplémentaire sur les serveurs d’application existants.
• Certaines modifications du serveur Web sont nécessaires.

RP-IDP

L’architecture RP-IDP combine le modèle de « proxy local » (parties utilisatrices) avec une réservce d’orchestrateur(s) agissant en tant que fournisseurs d’identité. Ce modèle est particulièrement bien adapté aux administrateurs qui souhaitent remplacer une solution de gestion de l’accès au web telle que SiteMinder ou Oracle Access Manager, mais peut également être utilisé avec succès dans de nombreux cas de figure.

Avantages

• Gestion centralisée de la configuration.
• Aucune modification du réseau n’est nécessaire.
• Architecture éprouvée.

Inconvénients

• Le propriétaire de l’application doit être impliqué dans une certaine mesure.
• Charge supplémentaire sur les serveurs d’application existants.
• Certaines modifications du serveur Web sont nécessaires.