Aller au contenu principal

ACL et Endpoints

Les groupes d'accès :​

Ils représentent les différentes populations qui utilisent l'application. On dénombre 5 groupes (cf préambule - cahier des charge V3) représentés dans l'application par l'enum AccessGroup :

  • MANAGER : Gestionnaire de la convention
  • WRITER : Utilisateur avec droits d’écriture (inclu les MANAGER)
  • READER : Utilisateur avec droits de lecture (inclu les WRITER)
  • LIMITED : Utilisateur avec droits réduits
  • NO_RIGHTS : Utilisateur sans droits

Sécuriser un endpoint​

La sécurisation s'appuie sur l'annotation @PreAuthorize qui permet de déclarer, pour chaque endpoint

  • une cible (target) : Quel élément est à sécuriser (ex : la liste des utilisateurs, le bloc 'informations générales' des conventions...)
  • une variable qui permet de préciser la cible : par ex, l'id de la convention tel que passé en paramètre du endpoint
  • un droit sur la cible : typiquement read, write, execute...

Le mécanisme récupère automatiquement l'utilisateur authentifié et s'appuie sur le GrantService afin de déterminer :

  • de quels accessGroup l'utilisateur fait parti
  • si un des accessGroup dispose bien du droit demandé sur la cible spécifiée.
info

Pour assurer une flexibilité maximale, nous avons fait le choix de créer une cible par endpoint.

Exemple : gestion des informations financières​

EndpointCible (Droit)Description
GET /conventions/{id}/impactGET_INFO_FINANCIERE (+ READ)Afficher les infos financières
POST /conventions/{id}/declarer-impactCREATE_INFO_FINANCIERE (+ WRITE)Créer un impact financier (définir les informations financières)
POST /conventions/{id}/delete-impactDELETE_INFO_FINANCIERE (+ WRITE)Supprimer l'impact financier

Sécurisation côté front​

Pour éviter d'afficher des parties ou des boutons qui seraient interdits d'accès, le front récupère depuis un endpoint l'ensemble des cibles accessibles à l'utilisateur.

Voir aussi : Lien vers le CR