Autorisation

Statut

Document de cadrage sécurité — version initiale.

Objectif

L'autorisation détermine si une identité authentifiée peut réaliser une action précise sur une ressource donnée.

Dans DMV, elle doit tenir compte :

• du rôle de l'utilisateur ;
• du périmètre concerné ;
• de l'application source ;
• du rattachement à un acteur, une association ou une mairie ;
• de la sensibilité de l'action.

État actuel visible

Le repo montre plusieurs mécanismes d'autorisation :

• middleware ensure.admin basé sur isAdmin() ;
• middleware mairie.access qui vérifie un acteur de type mairie et son rattachement ;
• middleware asso.access qui vérifie l'appartenance active à une association ;
• policies Laravel sur les acteurs et publications ;
• contrôle propriétaire ou admin sur certaines actions ;
• middleware identify.app qui identifie l'application source via X-App-Source.

Règles observées

Domaine	Règle visible
Administration	Accès réservé à un profil reconnu admin.
Acteurs	Mise à jour ou suppression par propriétaire rattaché ou admin.
Publications	Mise à jour ou suppression par propriétaire de l'acteur ou admin.
Modération publication	Réservée à l'admin dans la policy visible.
Mairie	Écriture réservée à une mairie rattachée ou à un admin.
AssoSuite	Accès lié à une adhésion active à l'association.

Principes

• Une route authentifiée n'est pas automatiquement autorisée.
• Les droits doivent être évalués côté backend.
• Les scopes métier doivent limiter les actions même pour des rôles élevés.
• Les routes publiques doivent être explicitement identifiées.
• Les erreurs d'autorisation doivent éviter d'exposer des informations inutiles.
• Les changements de droits doivent être auditables.

Application source

Le header X-App-Source permet d'indiquer l'application appelante parmi :

• dmv
• backoffice
• playloop
• assosuite
• mairie

Ce header ne doit pas être considéré comme une preuve suffisante de droit. Il sert à contextualiser la requête, pas à remplacer l'authentification ni les permissions métier.

Vision cible

La cible est un modèle d'autorisation centralisé où :

• chaque action sensible a une règle lisible ;
• les policies, middlewares ou services de permission sont cohérents entre modules ;
• les rôles globaux sont complétés par des scopes territoriaux ou acteurs ;
• les applications connectées consomment l'API sans contourner la logique métier ;
• les exceptions d'autorisation sont journalisées quand l'action est sensible.

Points à clarifier

• Convention unique entre policies, middlewares et services de permission.
• Liste exhaustive des actions sensibles.
• Modèle de permission par commune, acteur, association et application.
• Règles exactes pour les validateurs/responsables locaux.
• Niveau de détail des logs d'autorisation refusée.