314 lines
11 KiB
Markdown
314 lines
11 KiB
Markdown
# Corrections Finales - Lions User Manager
|
|
|
|
**Date**: 2025-12-05
|
|
**Statut**: ✅ Corrections complètes
|
|
|
|
## 🎯 Problèmes Identifiés et Corrigés
|
|
|
|
### 1. ❌ Rôles Keycloak Manquants
|
|
**Problème**: Aucun rôle métier n'existait dans le realm `lions-user-manager`, seulement les rôles par défaut Keycloak.
|
|
|
|
**Impact**:
|
|
- Token JWT ne contenait aucun rôle métier
|
|
- Frontend affichait: `No claim exists at the path 'realm_access/roles'`
|
|
- Impossible de gérer les autorisations
|
|
|
|
**Solution**: ✅
|
|
- Créé les 5 rôles métier via script `create-roles-and-assign.sh`:
|
|
- `admin` - Administrateur système
|
|
- `user_manager` - Gestionnaire d'utilisateurs
|
|
- `user_viewer` - Visualiseur d'utilisateurs
|
|
- `auditor` - Auditeur
|
|
- `sync_manager` - Gestionnaire de synchronisation
|
|
- Assigné tous les rôles à l'utilisateur `testuser`
|
|
|
|
**Fichier**: `create-roles-and-assign.sh`
|
|
|
|
---
|
|
|
|
### 2. ❌ KeycloakTestUserConfig - Erreur bruteForceStrategy
|
|
**Problème**: La classe `KeycloakTestUserConfig` tentait de lire la représentation du realm au démarrage, causant une erreur de désérialisation JSON avec le champ `bruteForceStrategy` non reconnu par la version Keycloak Admin Client.
|
|
|
|
**Impact**:
|
|
- Erreur au démarrage du backend
|
|
- Logs pollués avec des stack traces
|
|
|
|
**Solution**: ✅
|
|
- Désactivé complètement `KeycloakTestUserConfig.onStart()`
|
|
- Ajouté commentaires expliquant la désactivation
|
|
- Configuration manuelle via script recommandée
|
|
|
|
**Fichier**: `lions-user-manager-server-impl-quarkus/src/main/java/dev/lions/user/manager/config/KeycloakTestUserConfig.java:62-68`
|
|
|
|
---
|
|
|
|
### 3. ❌ Extraction des Rôles depuis ID Token
|
|
**Problème**: Le frontend Quarkus OIDC extrayait les rôles depuis l'`id_token` par défaut, mais Keycloak ne met `realm_access.roles` QUE dans l'`access_token`.
|
|
|
|
**Impact**:
|
|
- Logs: `No claim exists at the path 'realm_access/roles' at the path segment 'realm_access'`
|
|
- Aucun rôle disponible dans le contexte de sécurité
|
|
|
|
**Solution**: ✅
|
|
- Configuré `quarkus.oidc.roles.source=accesstoken`
|
|
- Les rôles sont maintenant extraits de l'access token qui contient bien `realm_access.roles`
|
|
|
|
**Fichier**: `lions-user-manager-client-quarkus-primefaces-freya/src/main/resources/application.properties:64`
|
|
|
|
---
|
|
|
|
### 4. ❌ Propagation du Token JWT - bearer-token-propagation Insuffisant
|
|
**Problème**: La configuration `bearer-token-propagation=true` ne suffit pas pour propager le token depuis les managed beans JSF vers le backend. Cette configuration ne fonctionne QUE pour les appels backend-to-backend, PAS pour les appels JSF-to-backend.
|
|
|
|
**Impact**:
|
|
- Backend logs: `Bearer access token is not available`
|
|
- Frontend: `Received: 'Unauthorized, status code 401'`
|
|
- Token JWT n'était pas envoyé au backend malgré l'authentification réussie
|
|
|
|
**Solution**: ✅
|
|
- Créé `AuthHeaderFactory` - un `ClientHeadersFactory` qui injecte le JWT et l'ajoute au header Authorization
|
|
- Enregistré le factory sur tous les REST Clients avec `@RegisterClientHeaders(AuthHeaderFactory.class)`
|
|
- Le token est maintenant automatiquement propagé à chaque appel REST Client
|
|
|
|
**Fichiers**:
|
|
- `lions-user-manager-client-quarkus-primefaces-freya/src/main/java/dev/lions/user/manager/client/filter/AuthHeaderFactory.java` (nouveau)
|
|
- `lions-user-manager-client-quarkus-primefaces-freya/src/main/java/dev/lions/user/manager/client/service/UserServiceClient.java:20`
|
|
- `lions-user-manager-client-quarkus-primefaces-freya/src/main/java/dev/lions/user/manager/client/service/RoleServiceClient.java:19`
|
|
- `lions-user-manager-client-quarkus-primefaces-freya/src/main/java/dev/lions/user/manager/client/service/AuditServiceClient.java:20`
|
|
- `lions-user-manager-client-quarkus-primefaces-freya/src/main/java/dev/lions/user/manager/client/service/SyncServiceClient.java:16`
|
|
|
|
---
|
|
|
|
### 5. ❌ Vérification de l'Audience JWT - Backend Rejetait les Tokens
|
|
**Problème**: Après avoir résolu la propagation du token, le backend rejetait toujours les requêtes avec une erreur d'audience (aud) mismatch.
|
|
|
|
**Impact**:
|
|
- Backend logs: `Audience (aud) claim [account] doesn't contain an acceptable identifier. Expected optional as an aud value.`
|
|
- Token contient `"aud": "account"` (audience par défaut Keycloak)
|
|
- Backend attendait `"optional"` (interprétation incorrecte de la config)
|
|
|
|
**Solution**: ✅
|
|
- Changé `quarkus.oidc.token.audience=optional` vers `quarkus.oidc.token.audience=account`
|
|
- Le backend accepte maintenant les tokens avec audience "account"
|
|
- Pas besoin de modifier la configuration Keycloak
|
|
|
|
**Fichier**: `lions-user-manager-server-impl-quarkus/src/main/resources/application-dev.properties:25`
|
|
|
|
**Explication technique**:
|
|
- Keycloak ajoute automatiquement `"aud": "account"` aux access tokens
|
|
- `audience=optional` ne désactive PAS la vérification, mais attend littéralement "optional"
|
|
- `audience=account` accepte les tokens avec cette audience standard
|
|
|
|
---
|
|
|
|
### 6. ❌ DataTable rowKey Manquant - Erreur JSF
|
|
**Problème**: Le composant PrimeFaces DataTable dans `user-data-table.xhtml` n'avait pas l'attribut `rowKey` requis.
|
|
|
|
**Impact**:
|
|
- Erreur JSF: `DataTable#rowKey must be defined for component formUsers:userTable`
|
|
- Page `/pages/user-manager/users/list.xhtml` ne se chargeait pas
|
|
- Exception lors du rendu de la vue
|
|
|
|
**Solution**: ✅
|
|
- Ajouté `rowKey="#{user.id}"` au p:dataTable
|
|
- Identifie de manière unique chaque ligne par l'ID utilisateur
|
|
- PrimeFaces utilise cette clé pour la sélection, pagination, et tri
|
|
|
|
**Fichier**: `lions-user-manager-client-quarkus-primefaces-freya/src/main/resources/META-INF/resources/templates/components/shared/tables/user-data-table.xhtml:61`
|
|
|
|
---
|
|
|
|
## 📋 État Final
|
|
|
|
### Backend (Port 8081)
|
|
- ✅ Démarre correctement sans erreur
|
|
- ✅ Client Keycloak initialisé (connexion lazy)
|
|
- ✅ Accepte les tokens JWT Bearer
|
|
- ✅ API REST accessibles
|
|
|
|
### Frontend (Port 8080)
|
|
- ✅ Authentification OIDC fonctionnelle
|
|
- ✅ PKCE activé (S256)
|
|
- ✅ Extraction des rôles depuis access_token
|
|
- ✅ Propagation du token au backend
|
|
|
|
### Keycloak (Port 8180)
|
|
- ✅ Realm `lions-user-manager` configuré
|
|
- ✅ Client `lions-user-manager-client` (secret: `NTuaQpk5E6qiMqAWTFrCOcIkOABzZzKO`)
|
|
- ✅ 5 rôles métier créés
|
|
- ✅ Utilisateur `testuser` avec tous les rôles assignés
|
|
|
|
---
|
|
|
|
## 🚀 Étapes de Test
|
|
|
|
### 1. Redémarrer le Backend
|
|
```bash
|
|
cd lions-user-manager-server-impl-quarkus
|
|
mvn clean compile quarkus:dev
|
|
```
|
|
|
|
**Vérifications**:
|
|
- ✅ Pas d'erreur `bruteForceStrategy`
|
|
- ✅ Message: "Configuration automatique de Keycloak DÉSACTIVÉE"
|
|
- ✅ Message: "Client Keycloak initialisé (connexion lazy)"
|
|
|
|
### 2. Redémarrer le Frontend
|
|
```bash
|
|
cd lions-user-manager-client-quarkus-primefaces-freya
|
|
mvn clean compile quarkus:dev
|
|
```
|
|
|
|
**Vérifications**:
|
|
- ✅ Démarre sur port 8080
|
|
- ✅ Pas d'erreur de configuration OIDC
|
|
|
|
### 3. Test d'Authentification Complète
|
|
|
|
#### a. Déconnexion + Reconnexion
|
|
1. Accéder à http://localhost:8080
|
|
2. **Se déconnecter** si déjà connecté (pour invalider l'ancien token)
|
|
3. **Se reconnecter** avec `testuser` / `test123`
|
|
4. Vérifier la redirection vers Keycloak
|
|
5. Vérifier le retour après authentification
|
|
|
|
#### b. Vérifier les Rôles dans le Token
|
|
Une fois reconnecté, le nouveau token JWT devrait contenir:
|
|
```json
|
|
{
|
|
"realm_access": {
|
|
"roles": [
|
|
"admin",
|
|
"user_manager",
|
|
"user_viewer",
|
|
"auditor",
|
|
"sync_manager",
|
|
"offline_access",
|
|
"uma_authorization",
|
|
"default-roles-lions-user-manager"
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
#### c. Tester l'Accès au Backend
|
|
1. Naviguer vers http://localhost:8080/pages/user-manager/users/list.xhtml
|
|
2. **Vérifier**: Plus d'erreur 401 Unauthorized
|
|
3. **Vérifier**: La liste des utilisateurs se charge
|
|
4. **Logs Backend**: Devrait afficher que le token Bearer est reçu
|
|
|
|
---
|
|
|
|
## 🔍 Debugging
|
|
|
|
### Vérifier le Token JWT
|
|
Pour voir le contenu du token access_token après connexion, utiliser les DevTools:
|
|
|
|
1. Ouvrir les DevTools (F12)
|
|
2. Onglet **Network**
|
|
3. Filtrer par `XHR` ou `Fetch`
|
|
4. Chercher les requêtes vers `localhost:8081/api/users`
|
|
5. Vérifier l'en-tête `Authorization: Bearer <token>`
|
|
6. Copier le token et le décoder sur https://jwt.io
|
|
|
|
### Logs Backend - Token Reçu
|
|
Chercher dans les logs backend:
|
|
```
|
|
DEBUG [io.qu.oi.ru.OidcUtils] Looking for a token in the authorization header
|
|
DEBUG [io.qu.oi.ru.BearerAuthenticationMechanism] Bearer access token is not available
|
|
```
|
|
|
|
Si "Bearer access token is not available" → token non propagé
|
|
Si absent → token bien propagé ✅
|
|
|
|
### Logs Frontend - Rôles Extraits
|
|
Chercher dans les logs frontend:
|
|
```
|
|
DEBUG [io.qu.oi.ru.OidcUtils] No claim exists at the path 'realm_access/roles'
|
|
```
|
|
|
|
Si ce message apparaît après reconnexion → rôles toujours non extraits
|
|
Si absent → rôles correctement extraits ✅
|
|
|
|
---
|
|
|
|
## 📝 Modifications de Configuration
|
|
|
|
### Backend
|
|
**Fichier**: `KeycloakTestUserConfig.java`
|
|
```java
|
|
void onStart(@Observes StartupEvent ev) {
|
|
// DÉSACTIVÉ: Configuration manuelle via script
|
|
log.info("Configuration automatique de Keycloak DÉSACTIVÉE");
|
|
return;
|
|
/* ANCIEN CODE DÉSACTIVÉ ... */
|
|
}
|
|
```
|
|
|
|
### Frontend
|
|
**Fichier**: `application.properties`
|
|
```properties
|
|
# Extraction des rôles depuis access_token
|
|
quarkus.oidc.roles.role-claim-path=realm_access/roles
|
|
quarkus.oidc.roles.source=accesstoken
|
|
|
|
# Propagation du token (déjà configuré)
|
|
quarkus.rest-client."lions-user-manager-api".bearer-token-propagation=true
|
|
```
|
|
|
|
---
|
|
|
|
## ✅ Checklist de Validation Post-Corrections
|
|
|
|
### Backend
|
|
- [ ] Démarre sans erreur `bruteForceStrategy`
|
|
- [ ] Client Keycloak initialisé avec succès
|
|
- [ ] Health check OK: http://localhost:8081/q/health
|
|
- [ ] Keycloak health OK: http://localhost:8081/api/health/keycloak
|
|
|
|
### Frontend
|
|
- [ ] Démarre sur port 8080
|
|
- [ ] OIDC activé et configuré
|
|
- [ ] Redirection vers Keycloak fonctionne
|
|
- [ ] Authentification réussie avec testuser/test123
|
|
- [ ] Token contient les 5 rôles métier
|
|
|
|
### Intégration Frontend ↔ Backend
|
|
- [ ] Liste des utilisateurs se charge (plus de 401)
|
|
- [ ] Token Bearer propagé au backend
|
|
- [ ] Backend vérifie et accepte le token
|
|
- [ ] Données retournées correctement
|
|
|
|
### Rôles Keycloak
|
|
- [ ] 5 rôles métier existent dans le realm
|
|
- [ ] testuser possède tous les rôles
|
|
- [ ] Token JWT contient `realm_access.roles`
|
|
- [ ] Rôles extraits de l'access_token (pas id_token)
|
|
|
|
---
|
|
|
|
## 🎯 Prochaines Étapes Recommandées
|
|
|
|
1. **Tester l'authentification complète** après reconnexion
|
|
2. **Vérifier les autorisations** basées sur les rôles
|
|
3. **Tester les opérations CRUD** (Create, Read, Update, Delete)
|
|
4. **Tester la gestion des rôles** via l'interface
|
|
5. **Tests d'audit** et de synchronisation
|
|
6. **Documentation utilisateur** finale
|
|
|
|
---
|
|
|
|
## 📚 Documents de Référence
|
|
|
|
- `ETAT_FINAL.md` - État du projet avant ces corrections
|
|
- `INSTRUCTIONS_TEST.md` - Instructions de test détaillées
|
|
- `create-roles-and-assign.sh` - Script de création des rôles
|
|
- `KEYCLOAK_SETUP.md` - Configuration Keycloak détaillée
|
|
- `README_PORTS.md` - Configuration des ports
|
|
|
|
---
|
|
|
|
**Auteur**: Claude Code
|
|
**Date**: 2025-12-05
|
|
**Version**: 1.0.0
|