Maarch Framework 3/Fonctionnalités/security fr

De Maarch // Wiki.

Sommaire 1 La gestion des sécurités dans Maarch Framework 3 1.1 Introduction 1.2 Définir le périmètre documentaire 1.2.1 Restreindre l'accès à l'archive pour un groupe 1.2.1.1 Modèle de données pour appliquer la sécurité sur le périmètre documentaire 1.3 Définir le profil d'utilisation 1.4 Définir le positionnement dans l'organisation 1.4.1 1ère étape : définir l'organisation des services 1.4.2 2ème étape : associer les utilisateurs aux entités 1.4.3 Utiliser les entités dans la gestion du périmètre documentaire 1.4.4 Utiliser les entités dans le contrôle des redirections

La gestion des sécurités dans Maarch Framework 3

Introduction

Ce chapitre aborde la gestion de la sécurité dans Maarch Framework 3 au sens large, c'est à dire en passant en revue tout ce qui est relatif aux restrictions d'utilisation.

Maarch gère trois concepts de sécurité distincts, en réponse aux questions suivantes :

• Quels sont les documents auxquels j'ai accès ?

> c'est la question du périmètre documentaire

• Que puis-je faire avec Maarch ?

> c'est la question du profil d'utilisation

• Quel est mon rapport aux autres ?

> c'est la question du positionnement dans l'organisation

Définir le périmètre documentaire

Restreindre l'accès à l'archive pour un groupe

Un problème reccurent des grands logiciels de GED est qu'ils positionnent la sécurité au niveau de chaque document, au moyen de listes de contrôle d'accès (ACL). Cette méthode consomme beaucoup de ressource machine, tant en mise à jour qu'en consultation. De plus, elle est très mal adaptée à la problématique de l'archive, puisque pour réviser la politique de sécurité d'une organisation, il faut repasser sur chaque document pour modifier les ACL.

Le schéma de sécurité Maarch est bien mieux adapté à de gros volumes d'archives intermédiaires ou définitives. Il est basé sur du filtrage en accès, pour un groupe donné : Lorsqu'un utilisateur se connecte, la liste des groupes auxquels il appartient est constituée. Chaque groupe dispose d'accès à une ou plusieurs collections, et se voit filtrer l'accès à la collection par une clause where de restriction.

Par exemple, un groupe Service pourra uniquement voir les documents dont l'indicateur de confidentialité est positionné à faux, alors que le groupe Direction pourra tout voir.

Modèle de données pour appliquer la sécurité sur le périmètre documentaire

Voici le schéma de donnée entrant en jeu dans la définition du périmètre documentaire :

Dans un premier temps, les utilisateurs doivent être déclarés dans la table users :

• USER_ID varchar(32)
• PASSWORD varchar(255) /* encrypted */
• FIRSTNAME varchar(255)
• LASTNAME varchar(255)
• PHONE varchar(15)
• MAIL varchar(255) /* mandatory for notification */
• DEPARTMENT varchar(50)
• CUSTOM_T1 varchar(50) /* custom fields not used by standard release */
• CUSTOM_T2 varchar(50)
• CUSTOM_T3 varchar(50)
• COOKIE_KEY varchar(255)
• COOKIE_DATE
• ENABLED char(1)
• CHANGE_PASSWORD char(1)
• DELAY datetime

Dans le même temps, les groupes sont déclarés dans la table usergroups, puis les utilisateurs sont attachés à ces groupes via la relation usergroup_content :

usergroups :

• GROUP_ID varchar(32)
• GROUP_DESC varchar(255)
• ADMINISTRATOR char(1)
• CUSTOM_RIGHT1 char(1)
• CUSTOM_RIGHT2 char(1)
• CUSTOM_RIGHT3 char(1)
• CUSTOM_RIGHT4 char(1)
• ENABLED char(1)

usergroup_content :

• USER_ID varchar(32)
• GROUP_ID varchar(32)
• PRIMARY_GROUP char(1)
• ROLE varchar(255)

Voyons maintenant comment sont décrites les ressources.

Avec Maarch, les descripteurs de ressources électroniques sont placés dans des tables de type res_x. Cependant, du point de vue de l'utilisateur et de l'administrateur, les ressources sont connues sous le nom de Collections Maarch. La collection est l'abstraction d'un dépôt de ressource. Elle est composée d'un table où les données sont stockées, une vue SQL par laquelle elles sont restituées, une description et une id.

