Author: glandais Date: 2008-03-20 16:43:50 +0000 (Thu, 20 Mar 2008) New Revision: 1433 Modified: trunk/simexplorer-is/src/site/fr/rst/rules.rst Log: Rules document Modified: trunk/simexplorer-is/src/site/fr/rst/rules.rst =================================================================== --- trunk/simexplorer-is/src/site/fr/rst/rules.rst 2008-03-20 16:43:31 UTC (rev 1432) +++ trunk/simexplorer-is/src/site/fr/rst/rules.rst 2008-03-20 16:43:50 UTC (rev 1433) @@ -11,13 +11,34 @@ Droits sur un élément : + - owner : l'utilisateur est propriétaire, il a tous les droits + - admin : l'utilisateur peut gérer les droits sur l'élément. Il peut aussi le supprimer. Il peut bien sûr lire et écrire. + - write : l'utilisateur peut créer une nouvelle version, et le lire + - read : l'utilisateur peut uniquement lire l'élément (dans toutes ses versions) - le superadmin possède tous les droits sur tous les éléments - "atomique" : droits explicites ou d'admin ou propriétaire de l'Actor - global : droits atomique de l'Actor ou d'un de ses parents (memberOf récursif). Ainsi si l'utilisateur n'a pas les droits explicites, mais qu'un de ses groupes auxquels il apprtient les possède, l'utilisateur acquière ces droits. - - si un User est propriétaire d'un groupe sans en être membre, il n'a pas les droits du groupe + - si un User est propriétaire d'un groupe sans en être membre, il n'a pas les droits du groupe + - tout utilisateur a tous les droits sur un id non encore enregistré (permet l'enregistrement d'un nouvel élément) +Exemple : Si l'utilisateur a les droits d'écriture, il a aussi les droits de lecture. + ++--------+-------+-------+-------+-------+ +| | Owner | Admin | Write | Read | ++========+=======+=======+=======+=======+ +| Owner | O | X | X | X | ++--------+-------+-------+-------+-------+ +| Admin | O | O | X | X | ++--------+-------+-------+-------+-------+ +| Delete | O | O | X | X | ++--------+-------+-------+-------+-------+ +| Write | O | O | O | X | ++--------+-------+-------+-------+-------+ +| Read | O | O | O | O | ++--------+-------+-------+-------+-------+ + Sauvegarde d'un élément : - les droits associés sont mis à jour via cette méthode @@ -25,3 +46,110 @@ - une permission est créée si et seulement si aucune permission n'existe avec cet utilisateur. La permission créée a pour propriétaire l'utilisateur sauvant l'élément, donc tous les droits. +Storage +======= + +Config +------ + +Sera modifié prochainement (utilisation d'un fichier par défaut et/ou d'un fichier externe et/ou de la +configuration commandline). + +Stockage des "Attachments" +-------------------------- + +Les flux associés aux entités sont sauvées sur le disque par FileSystemAttachmentHandler. +Le dossier de base est retrouvé via la configuration. Afin de ne pas générer trop de dossiers dans +ce dossier, les données sont stockées dans une arborescence correspondant aux trois premiers caractères +de leur id. +Ainsi, l'élément avec l'id efjsisjd sera stocké dans le dossier /baseFolder/e/f/j/efjsisjd. +Si l'id a moins de trois caractères, le dossier est directement l'id. + +Le stockage des données (storeData) met à jour l'Attachment associé (hash et taille). + +Aucun contrôle métier n'est fait à ce niveau. + +Database +-------- + +Cette classe gère uniquement le stockage des données spécifiques à SimExplorer IS. De plus, elle doit +être en mesure d'indexer les données afin d'effecture les recherches. + +L'implémentation par défaut est LuceneDatabase. + +Le dossier où est stocké l'index est spécifié dans la configuration, ainsi que l'intervalle de +compactage de l'index (réduction du nombre de fichiers utilisés pour l'index). + +Un pool de searchers permet de traiter les requêtes en parallèle de l'insertion. Une insertion invalide +le pool et les searchers doivent être recréés à la requête suivante. + +Le filtrage des données (afin d'afficher uniquement les éléments que l'utilisateur peut lire) est détaché +du module de sécurité (les données étant stockées dans deux systèmes différents, JPA d'un côté, Lucene +de l'autre). +Il est maintenu en mémoire une liste de filtre sur les éléments visibles pour un utilisateur. Cette liste +est gérée par le service liant sécurité et persistence. La méthode updateFilter met à jour le filtre +d'un utilisateur en passant en paramètre la liste des ids des éléments qu'il a le droit de visualiser. +Un filtre Lucene est créé à partir de cette liste, avec de très bonnes performances (voir +http://www.nabble.com/Security-filtering-from-external-DB-td15630408.html). + +Deux types de données sont sauvées dans la base Lucene : + + - les MetaData : des méthodes permettent de transformer un Document lucene en MetaData et vice versa. + Ces méthodes ne sont appellées uniquement si c'est vraiment utile, pour l'affichage d'un élément ou le + chargement d'un élément. Tout Document d'un ensemble Hits (résultat de recherche) peut être converti, + mais c'est une opération coûteuse, nottament sur des milliers d'éléments... + - les hierarchies entre MetaData : on conserve dans l'index les relations d'un MetaData, avec ses parents + et ses enfants. Cela permettra d'appliquer les règles métiers durant les ajouts/suppressions. Lors + du clonage d'un élément, une méthode permet de dupliquer les associations des éléments utilisés par le cloné. + +Pour ces deux types de données, un champ composite avec l'id et la version est créé, afin de faciliter les +recherches. + +La base peut être explorée avec Luke (http://www.getopt.org/luke). + +Aucun contrôle métier n'est fait à ce niveau. + +StorageEngine +------------- + +Dans son implémentation de base, StorageEngineImpl, cette classe sert de liant entre les métadonnées et les fichiers. + +Elle délègue toutes ses méthodes aux implémentations de Database et AttachmentHandler. Elle permet tout de même de stocker +des fichiers temporaires avec un MetaData spécifique dédié. De plus, elle a en charge la conversion des Attachment en +données indexables, en passant par les ContentType des données (méthode saveElement). + +En mode serveur, cette classe est utilisée en EJB, via StorageEngineSecuImpl. Cela permet d'accéder à l'EJB CredentialManager. +Ainsi, on peut contrôler toutes les actions de l'utilisateur en vérifiant ses droits. + +Les règles évoquées dans la partie Security s'appliquent. + +Service +======= + +Authentification +---------------- + + - Droits d'administration sur un groupe : superadmin, admin du groupe ou d'un groupe parent + - Droits d'administration sur un utilisateur : superadmin, ou droits d'administration sur un groupe + des groupes de l'utilisateur + - Droits de suppression d'un groupe : droits d'administration sur le groupe + - Droits de suppression d'un utilisateur : droits d'administration sur l'utilisateur + - Droits de consultation d'un utilisateur/groupe : l'utilisateur doit être connecté (ie token valide) + - Droits de création d'un utilisateur/groupe : l'utilisateur doit être admin ou superadmin + - Droits de mise à jour = droits d'administration + +Création d'un utilisateur : un mail est envoyé à l'adresse spécifiée avec son mot de passe et son login. +Suppression d'un groupe/utilisateur : suppression logique (visible = false) +Mise à jour d'un groupe : la récursion est vérifiée et supprimée le cas échéant +Mise à jour d'un utilisateur : seul le super admin peut modifier le fait qu'il soit admin ou superadmin + +A la première connexion, on vérifie si le superadmin existe, sinon il est créé avec le mot de passe password. +Le paramètre password passée à la méthode de login n'est pas le mot de passe en clair, mais un hash (voir AuthenticationServiceHelper). +Au login, les token vieux de plus de 24h sont supprimés. +Chaque appel à getLoggedUser mets à jour la date de login à l'instant présent. + +La demande d'un compte envoie un mail au superadmin avec le login désiré et l'adresse mail de l'utilisateur. + +Un nouveau mot de passe peut être généré si l'administrateur possède les droits d'administration sur cet utilisateur. Un +mail est alors envoyé à l'adresse de l'utilisateur. +