Proposition sur la sécurité =========================== Contexte -------- Actuellement, la sécurité dans ToPIA se fait par JAAS. Elle propose la gestion de permission sur les entités ToPIA, droit en lecture, écriture, création et chargement. La gestion des droits fonctionne correctement. Mais elle semble ne pas être adaptée à la problèmatique du projet Chorem. Le projet Chorem a besoin de plus de souplesse dans l'écriture des permissions. Inversion de permission ------------------------ En sécurité, il existe deux stratégies pour la création des permissions : - la première consiste à interdire l'accès à l'ensemble des données et d'autoriser au cas par cas - la deuxième consiste à autoriser l'accès à l'ensemble des données et d'interdire au cas par cas Le framework ToPIA ne permet que d'utiliser la première stratégie. Il semble aussi important de proposer la deuxième stratégie. Lien entre permissions ---------------------- Un lien entre permissions consite à spécifier qu'une permission est la copie d'une autre permission sur des entités différentes. L'utilité d'un tel mécanisme est la propagation des modifications des droits sur la permission. Exemple sur un arbre, tous les noeuds vont avoir les mêmes droits que le noeud racine. En cas de modification sur le noeuds racine, automatiquement l'ensemble des noeuds de arbre vont changer de droit. L'avantage est notable, il n'est plus nécessaire de prendre l'ensemble des permissions des noeuds pour leur notifier les changements. LinkPermission : - id (* ou TopiaId) - link (permission ou principal ?) - principals Permission de type association ------------------------------ On va partir d'un exemple : |--------| 1 * |-------| | Projet |----------------| Tâche | |--------| contient |-------| On souhaiterait spécifier qu'un utilisateur à aucune restriction sur l'ensemble des projets. Et il n'a la permission de créer des sous-tâches seulement dans le projet «essai». Utilisation d'EntityPermission ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On peut spécifier que la première partie ALL - * Project, mais la deuxième partie ne pourra pas être défini. Utilisation de LinkPermission ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On va avoir tendance à écrire : - EntityPermissionName = CREATE - essai Project - LinkPermissionName = * Task - EntityPermissionName Attention, ce n'est pas ce que l'on veut. On vient de dire que l'on a la permission de création sur toutes les tâches (CREATE * Task). AssociationPermission ~~~~~~~~~~~~~~~~~~~~~ L'exemple précédent à mis en évidence un manque. Les permissions de type association répondent à ce type de problème. Elles consitent à donner une permission par rapport à une autre entité par le biais d'une association. Dans le cas d'une action de modification, de suppression ou de chargement, les permissions de type association peuvent être remplacées par des permissions de type entité. En effet, les permissions de type association ne sont qu'une virtualisation d'un ensemble d'entité, pour lesquelles on associe des permissions. Attention, les permissions de type association sont caractérisées par leur sens de navigation. Le cas de la récursivité des associations n'est pas traité car cette caractéristique est compliquée à mettre en oeuvre. L'utilisation de lien entre permissions est recommandé de ce type cas. AssociationLink : - id (* ou TopiaId) - association (name) - actions (ALL, CREATE, UPDATE, DELETE et LOAD) - reverseId (* ou TopiaId) - principals En applicant, ce nouveau type de permission sur l'exemple précédent, on obtient : essai Project - contient - CREATE - * Task. C'est à dire qu'on a la permission de création si c'est le projet essai qui contient les nouvelles tâches. ----------------------------------------------------------- Julien Ruchaud