Les collections sont définies dans <application>/xml/config.xml :

<COLLECTION>
 <COLLECTION_ID>COLL_INVOICE_2008</COLLECTION_ID>
 <COLLECTION_TABLE>res_invoice_2008</COLLECTION_TABLE>
 <VIEW>view_invoice_2008</VIEW>
 <LABEL>Invoices year 2008</LABEL>
</COLLECTION>
<COLLECTION>
 <COLLECTION_ID>COLL_INVOICE_2009</COLLECTION_ID>
 <COLLECTION_TABLE>res_invoice_2009</COLLECTION_TABLE>
 <VIEW>view_invoice_2009</VIEW>
 <LABEL>Invoices year 2009</LABEL>
</COLLECTION>

Dans cet exemple, la collection 'COLL_INVOICE_2008' référence des documents stockés dans la table res_invoice_2008. Parceque les données d'une ressource peuvent faire appel à des tables de référence pour afficher des libellés, les recherches et listes de résultat utilisent des vues SQL qui résolvent ces références (par exemple, retrouver CUSTOMER_NAME à partir de CUSTOMER_ID).

Quand vous définissez la vue SQL, n'oubliez pas de créer une colonne 'COLLECTION_ID', renseignée avec l'id de la collection utilisée pour accéder et mettre à jour la ressource. Cette colonne est utilisée pour connaitre la table à mettre à jour, dans le cas d'une collection multitable.

Une collection multitable permet de lancer des recherches sur des ressources réparties sur plusieurs collections primaires (partitionnement logiciel). dans le fichier de definition de la collection, le tag COLLECION_TABLE n'est pas renseigné, et la définition de la vue implique plus d'une table.

Pour autoriser des recherches sur toutes les factures, la définition de la collection sera :

<COLLECTION>
 <COLLECTION_ID>COLL_INVOICE_ALL</COLLECTION_ID>
 <COLLECTION_TABLE></COLLECTION_TABLE>
 <VIEW>view_invoice_all</VIEW>
 <LABEL>All invoices</LABEL>
</COLLECTION>

view_invoice_all est l'union de res_invoice_2008 and res_invoice_2009 :

SELECT "COLL_INVOICE_2008" as COLLECTION_ID, DOCDATE, ...
FROM res_invoice_2008
UNION
SELECT "COLL_INVOICE_2009" as COLLECTION_ID, DOCDATE, ...
FROM res_invoice_2009

Maintenant que nous avons défini le dépôt de ressource, nous n'avons plus qu'à filtrer l'accès du groupe à la collection, via la table security :

• GROUP_ID varchar(32)
• COLLECTION_ID varchar(32)
• WHERE_CLAUSE varchar(255) /* filtering on collection */
• COMMENT text
• CAN_INSERT char(1)
• CAN_UPDATE char(1)
• CAN_DELETE char(1)

N'ayez pas peur, tout cela se gère très bien via les écrans d'administration Maarch :

• Administration/Utilisateurs : ajout/modification d'utilisateurs, affectation à un groupe, et définition du groupe primaire
• Administration/Groupes : ajout/modification de groupes, accès et filtrage sur les collections disponibles

Définir le profil d'utilisation

Le profil d'utilisation est l'inventaire des capacités de l'utilisateur à manipuler les fonctions proposées par la couche de présentation Maarch.

Maarch dispose de modules proposant des fonctionnalités exposées en tant que services.

Les services disponibles figurent par module dans <module>/xml/services.xml. Les services de nature "utilisateur" (et non "système") peuvent être affectés à un groupe, afin que les utilisateurs de ce groupe puissent en tirer parti.

Dans Administration/Groupes, partie gauche, un profil administrateur peut affecter les différents services :

Le résultat du paramétrage se retrouve dans la table usergroups_services.

Notez que l'application propose elle-aussi les services qui lui sont propres.

Les autorisations sont cumulatives : elles s'ajoutent les unes aux autres en fonction des groupes d'appartenance de l'utilisateur.

Définir le positionnement dans l'organisation

(Applicable depuis la version 3.1 du Framework)

