Une seule connexion dans L'Architecture Microservice
j'essaie de concevoir un projet de champ vert qui aura plusieurs services (servir des données) et des applications web (servir HTML). J'ai lu des articles sur les microservices et ils m'ont l'air bien assortis.
le problème que j'ai encore est comment mettre en œuvre SSO. Je veux que l'utilisateur s'authentifie une fois et ait accès à tous les différents services et applications.
je ne peux penser à plusieurs approches:
-
ajouter Service et application d'identité. Tout service qui dispose de ressources protégées s'adressera au service D'identité pour s'assurer que les justificatifs d'identité qu'il possède sont valides. S'ils ne le sont pas, il redirigera l'utilisateur pour authentification.
-
utilisez une norme Web comme OpenID et demandez à chaque service de gérer ses propres identités. Cela signifie que l'Utilisateur devra autoriser individuellement chaque service/application, mais après cela ce sera SSO.
je serai heureux d'entendre d'autres idées. Si un PaaS spécifique (tel que Heroku) a une solution propriétaire qui serait également acceptable.
2 réponses
lors de la mise en œuvre d'une architecture microservice dans le cadre de mon emploi précédent, nous avons décidé que la meilleure approche était l'harmonisation avec le numéro 1, L'ajout d'un service d'identité et l'autorisation d'accès au service par ce biais. Dans notre cas, cela a été fait avec des jetons. Si une demande était accompagnée d'un token d'autorisation, nous pourrions vérifier ce token avec le service d'identité si c'était le premier appel dans la session de l'utilisateur avec le service. Une fois que le token a été validé, il a été sauvegardé dans la session. la session de l'utilisateur n'a pas à faire l'appel supplémentaire. Vous pouvez également créer un emploi programmé si les tokens doivent être rafraîchis dans cette session.
dans cette situation nous étions en train de nous authentifier avec un terminal OAuth 2.0 et le token a été ajouté à L'en-tête HTTP pour les appels vers notre domaine. Tous les services ont été routés à partir de ce domaine afin que nous puissions obtenir le token à partir de L'en-tête HTTP. Étant donné que nous faisions tous partie du même écosystème d'application, l'autorisation initiale de L'OAuth 2.0 énumérerait les services d'application que l'utilisateur donnerait la permission pour leur compte.
un ajout à cette approche était que le service d'identité fournirait la bibliothèque du client mandataire qui serait ajoutée à la chaîne de filtrage des requêtes HTTP et traiterait le processus d'Autorisation du service. Le service serait configuré pour utiliser la bibliothèque de clients mandataires du service d'identité. Puisque nous utilisions Dropwizard ce proxy deviendrait un Dropwizard Module bootstrapping le filtre dans le processus de service courant. Cela a permis aux mises à jour du service d'identité qui avaient également une mise à jour gratuite côté client d'être facilement consommées par les services dépendants aussi longtemps que l'interface n'a pas changé de manière significative.
notre architecture de déploiement a été étendue à AWS Virtual Private Cloud (VPC) et aux centres de données de notre propre entreprise. Le service d'authentification OAuth 2.0 était situé dans le centre de données de la société tandis que tous nos des services d'application ont été déployés à AWS VPC.
j'espère que l'approche que nous avons adoptée est utile à votre décision. Laissez-moi savoir si vous avez d'autres questions.
Chris Sterling a expliqué la pratique d'authentification standard ci-dessus et cela a un sens absolu. Je veux juste mettre une autre pensée ici pour des raisons pratiques.
nous avons mis en place des services d'authentification et de multiples autres services micro en s'appuyant sur le serveur auth afin d'autoriser des ressources. À un certain moment, nous avons couru à des problèmes de performance en raison de trop nombreux voyages aller-retour vers le serveur d'authentification, nous avons également eu des problèmes d'évolutivité pour le serveur d'auth comme le nombre de micro les services ont augmenté. Nous avons changé l'architecture un peu pour éviter trop de voyages aller-retour.
Auth server ne sera contacté qu'une seule fois avec des informations d'identification et générera le token basé sur une clé privée. La clé publique correspondante sera installée dans chaque client (micro-serveur de service) qui pourra valider la clé d'authentification en contactant le serveur auth. La clé contient le temps généré et un utilitaire client installé dans micro service sera également valide. Même s'il ne s'agissait pas d'une mise en œuvre standard, Ce modèle connaît un assez bon succès, surtout lorsque tous les micro-services sont hébergés en interne.