Memoire Online - Confidentialité et ergonomie, personnaliser l'accès au SIRH avec RBAC

Les concepts sous-jacent de l'intentionnalité sont maintenant utilisées dans la mis au point de systèmes multi-agents (SMA). Elle peut nous aider à établir le modèle comportemental de l'utilisateur (buts, plans d'action, rôles...).

Le terme intentionnalité dérive du terme latin intendo qui signifie pointer vers, se diriger vers.

Donald Davidson, dans l'article « Intending », discute de façon approfondie la question des intentions dirigées vers le futur (Davidson 1980) .L'article commence par une mise au point sur la théorie des intentions dans l'action et de la rationalisation des actions :

ï L'ergonome a besoin d'expliquer une action, c'est-à-dire de la rationaliser, et de trouver une raison de l'action qui ait pu la causer ;

ï Rationaliser, c'est reconstruire un raisonnement pratique dont l'action est la conclusion ;

Ce point identifie les valeurs et les désirs : accorder de la valeur à la réalisation d'une certaine action revient, selon Davidson, à désirer cette réalisation.

ï Un raisonnement pratique ne comporte rien d'autre que des et des assertions pratiques (exprimant les croyances pratiques).

Le dernier point exclut que des états spécifiques, comme des volitions^5(*), puissent figurer dans un raisonnement pratique : « agir avec une intention ne requiert pas qu'existe quelque acte mystérieux de la volonté que ce soit, ni d'attitudes ou d'épisodes spéciaux de vouloir. La théorie n'a besoin que des désirs (ou d'autres pro-attitudes), des croyances, et des actions elles-mêmes ».

Pour MICHAEL BRATMAN l'intention est bien plus qu'une rémanence des choix commis.

Dans son ouvrage (Bratman 1987) il place l'intention au coeur de la prise de décision. Pour lui, la modélisation au moyen des seules notions de désir et de croyance est insuffisante. Il considère la notion d'intention comme intrinsèquement liée à celle de plan. Il dénonce en outre l'ambiguïté de ce second concept dont il donne deux définitions différentes. Selon lui, un plan peut être une structure abstraite identifiant une fonction qui lie un enchaînement d'actions à une situation. C'est le sens le plus communément adopté. Mais il définit aussi le plan comme une structure comprenant en plus des états mentaux. Dans ce second cas, un plan contient, en plus d'une représentation d'un enchaînement d'action, des états mentaux spécifiques à ce plan, tels que des croyances, des désirs. Pour résumer la proposition de BRATMAN, nous pourrions synthétiser le rôle de l'intention dans le processus de prise de décision en trois points :

ï l'intention participe à la recherche d'un plan permettant d'atteindre le but fixé selon les ressources disponibles ;

ï l'intention contraint les plans envisageables (l'entité ne peut avoir d'intentions contradictoires) ;

Un plan est partiel : il ne décrit pas avec précision l'activité qu'il doit guider. Un plan est la composante de l'activité qui traduit la consistance de cette même activité avec nos intentions / désirs.)

Le plan est en effet partiel : ce qui a été fait n'est su qu'après l'activité. Il n'y a pas d'instructions dans le plan. (Suchman 1987)

Cette notion de plan est reprise dans HRA Suite 7. Un Plan HRa définit dans une langue donnée pour chaque catégorie d'acteur (employé, manager, professionnel RH) les domaines et thèmes RH qui les concernent ainsi que les actions fonctionnelles correspondantes.

- la barre de navigation comportant les actions fonctionnelles et activités regroupées par thèmes,

Les critères ergonomiques ont trois caractéristiques qui les distinguent d'autres activités ergonomiques et en font un outil de choix:

· Ils sont basés sur une analyse de l'interface, activité plus rapide et moins dispendieuse que les tests d'utilisabilité;

· Ils sont utilisables par des non-spécialistes du domaine de l'utilisabilité;

· Ils sont explicites pour permettre des mesures précises, puis standardisés pour donner des résultats reproductibles. (Scapin et Bastien 1993)

· Compatibilité : Capacité du système à s'intégrer dans l'activité des utilisateurs. Il s'agit pour nous de ne fournir à l'utilisateur seulement les écrans nécessaires à son rôle.

· Guidage : Faciliter l'utilisation du système et son apprentissage. Aider l'utilisateur a accomplir son plan et réaliser son intention.

· Flexibilité : Capacité de l'interface à s'adapter à différents contextes d'utilisation. La structure de l'interface utilisateur a été étudiée pour être homogène et flexible puisque cette structure est identique pour toutes les catégories d'acteur.

· Contrôle utilisateur : Concerne le degré de contrôle de l'utilisateur sur les traitements réalisés par le système. Nous avons indiqué en page 29 qu'un rôle était caractérisé par des droits (concerne l'accès aux données et aux processus métiers). Ces droits déterminent les traitements auxquels l'utilisateur à droit et peut enclencher.

· Traitements des erreurs : Regroupe les différents moyens visant à protéger l'utilisateur des erreurs et à corriger celle-ci. Le fait de ne pas donner les droits d'accès à des tâches pour lequel l'utilisateur n'est pas compétent et de pouvoir restreindre les droits de mise à jour limite les risques d'erreur.

· Concision : Ensemble des moyens visant à réduire la charge perceptive et mnésique de l'utilisateur. Notre objectif de réduire le nombre le page accessible à l'utilisateur répond totalement à ce critère.

Cette sélection de critères nous servira à évaluer à la fin de notre étude la pertinence des rôles dans l'ergonomie de l'application.

Pour répondre de façon satisfaisante aux critères d'ergonomie, nous avons besoin de connaitre le contexte de l'utilisation. Le contexte peut être décrit par un ensemble d'interaction.

La Théorie de l'activité

La théorie de l'activité est une manière de décrire et de caractériser les structures de l'activité humaine de toutes sortes. D'abord présenté par les psychologues russes Rubinshtein, Leontiev, et Vigotsky au siècle dernier, la théorie de l'activité plus récemment a gagné une attention croissante parmi les designers et les ergonomes. Pour les ergonomes, le grand potentiel de la théorie de l'activité est de fournir un modèle organisé et cohérent pour examiner, décrire, et comprendre le plus grand nombre de contexte d'activité dans lesquelles l'usage d'un outil logiciel ou de tout autre objet est inclut. Pour que ce potentiel soit entièrement réalisé cependant, les formulations et les expressions un peu vagues de cette théorie de l'activité ont du être reformulé pour être plus précise et accessible.

Dans une formulation qui a été largement copié, la structure de l'activité humaine est schématiquement représentée comme dans le diagramme de la Figure 20. La perspective originale, représentée par le triangle supérieur dans le diagramme, est que cette activité humaine est exécutée par les agents (le sujet) motivé vers la solution d'un problème ou par un but (l'objet ou le motif). Il agi en médiateur par ses outils (les objets) dans un procédé transformationnel produisant un résultat (l'issue). d'Engeström (Engeström, Miettinen et Punamäki 1999) a élaboré cette perspective en ajoutant les éléments dans la moitié inférieure du diagramme, impliquant que toute activité a lieu dans un contexte social (la communauté) avec les responsabilités différenciées (les rôles ou la division de travail) contraint par les facteurs socio-culturels et de procédure (les règles).

Pour comprendre les interactions, la théorie de l'activité et le modèle d'Engeström (Engeström, Miettinen et Punamäki 1999) peuvent nous fournir un cadre de réflexion intéressant.

Figure 20 : modèle d'Engestrom d'analyse de l'activité et des relations médiatrices

Pour illustrer notre propos, Arthur (sujet) doit saisir ses congés (objet). Arthur doit s'authentifier (règles). L'acquisition et la saisie des congés sont aussi soumises à des règles (de gestion). Dans le SIRH, les unités organisationnelles peuvent être considérées comme des « communautés » et ainsi servir à différencier les règles, les sujets ou les objets. Les instruments seront les écrans, l'application, les traitements informatiques. Ce modèle est intéressant pour comprendre les interactions. Le point d'entrée de notre étude est le sujet.

Par rapport à notre modèle conceptuel des données du SIRH : sont modélisé comme dossier de gestion, le sujet (le salarié) et la communauté (l'unité organisationnelle). Les « objets » sont des attributs des éléments du modèle. Les instruments et les règles sont des moyens de traitements des dossiers de gestion.

En continuant notre transformation du modèle, nous pensons que les relations médiatrices passent par des contraintes contextuelles qui décideront des permissions accordées aux rôles du sujet.

Notre objectif est de trouver un moyen définir l'accès aux entités du système afin d'une part d'en limité l'accès pour assurer la confidentialité des données et d'autre part de fournir un environnement de travail orienté métier en ne donnant accès qu'aux écrans utile au rôle de l'utilisateur.

Maintenant que nous avons une vision claire de ce qui doit être accessible en terme de confidentialité et d'ergonomie. Il nous faut maintenant définir ce qui va supporter les contraintes contextuelles qui décideront des permissions accordées. Pour cela nous allons étudier le contrôle d'accès basé sur les rôles. Le modèle R-BAC (Role Based Access Control) propose de structurer l'expression de la politique d'autorisation autour du concept de rôle ..

Un rôle est un concept organisationnel : des rôles sont affectés aux utilisateurs conformément à la fonction attribuée à ces utilisateurs dans l'organisation. Le principe de base du modèle R-BAC est de considérer que les autorisations sont directement associées aux rôles. Dans R-BAC, les rôles reçoivent donc des autorisations de réaliser des actions sur des objets. Comme nous l'avons vu en page 15, le modèle R-BAC ne considère que des autorisations positives (permissions) et fait donc l'hypothèse que la politique est fermée. Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir réaliser une action sur un objet, un utilisateur doit d'abord créer une session et, dans cette session, activer un rôle qui a reçu l'autorisation de réaliser cette action sur cet objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur aura la permission de réaliser cette action sur cet objet une fois ce rôle activé. Lorsqu'un nouveau sujet est créé dans le SI, il suffit d'affecter des rôles au sujet pour que ce sujet puisse accéder au SI conformément aux permissions accordées à cet ensemble de rôles. Comparé au modèle I-BAC que nous avons vu pour Définir des Modèles d'autorisations dynamiques et contextuelles ci-dessus en page 14, la gestion de la politique d'autorisation s'en trouve simplifiée puisqu'il n'est plus nécessaire de mettre à jour cette politique chaque fois qu'un nouveau sujet est créé. Dans le cas général, n'importe quel ensemble de rôles peut être affecté à un utilisateur et un utilisateur peut activer dans une session n'importe quel sous-ensemble des rôles qui lui ont été affectés. Le modèle R-BAC introduit la notion de contrainte pour spécifier des politiques d'autorisation incluant des situations plus restrictives. Ainsi, une contrainte de séparation statique spécifie que certains rôles, par exemple médecin et infirmier, ne peuvent pas être simultanément affectés à un utilisateur. Une contrainte de séparation dynamique spécifie que, même si certains rôles peuvent être affectés à un même utilisateur, par exemple médecin libéral et chirurgien, ces rôles ne peuvent pas être activés simultanément dans une même session. Dans R-BAC, il est également possible d'organiser les rôles de façon hiérarchique. Les rôles héritent les autorisations des autres rôles qui leur sont hiérarchiquement inférieurs. Lorsqu'un rôle r1 est hiérarchiquement supérieur à un rôle r2, on dit que r1 est un rôle senior de r2. Le modèle R-BAC constitue aujourd'hui un standard.

Une terminologie s'est développée pendant les dernières 3 décennies pour décrire les modèles et les systèmes de contrôle d'accès. Presque n'importe quel modèle de contrôle d'accès peut être énoncé formellement en utilisant les notions des utilisateurs, les sujets, les objets, les opérations, et les permissions, et les rapports entre ces entités. Il est important de comprendre ces limites, parce que le lecteur les rencontrera non seulement dans notre mémoire mais également dans la majeure partie de la littérature sur le contrôle d'accès et la sécurité informatique.

Le périmètre de l'utilisateur se réfère aux personnes qui se connectent par une interface au système informatique. Dans beaucoup d'applications, il est possible qu'un utilisateur simple ait de multiples identifiants, et ces identifications peuvent être ouvertes simultanément. Les mécanismes d'authentification rendent cela possible. Une instance de dialogue d'un utilisateur avec un système s'appelle une session.

Un objet peut être n'importe quelle ressource accessible sur un système informatique, y compris des dossiers, des périphériques tels que des imprimantes, des bases de données, et des entités à grain fin telles que différents champs dans des disques de base de données. Des objets sont traditionnellement regardés en tant qu'entités passives qui contiennent ou reçoivent l'information, bien que les mêmes modèles tôt de contrôle d'accès aient inclus la possibilité de traiter des programmes, des imprimantes, ou d'autres entités actives comme objets.

Une opération est un processus actif appelé par un sujet. Les premiers modèles (tel que I-BAC) de contrôle d'accès qui ont été concernés strictement par les contrôle de flux de l'information (c.-à-d., l'accès en lecture/écriture) ont appliqué le terme de sujet à tous les processus actifs, mais les modèles de R-BAC exigent une distinction entre le sujet et l'opération.

Les permissions (ou les privilèges) sont des autorisations pour effectuer certaines actions sur le système. Comme utilisé dans ce livre, et dans la plupart de la littérature sur la sécurité informatique, le terme de permission se rapporte à une certaine combinaison d'objet et d'opération. Une opération particulière utilisée sur deux objets différents représente deux permissions distinctes, et de la même façon, deux opérations différentes appliquées à un objet simple représentent deux permissions distinctes.

Dans leur ouvrage de référence (Ferraiolo, Kuhn et Chandramouli 2003) D. Ferraiolo et al. Fournissent une description formelle du modèle R-BAC.

Description formelle originale de R-BAC

Pour chaque sujet, le rôle actif est celui qui est actuellement l'objet en utilisant:

AR (s :sujet) = (Le rôle actif de sujet s)

Chaque objet peut être autorisé à effectuer un ou plusieurs rôles:

RA (s :sujet) = (Autorisé rôles pour objet s)

Chaque fonction peut être autorisé à réaliser une ou plusieurs opérations:

TA(r :rôle) = (Transactions autorisées pour rôle r)

Les Sujets peuvent exécuter des transactions. Le prédicat exécuter(s, t) est vraie si et seulement si l'objet peut exécuter la transaction t à l'heure actuelle, sinon, elle est fausse:

Exécuter(s :sujet ;t :transaction) = [Vrai si sujet s peut exécuter transaction t]

1. Rôle de la mission: Un sujet peut exécuter une transaction que si le sujet a été choisi ou assigné un rôle:

s : sujet,t : tran ? exec(s,t) \u8658Ë AR(s) ? ?

2. Rôle d'autorisation: Un rôle actif du sujet doit être autorisé pour le sujet:

s : subject ? AR(s) \u8838° RA(s)

3. Autorisation de la transaction: un objet peut exécuter une transaction que si l'opération est autorisée pour le rôle actif du sujet:

s : subject,t : tran ? exec(s,t) \u8658Ë t \u8712 TA(AR(s))

Notez que, parce que la condition de l'article 3 est «seulement si», cette règle prévoit la possibilité que des restrictions supplémentaires puissent être mises sur l'exécution des transactions.

Cette règle ne constitue pas une garantie pour une transaction d'être exécutable seulement parce que c'est une TA [AR (s)]. L'ensemble des transactions sont potentiellement exécutables par le rôle actif du sujet. Par exemple, un stagiaire pour un rôle de supervision peut être assigné au rôle de superviseur, mais peut avoir des restrictions appliquées à son rôle, qui limitent les transactions accessibles à un sous-ensemble de ceux qui sont normalement autorisés pour le rôle de superviseur.

Le modèle brut de R-BAC est défini de façon formelle dans les tableaux suivant :

UTILISATEURS, RÔLES, OPS et OBS : (Respectivement Utilisateurs, les rôles, les activités et les objets)

AU UTILISATEURS X ROLES : une relation n,n entre utilisateur et rôle (relation d'assignation d'un utilisateur à un rôle).

Utilisateurs_assignés : (r :ROLES) 2^utilisateurs, application du rôle à un ensemble d'utilisateurs. Formellement Utilisateurs_assignés(r) = {u UTILISATEURS | (u,r) AU)

PRMS = 2^(OPSxOBS), l'ensemble des permissions.

PA PRMS X ROLES, relation n,n entre permissions et rôles (relation d'assignation rôle-permission).

Permission_assignées (r :ROLES) 2^PRMS, l'application du rôle r à un ensemble de permission. De façon formelle Permission_assignées (r :ROLES)= {p\u8712PRMS|(p,r)\u8712PA}

SUJETS : l'ensemble des sujets.

Utilisateur_sujet (s :SUJET) UTILISATEUR, l'application des sujets s à l'ensemble des utilisateurs associés aux sujets.

Roles_sujet(s :SUJET) 2^ROLES, l'application de sujets s à un ensemble de rôle. Soit Roles_sujet(s_i) {r \u8712 ROLES|(Utilisateur_sujet(s_i),r) \u8712 AU}

Propriété 1 : autorisation du rôle = Un sujet ne peut jamais avoir un rôle actif qui n'est pas autorisé pour son utilisateur.

\u8704Í s:SUJETS, u : UTILISATEURS, r :ROLES

r \u8712 roles_sujet(s) ^ u \u8712 utilisateur_sujet(s) \u8658Ë u \u8712 utilisateur_assigné(r)

? acces: SUJETS × OPS × OBS ? BOOLEAN;

? acces(s, op, o) = 1 Si le sujet peut accéder à l'objet sur l'opération en utilisant op, sinon 0

Propriété 2 : autorisation s'accès à l'objet = Un sujet s peut effectuer une opération op sur objet O seulement si il existe un rôle r qui est inclus dans le sujet du rôle actif fixés et il existe une permission qui est attribué à r tels que la permission autorise l'exécution d'op portant sur O .

s:SUJETS, op:OPS, o:OBS

access(s, op, o) \u8658Ë \u8707Îr: ROLES, p:PRMS r \u8712 roles_sujet ^ p \u8712 permissions_assigné(r) ^ (op, o) \u8712 p

Ces descriptions formalisées ne favorisent pas la créativité. Nous allons illustrer notre propos avec le schéma suivant :

Nous avons identifiés plusieurs éléments pour construire ce modèle conceptuel. Il s'agit de :

Un utilisateur déclaré dans l'annuaire d'entreprise devant avoir accès à l'application. C'est à lui que sera attribué un rôle.

Par exemple, une action fonctionnelle peut être une action concernant l'état civil d'un individu, l'historique des absences, les données professionnelles.

Dans notre modèle R-BAC, les permissions d'exécution concernent les actions fonctionnelles. Il ne concerne pas le lancement d'exécutable comme sur un micro-ordinateur.

Elles vont nous aider à créer une association entre un ensemble de caractéristiques métiers et un rôle.

Exemple : si métier=Expert_recrutement et Unité Organisationnel = Siege alors rôle = Expert_recrutement siège

Une caractéristique permettant de définir le métier ou le domaine de responsabilité au sein de l'organisation

Organisation au sein de l'entreprise. L'unité organisationnelle est la plus petite entité d'organisation dans une structure organisationnelle. Il s'agit d'un rôle ou d'une position tenue par une entité organisationnelle (personne, machine ou système informatique) (Vernadat 1996).

La granularité de la définition de l'organisation dépendra de la volonté de délimité les périmètres de chacun. Comme nous l'avons dans la définition formelle de R-BAC, l'organisation n'est pas prise en compte. Elle le sera dans les versions étendues de R-BAC. Or comme nous le verrons plus loin l'unité organisationnelle est une contrainte contextuelle importante pour le SIRH.

C'est un environnement structurel et événementiel qui sert de cadre. C'est aussi un sous-ensemble du champ d'application des permissions. Cet élément nous semble important, nous allons le développer plus loin dans notre étude en particulier avec le concept de contraintes contextuelles qui permettront de combler les lacunes du modèle initial de R-BAC.

Il s'agit de déterminer de façon manuelle ou automatique les incohérences et les incompatibilités entre différentes permissions et/ou différents rôles et/ou différents couples (rôles, organisations).

Un risque est la possibilité d'être exposé aux conséquences néfastes d'événements futurs. Dans le cadre de R-BAC, il s'agit de la définition du mode d'application de l'exclusion en fonction de la criticité du risque associé.

Les rôles peuvent être hiérarchisés entre eux comme nous l'avons vu en page 50 dans Assembler l'authentification à l'autorisation. L'héritage d'une permission (d'un droit) permet à un utilisateur de se voir reconnaître son droit parce que soit son rôle soit son organisation en hérite. Cette notion permet de réduire très significativement le nombre de règles pour définir l'ingénierie des rôles.

L'héritage par les rôles fait partie du modèle R-BAC. Il permet de s'assurer qu'un rôle possède bien tous les droits associés aux rôles qu'il inclue.

Ainsi si le rôle « Expert Dossier Administratif » contient le rôle « Expert RH » et le rôle « Dossier Administratif », le rôle « Expert Dossier Administratif » héritera des droits et permissions associés aux rôles « Expert RH » et « Dossier Administratif » en plus de ses droits et permissions propres.

L'héritage par les organisations permet d'affecter à toute une organisation un droit ou une permission particulière.

Un utilisateur qui appartient à une organisation appartient « d'une certaine manière » à tous les noeuds de cette organisation. Il peut donc se voir affecter des droits associés.

Un utilisateur affecté à une unité organisationnelle de niveau 1 (Siège) peut voir toutes les UO subordonnées (niveau > 1). Un utilisateur affecté à une UO de niveau 3 peut voir le UO de niveau inférieur ou égale à 3 sous réserve qu'il appartienne au groupe d'acteur "manager" ou "expert RH".

Ce type d'héritage se positionne au niveau des utilisateurs pour leur permettre d'hériter d'applications associées aux organisations sous-jacentes. Cet héritage permet à l'utilisateur d'une organisation parente de pouvoir effectuer les mêmes opérations que les utilisateurs des organisations sous-jacentes.

L'héritage s'applique aussi sur les couples (rôles, organisation) par application des règles associées aux rôles et aux organisations. Par exemple, si l'on affecte au couple (rôle=professionnel RH, organisation=Siège) le droit d'accéder l'action fonctionnelle "Saisir éléments de Paie", ce droit s'appliquera à :

· Tous les Professionnels RH du siège sous-jacent (héritage par l'organisation).

· Tous les responsables Professionnels RH de la Direction générale (héritage par les rôles).

· Tous les responsables Professionnels RH des organisations sous-jacentes (directions fonctionnelles reliés au siège).

Les exclusions permettent de définir au niveau de la politique de sécurité des accès les règles de séparation des tâches (en anglais « segregation of duties »). Le modèle R-BAC étendu permet de définir des règles avancées d'exclusion qui peuvent combiner des ensembles de rôles, de couples (rôles, organisation), de permissions et de couples (permission, organisation)...

Il est ainsi possible, par exemple, d'empêcher qu'un utilisateur soit à la fois gestionnaire administratif de son unité organisationnelle et puisse saisir ses propres éléments de paie.

Nous allons regrouper les concepts définit précédemment au sein d'un schéma récapitulatif.

Ce que la plupart des spécialistes reprochent à R-BAC, c'est qu'il n'y a pas de prise en compte de l'organisation. Chacun reprend le noyau de R-BAC et lui implémente des contraintes supplémentaires. Il nous faut donc voir comment ajouter ces contraintes supplémentaires. Comme l'ont souligné (Saidani et Nurcan 2007) la prise en compte du contexte de l'utilisateur permet de répondre aux besoins de flexibilité des processus d'entreprise. Le résultat est une variabilité du comportement en fonction du contexte. Dans le cadre de notre étude, nous pensions initialement que le contexte changerait avec le rôle. C'est le rôle qui donne les éléments du contexte, si un paramètre du rôle change, le contexte changera grâce aux contraintes contextuelles que nous allons maintenant définir.

Figure 26 : Taxonomie des contraintes contextuelles d'après (Saidani et Nurcan 2007)

En principe, R-BAC s'appuie sur la définition des contraintes conventionnelles dans les différentes parties du modèle R-BAC (Ferraiolo, Kuhn et Chandramouli 2003). Toutefois, les premiers efforts de recherche concernant R-BAC ont porté principalement sur les contraintes de séparation des droits. Avec l'intérêt croissant pour R-BAC, la recherche se rapportant à d'autres types de contraintes sur R-BAC a aussi gagné en importance [voir, par exemple, La gestion des identités et des accès en page 15]. Dans ce document, nous allons détailler les contraintes contextuelles de R-BAC. Ensuite, nous décrirons certaines dimensions pour la catégorisation des contraintes R-BAC qui nous semble pertinente. Ensuite, nous utiliserons ces dimensions pour expliquer notre définition du contexte. Au début, nous faisons une distinction entre les contraintes statiques et dynamiques:

· Les contraintes Statiques sont les contraintes qui peuvent être évaluées par des "temps d'administration" d'un modèle R-BAC, par exemple, la contrainte de séparation des fonctions statique (SSD) qui précise que deux rôles sont mutuellement exclusifs et ne doivent jamais être attribué à un même sujet en même temps.

· Les contraintes dynamiques ne peuvent être vérifiées qu'au moment de l'exécution en fonction des valeurs effectives d'attributs spécifiques ou par rapport à des caractéristiques de la session en cours. Par exemple, à cause de la séparation dynamique des fonctions qui définissent les contraintes réciproques que deux rôles exclusifs ne doit jamais être activées en même temps au sein de la même session utilisateur, ou que des contraintes de temps qui limitent à un rôle une activation spécifique par rapport à un intervalle de temps (par exemple, de 8 heures du matin à 8 heures du soir).

Un autre critère pour classer les contraintes R-BAC est la distinction entre facteurs endogènes (modèle intrinsèque) et exogènes (environnementaux) :

* ⁵ En psychologie acte ou conduite qui manifestent la faculté de se déterminer librement à agir ou à ne pas agir en vertu de motifs conscients et délibérés (Encarta® 2008 2007)

Confidentialité et ergonomie, personnaliser l'accès au SIRH avec RBAC

Intentionnalité

La Théorie de l'activité