Il s'agit ici de définir l'organisation hiérarchique appliquée dans l'entreprise, afin de savoir où chacun se situe, et d'impacter la gestion de la sécurité en conséquence.

En particulier, la position dans l'organisation (ex: l'appartenance à une direction, un service ou un bureau particulier) va permettre de gérer strictement :

• les accès au périmètre documentaire, si la sécurité des documents dépend de leur relation à un service rédacteur ou traitant
• le contenu des corbeilles, si celles-ci constituent un moyen de transférer un document d'un service à l'autre
• les autorisations de redirection de service à service ou utilisateur

1ère étape : définir l'organisation des services

Pour démarrer, il faut représenter l'organisation. Prenons l'exemple d'une mutuelle disposant de l'organisation suivante :

Direction Générale
Juridique
Contrôle Interne
Comptabilité et Contentieux 
  Comptabilité
  Contentieux
Stratégie Opérationnelle
  Communication
  Marketing
  Commercial (Individuels)
Commercial (Entreprises) 
Département Informatique
  Etudes
  Systèmes et réseaux
  Processus et Relations Clients
  Statistiques
Département Gestion des Entreprises
  Service contrats entreprises complexes
  Autres contrats entreprises
  Tiers (Prises en charges, tiers payant,…)
Service Gestion des Individuels
Accueil (téléphone et visites)
Courrier – Reprographie
Moyens généraux

C'est une structure relativement simple à deux niveaux, à laquelle s'ajoute un niveau "chapeau" que l'on va appeler "ACME S.A.", du nom de cette société fictive.

Dans Administration/Entités (à condition que le module entities soit connecté), vous allez pouvoir définir les composants hiérarchiques de l'organisation.

Le résultat est stocké dans une seule table reflexive Maarch : entities.

2ème étape : associer les utilisateurs aux entités

Si le module Entities est connecté, il devient possible de rattacher un utilisateur à une entité, dans Administration/Utilisateurs. La liste des entités disponibles à l'affectation dépend directement du positionnement de l'administrateur lui-même, qui ne peut qu'affecter des entités au niveau inférieur du sien.

Le résultat de l'affectation est stocké dans la table de relation users_entities.

Utiliser les entités dans la gestion du périmètre documentaire

Une fois l'organisation définie, vous allez pouvoir utiliser des variables de contexte décrivant les services autorisés :

• @my_entities : toutes les entités rattachées à l'utilisateur connecté. N'inclue pas les sous-entités
• @my_primary_entity : entité primaire de l'utilisateur connecté
• @subentities[(entity_1,...,entity_n)] : sous-entités de la liste d'argument, qui peut aussi être @my_entities ou @my_primary_entity
• @parent_entity[entity_id] : entité parente de l'entité en argument
• @sisters_entities[entity_id] : toutes les entités du même niveau que l'entité en argument
• @all_entities : toutes les entités (actives)
• @immediate_children[entity_1,..., entity_id] : sous-entités immédiates (n-1) des entités données en argument

Exemple dans la définition de la sécurité d'un groupe ("where clause") : accès sur les ressources concernant le service d'appartenance principal de l'utilisateur connecté, ou les sous-services de ce service.

where_clause : (DESTINATION = @my_primary_entity or DESTINATION in (@subentities[@my_primary_entity]))

Remarque : la variable de contexte suivante était déjà disponible dans le Core 3.0 :

• @user : id de l'utilisateur connecté

Utiliser les entités dans le contrôle des redirections

Pour la gestion des corbeilles, nous avons créé des mots-clé reprenant ces variables de contexte, qui ne sont pas visibles directement, mais apparaissent sous leurs intitulés :

• ALL_ENTITIES : toutes les entités
• ENTITIES_JUST_BELOW : Les entités imédiatement inférieures à l'entité primaire de l'utilisateur [n-1]
• ALL_ENTITIES_BELOW : Toutes les entités inférieures à l'entité primaire de l'utilisateur
• ENTITIES_JUST_UP : les entités immédiatement supérieures à l'entité primaire de l'utilisateur
• MY_ENTITIES : Toutes les entités auxquelles l'utilisateur appartient (table users_entities)
• MY_PRIMARY_ENTITY : L'entité primaire de l'utilisateur
• SAME_LEVEL_ENTITIES : Toutes les entités au même niveau que l'entité primaire de l'utilisateur