lions-user-manager/EXPLICATION_PERMISSIONS.md

Explication des Permissions dans lions-user-manager

Architecture des Permissions

Il y a deux niveaux de permissions distincts dans lions-user-manager :

1. Permissions OIDC (Authentification/Autorisation Frontend → Backend)

Qui : L'utilisateur connecté au frontend (test-user)

Où : Le realm où l'utilisateur se connecte (lions-user-manager)

Comment :

• L'utilisateur test-user se connecte via OIDC dans le realm lions-user-manager
• Il obtient un token JWT contenant ses rôles (admin, user_manager, etc.) dans le claim realm_access.roles
• Le frontend envoie ce token au backend dans l'en-tête Authorization: Bearer <token>
• Le backend vérifie ces rôles avec @RolesAllowed pour autoriser l'accès aux endpoints

Rôles nécessaires (dans le realm lions-user-manager) :

• admin - Accès complet
• user_manager - Gestion des utilisateurs
• user_viewer - Consultation des utilisateurs
• role_manager - Gestion des rôles
• role_viewer - Consultation des rôles
• auditor - Consultation des logs
• sync_manager - Gestion de la synchronisation

2. Permissions Admin API (Opérations Keycloak)

Qui : Le backend (lions-user-manager-server-impl-quarkus)

Où : Le realm master (realm d'administration)

Comment :

• Le backend utilise les credentials admin/admin du realm master pour se connecter à l'API Admin Keycloak
• Ces credentials permettent de gérer TOUS les realms, y compris master, lions-user-manager, btpxpress, etc.
• Le backend effectue les opérations (créer utilisateur, assigner rôles, etc.) via l'API Admin Keycloak

Configuration (dans application-dev.properties) :

lions.keycloak.admin-realm=master
lions.keycloak.admin-username=admin
lions.keycloak.admin-password=admin

Réponse à la Question

Question : test-user a-t-il les droits admin pour manipuler l'administration Keycloak master ?

Réponse : NON, et ce n'est pas nécessaire !

Explication :

1. test-user a les rôles nécessaires dans le realm lions-user-manager pour autoriser l'accès aux endpoints du backend
2. Le backend utilise ensuite les credentials admin/admin du realm master pour effectuer les opérations sur n'importe quel realm (y compris master)
3. Donc test-user n'a pas besoin d'avoir des droits dans le realm master pour que le backend puisse gérer ce realm

Flux Complet

1. test-user (realm: lions-user-manager) 
   → Se connecte via OIDC
   → Obtient token JWT avec rôles: [admin, user_manager, ...]

2. Frontend
   → Envoie requête au backend avec token JWT
   → Exemple: GET /api/users/search?realm=master

3. Backend
   → Vérifie les rôles dans le token JWT avec @RolesAllowed
   → Si autorisé, utilise admin/admin (realm: master) pour effectuer l'opération
   → Appelle l'API Admin Keycloak: GET /admin/realms/master/users

4. Keycloak Admin API
   → Accepte la requête car elle vient de admin/admin (realm: master)
   → Retourne les utilisateurs du realm master

Cas d'Usage

Cas 1 : Gérer les utilisateurs du realm lions-user-manager

• test-user a les rôles dans lions-user-manager ✅
• Backend utilise admin/admin pour gérer lions-user-manager ✅
• Résultat : ✅ Fonctionne

Cas 2 : Gérer les utilisateurs du realm master

• test-user a les rôles dans lions-user-manager ✅ (pour autoriser l'accès)
• Backend utilise admin/admin pour gérer master ✅
• Résultat : ✅ Fonctionne aussi !

Conclusion

test-user n'a PAS besoin d'avoir des droits dans le realm master car :

• Les rôles de test-user servent uniquement à autoriser l'accès aux endpoints du backend
• Le backend utilise ses propres credentials admin (admin/admin du realm master) pour effectuer les opérations

C'est une architecture sécurisée qui sépare :

• Autorisation utilisateur (via OIDC et rôles dans le token JWT)
• Permissions opérationnelles (via credentials admin du backend)