Zuul - Passerelle Api D'Authentification
je veux présenter Zuul à travers Spring Cloud comme une passerelle API devant quelques services.
j'ai quelques doutes quant à la conception de L'authentification. L'authentification serait gérée par Spring Security, qui passe avant Zuul dans la chaîne servlet filter.
Mon inquiétude:
-
la Passerelle serait de s'asseoir en face de beaucoup de services
-
certains services peut exposer des paramètres qui ne nécessitent pas d'authentification
-
certains services peuvent exposer des points terminaux qui ont besoin d'un ID de Session et d'autres avec un token", une valeur opaque arbitraire (par exemple télécharger un fichier si vous connaissez une url" difficile à deviner")) Dans la sécurité API Gateway / Spring, vous pouvez configurer tous les endpoints avec leurs exigences d'authentification spécifiques.
en termes de gestion de la passerelle API:
- comment faire respecter les équipes de Service actuelles pour fournir les paramètres requis par service en aval?
- comment autoriser des modifications fréquentes des paramètres D'authentification dans la passerelle (selon les besoins de service) sans devoir arrêter toute la passerelle?
Merci, Adrian
2 réponses
nous utilisons session de printemps pour répliquer la session sur tous nos services qui se trouvent derrière un serveur Zuul Edge. Zuul authentifiera l'utilisateur qui peuplera les informations d'identification de l'utilisateur et insérera l'utilisateur authentifié dans la session. Cela est ensuite reproduit dans tous les services et chaque service est responsable de ses propres règles et paramètres de sécurité. Donc, tout ce que Zuul fait, c'est chercher l'utilisateur dans la sécurité du printemps et les services sur le backend font les règles de sécurité qu'ils appliquent à leurs besoins. De cette façon, vous pouvez changer chaque service indépendamment faisant de la passerelle juste un mandataire muet.
un bon exemple de ceci est dans le tutoriel de Dave Syers sur sécurité de ressort et une application JS angulaire . J'ai aussi posté une autre question liée à ceci qui contenait un échantillon de comment nous faisons ceci aussi bien qui pourrait aider.
- la Passerelle serait de s'asseoir en face de beaucoup de services
Quelle est la préoccupation ici ?
- certains services peuvent révéler des paramètres qui ne nécessitent pas d'authentification
Printemps de Sécurité a un permitAll() règle d'accès
- certains services peuvent exposer des paramètres qui ont besoin D'un ID de Session et certains avec un token", une valeur opaque arbitraire (par exemple télécharger un fichier si vous connaissez une url "difficile à deviner" dans L'API passerelle / printemps Sécurité Vous pouvez configurer tous les paramètres avec leur exigences d'authentification.
votre mandataire Zuul peut avoir des sessions. Si vous utilisez Spring Security OAuth 2.0, vous pouvez utiliser ResourceServerSecurityConfigurer#stateless(false) et activer les sessions avec HttpSecurity#sessionManagement().sessionCreationPolicy(...) pour créer des sessions. chaque fois que vous recevez un jeton d'accès valide. Un Cookie JSESSIONID sera placé dans la réponse HTTP.
- comment renforcer les équipes de Service actuelles 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 imposer des contraintes de sécurité au niveau de la passerelle API (Zuul proxy)? ou essayez-vous d'avoir "la sécurité à double contrôle" à la fois sur l'Application proxy et target?
- comment autoriser des modifications fréquentes des paramètres D'authentification dans la passerelle (selon les besoins du service) sans devoir arrêter toute la passerelle?
Zuul vous permet d'ajouter des ZuulRoute s dynamiquement à l'exécution, si vous l'utilisez comme une bibliothèque autonome qui est. Enveloppé dans une sécurité de printemps, dont le contexte est initialisé une fois au démarrage... Je doute que vous peut facilement modifier la configuration de sécurité à l'exécution.
modifier les précisions suivantes par L'OP dans les commentaires : si vos équipes devraient être responsables de leurs règles de sécurité, avoir une passerelle centralisée est une contradiction de conception.
mon interprétation de la philosophie de microservice est que chaque application est autonome, et en charge de sa pleine portée fonctionnelle, et la sécurité / accès le contrôle est partie. Vous pouvez facilement vérifier les tokens au niveau de l'application (en faisant un appel au serveur d'autorisation ou en utilisant JWTs), chaque application définissant le champ requis pour chaque ressource. Spring Cloud dispose déjà d'un démarreur OAuth 2.0 , ou vous pouvez facilement en créer un si vous utilisez une botte à ressort" simple".
de cette façon, vous pouvez déployer des applications individuelles où vous voulez (cloud public ou serveurs sur site), sans avoir compter sur des composants amont pour la sécurité ou synchroniser vos déploiements de configuration de passerelle avec d'autres équipes.
La Passerelle API chose est une tentation facile, mais ne négligez pas les risques et les contraintes :
- Vous ne serez pas en mesure de sécuriser les appels internes
- vous devrez vous fier aux composants du réseau amont, et prendre pour acquis l'entrée de vos applications
- contrôle D'accès avancé les règles peuvent devenir un casse-tête : comment obtenir les permissions individuelles de l'utilisateur, etc
- vous devrez synchroniser les changements de configuration avec les autres équipes