Zuul - Authentification de passerelle Api
Je veux présenter Zuul via Spring Cloud en tant que passerelle API devant quelques services.
J'ai des doutes quant à la conception de l'authentification. L'authentification serait gérée par Spring Security, qui précède Zuul dans la chaîne de filtrage des servlets.
Ma préoccupation:
la passerelle serait assis devant de nombreux services
certains services peuvent exposer des points de terminaison qui ne nécessitent pas d'authentification
certains services peuvent exposer des points de terminaison qui ont besoin d'un identifiant de session et d'autres avec un jeton ", une valeur opaque arbitraire (par exemple en téléchargeant un fichier si vous connaissez une URL" difficile à deviner "). Dans l'API Gateway/Spring Security, vous pouvez configurer tous les points de terminaison avec leurs exigences d'authentification spécifiques.
En termes de gestion de la passerelle API:
- comment appliquez-vous les équipes de service réelles pour fournir les paramètres requis par service en aval?
- comment autorisez-vous des changements fréquents des paramètres d'authentification dans la passerelle (selon les besoins du service) sans avoir à arrêter la passerelle entière?
Merci, Adrian
Nous utilisons Spring Session pour répliquer la session sur tous nos services situés derrière un serveur Zuul Edge. Zuul authentifie l'utilisateur qui remplit les informations d'identification des utilisateurs et insère l'utilisateur authentifié dans la session. Il est ensuite répliqué sur tous les services et chaque service est responsable de ses propres règles et paramètres de sécurité. Donc vraiment, tout ce que Zuul fait, c'est rechercher l'utilisateur dans la sécurité du printemps et les services sur le backend appliquent les règles de sécurité telles qu'elles s'appliquent à leurs besoins. De cette façon, vous pouvez modifier chaque service indépendamment en faisant de la passerelle un proxy stupide.
Un bon exemple de cela est dans le didacticiel de Dave Syers sur Spring Security et une Angular JS app . J'ai également posté ne autre question liée à cette qui contenait également un exemple de la façon dont nous procédons, ce qui pourrait être utile.
- la passerelle serait assis devant de nombreux services
Quelle est la préoccupation ici?
- certains services peuvent exposer des points de terminaison qui ne nécessitent pas d'authentification
Spring Security a une règle d'accès permitAll()
- certains services peuvent exposer des points de terminaison qui ont besoin d'un identifiant de session et certains avec un jeton ", une valeur opaque arbitraire (par exemple en téléchargeant un fichier si vous connaissez une URL" difficile à deviner "). Dans l'API Gateway/Spring Security, vous pouvez configurer tous les points de terminaison avec leurs exigences d'authentification spécifiques.
Votre proxy Zuul peut avoir des sessions. Si vous utilisez Spring Security OAuth 2.0, vous pouvez utiliser ResourceServerSecurityConfigurer#stateless(false) et activer des sessions avec HttpSecurity#sessionManagement().sessionCreationPolicy(...) pour créer des sessions chaque fois que vous recevez un jeton d'accès valide. A Le cookie JSESSIONID sera placé dans la réponse HTTP.
- comment appliquez-vous les équipes de service réelles pour fournir les paramètres requis par service en aval?
Je ne suis pas sûr de comprendre la question ici, ne voulez-vous pas appliquer des contraintes de sécurité au niveau de la passerelle API (proxy zuul)? ou essayez-vous d'avoir des "doubles vérifications de sécurité" sur le proxy ET l'application cible?
- comment autorisez-vous des changements fréquents des paramètres d'authentification dans la passerelle (selon les besoins du service) sans avoir à arrêter la passerelle entière?
Zuul vous permet d'ajouter dynamiquement ZuulRoutes au moment de l'exécution, si vous l'utilisez comme bibliothèque autonome. Enveloppé dans Spring Security, dont le contexte est initialisé une fois au démarrage ... Je doute que vous puissiez facilement modifier la configuration de sécurité au moment de l'exécution.
MODIFIER les précisions du PO dans les commentaires : Si vos équipes doivent être responsables de leurs règles de sécurité, avoir un centralisé = la passerelle est une contradiction par conception.
Mon interprétation de la philosophie du microservice est que chaque application est autonome, et en charge de sa portée fonctionnelle complète, et le contrôle de sécurité/accès en fait partie. Vous pouvez facilement vérifier les jetons au niveau de l'application (en appelant le serveur d'autorisation ou en utilisant des JWT), chaque application définissant l'étendue requise pour chaque ressource. Spring Cloud a déjà un démarreur OAuth 2. , ou vous pouvez facilement en créer un si vous utilisez Spring Boot "ordinaire".
De cette façon, vous pouvez déployer des applications individuelles où vous le souhaitez (cloud public ou serveurs sur site), sans avoir à compter sur des composants en amont pour la sécurité ou synchroniser vos déploiements de configuration de passerelle avec d'autres équipes.
La chose API Gateway est une tentation facile, mais ne négligez pas les risques et les contraintes:
- Vous ne pourrez pas sécuriser les appels internes
- Vous devrez vous fier aux composants réseau en amont et tenir pour acquis la contribution de vos applications
- Les règles de contrôle d'accès avancées peuvent devenir un casse-tête: comment obtenir les autorisations individuelles de l'utilisateur, etc.
- Vous devrez synchroniser les changements de configuration avec les autres équipes