Authentification unique dans l'architecture de microservice
J'essaie de concevoir un projet sur le terrain qui aura plusieurs services (servant des données) et des applications Web (servant du HTML). J'ai lu des informations sur les microservices et ils semblent bien adaptés.
Le problème que j'ai toujours est de savoir comment implémenter l'authentification unique. Je veux que l'utilisateur s'authentifie une fois et ait accès à tous les différents services et applications.
Je peux penser à plusieurs approches:
Ajoutez le service et l'application d'identité. Tout service qui a des ressources protégées communiquera avec le service d'identité pour s'assurer que les informations d'identification qu'il possède sont valides. S'ils ne le sont pas, il redirigera l'utilisateur pour l'authentification.
Utilisez un standard Web tel que 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.
Lors de la mise en œuvre d'une architecture de microservices lors de mon travail précédent, nous avons décidé que la meilleure approche était en alignement avec le n ° 1, Ajouter un service d'identité et autoriser l'accès au service via celui-ci. Dans notre cas, cela a été fait avec des jetons. Si une demande venait avec un jeton d'autorisation, nous pourrions vérifier ce jeton auprès du service d'identité s'il s'agissait du premier appel dans la session de l'utilisateur avec le service. Une fois le jeton validé, il a été enregistré dans la session afin que les appels suivants dans la session de l'utilisateur n'aient pas à effectuer l'appel supplémentaire. Vous pouvez également créer un travail planifié si les jetons doivent être actualisés au cours de cette session.
Dans cette situation, nous nous authentifions avec un point de terminaison OAuth 2.0 et le jeton 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 jeton Étant donné que nous faisions tous partie du même écosystème d'applications, l'autorisation initiale OAuth 2.0 répertorierait les services d'application que l'utilisateur autoriserait pour son compte.
Un ajout à cette approche était que le service d'identité fournirait la bibliothèque cliente proxy qui serait ajoutée à la chaîne de filtrage des requêtes HTTP et gérerait le processus d'autorisation du service. Le service serait configuré pour consommer la bibliothèque cliente proxy du service d'identité. Puisque nous utilisions Dropwizard, ce proxy deviendrait un module Dropwizard amorçant le filtre dans le processus de service en cours d'exécution. Cela a permis aux mises à jour du service d'identité qui avaient également une mise à jour côté client gratuite d'être facilement consommées par les services dépendants tant que l'interface n'a pas changé de manière significative.
Notre architecture de déploiement était répartie sur AWS Virtual Private Cloud (VPC) et les centres de données de notre propre entreprise. Le service d'authentification OAuth 2.0 était situé dans le centre de données de l'entreprise tandis que tous nos services d'application étaient déployés sur AWS VPC.
J'espère que l'approche que nous avons adoptée sera utile à votre décision. Faites-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 implémenté des services d'authentification et plusieurs autres micro services reposant sur un serveur d'authentification afin d'autoriser les ressources. À un moment donné, nous avons rencontré des problèmes de performances en raison d'un trop grand nombre d'aller-retour vers le serveur d'authentification, nous avons également eu des problèmes d'évolutivité pour le serveur d'authentification à mesure que le nombre de micro-services augmentait. Nous avons légèrement changé l'architecture pour éviter trop de voyages aller-retour.
Le serveur d'authentification ne sera contacté qu'une seule fois avec des informations d'identification et il générera le jeton 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 sans contacter le serveur d'authentification. La clé contient le temps généré et un utilitaire client installé dans le micro-service sera également valide. Même s'il ne s'agissait pas d'une implémentation standard, nous avons assez bien réussi avec ce modèle, en particulier lorsque tous les micro-services sont hébergés en interne.