Multi-locataires

Par défaut, un serveur Vuisio est mono-locataire : une seule clé API pilote la création de salles, et qui la détient voit et pilote toutes les réunions du serveur. C’est le bon réglage tant qu’un seul service utilise le serveur.

Dès que plusieurs clients ou plusieurs plateformes (par exemple plusieurs instances Moodle, ou plusieurs établissements) partagent le même serveur, le mode multi-locataire donne à chacun sa propre clé : une clé ne voit et ne pilote que les salles qu’elle a créées, jamais celles des autres.

Le modèle

• Une clé par locataire. Chaque client ou intégration reçoit une clé avec un identifiant lisible (un slug comme greta ou moodle-acme). Les salles qu’elle crée lui appartiennent : elle seule peut les lister, les rejoindre par l’API, les terminer, et lire leurs tableaux de bord.
• Une clé primaire. L’opérateur garde une clé primaire qui, elle, voit tout le serveur. C’est la clé utilisée par le hall d’accueil, la supervision et le support. Deux locataires peuvent réutiliser le même identifiant de salle sans se marcher dessus : les salles vivent chacune dans l’espace de nom de leur clé.

L’isolation est appliquée par le SFU lui-même : une clé qui tente d’atteindre la salle d’une autre reçoit la même réponse que pour une salle inexistante, sans révéler qu’elle existe.

Gérer les clés

Deux moyens, sur le même registre.

En ligne de commande

vuisio tenant list
vuisio tenant add greta --label "GRETA Bretagne" --generate-token
vuisio tenant remove greta

--generate-token crée un jeton d’accès à l’API native et l’affiche une seule fois, à la création : notez-le immédiatement, il n’est jamais réaffiché. Le registre est conservé dans le coffre chiffré ; chaque ajout ou retrait redémarre la pile pour prendre effet.

Par l’API d’administration

L’orchestrateur expose /api/tenants, réservé à la clé primaire, pour créer, révoquer et lister les clés à chaud sans redéploiement (utile pour intégrer un client depuis un outil d’exploitation). Toute écriture est persistée dans le même registre et prise en compte immédiatement.

Révoquer une clé

Révoquer une clé la désactive : elle ne peut plus créer ni piloter de salles, mais ses réunions en cours se terminent normalement et ses données restent accessibles à la clé primaire. Rien n’est supprimé brutalement.

Installations existantes

Une installation mono-locataire continue de fonctionner à l’identique après une mise à jour : le jeton d’API existant devient simplement la clé primaire. Aucun secret n’est régénéré ni modifié. Vous n’avez rien à faire tant que vous ne souhaitez pas séparer plusieurs clients.