Autorisation utilisateur avec microservices

12

Les microservices devraient-ils être responsables de la gestion de leur propre autorisation ou pensez-vous qu'il est préférable d'avoir un service d'autorisation distinct qui soit partagé entre tous ou un sous-ensemble (dans le même domaine d'activité) de microservices?

Pour moi, ce dernier est plus logique car il facilite l'application des changements, l'application des politiques; il est SEC, etc. Cependant, il peut facilement devenir incontrôlable par toutes sortes de services jetant leurs règles en un seul endroit, et également préoccupé par les frais généraux du réseau.

Des pensées?

architecture authorization microservices

— morcmarc
source

7

J'utiliserais un système d'authentification centralisé et unifié et disposerais d'autorisations / statistiques distinctes pour chaque microservice (un peu comme la façon dont je ne peux pas encore voter sur ce site d'échange de pile, mais je peux déborder de pile tout en utilisant le système d'authentification central d'échange de pile). Un de mes projets en cours impliquera cette approche dans un futur proche, ce qui sera sympa; le travail de développement précédent impliquait la création d'un système conforme à HIPPA, nécessitant un deuxième niveau d'autorisation / d'authentification, et il est fastidieux de chaîner des autorisations à partir de composants juridiquement séparés mais fonctionnellement inséparables du système. Le processus de débogage implique beaucoup moins de joie qu'une simple connexion oauth ou une api avec des en-têtes appid et x-auth.

Laquelle utiliser dépend des exigences spécifiques d'une feuille de route de développement, mais je choisirais l'approche la plus simple lorsque cela est possible pour éviter une surcharge et un temps / effort de développement excessifs.

— Jonathan Voss
source

Nous utilisons OAuth2 pour l'authentification, et j'aimerais suivre le même principe - c'est-à-dire avoir un service central avec une responsabilité unique et bien définie - pour l'autorisation, plutôt que de dupliquer la fonctionnalité et la logique de dispersion entre les services. Pour moi, c'est une violation de la frontière du domaine. Je suis d'accord cependant que cela signifie que nous devrons trier l'isolement des règles de service (ala stackoverflow, programmeurs, etc.).

— morcmarc

2

Vous pouvez potentiellement avoir des autorisations globales qui sont annulées par des autorisations spécifiques au service, utiles si une poignée de microservices principaux utilisent les mêmes autorisations. Les autorisations spécifiques au microservice doivent probablement être stockées dans l'infrastructure de l'application pour ce microservice afin d'éviter des problèmes de performances potentiels pour le service d'authentification central.

— Jonathan Voss

4

Chaque microservice ne devrait pas avoir à faire sa propre authentification, mais il doit faire sa propre autorisation.

La source

Et cela est parfaitement logique. Je suppose qu'il n'y a aucun doute sur l'authentification centrale. Mais l'autorisation est assez déroutante.

Étant donné que le nombre de micro-services peut atteindre des centaines, des milliers, un service d'autorisation central devrait être responsable de la liste des autorisations uniquement, mais pas de la validation de ces autorisations. Le micro-service individuel peut avoir à aborder différemment pour valider l'autorisation.

Ce service d'autorisation central, peut avoir besoin d'obtenir des modèles de différents services, et d'approcher différemment pour prendre une décision, il peut sembler facile et joli au début. Mais cela pourrait être le chaos plus tard.

— Ashwani Agarwal
source