Contrôle d'accès utilisateur

Rôles et permissions

DAZZM a conçu une approche unique pour contrôler l’accès des utilisateurs appelée Can Access. Au lieu d’utiliser un système typique de rôles et permissions qui pourrait être difficile à dépanner, notre approche a été conçue pour offrir la flexibilité nécessaire afin de s’aligner parfaitement sur les besoins de toute application. Par exemple, l’accès des utilisateurs pourrait être réglementé dans une application en attribuant un ou plusieurs rôles à chaque utilisateur. Dans une autre application, les utilisateurs pourraient être assignés à un rôle ou faire partie de groupes, et tout comme avec Active Directory, le groupe dicterait les permissions de l’utilisateur. Une autre façon d’implémenter les permissions avec notre système serait d’assigner un utilisateur à un projet, donnant à cette personne des droits implicites sans avoir besoin de modifier les privilèges de cet utilisateur.

Le contrôle d’accès dans DAZZM est hautement personnalisable, supportant l’implémentation de conditions métier complexes. L’accès d’un gestionnaire, par exemple, peut être limité à la consultation de ses propres employés uniquement. De même, les permissions peuvent être configurées pour s’assurer que seul le propriétaire du projet a l’autorité de modifier le champ « project code ». L’approche granulaire de DAZZM en matière de contrôle d’accès peut bloquer un champ spécifique dans les cas impliquant une entity ou un enum. De plus, les Permissions et les Business Rules peuvent être combinées dans une seule expression canAccess. Par exemple, vous pourriez définir une règle comme :

currentUser.hasPermission('canManageAuthorisationCode') && data.amount > 10000.

De plus, la plateforme ne filtre pas les Aggregates. Si un utilisateur n’a qu’un accès partiel à une liste de factures, cela doit être reflété dans les critères de la liste. Sinon, le backend bloquera l’accès à la liste entière.

La méthode de DAZZM peut limiter les utilisateurs dans la lecture et l’écriture de données gérées depuis les API natives ainsi que celles spécifiques à l’application. Elle combine les paramètres backend et frontend pour offrir une expérience utilisateur fluide. Côté backend, l’accès peut être retiré d’un Aggregate ou bloqué au niveau du champ. Par exemple, l’accès à l’aggregate Employee ou au champ Salary peut être révoqué. L’accès aux données est sécurisé au niveau du serveur, et l’interface utilisateur de l’application doit être conçue pour correspondre à l’accès de l’utilisateur. La plateforme masque automatiquement les champs auxquels un utilisateur ne peut pas accéder ; cependant, elle ne masquera pas automatiquement les labels d’aggregate. Par exemple, si un utilisateur n’a pas la permission de voir le salaire de l’employé, mais a accès à la page de détail de l’employé, le label du champ devra être masqué à l’aide d’un behavior Show Component Based On A Condition avec une condition Can Access.

Après mûre réflexion, DAZZM a opté pour tout ouvrir à tout le monde par défaut. Les applications qui ne nécessitent pas de rôles et permissions seront prêtes à l’emploi immédiatement. Il est plus facile d’ajouter des restrictions là où elles sont nécessaires que d’accorder des permissions partout. Cela place la responsabilité sur les Solution Creators de s’assurer que les règles Can Access sont appliquées correctement lors de l’ajout de nouvelles commands, pages et données. Si un utilisateur tente d’exécuter une command ou une API à laquelle il n’a pas accès, le système affichera un message d’erreur. Cependant, ce message est destiné au Solution Creator pendant la phase de test de Can Access.

Comment la plateforme réagit à différents scénarios

canAccess sur un champ dans une liste

La valeur disparaît dans la colonne lorsqu’un canAccess est appliqué au champ.

canAccess sur un champ dans une page

La valeur disparaît mais le champ reste visible à l’écran. Pour masquer le champ, ajoutez une condition de visibilité utilisant canAccess.

canAccess sur une command

L’interaction avec le champ ne déclenche pas la command.

canAccess sur un aggregate — message d’erreur

Voici ce qui se passe lorsque le front-end permet à un utilisateur d’accéder à une page de liste à laquelle il n’est pas autorisé.

Et voici ce qui se passe si un utilisateur tente d’accéder à une page de détail sans permission :

canAccess sur une page de détail

Depuis la liste, les utilisateurs ne peuvent plus cliquer pour voir les détails.

Même si l’utilisateur tentait d’accéder à la page via son URL, cela ne fonctionnerait pas.

canAccess sur une page de liste

Scénario : L’utilisateur peut accéder à la liste Opportunities mais ne peut pas ouvrir une page de détail de facture.

Dans cet exemple, l’utilisateur n’a pas accès à la page de détail depuis la barre latérale de l’application.

Même si l’utilisateur tente d’accéder à la page via l’URL, cela ne fonctionnera pas.

Comment filtrer une page de liste ?

La plateforme ne filtre pas les aggregates automatiquement, les développeurs doivent donc appliquer les conditions de filtrage nécessaires du côté de l’utilisateur.

