¶ Authentification et rôles
Trois modes, tranchés par AUTH_MODE, et trois rôles indépendants du mode.
¶ Les trois modes
¶ local — comptes gérés dans l'application (défaut)
Les comptes vivent dans la base, se gèrent depuis Administration → Comptes.
Le mot de passe est haché avec scrypt (N = 2¹⁵), paramètres inscrits dans
l'empreinte pour permettre un recalcul futur.
À la première installation, deux comptes sont créés automatiquement :
| Compte | Mot de passe | Rôle | Remarque |
|---|---|---|---|
admin |
admin1234 |
Administration | à changer dès la première connexion |
admin_dev |
admin1234 |
Administration | compte de développement, à bloquer en production |
La connexion propose immédiatement de changer le mot de passe, et un bandeau
rouge persiste dans l'administration tant qu'un compte utilise encore la valeur
par défaut.
¶ oidc — Keycloak, et comptes locaux
Authorization Code + PKCE contre Keycloak. Les comptes locaux restent
utilisables : c'est délibéré, et c'est l'accès de secours. Une erreur de
configuration du fournisseur — realm renommé, secret périmé, service en panne —
ne doit pas vous enfermer dehors de votre propre application.
Toutes les URLs viennent de la découverte automatique
(<issuer>/.well-known/openid-configuration) : aucune adresse n'est écrite en
dur, et changer de version de Keycloak ne casse rien.
¶ dev — aucune authentification
Tout le monde est administrateur. Pratique pour démarrer ou pour une démonstration.
Refusé au démarrage si ENV=production : l'application ne se lance pas du
tout. Un mode qui donne l'administration à quiconque atteint le port ne se
signale pas par un bandeau, il s'interdit.
¶ Les trois rôles
| Rôle | Consulte | Modifie plannings et équipements | Déploie dans Home Assistant | Administre |
|---|---|---|---|---|
| Visualisation | oui | — | — | — |
| Contribution | oui | oui | — | — |
| Administration | oui | oui | oui | oui |
La frontière qui compte est entre Contribution et Administration :
concevoir un scénario n'est pas l'écrire dans la maison. Un contributeur
prépare tout, consulte l'aperçu du YAML, et laisse un administrateur déclencher
le déploiement.
L'écran d'administration est réservé aux administrateurs même en lecture : la
liste des comptes expose des identifiants, des rôles et des adresses de connexion.
¶ L'autorisation ferme par défaut
Le contrôle ne repose pas sur la vigilance de chaque route. Un intergiciel déduit
le rôle nécessaire du chemin et de la méthode, et ferme par défaut : une
route d'écriture ajoutée demain exige le rôle Administration tant que personne ne
l'a délibérément ouverte à la contribution.
L'inverse — ouvrir par défaut et fermer au cas par cas — finit toujours par
laisser passer quelque chose.
¶ Configurer Keycloak
¶ Dans Keycloak
Déclarer un client confidentiel :
| Réglage | Valeur |
|---|---|
| Type d'accès | confidentiel (avec client secret) |
| Flow autorisé | Standard (Authorization Code) |
| URL de redirection | https://votre-hote/rappel |
| Mapper | Group Membership, nom du claim groups, sans le chemin complet |
Créer ensuite le groupe d'administration, par exemple domodrive-admin, et y
placer les personnes concernées.
¶ Dans l'application
Administration → Réglages et connexions → Authentification, ou par
l'environnement :
AUTH_MODE=oidc
OIDC_ISSUER=https://auth.exemple.fr/realms/monrealm
OIDC_CLIENT_ID=domodrive
OIDC_CLIENT_SECRET=<secret du client>
OIDC_SCOPES=openid profile email groups
OIDC_GROUPS_CLAIM=groups
OIDC_ADMIN_GROUP=domodrive-admin
Le bouton Tester Keycloak de l'écran de réglages interroge le document de
découverte et dit ce qui manque, avant que quiconque n'essaie de se connecter.
¶ Comment le rôle est attribué
Le rôle est recalculé à chaque connexion à partir du claim de groupes :
- membre de
OIDC_ADMIN_GROUP→ Administration ; - authentifié mais hors du groupe → Visualisation (lecture seule, aucun
déploiement).
Retirer quelqu'un du groupe dans Keycloak suffit donc à lui retirer ses droits,
sans rien faire côté application. Le préfixe / que Keycloak ajoute aux groupes
est ignoré dans la comparaison : /domodrive-admin et domodrive-admin sont
équivalents.
Le rôle Contribution ne s'attribue pas par Keycloak. Il se donne à un
compte local, depuis l'écran Comptes. C'est cohérent avec le rôle : préparer un
scénario sans pouvoir le déployer est une délégation ponctuelle, pas une
appartenance de groupe.
¶ Gérer les comptes locaux
Administration → Comptes et rôles permet de créer un compte, changer son
rôle, réinitialiser son mot de passe, le bloquer ou le supprimer.
Bloquer plutôt que supprimer, quand la personne peut revenir : la suppression
d'un compte fait perdre le lien entre les entrées d'audit et leur auteur.
Chaque ligne montre la dernière connexion et son adresse IP — c'est souvent
la première chose qu'on regarde quand une alerte apparaît sur l'écran des
journaux.
¶ Surveillance des connexions
Si plus de cinq connexions échouent en 24 heures pour moins de connexions
réussies, une alerte apparaît sur l'écran des journaux et sur le sommaire de
l'administration, avec les adresses concernées.
Le détail des vues d'audit est sur la page Administration.
¶ Aller plus loin
- Configuration et options — toutes les variables
- Administration — journaux de connexion et d'activité
¶ Sommaire de la documentation
- Accueil Domodrive
- Domodrive — présentation
- Installation avec Docker
- Installation sur Kubernetes
- Configuration et options
- Authentification et rôles (page courante)
- Prise en main
- Plannings
- Routines de contrôle environnemental
- Périodes et déploiement
- Administration
- Exploitation et dépannage
- Référence technique
Documentation Domodrive 1.0.0 — copie conforme du répertoire docs/ du dépôt gitlab.ev1.fr/ev1/domodrive (dépôt privé).