Groupes et autorisations

La gestion des autorisations permet de prendre en compte des situations allant des cas les plus simples aux cas les plus complexes. Dans certains cas, une solide analyse peut être requise.

L'écran ci-dessous, outre le fait qu'il permette d'accéder à la définition des groupes et autorisations, illustre le schéma relationnel liant toutes les entités pour lesquelles des autorisations peuvent être mises en place.

Les grands principes

Les autorisations

Les autorisations ont pour objectif de "libérer" des fonctions de l'application Kentika. Exemple : "consulter une fiche document". Pour qu'une personne puisse voir une notice descriptive d'un document, il faut que cette personne appartienne à au moins un groupe auquel est affecté cette autorisation.

Les autorisations ont aussi pour objectif de "restreindre" certaines ressources. Exemple : "une maquette traitement de texte". Si aucune autorisation ne lui est affectée, elle est réputée "publique". Par contre, dès qu'une autorisation lui est affectée, pour qu'une personne puisse l'utiliser, il faut qu'elle appartienne à un groupe disposant de l'autorisation correspondante.

Les autorisations permettent de "brider" l'accès à certaines informations. C'est le seul cas où les autorisations fonctionnent en négatif. Ainsi, si vous voulez que certaines personnes ne puissent pas voir certaines informations (exemple : la rubrique " prix"), vous créez une nouvelle autorisation que vous nommez, par exemple, "tout public" ; vous mettez une restriction d'accès à la rubrique prix (voir "rubriques") ; puis vous affectez cette autorisation aux groupes correspondant aux personnes auquelles vous voulez masquer l'information.

Les groupes

Les groupes sont des "assemblages" d'autorisation. Les personnes sont rattachées à des groupes (et jamais en direct à des autorisations) et bénéficient de toutes les autorisations de tous les groupes auxquelles elles appartiennent. Au sein d'un groupe, une autorisation peuvent être limitée à un sous-ensemble (exemple : les documents du site de la personne).

Notion d' "héritage"

Les autorisations sont hiérarchisées. Le fait d'affecter une autorisation à un groupe fait que ce groupe bénéficie également de toutes les autorisations qui lui sont rattachées.

Exemple : dans la cas de la branche "document", les autorisations sont structurées de la manière suivante :

Code Intitulé

0301 Table document

030101 Ajouter un document

030102 Modifier un document

03010201 Consulter un document

03010202 Déclarer un exemplaire

030103 Supprimer un document

Si vous affectez l'autorisation "modifier un document" à un groupe, les personnes de ce groupe auront également le droit de "consulter un document" "ainsi que celui de "déclarer un exemplaire" mais n'auront pas pour autant le droit de "supprimer un document".

Notion de "corpus"

Une autorisation peut être limitée à un sous-ensemble de la base de données. Il existe trois notions de sous-ensemble :

• site
• collection
• thesaurus

Site : concerne les base de données exploitées en multi-site. Dans ce cas, une autorisation peut être donnée pour tous les sites, un site précis, le site de la personne connectée.

Collection : une collection (ou filtre) se définit par le résultat d'une requête. Les requêtes utilisables comme filtres sont celles ayant l'attribut "Autorisations" coché.

Requête utilisables comme "filtre"

Thesaurus : concerne les autorisations relatives au thesaurus

Notion de "valeur relative"

Une valeur relative est une valeur qui dépend d'autres valeurs. Une valeur absolue ne dépend pas du contexte.

Exemples de valeur absolue dans une requête :

Région = "Sud" ou "Est"

Date de parution > "1/1/2005"

Exemples de valeur relative :

Région = (une des valeurs de la rubrique région de la fiche personne)

Date de parution > (date du jour moins 2 ans)

Ecran de composition d'une requête "autorisation" : une des "régions" de la fiche "document" doit être égale à une des régions de la fiche "personne"

Ainsi, à partir d'une seule définition de filtre, il est possible d'engendrer autant de sous-ensembles que de combinaisons possibles de valeurs au niveau des utilisateurs.

Analyse préalable

Si vous êtes dans un environnement relativement simple, vous pouvez, après validation, utiliser les groupes pré-définis et les compléter en fonction de vos besoins.

Par exemple :

• Administrateur  : regroupant la ou les personnes possédant toutes les autorisations.
• Gestionnaires de base  : regroupant la ou les personnes possédant toutes les autorisations hormis celles de définir les groupes.
• Opérateurs de saisie  : regroupant les personnes chargées uniquement d’alimenter la base.
• Opérateurs de prêt  : regroupant les personnes chargées des opérations de prêts et retours.
• Opérateurs de commande  : regroupant les personnes chargées uniquement de la gestion des commandes, du budget et de la saisie des livraisons.
• Opérateurs revues  : regroupant les personnes chargées du bulletinage, des listes de circulation.
• Stagiaire  : à définir selon la mission.
• Guest  : profil chargé par défaut si aucun identifiant / mot de passe n’est saisi et si aucun utilisateur ayant "Guest" comme identifiant n'existe dans la base. Ce groupe doit donc contenir les accès minimum (consultation de la base tout public, dossiers documentaires, formulaires de recherche, etc).

Par contre, dans un environnement plus sensible, il conviendra de prendre un soin tout particulier dans le mise en oeuvre des autorisations d'accès.

Opérations de saisie

La gestion des groupes et des autorisations comprend trois onglets. Le premier est un schéma des liens qui existent entre toutes les entités mises en jeu dans la gestion des autorisations. Le deuxième permet de définir les groupes et autorisations rattachées ainsi que l'affectation de personnes. Le troisième permet de visualiser qui peut faire quoi et de créer le cas échéant de nouvelles autorisations.