Les systèmes logiciels de gestion de projets multiples sont complexes - du moins dans les coulisses, du côté technique. Une multitude de fonctions doivent être fournies pour la planification des projets individuels, la gestion des tâches, la création de rapports, pour n'en citer que quelques-unes. En même temps, il n'y a pas qu'un seul utilisateur qui travaille avec. Non, il y a généralement des dizaines d'utilisateurs qui se partagent toutes ces fonctions et les données du système, et qui travaillent souvent avec celui-ci simultanément et depuis différents endroits. Et bien sûr, l'application doit être "super facile" à utiliser pour toutes les personnes concernées et offrir une excellente expérience utilisateur, en fonction des besoins de l'entreprise, bien entendu.

Les systèmes multi-utilisateurs nécessitent un concept d'autorisation

Avec cette position de départ, il n'est pas surprenant que le système logiciel recherché doive avoir un concept d'autorisation flexible mais aussi facilement compréhensible. Qu'entendons-nous par là ? Dans le contexte d'un système logiciel, un concept d'autorisation est simplement défini,

1. quel utilisateur
2. à quelles données
3. quel type d'accès.

Cela soulève plusieurs questions de compréhension qui doivent être expliquées. Tout d'abord, l'utilisateur du système doit être identifié par le système. C'est ce qu'on appelle aussi l'authentification. L'utilisateur se connecte au système en disant qui il est et le système lui demande de le prouver. Cela semble compliqué, mais nous le faisons plusieurs fois par jour en saisissant notre nom d'utilisateur et son mot de passe dans une fenêtre de connexion. Avec le nom d'utilisateur, je dis au système qui je suis, et avec le mot de passe, je fournis la preuve. Ce processus simple est appelé authentification. Si nous voulons renforcer la sécurité, nous exigeons un peu plus de preuves de la part de l'utilisateur, par exemple en lui demandant de saisir un code supplémentaire à usage unique que le système envoie à son téléphone portable. C'est là que nous parlons ensuite de l'authentification à deux facteurs. Mais ce n'est pas le sujet ici.

Qu'est-ce qu'une autorisation ?

