RBAC rôle + périmètre
Statut
Document de cadrage sécurité — version initiale.
Définition
Le RBAC DMV ne doit pas se limiter à un rôle global. Il doit combiner :
- un rôle ;
- un périmètre ;
- une ressource ;
- une action.
Exemple : un utilisateur peut être contributeur d'un acteur précis sans être contributeur global de toute la plateforme.
État actuel visible
Le code et les migrations montrent :
- une table ou logique de rôles utilisateurs ;
- une méthode
isAdmin()côté profil ; - des rattachements
user_acteurs; - des policies qui utilisent la propriété d'acteur ;
- des règles RLS historiques liées à
users_roles,profiles,user_acteursetauth.uid(); - des middlewares dédiés pour mairie, association, admin et device PlayLoop.
Rôles de référence
| Rôle | Périmètre type | Responsabilité |
|---|---|---|
| Utilisateur | Son compte | Consultation, favoris, interactions autorisées. |
| Contributeur | Acteur, association ou commune rattachée | Publication ou gestion selon droits accordés. |
| Opérateur | Domaine ou backoffice limité | Traitement opérationnel selon scope. |
| Validateur local | Commune, territoire ou acteur | Validation de contenus ou demandes dans un périmètre. |
| Mairie | Commune ou acteur mairie | Services communaux, alertes, publications mairie. |
| Admin global | Plateforme | Administration transverse et actions sensibles. |
Ces rôles sont des repères de cadrage. Leur implémentation exacte doit rester alignée avec le code.
Scopes nécessaires
| Scope | Usage |
|---|---|
| Compte utilisateur | Données personnelles, favoris, préférences. |
| Acteur | Mini-site, publications, documents, abonnement. |
| Association | Membres, cotisations, projets, communication interne. |
| Commune | Alertes, services communaux, informations mairie. |
| Application | DMV, backoffice, PlayLoop, AssoSuite, Mairie. |
| Global | Administration plateforme, sécurité, support. |
Règles de conception
- Aucun rôle large ne doit être créé sans justification.
- Les droits d'administration doivent être limités au besoin réel.
- Les scopes doivent être vérifiés côté backend.
- Les droits temporaires doivent avoir une date de fin si le besoin existe.
- Les changements de rôle ou de rattachement doivent être auditables.
- Les droits hérités doivent être documentés pour éviter les surprises.
Matrice cible simplifiée
| Action | Utilisateur | Contributeur | Mairie | Admin global |
|---|---|---|---|---|
| Modifier son profil | Oui | Oui | Oui | Oui |
| Modifier un acteur | Non | Si rattaché | Si acteur mairie rattaché | Oui |
| Publier pour un acteur | Non | Selon droit | Selon droit mairie | Oui |
| Gérer les rôles | Non | Non | À définir par scope | Oui |
| Modérer globalement | Non | Non | Non, sauf délégation locale | Oui |
| Gérer une alerte mairie | Non | Non | Si commune autorisée | Oui |
Vision cible
La cible est un système RBAC maintenable :
- rôles métier documentés ;
- permissions explicites ;
- scopes territoriaux et acteurs ;
- règles réutilisables dans les modules ;
- tests sur les cas critiques ;
- audit logs pour les changements de droits.
Points à clarifier
- Liste finale des rôles métier.
- Différence exacte entre opérateur, validateur local et responsable local.
- Droits spécifiques des communes et mairies.
- Délégations possibles à des contributeurs.
- Interface de gestion des permissions.