Comment un service d'autorisation met en œuvre des contrôles de propriété dans une architecture Microservice basée sur les rôles

Question

Disons que j'ai trois types d'utilisateurs sur une application blogging

1. Auteur (est capable de modifier leurs propres messages mais pas d'autres)
2. administrateur (est capable de modifier tous les messages)
3. lecteur (ne peut pas modifier les messages)

Pour gérer ce système que je veux avoir trois services principaux:

• Une API passerelle qui expose toutes les API clients consommeront, composer des services selon les besoins.
• Un de gestion après qui fournit les opérations CRUD pour les blogs (y compris les données de qui possède quoi les messages)
• Un service d'autorisation qui stocke des rôles et autorisations, ce qui expose une API qui prend dans un tableau de rôles (les rôles d'un utilisateur demandeur) et un tableau d'autorisations (les autorisations nécessaires pour accéder à une API) et détermine si ces rôles en entrée couvrent toutes les autorisations entrées.

Maintenant, ce que je suis aux prises avec est la propriété d'une ressource (et où la propriété doit être vérifiée). Sans communiquer avec d'autres services, comment un service d'autorisation peut-il déterminer si un utilisateur doit pouvoir accéder à quelque chose qu'il possède sans savoir comment déterminer si un utilisateur possède une ressource donnée?

Je suis venu avec quelques solutions différentes à ce problème, bien que je ne suis pas très content de l'un d'eux.

1. La passerelle API interrogerait un autre service qui gère les messages pour déterminer si un utilisateur demandeur est propriétaire du poste qu'ils tentent d'accéder, cela signifierait il est logique d'autorisation qui se passe en dehors du service d'autorisation. Le service de gestion des articles de blog gérerait l'autorisation basée sur la propriété, cela signifierait aussi que la logique d'autorisation se passe en dehors du service d'autorisation ainsi que le fait que les demandes non autorisées soient marquées comme autorisées initialement (puisqu'elles passeront toujours par l'autorisation service)
2. Le service d'autorisation pourrait être donné la connaissance de la façon de vérifier la propriété, l'API devrait pouvoir être dit si oui ou non il devrait vérifier la propriété avec les autorisations. Cela ajouterait de la complexité au service d'autorisation et augmenterait la communication inter-services que je voudrais reléguer le plus possible à la passerelle d'API puisqu'elle devrait être le compositeur de service primaire.

Vous cherchez des idées sur d'autres méthodes ou un aperçu de ce que pourrait être la meilleure solution à ce problème.

Answer 1

Étant donné qu'il est externalisé, le service d'autorisation doit être aussi "stupide" que possible. Parfois, une «autorisation» basée sur la logique métier et les données peut devenir très complexe. Je pense que la logique métier appartient au service responsable de la gestion.De plus, la passerelle API devra probablement fournir au client le statut de propriétaire (du service qui gère ces articles de blog?) Afin que les clients sachent quoi exposer. Gardez donc l'autorisation simple et encapsulez des contrôles d'affaires plus complexes pour voir ce qui peut être fait au sein même du service.

Une alternative est de renforcer le service d'autorisation pour prendre un autre paramètre, dans ce cas, l'état de propriété. La passerelle API ou toute autre autorisation de vérification de service (Blog Post Manager?) Peut d'abord obtenir le statut de propriété du service en connaissant l'activité de propriété, puis utiliser le service d'autorisation fournissant le rôle et le statut de propriété. Les règles d'autorisation seraient (facultativement) basées sur le rôle et un indicateur vrai/faux. Le service d'autorisation n'a pas la connaissance de ce que signifie vrai/faux, juste que l'autorisation "Modifier le message" est accordée pour le rôle "Lecteur" + indicateur = vrai, et pour le rôle "Administrateur" + indicateur = faux ou Rôle "Administrateur" "+ indicateur = vrai, etc.