Authentification et autorisation dans une architecture microservices

Cette série traite de la manière d’implémenter l’authentification (Authentication) et l’autorisation (Authorization) dans une architecture microservices.
Cet article présente une vue d’ensemble et explique les différences avec une application monolithique.

---

Application d’exemple : RealGuard.io

RealGuard.io est une plateforme de systèmes de sécurité commerciaux qui gère le contrôle des équipements de sécurité et les alertes.
Les utilisateurs appartiennent à des revendeurs, des entreprises clientes et des prestataires de supervision, avec des droits d’accès différents selon leur profil.

---

Authentification et autorisation dans une architecture monolithique

Une architecture monolithique se compose d’une seule application et d’une seule base de données, et l’authentification y est implémentée avec un jeton de session.
L’autorisation s’effectue selon la structure suivante :

isAllowed(user, operation, resource)  

Exemple :

isAllowed(user, "disarm", SecuritySystem(ID))  

---

Les 4 modèles d’autorisation

1. RBAC : contrôle d’accès basé sur les rôles — les permissions sont déterminées par les rôles attribués à l’utilisateur
2. ReBAC : contrôle d’accès basé sur les relations — l’accès est déterminé par la relation entre l’utilisateur et la ressource
3. ABAC : contrôle d’accès basé sur les attributs — la décision repose sur les attributs de l’utilisateur, de la ressource et de l’environnement
4. Modèle hybride : combinaison des trois approches précédentes pour mettre en œuvre des politiques plus complexes

---

Exemples d’autorisation et permissions par rôle

Operation	Required Role
getAlarmSystem()	SecuritySystemViewer
armSystem()	SecuritySystemArmer
disarmSystem()	SecuritySystemDisarmer
cancelSystem()	SecuritySystemAlarmCanceller

Au-delà d’un rôle spécifique, des conditions supplémentaires peuvent s’appliquer, comme des contraintes d’horaires de travail (ABAC) ou la présence dans une liste de notifications.

---

Où vérifier l’autorisation

1. Infrastructure réseau : des vérifications simples des droits peuvent être effectuées dans un service mesh, un ingress controller, etc.
2. Handlers d’API REST : traitement de l’autorisation coarse-grained au niveau de la requête
3. Logique métier : traitement de l’autorisation basé sur des conditions complexes
4. Couche d’accès à la base de données : filtrage d’autorisation dans le SQL lui-même (efficace pour les traitements à grande échelle)

---

Autorisation dans l’UI

L’UI ne peut pas imposer l’autorisation, mais elle peut optimiser l’UX en affichant ou en désactivant des boutons et des fonctionnalités selon les droits de l’utilisateur.

---

Authentification dans une architecture microservices

Le BFF (Backend For Frontend) est chargé de la connexion et de la gestion de session.
Comme chaque microservice s’exécute indépendamment, il ne peut pas accéder directement aux informations utilisateur via la session et doit recevoir ces informations au moyen d’un jeton tel qu’un JWT.

---

Autorisation dans une architecture microservices

Les requêtes sont transmises dans l’ordre BFF → SecurityService, et la vérification de l’autorisation peut s’effectuer à trois endroits :

1. BFF : autorisation au niveau de la requête selon le chemin et la méthode, à partir des informations de session
2. Réseau inter-services : le service mesh prend en charge une partie de l’autorisation basée sur JWT
3. À l’intérieur de chaque service : autorisation appliquée dans la logique métier et la couche d’accès aux données

---

La difficulté de l’autorisation distribuée

Comme chaque service ne possède pas dans sa propre base toutes les informations nécessaires, il peut être nécessaire d’appeler l’API d’un autre service pour autoriser une opération.
Une autre approche consiste à résoudre cela via le JWT, mais la taille du jeton et le coût de vérification deviennent alors problématiques.

---

En résumé

• L’authentification vérifie l’identité de l’utilisateur, l’autorisation détermine ses permissions
• Le pattern isAllowed(user, operation, resource) est au cœur de l’autorisation
• L’implémentation combine les trois modèles d’autorisation RBAC, ReBAC et ABAC
• Dans un monolithe, l’autorisation est plus simple grâce à l’accès à une base unique
• Dans les microservices, l’implémentation est plus complexe car les données nécessaires à l’autorisation sont dispersées