# 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`) :
```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)