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
