|
Confidentialité et ergonomie, personnaliser l'accès au SIRH avec RBAC( Télécharger le fichier original )par Christophe THOMAS Université Paris 1 Panthéon Sorbonne - MASTER M2 Management Système d'information et de Connaissances 2008 |
Le modèle de scénario :Il se compose de tous les scénarios d'utilisation du système étudié. Il sert de modèle de base pour notre approche. Le catalogue des permissions :Il est constitué de toutes les permissions identifiées pour le système. Puisque les étapes du scénario sont associées avec des opérations d'accès, les permissions sont tirées des scénarios. Les permissions sont constituées des paires (opération, objet) et ont un identifiant unique. Nous retrouvons dans ce catalogue les écrans devant être accédé par les utilisateurs. Le catalogue des contraintes :Il contient les contraintes qui doivent être appliquées pour les permissions. Dans une application plus approfondit du processus, ce catalogue peut être enrichit des contraintes appliquées aux rôles (qui seront définit plus tard). La définition des contraintes contextuelles (Voir Les différentes catégories de contraintes dans R-BAC étudié ci-dessus en page 57) s'intégreront dans ce catalogue. Nous retrouverons dans ce catalogue les restrictions d'accès relatives à la confidentialité. Les définitions de tâches :Elles décrivent les tâches que doivent effectuer les utilisateurs avec le système étudié. Chaque tâche est composée d'un ou plusieurs scénarios qui sont exécutés séquentiellement ou en parallèle pour atteindre un but. Les profils de travail :Ils se composent des différentes définitions de tâches. Chaque profil de travail est unique. Il se veut une description complète de toutes les tâches qu'un utilisateur doit accomplir ou est autorisé à accomplir. Dans notre approche, c'est le rôle préliminaire à « R-BAC ». Nous détaillerons par la suite les différences entre nos profils de travail et les rôles R-BAC, ainsi que le processus pour extraire une hiérarchie de rôle R-BAC des profils de travail.
Figure 31 : composition d'un profil de travail Le modèle concret R-BAC :C'est le résultat final de l'ingénierie des processus. Il se compose de tous les rôles du système organisé en une ou plusieurs hiérarchies de rôle. Nous entendons par hiérarchie de rôles, les règles d'héritage des rôles seniors qui héritent des permissions et des contraintes de tout leur rôle junior. Notre dispositif pourra être résumé de la façon suivante :
Figure 32 : interrelation des modèles et des documents utilisés et produits dans le processus d'ingénierie des rôles Comme nous l'avons indiqué plus haut, les permissions ne sont pas explicitement associées avec les profils de travail. Elles peuvent être obtenues transitivement par les scénarios associés à un profil de travail ( voir Figure 31 : composition d'un profil de travail). C'est une différence essentielle entre les profils de travail et les rôles R-BAC, depuis que le dispositif R-BAC permet d'assigner directement les permissions aux rôles. De plus les profils de travail sont définis de façon autonome. Ils n'ont aucun lien direct entre eux. Puisqu'une tâche peut être assignée à plus d'un profil de travail et que chaque scénario peut être assigné à plus d'une tâche, il y a potentiellement de nombreuses redondances dans ces définitions de profils. C'est aussi une autre différence entre les profils et les rôles qui, eux, permettent des héritages hiérarchiques qui limite ces redondances. C'est en cela que les profils de travail peuvent être vue comme l'étape préliminaire des rôles R-BAC. Les liens de traçabilité : conçu pour le changement. Le modèle d'interrelation décrit en Figure 32 met en lumière les liens de traçabilité entre modèles (Gotel et Finkelstein 1994). Ces traces sont essentielles pour rendre efficace la gestion des modèles. Idéalement, cela permet de retrouver quelles permissions sont demandées dans un scénario aussi bien que de savoir dans quelle scénario (tâches, ou profil) utilise telle ou telle permission. Les liens de traçabilité facilitent la compréhension des modèles. Ils sont aussi des pré-requis pour une gestion du changement efficace. Ils assurent une propagation efficace des changements effectués dans les modèles. Par exemple si un nouveau scénario d'utilisation du système est défini, dans lequel nous devons assigner des tâches et des profils, cela pourrait mettre à jour le modèle R-BAC rattaché. D'autres liens de traçabilité pourraient être ajoutés comme : · « Concrétisé par » entre deux scénarios, · « Nécessaire pour exécuter » entre une permission et un scénario, · « Défini par » entre une contrainte et l'origine de cette contrainte, · « est une partie de » entre un scénario et une tâche, ou · « implémenté dans » entre un profil de travail et un rôle R-BAC. Malheureusement ce genre de liens, s'ils sont intellectuellement intéressant, consomment beaucoup trop de temps et complexifient le dispositif en le rendant plus difficile à gérer. Il ne faut donc retenir que les liens essentielles pour la gestion des modèles tels qu'ils ont été définis par (Neumann et Strembeck 2002). Néanmoins, il nous est apparu intéressant de signaler que nous pouvions gérer les liens de traçabilité lors du processus de conception. Mais la gestion de la traçabilité du processus de conception est un domaine de recherche à part entière avec le design rationale (Moran et Carroll 1996) et cela dépasse le cadre de ce mémoire. Nous allons vous détailler maintenant les sous-processus de (Neumann et Strembeck 2002) et voir comment les adapter dans le cadre d'une mise en oeuvre dans un SIRH. Dans ce sous-processus, les scénarios d'utilisation sont identifiés et formalisés. En premier, une phrase décrit l'objet du scénario : Exemple : « saisir les données individuelles de l'agent », « décrire le parcours de l'agent », « compléter le dossier ».
Figure 33 : sous-processus de formalisation du scénario Le scénario et ses séquences : il doit pouvoir répondre à l'ensemble des questions habituelles (QQCOQP : Qui, quoi, comment, où, quand, pourquoi)
Ces scénarios vont servir de base pour la dérivation des permissions et la définition des tâches et du profil de travail. Il est essentiel que chaque séquence soit explicitement décrite. Chaque scénario est décrit sous la forme structuré d'un tableau et peut être illustré d'un diagramme quand cela est nécessaire comme dans le cas d'un workflow de mise à jour. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
