DAViCal
Accorder des droits sur des Collections.
Sommaire : Monter son propre service de calendrier
Etape précédente : Créer des entités (Calendar, Addressbook)
Dans cet article, je suis logué à l'interface web de DAViCal en tant que Marie, qui souhaite accorder des droits à d'autres utilisateurs ou groupes, sur ses Collections (calendriers et carnets d'adresses).
Marie dispose de deux calendriers et deux carnets d'adresses :
Marie personal addressbook
: le carnet d'adresses personnel;Marie work addressbook
: le carnet d'adresses professionnel;Marie personal calendar
: le calendrier personnel;Marie work calendar
: le calendrier professionnel.
Les différents droits
Les droits (ou permissions) dans DAViCal correspondent à ceux évoqués dans la RFC3744.
Afin de garder cet article lisible sans paraphraser la RFC ni la page du wiki de DAViCal qui traite des permissions, je vais simplement parler des agrégats de droits suivants :
SCHEDULE DELIVER
: Permet aux autres utilisateurs de m'envoyer des invitations, de répondre aux miennes, et de consulter mon calendrier de disponibilités (free/busy);SCHEDULE SEND
: Permet aux autres utilisateurs d'envoyer/recevoir des invitations de ma part, et de faire des demandes de consultation de disponibilités (free/busy) de ma part;FREE/BUSY
: Permet aux autres utilisateurs de consulter mon calendrier de disponibilité (free/busy). Au lieu de voir le détail des événements, les autres verront simplement que je suis occupé ou non;READ
: Donne aux autres utilisateurs les droitsFREE/BUSY
, ainsi que le droit de lire les détails des évènements de mon calendrier (ou carnet d'adresses);READ/WRITE
: Donne aux autres utilisateurs les droitsREAD
, ainsi que le droit de modifier/ajouter des événements dans mon calendrier (ou des fiches dans mon carnet d'adresses);ALL
: La différence avecREAD/WRITE
résidant surtout dans la capacité à lire/écrire les ACL, et étant donné que la prise en compte des ACL n'est assurée par aucun logiciel client (à l'heure actuelle), je considèrerai par la suite que l'agrégatALL
est équivalent à l'agrégatREAD/WRITE
.
Bien sûr, ces permissions peuvent être affinées selon les goûts, la granularité étant particulièrement fine dans DAViCal.
A noter : les droits SCHEDULE DELIVER
et SCHEDULE SEND
s'appliquent sur des Principals seulement. Les autres droits s'appliquent sur des Principals ou des Collections.
Accorder des droits à tous les utilisateurs
Pour cela, je vais dans le menu User Functions
puis View My Details
. Dans la section Principal: Marie
, je vais à la ligne Privileges granted to All Users
:
Puis je choisis les droits que tous les utilisateurs auront sur mes Collections (Cf point précédent).
Collections et droits par défaut
Pour appliquer ces droits par défaut sur mes Collections, je vais maintenant dans la section Principal Collections
. Je sélectionne un objet de type Collection en cliquant sur la ligne correspondante.
Parmi les options de l'objet, je coche la case de l'option Default Privileges
:
Puis je clique sur APPLY CHANGES
.
La nouvelle politique pour cet objet devient alors :
- Tous les utilisateurs présents sur le serveur DAViCal se voient attribués les droits par défaut sur cette Collection;
- Si j'attribue des droits spécifiques à un Principal dans la section
Collection Grants
de cet objet, alors ces droits supplantent les droits par défaut.
Il s'agit donc d'une mesure destinée à assurer la confidentialité des Collections.
Astuce : Pour vérifier que ma Collection dispose bien des droits par défaut, je reviens dans la page de l'utilisateur Marie, à la section Principal Collections
. Dans la ligne de l'objet que je viens de modifier, la colonne Privileges
doit indiquer la valeur [from principal]
.
Exemple
Marie souhaite que :
- tous les utilisateurs présents sur le serveur DAViCal puissent voir ses disponibilités (ie son FREE/BUSY);
- tous les utilisateurs puissent lui envoyer des invitations, et qu'elle puisse y répondre;
- ses carnets d'adresses restent confidentiels.
D'abord, je définis les droits par défaut.
Menu User Functions
--> View My Details
.
Section Principal: Marie
, ligne Privileges granted to All Users
.
Je clique sur FREE/BUSY
puis SCHEDULE DELIVER
et j'obtiens :
Ensuite, j'applique ces droits sur mes calendriers.
Dans la section Principal Collections
, je vérifie que mes calendriers ont comme valeur [from principal]
dans la colonne Privileges
.
Si ce n'est pas le cas, je clique sur la ligne du calendrier, et dans la fenêtre qui apparaît, je coche la case Default Privileges
, puis je clique sur APPLY CHANGES.
Enfin, je reviens dans la section Principal Collection
de l'utilisateur marie, et pour chaque carnet d'adresses :
- Je clique sur la ligne correspondante;
- Je décoche la case
Default Privileges
, et je clique deux fois surALL
pour que tous les droits soient décochés; - Je clique sur
APPLY CHANGES
.
On voit rapidement l'intérêt de définir correctement les variables $c->default_privileges
et $c->default_collections
dans le fichier de configuration de DAViCal, surtout quand le nombre d'utilisateurs est important.
Cas général
Cet article et l'exemple qui l'illustre sont un cas particulier d'une situation qui peut se généraliser. En effet, si tous les utilisateurs se conforment au même schéma de droits que Marie, cela signifie que :
- tous les utilisateurs peuvent s'envoyer des invitations;
- tous les utilisateurs peuvent voir le FREE/BUSY des autres.
Autrement dit, l'utilisation des droits par défaut implique l'existence d'un groupe Tout_le_monde "caché", dans lequel tous les utilisateurs sont réunis. Le fait d'accorder des droits par défaut à tous les utilisateurs revient en réalité à accorder ces droits au groupe Tout_le_monde, et par transitivité à tout ses utilisateurs.
Il existe pourtant des cas où il n'est pas souhaitable que tous les utilisateurs soient en contact. Par exemple :
- une entreprise disposant de plusieurs entités peut vouloir limiter les intéractions entre celles-ci;
- un administrateur gérant un serveur DAViCal pour le compte de plusieurs associations.
Dans ces situations, il est alors nécessaire de passer par la création de groupes, et de délaisser complètement les droits par défaut, leur praticité se transformant en faille de sécurité potentielle.
Etape suivante : Utiliser des Groupes