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é.

Un ajout ou un retrait prend effet sans redémarrage : les services qui lisent le registre le relisent quand le fichier change.

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.

Une clé peut porter un plafond de réunions simultanées, max_concurrent_rooms, posé à la création ou par PATCH /api/tenants/{id}. Une réunion est une salle qui tient au moins une personne : le nombre de salles, lui, n’est borné par rien. Au plafond, la première personne d’une salle vide est refusée, quelle que soit la porte (hall d’accueil, API native, connecteur BigBlueButton), et la place se libère quand une réunion se termine. Zéro retire le plafond ; la clé primaire n’en a jamais.

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.