100 lines
4.0 KiB
Markdown
100 lines
4.0 KiB
Markdown
# 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)
|
|
|