Utilisateurs et rôles

Utilisateurs et rôles

difuzio distingue deux notions :

  • un utilisateur (users) : un compte avec une adresse email, capable de se connecter à l'interface web et de détenir des rôles. Les administrateurs et les propriétaires de listes sont des utilisateurs.
  • un abonné (members) : une adresse inscrite à une liste donnée. Un abonné n'a pas nécessairement de compte utilisateur.

Cette page traite des utilisateurs et de leurs rôles. Pour les abonnés, voir Listes et la documentation utilisateur.

États d'un utilisateur

users.status vaut :

  • active : compte utilisable.
  • disabled : compte désactivé.
  • unverified : compte créé mais email non vérifié.

Le modèle de rôles (RBAC)

Quatre rôles, du plus large au plus restreint :

  • super_admin : contrôle global de l'instance (tous les domaines, toutes les listes, tous les réglages).
  • domain_admin : administre un ou plusieurs domaines (leurs listes, abonnés, modérateurs).
  • list_owner : propriétaire d'une ou plusieurs listes (réglages, abonnés, modération de ces listes).
  • moderator : modère une ou plusieurs listes (file de modération des posts et des abonnements), sans accès aux réglages.

Un même utilisateur peut cumuler plusieurs rôles, sur des périmètres différents (par exemple domain_admin sur un domaine et list_owner sur une liste d'un autre domaine).

Périmètre et isolation

Chaque rôle est attaché à un périmètre (l'instance, un domaine, ou une liste). À chaque requête, difuzio reconstruit le Principal de l'utilisateur à partir de ses rôles en base : une révocation prend donc effet immédiatement, sans attendre l'expiration d'une session.

Un acteur qui tente d'accéder à une ressource hors de son périmètre reçoit une réponse 404 Not Found (et non 403 Forbidden) : l'existence même de la ressource n'est pas révélée.

Créer le premier super_admin

CREDENTIALS_DIRECTORY=/etc/difuzio/secrets difuzio bootstrap-admin --config /etc/difuzio/config.yaml \
    --email vous@example.org --password-stdin

Le mot de passe est lu sur l'entrée standard (--password-stdin), ce qui évite de le laisser dans l'historique du shell. Si un super_admin existe déjà, la commande refuse ; --force permet d'en créer un autre. La page web /setup est un repli atomique tant qu'aucun super_admin n'existe.

Ajouter un administrateur de domaine

CREDENTIALS_DIRECTORY=/etc/difuzio/secrets difuzio add-admin --config /etc/difuzio/config.yaml \
    --email admin@example.org \
    --domain lists.example.org \
    --display-name "Admin Example" \
    --password-stdin

La commande crée l'utilisateur s'il n'existe pas, puis lui octroie le rôle domain_admin sur le domaine indiqué. Le mot de passe initial est optionnel (--password ou --password-stdin) ; sans mot de passe, le compte existe mais ne peut pas encore se connecter (poser un mot de passe ensuite avec reset-password).

Désigner un propriétaire de liste

Le rôle list_owner est octroyé à la création de la liste, via l'option --owner de create-list (voir Listes). Le propriétaire désigné doit déjà exister comme utilisateur actif.

Réinitialiser un mot de passe

CREDENTIALS_DIRECTORY=/etc/difuzio/secrets difuzio reset-password --config /etc/difuzio/config.yaml \
    --email utilisateur@example.org --password-stdin

Pose un nouveau mot de passe pour un utilisateur existant. Les mots de passe sont hachés avec argon2id ; un mécanisme de verrouillage protège contre le bourrage d'identifiants à la connexion.

Octroyer ou révoquer un rôle

Au-delà de add-admin (domain_admin) et create-list (list_owner initial), tout rôle s'octroie ou se révoque avec grant-role / revoke-role :

difuzio grant-role  --email u@example.org --role moderator \
    --domain lists.example.org --list announce
difuzio revoke-role --email u@example.org --role moderator \
    --domain lists.example.org --list announce

--role vaut super_admin, domain_admin, list_owner ou moderator. --domain est requis pour domain_admin/list_owner/moderator ; --list pour list_owner/moderator. L'utilisateur doit déjà exister. Le plafond d'octroi est re-vérifié (un domain_admin ne peut pas octroyer super_admin).

Note : l'octroi de rôle n'est volontairement PAS accessible via une clé d'API (seulement par session interactive ou CLI), pour empêcher une escalade latérale par une perm manage.

Clés d'API

Les automatisations s'authentifient par clé d'API plutôt que par session. Une clé est liée à un utilisateur, porte un périmètre (utilisateur, domaine ou liste) et un jeu de permissions. Voir API REST.

Mails transactionnels Modération