Spécifications de Maarch MoReq2 V1.0/Sécurité V1.0

De Maarch MoReq2.

Sommaire

1 Finalité
2 Interfaces
3 Annexes

Finalité

Faire cohabiter la sécurité actuelle de Maarch, basée sur un principe de filtrage, et la sécurité Moreq, ouvertement orientée ACL.

Cas d'utilisation

Existant

Cas d'utilisation pour l'administration dans l'existant.

MoReq2 ciblé

Tous les cas d'utilisation du MoReq2 à implémenter dans la V1.0 sont déjà prévus dans l'existant de Maarch, seules les implémentations de ces cas vont évoluer, mais cela ne figure pas sur ces diagrammes.

Règles de gestion

Contrôles

Voir sur la page principale.

Modèles

Update running...

Conceptuel/Physique

L'objectif est de récupérer par extension les principes de sécurité appliqués sur les entités via la gestion des groupes. Une analyse a déjà été menée et peut être consultée sur la page concernée en interne.

Principe de fonctionnement des agrégations en lien avec les entités.

Ajout du champ bitmask à la table security. Le bitmask symbolise les actions concernées par le groupe et la where_clause. Il y a également ajout des dates permettant de gérer une période de validité.

Nouvelle table security avec le bitmask d'actions (sens MoReq2).

La sécurité de session sera gérée en utilisant une table spécifique :

session_security
Libellé	Type de valeur	Clé étrangère
user_id	long	users
session_begin_date	date
session_end_date	date
full_where_clause	varchar
last_available_bitmask	bit(x)[]
last_object_id	long[]

Codage

Existant	Cible
Détermination des accès : Union de tous les groupes auxquels appartient l'utilisateur. Application des droits maximums sur le résultat obtenu en 1. Les droits (lecture/modification/suppression) sont appliqués uniquement sur les documents.	Détermination des accès groupe par groupe : les tâches spécifiées ne sont appliquées qu'au résultat de la where_clause du groupe en question. Les droits sont appliqués aux documents et aux agrégations.
La « where_clause » est calculée une fois pour toute à la connexion de l'utilisateur.	La « where_clause » est toujours calculée une fois pour toute à la connexion de l'utilisateur pour tous les accès en lecture. En revanche, pour une action évoluée (ajout, modification, suppression d'un objet), les accès sont vérifiés chaque fois qu'un objet est sélectionné.

Par ailleurs :

Création de 5 groupes principaux disponibles par défaut :
- Accès en lecture à tout (@all_entities) et en écriture à « mes entités » (@my_entities) et à « mes sous-entités » (@subentities[@my_entities]).
- Accès en lecture et en écriture à « mes entités » (@my_entities) et à « mes sous-entités » (@subentities[@my_entities]).
- Accès en lecture et en écriture à « mes entités » (@my_entities).
- Accès en lecture à tout (@all_entities).
- Accès en lecture à « mes entités » (@my_entities).
L'utilisation de ces 5 groupes revient à de l'administration « simple ».
La création d'un nouveau groupe avec la saisie d'une clause where spécifique revient à de l'administration « avancée ».
À la connexion, il y a création de la where_clause de sécurité comme c'est déjà le cas avec l'existant, à la différence que cette clause ne détermine que l'accès en lecture.
En cas d'écriture (ajout/modification/suppression) ou de tâche d'administration, il y a interrogation des bitmasks de l'utilisateur.

Règles MAARCH

Les droits ne seront jamais définis au niveau de l'utilisateur mais toujours au niveau d'un groupe, quitte à obliger à créer un groupe d'une seule personne.
Pour commencer, un accès (visualisation) = document + métadonnées du document
Un document n'est jamais modifiable, seules certaines de ses métadonnées le sont.
La suppression de document est toujours logique.
L'historique n'est plus modifiable après enregistrement en base.

Listes des taches (actions et fonctionnalités) possibles dans le moreq (13.4)

Libellé de la tâche	Commentaire	V1	V1.1	V2 (à confirmer)
Ajouter de nouvelles séries		X	X	X
Créer de nouveaux dossiers		X	X	X
Modifier les métadonnées d’un dossier		X	X	X
Maintenir le plan de classement et les dossiers	Regroupe les actions avancées de duplication, division, regroupement et déplacement			X (sous réserves)
Détruire des dossiers	Cette action nécessite selon le moreq de proposer à l'administrateur de supprimer toutes les sous-entités ou de les déplacer	X (mais seulement dans le cas où le dossier et ses sous-agrégats ne comporte aucun documents, aucun choix proposé à l'administrateur)	X (mais seulement dans le cas où le dossier et ses sous-agrégats ne comporte aucun documents, aucun choix proposé à l'administrateur)	X (implémenté complétement)
Capturer les documents	La capture d'un document est un type d'action possible sur les agrégations	X	X	X
Reclasser un document dans un autre dossier	Déplacer un document			X
Rechercher et consulter un document archivé	Comprendre document présent dans la GED	X	X	X
Modifier le contenu des documents archivés
Modifier les métadonnées de documents archivés	Modifier une entité = modifier ses métadonnées	X	X	X
Détruire des documents archivés	La suppression de document dans Maarch est logique.	X	X	X
Décider ou suspendre un gel	Concerne le cycle de vie.		A préciser lors de l'analyse du cycle de vie
Gérer les règles de conservation/destruction et le sort final	Concerne le cycle de vie.		A préciser lors de l'analyse du cycle de vie
Exporter et importer des dossiers et des documents	Fonctionnalité qui mérite à elle seule une analyse détaillée			X (sous réserve)
Consulter les historiques	Dans Maarch l'historique est considéré comme les autres métadonnées. Doit-on faire de l'accès à l'historique d'une entité un droit particulier ?	?	?	?
Configurer et gérer l’historique	La configuration de ce que l'on enregistre se fait dans les fichiers config.xml de l'apps et des modules.	X	X	X
Modifier les données d’historique	Dans Maarch l'historique n'est plus modifiable après enregistrement en base.
Transférer les données d’historique sur un support hors ligne	Exporter des données d'historique dans un fichier (PDF, XML, CSV...).			A étudier
Exécuter toutes les opérations relatives aux utilisateurs et à leurs droits d’accès	Tous les accès se font par l'intermédiaire des groupes. Question de la gestion des droits d'accès et des types d'action possible à chaque niveau du plan de classement.	?	?	?
Attribuer des autorisations d’accès aux administrateurs locaux	Reviens à donner les droits d'administration.	X	X	X
Déléguer ses autorisations d’accès à d’autres utilisateurs	Actuellement les seuls accès que l'on peut déléguer le sont au travers des corbeilles (gestion des absences).	?	?	?
Créer et gérer des profils de gestionnaires de dossiers	Reviens à gérer des groupes ?.	?	?	?
Maintenir les bases de données et le stockage		?	?	?
Maintenir les autres paramètres du système		?	?	?
Définir et consulter les autres rapports du système		?	?	?

Interfaces

Nouvelle interface de gestion des groupes.

Annexes

Matrice d'actions proposée par le MoReq2