En plus du CanAccess sur l’aggregate accountManager, la règle d’accès doit également être réimplémentée dans les critères de la liste, en utilisant un Set Component Data avec un critère pour que la liste n’affiche que les données autorisées.

Par exemple, nous pourrions filtrer la liste pour n’afficher que les comptes gérés par l’utilisateur. Pour ce faire, utilisez un Set Component Data avec des critères (account equal currentUser) sur la liste.

Mise à jour de CanAccess : actualisation automatique des permissions utilisateur lors de la modification des règles d’accès

Lorsque les rôles ou permissions d’un utilisateur sont mis à jour, la fonctionnalité CanAccess de DAZZM permet à l’application d’actualiser et d’appliquer automatiquement les nouvelles règles d’accès. Cependant, cette fonctionnalité nécessite une configuration préalable par le Solution Creator.

Il est important de comprendre que le système ne détecte pas automatiquement les changements au modèle de permissions, car ces règles sont implémentées en JavaScript. Par exemple, si une règle est définie dans canAccess pour une requête, spécifiant que seuls les utilisateurs du même département peuvent voir les données, cela pourrait s’exprimer comme :

currentUser.department.$isSame(data.department)

Comment le système sait-il quand actualiser l’application ?

Le système ne peut pas déduire qu’une action, telle que User::changeDepartment, affecte le champ currentUser.department utilisé dans canAccess. Pour remédier à cela, vous devez indiquer explicitement au système quelles actions ont un impact sur les permissions utilisateur en les marquant avec l’attribut Has impact on user access. Une fois cet attribut assigné, le système saura qu’il doit recharger l’application pour l’utilisateur affecté après l’exécution de l’action.

Par exemple, si le modèle User inclut un champ role et une command changeRole, la même procédure doit être appliquée à la command changeRole.

Que se passe-t-il lorsque les permissions d’un rôle sont mises à jour ?

Si un rôle, tel que le rôle « Manager », est modifié pour accorder l’accès à certaines données (par exemple, en activant la permission canViewFinancialData via la command Role:modifyPrivileges), vous devez également marquer la command modifyPrivileges avec l’attribut Has impact on user access pour s’assurer que le système sait que les permissions utilisateur ont changé et qu’une actualisation est requise.

Comment le système identifie-t-il les utilisateurs à actualiser ?

Pour spécifier quels utilisateurs doivent être actualisés, vous devez assigner l’attribut Impacted users à la command pertinente. Cet attribut doit retourner une liste de tous les utilisateurs affectés par la modification. Par exemple, dans un scénario où un rôle est modifié, le système actualisera tous les utilisateurs assignés à ce rôle.

Plutôt que d’utiliser une command de recherche, vous pouvez référencer directement un champ qui contient la liste des utilisateurs affectés.

L’attribut Impacted users garantit que seuls les utilisateurs directement affectés sont actualisés, minimisant les perturbations pour les autres. En conclusion, il est crucial de noter que l’attribut Impacted users est obligatoire. Sans lui, l’actualisation automatique ne sera pas déclenchée pour les utilisateurs actuellement en session.

Limitations et feuille de route

Certaines fonctionnalités ne sont actuellement pas supportées, ce qui pourrait entraver le déploiement de la solution dans un environnement de production. Premièrement, le contrôle d’accès ne régit pas les métriques, ce qui a un impact à la fois sur l’interface utilisateur et sur les API sous-jacentes. En conséquence, un utilisateur authentifié disposant d’une expertise technique suffisante pourrait potentiellement invoquer l’API pour récupérer des données que ses permissions restreindraient normalement. Pour atténuer cela, les concepteurs de solution doivent développer des tableaux de bord qui ajustent la visibilité selon l’accès de l’utilisateur. De plus, il n’existe actuellement aucune méthode pour créer des métriques qui tiennent compte du contrôle d’accès, comme générer un graphique qui n’affiche que les données des projets accessibles à l’utilisateur actuel.

Cette limitation présente un défi important pour la conception de la plateforme ; pour l’instant, aucune solution identifiée ne permet de la résoudre.

De plus, JavaScript est requis pour configurer l’accès, car l’attribut canAccess ne supporte que les expressions JavaScript.

Statut : Avant d’introduire une alternative no-code, nous souhaitons recueillir les commentaires des utilisateurs sur l’efficacité de la solution actuelle et analyser divers cas d’utilisation pour canAccess afin de déterminer l’approche no-code la plus appropriée.

Conclusion

La plateforme DAZZM offre un système robuste et flexible pour gérer l’accès des utilisateurs, permettant aux Solution Creators d’adapter les permissions pour répondre à des besoins métier spécifiques. En utilisant CanAccess pour les champs, commands et aggregates, vous pouvez contrôler l’accès avec précision et vous assurer que le système se comporte comme prévu. Cependant, les développeurs doivent être conscients des limitations et s’assurer de configurer manuellement certains aspects comme le filtrage des aggregates et les mises à jour automatiques des permissions.