Permissions
Permissions
En association avec l'identification, vous pouvez gérer les permissions accordées à l'utilisateur.
Définir le schéma des permissions pour votre système
Un des premiers points à régler est de décider comment organiser les permissions, d'un point de vue fonctionnel.
Les applications
Commencez par le niveau fonctionnel le plus élevé: les applications. Faites une liste des applications qui nécessitent une gestion des permissions
Aires fonctionnelles
Chaque application peut être divisée en aires fonctionnelles. Pour chaque application, énumérez toutes les parties qui requièrent une gestion particulière des permissions.
Les droits
Pour chaque aire fonctionnelle, définissez tous les droits dont il faut tenir compte.
Du fonctionnel au technique...
Maintenant que vous avez défini vos besoins, voyons comment compléter les tables LiveUser.
La table «liveuser_applications»
Pour chaque application, notez leur nom et un identifiant.
La table contient quelques champs:
- application_id: l'identifiant de l'application
- application_define_name: le nom de l'application
Exemple:
| application_id | application_define_name |
|---|---|
| 1 | TEST |
La table «liveuser_areas»
Pour chaque aire fonctionnelle, notez son nom et son identifiant ainsi que l'identifiant de l'application de laquelle elle dépend.
La table contient quelques champs:
- area_id: l'identifiant de l'aire fonctionnelle
- application_id: l'identifiant de l'application à laquelle elle se rattache
- area_define_name: le nom de l'aire fonctionnell
Exemple: dans notre exemple, l'application «TEST» sera composée de 4 aires fonctionnelles.
| application_id | area_id | area_define_name |
|---|---|---|
| 1 | 1 | EVENT |
| 1 | 2 | RECEIPT |
| 1 | 3 | REAL_ESTATE |
| 1 | 4 | ADMIN |
La table «liveuser_rights»
Pour chaque droit, notez le nom du droit, l'identifiant de l'aire fonctionnelle à laquelle il est associé et l'identifiant du droit.
La table contient quelques champs:
- right_id: l'identifiant du droit
- area_id: l'identifiant de l'aire fonctionnelle à laquelle ce droit se rattache
- right_define_name: le nom du droit
- has_implied: un booléen indiquant si, lorsque l'utilisateur se voit accorder ce droit, un (ou plusieurs) autre(s) droit(s) lui sera également accordé. Les droits implicites sont spécifiés dans la table «liveuser_right_implied».
Attention: ceci n'est utilisable qu'au niveau de gestion de permissions complexe (voir plus loin). D'ici là, nous laisserons la valeur à «0».
Exemple: les utilisateurs pourront se voir accorder 4 droits différents à l'aire fonctionnelle «EVENT»:
| area_id | right_id | right_define_name | has_implied |
|---|---|---|---|
| 1 | 1 | EVE_VIEW | 0 |
| 1 | 2 | EVE_CREATE | 0 |
| 1 | 3 | EVE_EDIT | 0 |
| 1 | 4 | EVE_DELETE | 0 |
Gestion des utilisateurs
La table «liveuser_users»
Les informations concernant l'authentification des utilisateurs sont sauvegardées dans la table «liveuser_users».
| auth_user_id | handle | ... |
|---|---|---|
| 25 | userF | ... |
La table «liveuser_perm_users»
Les informations relatives aux permissions des utilisateur est sauvegardée dans la table «liveuser_perm_users»:
- perm_user_id: un identifiant unique pour un utilisateur au niveau de la gestion des permissions
- auth_user_id: un identificateur de l'utilisateur au niveau de la gestion de l'authentification
- auth_container_name: le numéro ou le nom du conteneur (container) pour l'authentification
- perm_type: nous indiquerons la valeur pour un utilisateur simple (= 1) et nous reviendrons plus tard sur l'usage de ce champ
| perm_user_id | auth_user_id | auth_container_name | perm_type |
|---|---|---|---|
| 12 | 25 | 0 | 1 |
Etablir les liens entre les tables d'authentification et de permission
Pour établir les liens entre ces deux tables, le «auth_user_id» pour un conteneur (container) d'authentification particulier est lié à un «perm_user_id» unique. Un seul conteneur d'authentification sera utilisé dans cet exemple.
Il est utile de se souvenir que LiveUser est capable de supporter plus d'un conteneur (container) d'authentification (par exemple une base de données database contenant la liste des employés fixes et un fichier XML contenant la liste des consultants externes) mais ne supporte qu'un seul conteneur pour les permissions. Tous les utilisateurs faisant partie de n'importe quel conteneur (container) d'authentification sera lié à un «perm_user_id» unique.
Notez que ces liens sont optionnels. Si un lien entre un enregistrement de la table «liveuser_users» et un enregistrement de la table «liveuser_perm_users» ne peut être établi, l'utilsateur authentifié ne fera partie d'aucun groupe et ne se verra accorder aucun droit.
Lien utilisant une clé numérique
Dans notre fichier de configuration, «authContainters» contient une source d'authentification MDB2. Aucune clé n'y est associée. Cette source est donc implicitement associée à la valeur «0».
... 'authContainers' => array( array( 'type' => 'MDB2', // auth container name 'expireTime' => 3600, // max lifetime of a session in seconds 'idleTime' => 1800, // max time between 2 requests 'allowDuplicateHandles' => 0, 'allowEmptyPasswords' => 1, 'passwordEncryptionMode'=> 'MD5', ... ?>
La valeur qui doit être assignée à «auth_container_name» est donc égale à zéro.
| perm_user_id | auth_user_id | auth_container_name | perm_type |
|---|---|---|---|
| 12 | 25 | 0 | 1 |
Liens utilisant un vecteur associatif
Vous pouvez adapter le fichier de configuration et associer une clé au conteneur (container) d'authentification.
...
'authContainers' => array(
'myTestDB' => array(
'type' => 'MDB2', // auth container name
'expireTime' => 3600, // max lifetime of a session in seconds
'idleTime' => 1800, // max time between 2 requests
'allowDuplicateHandles' => 0,
'allowEmptyPasswords' => 1,
'passwordEncryptionMode'=> 'MD5',
...
Dans ce cas, la valeur qui doit être indiquée comme «auth_container_name» doit être égale à «myTestDB».
| perm_user_id | auth_user_id | auth_container_name | perm_type |
|---|---|---|---|
| 12 | 25 | myTestDB | 1 |
Quel que soit le système que vous choisissez, veillez à ce que votre solution soit consitante, sans quoi celà ne fonctionnera pas.
Assigner des droits aux utilisateurs
Il y a plusieurs manières de l'effectuer:
- assigner un droit directement a un utilisateur
- assigner un droit à un groupe d'utilisateurs
- assigner un droit à un sous-groupe d'utilisateurs et/ou hériter d'un droit implicite
En les énumérant, nous avons en fait défini les 3 niveaux de gestion de permission que LiveUser supporte:
Nous les couvrirons dans les pages suivantes.
