Lors de la récente Microservices Conference à Londres, David Borsos a expliqué dans sa présentation évaluant quatre options d'authentification pour un microservice que la sécurité des logiciels est un problème complexe et devient encore plus complexe avec les microservices où chaque service doit gérer la sécurité.
Dans une architecture monolithique traditionnelle, un seul serveur contient toutes les données utilisateur et peut vérifier et créer une session HTTP lorsqu'un utilisateur est authentifié. Dans une architecture de microservices, un utilisateur interagit avec une collection de services, chacun ayant le besoin potentiel de savoir qui est l'utilisateur. Une solution naïve est d'appliquer le même modèle dans un système microservices que dans un système monolithique mais alors se pose le problème de la manière de donner à tous les services l'accès aux données utilisateur. Lors de l'utilisation d'une base de données utilisateur partagée, la mise à jour du schéma devient un problème difficile puisque tous les services doivent être mis à niveau en même temps. Lors de la distribution des mêmes données à tous les services, se pose le problème de savoir comment informer chaque service lorsqu'un utilisateur est authentifié.
En examinant différentes solutions, Borsos note qu'une solution de single sign-on (SSO) peut à priori sembler une bonne idée mais cela signifie que chaque service frontal doit communiquer avec le service d'authentification, ce qui rend le trafic assez bavard. C'est également assez complexe à mettre en œuvre. D'autre part, la sécurité est aussi bonne que le SSO choisi et l'état de connexion utilisateur est opaque, empêchant un attaquant de déduire toute information utile de celui-ci.
Avec une solution de session distribuée, les informations d'authentification utilisateur sont stockées dans un magasin de données partagé, souvent un simple dictionnaire distribué dont la clé est la session utilisateur. Lorsqu'un utilisateur accède à un microservice, les données utilisateur peuvent alors être extraites du magasin de données. Un autre avantage de cette solution est que l'état de connexion de l'utilisateur est opaque. Dans le cadre de l'utilisation d'une base de données distribuée, il s'agit également d'une solution hautement disponible et évolutive. Les inconvénients comprennent le fait que le magasin de données doit être protégé et donc seulement accessible via une connexion sécurisée et que la mise en œuvre de la solution présente souvent une complexité assez élevée.
En utilisant des jetons côté client, l'utilisateur est authentifié et un jeton est créé côté client. Ce jeton est signé par un service d'authentification et doit contenir suffisamment d'informations pour que l'identité de l'utilisateur puisse être établie dans tous les microservices. Le jeton est lié à chaque demande, donnant au service la possibilité de vérifier l'utilisateur. La sécurité est relativement bonne avec cette solution mais un problème important concerne la difficulté pour se déconnecter. Les moyens de remédiation comprennent l'utilisation de jetons de courte durée et des vérifications fréquentes avec le service d'authentification. Pour l'utilisation de jetons côté client, Borsos préfère utiliser JSON Web Tokens (JWT), entre autres pour sa simplicité et ses bonnes librairies de support.
L'utilisation d'un jeton côté client avec une passerelle d'API signifie que toutes les demandes passent par la passerelle, masquant efficacement les microservices. Pour une requête, la passerelle transforme le jeton d'utilisateur original en jeton d'identité de session interne. La déconnexion n'est pas un problème car la passerelle peut révoquer le jeton de l'utilisateur lorsqu'il se déconnecte. Même si le support de la bibliothèque est bon, la mise en œuvre peut se révéler complexe.
Comme recommandation générale, Borsos suggère d'utiliser des jetons côté client avec JWT et une passerelle d'API car il est généralement plus aisé, plus simple à mettre en œuvre et offre de bonnes performances. Le SSO pourrait fonctionner mais il pense qu'il devrait être évité. L'utilisation de sessions distribuées peut être intéressante, en particulier dans les cas d'utilisation où les technologies nécessaires sont déjà en cours d'utilisation. Il souligne cependant l'importance de considérer l'importance de la déconnexion lors du choix d'une solution.
La conférence Microservices de l'année prochaine aura lieu à Londres du 6 au 7 novembre 2017.