Refonte de l'ACL

Contexte

L'actuellement implémentation présente des rôles trop permissifs par rapport à l'utilisation quotidienne qu'ont certains profils utilisateurs. Cela représente un risque de sécurité et également une difficulté à faire évoluer les droits. Il devient necéssaire d'ajouter un nouveau rôle Gestionnaire de parc pour leur restreindre certains droits. L'exploitation a également relevé que certains gestionnaires supprimaient des comptes de membres de l'exploitation car, étant visibles dans leur groupe, ceux-ci sont considérés comme des anomalies aux yeux des gestionnaires qui ne veulent pas les avoir dans leur groupe, ce qui résulte d'une suppression de compte.

But de la refonte des rôles

On aimerait alors une granularité plus fine des permissions. En accord avec l'analyse détaillée de Pierre sur le chantier UX - UI, celui-ci a obtenu nombre de témoignages qui vont en ce sens. Il faut alors créer un nouveau rôle dédié pour ce profil utilisateur.

Actions principales

Mise en place d'une hiérarchie des rôles

Cela permet plus particulièrement lors de suppression / modification d'utilisateur, de ne pouvoir intervenir que si le rôle de la personne modifiée est similiaire ou inférieur au notre. Ainsi, un gestionnaire ne pourra plus supprimer des membres de l'exploitation tel que la hiérarchie définit est la suivante :

MANAGER > TECHNICIAN > FLEET_MANAGER > VIEWER > USER

Refonte font-end de la gestion des droits

L'ACL front-end a été revue pour être plus fidèle à la matrice des droits. Cela assure plus de sécurité et permet une meilleure maintenabilité, évolutivité. Originellement découpé selon canRead et canWrite dans chaque components, on a voulu plutôt retranscrire exhaustivement les droits liés, permettant alors de désactiver directement des pages ou fonctionnalités selon le rôle. Cela facilite la fluidité du parcours utilisateur et on pourra également imaginer à l'avenir des interfaces dédiés plus poussés. Par exemple, concernant la situation écrite en préambule du document, on pourrait personnaliser la page utilisateurs pour afficher 2 boutons distincts, facile d'utilisation, qui expliciterait la suppression du compte ou la suppression du rôle dans le groupe.

Implémentation technique

Le front-end ne sécurise pas seul, c'est le back-end qui vérifie toujours, néanmoins il sert à l'UX.

Back-end

Dans src/acl/roles.enum.ts on retrouve les différents rôles associés aux utilisateurs. Chaque endpoint situé dans les controllers utilise l'ACL par l'intermédiaire de décorateurs. Les guards vérifient la connexion et assurent que le rôle utilisé existe :

@UseGuards(AuthenticationGuard, AuthorizationGuard)

On désigne ensuite quels sont les rôles à pouvoir accéder a l'endpoint :

@ROLES(Role.MANAGER, Role.TECHNICIAN, Role.VIEWER)

Front-end

Dans src/app/models/acl-rights.ts on établit un inventaire exhaustif des fonctionnalités. On les attribue aux rôles dans src/app/models.roles.ts

Ensuite, dans chaque components on vérifie les droits utilisés qu'on stocke dans la variable aclRights soit :

aclRights: AclRights = {};

constuctor(private aclService: AclService){}

this.aclRights[ACL_READ_LOCATIONS_MAP] = this.aclService.can(ACL_READ_LOCATIONS_MAP);

Matrice des droits

Disponible ci-joint.