Avec l'authentification, nous savons maintenant qui nous avons en face de nous. Mais qu'est-ce que cet utilisateur est autorisé à faire dans le système ? C'est là qu'intervient l'autorisation , c'est-à-dire l'attribution d'autorisations concernant les données et les fonctions contenues dans le système. Maintenant, cela devient un peu plus compliqué (du moins d'un point de vue technique). Fondamentalement, vous définissez un ensemble de base d'autorisations (également appelées permissions ). À partir de ce pot, vous attribuez ensuite un certain nombre de permissions à l'utilisateur. Jusqu'à présent, tout va bien. Mais qu'est-ce qu'une permission ?

Il s'agit du premier défi majeur dans ce domaine. Une autorisation peut être définie de plusieurs manières différentes. Quelques exemples :

• Voir un projet
• modifier une tâche
• générer un rapport
• créer un nouvel utilisateur
• attribuer une autorisation

Le dernier exemple montre que les autorisations fonctionnent même de manière récursive : Nous pouvons définir des permissions qui permettent d'accorder d'autres permissions..... Mais les premiers exemples sont également intéressants, car ils nous montrent qu'une permission agit généralement sur un type d'objet (un projet, une tâche, un rapport, etc.) et implique une action (visualiser, modifier, générer, etc.). En gros, nous pouvons simplement dresser la liste de tous les types d'objets de données dans notre système et prendre toutes les mesures possibles à cet égard. Les combinaisons de ces éléments donnent ensuite l'ensemble des autorisations de base. Aussi simple que cela soit à écrire, c'est complexe dans la réalité. Même les systèmes de stockage de données simples contiennent des dizaines de types d'objets et de nombreuses actions différentes sont possibles sur ceux-ci. La simple multiplication de ces ensembles conduit à une explosion des possibilités. Ajoutez à cela le fait que vous souhaitez naturellement accorder des permissions sur des objets individuels (c'est-à-dire des instances de types d'objets). Par exemple, "changer le projet X", et non pas généralement "changer les projets". Cela ajoute une autre dimension de complexité.

Cette pléthore d'autorisations doit être bien structurée afin d'en avoir la maîtrise et d'en assurer le suivi. Ce que nous pouvons faire, par exemple, est le suivant. Les autorisations peuvent être liées les unes aux autres dans une structure arborescente. Une permission B peut être définie comme une branche d'une permission A. De cette façon, nous exprimons que si un utilisateur est autorisé à faire B, alors implicitement il est aussi autorisé à faire A. Encore un exemple simple : "B = modifier un projet" et "A = modifier une tâche". Ainsi, si un utilisateur est autorisé à modifier un projet, il doit implicitement modifier aussi toutes les tâches qu'il contient. On peut procéder de la même manière avec les actions : "B = modifier un projet" et "A = visualiser un projet". Ici aussi, la permission B implique la permission A, c'est-à-dire que si quelqu'un est autorisé à modifier un projet, il est également autorisé à le visualiser (clairement).

Comment un utilisateur obtient-il ses permissions ?

Partons donc du principe que nous avons défini et structuré l'ensemble des autorisations de base et que nous les connaissons donc. Comment puis-je maintenant les attribuer à un utilisateur ? À première vue, on pourrait faire une attribution directe. Par exemple : "L'utilisateur Meier a les permissions B, D, E et H". C'est facile à comprendre - mais seulement parce que l'exemple est si trivial. Là encore, la complexité réside dans le nombre de combinaisons possibles. Si nous avons des dizaines, voire des centaines d'utilisateurs et beaucoup plus de permissions, nous devons gérer des tables de permissions d'une taille exorbitante. La disparition de la vue d'ensemble est alors garantie. Le problème peut être éliminé si vous vous contentez d'un petit ensemble d'autorisations de base. Mais, par expérience, nous pouvons dire que chaque acheteur de tels systèmes logiciels exige tellement de flexibilité en termes de "contrôle et de surveillance de l'accès" qu'il faut une meilleure solution.

La meilleure solution est celle qui fonctionne avec des rouleaux . Cette approche remonte au début des années 1990 et a fait ses preuves dans la pratique. Il est utilisé dans de nombreux systèmes de gestion des données, si ce n'est la plupart. Cette approche est connue sous le nom de contrôle d'accès basé sur les rôles (RBAC). Le principe peut être expliqué comme suit : Nous définissons différents rôles (par exemple, chef de projet, gestionnaire de portefeuille, administrateur système), puis nous attribuons des autorisations à ces rôles. Ce n'est qu'ensuite que nous prenons les utilisateurs et leur attribuons un ou plusieurs rôles. De cette façon, les utilisateurs obtiennent leurs autorisations indirectement par le biais de leurs rôles. Ce principe a le grand avantage de me permettre de gérer plus facilement l'interaction entre les utilisateurs et les autorisations, notamment en cas de modifications. Et comme nous le savons tous, il y a souvent des changements. Ainsi, si je veux révoquer l'autorisation des chefs de projet de changer de projet, je le fais sur le rôle "chef de projet". Tous les utilisateurs ayant ce rôle ont alors immédiatement les permissions modifiées.

Il faut donc une structure adéquate

C'est le grand nombre de possibilités de définir des autorisations et de les attribuer aux utilisateurs qui rend la question si complexe. Toutefois, avec une structure sophistiquée, c'est-à-dire un bon concept d'autorisation, nous pouvons relever ce grand défi. Les explications ci-dessus ne font qu'effleurer le sujet et le simple exemple de l'introduction des rôles n'a nullement pour but de donner l'impression qu'il s'agit du dernier mot en matière de sagesse. C'est une approche possible et bonne. Ce que nous n'avons pas non plus abordé ici, c'est la visualisation de l'ensemble des états et des fonctionnalités du système du point de vue de l'utilisateur. Comment un administrateur système peut-il facilement gérer les utilisateurs, les rôles et les autorisations et être toujours sûr qu'il a effectivement effectué les bons réglages ? Nous irons au fond de cette question dans un prochain article et montrerons comment nous résolvons ce problème en utilisant PQFORCE. Alors restez à l'écoute.