Organisation, rôles et permissions¶

L'organisation¶

L'organisation est l'entité centrale de Xolo : elle regroupe des membres, des équipes, un ou plusieurs fournisseurs LLM, des budgets, des middlewares et des paramètres (devise, rétention des événements…). Toutes les données et configurations sont cloisonnées par organisation.

Un même utilisateur peut appartenir à plusieurs organisations ; il bascule de l'une à l'autre depuis le menu de l'interface.

Le tenant¶

Au-dessus de l'organisation se trouve le tenant, la frontière d'isolation la plus externe : il possède des organisations et des utilisateurs. Rien ne franchit cette frontière — ni un compte, ni un jeton d'API, ni une session.

Vous n'avez normalement pas à vous en soucier. Par défaut, Xolo fonctionne avec un tenant unique nommé default, créé automatiquement : aucun sous-domaine n'est nécessaire, aucune URL ne change, et le tenant n'apparaît nulle part dans l'interface.

Il ne devient visible que sur une instance mutualisée, où plusieurs clients cohabitent. Le multi-tenant s'active alors par configuration (XOLO_MULTITENANCY_ENABLED), et chaque tenant est identifié par les domaines déclarés pour lui, par exemple acme.xolo.example.com. Un hôte qui n'est le domaine actif d'aucun tenant actif renvoie une erreur 404.

Deux tenants peuvent héberger une organisation portant le même slug, et une même identité peut y disposer de deux comptes distincts, sans aucune collision. La gestion des tenants passe exclusivement par l'API de provisioning ; il n'existe pas d'interface dédiée.

Rôles¶

Un rôle est un ensemble de permissions attribué à un ou plusieurs membres. Xolo distingue deux catégories de rôles :

Rôles intégrés¶

Ces rôles ne peuvent être ni renommés, ni supprimés, ni voir leurs permissions modifiées.

Rôles personnalisés¶

Une organisation peut créer autant de rôles personnalisés que nécessaire, en combinant librement les permissions disponibles (voir le tutoriel Rôles pour la liste complète des permissions et la marche à suivre).

Modèle de permissions¶

Les permissions suivent un schéma <ressource>:<action>, par exemple providers:write ou events:read:all.

Règle implicite lecture/écriture¶

Lorsqu'une permission d'écriture (*:write) est attribuée, la permission de lecture correspondante (*:read) est automatiquement accordée. Il n'est donc jamais nécessaire d'attribuer les deux permissions séparément.

Équipes¶

Un rôle dit ce qu'un membre peut faire ; une équipe dit avec quoi. Une équipe regroupe des membres, les modèles et middlewares qu'ils utilisent, et leur budget. Un membre peut appartenir à plusieurs équipes.

• Accès aux modèles. Un membre utilise un modèle si l'une de ses équipes y donne accès. Les permissions model:use:org et model:use:virtual ouvrent tous les modèles de l'organisation sans passer par une équipe ; le rôle intégré Membre les porte.
• Attribution. Chaque requête est attribuée à une équipe, choisie par le nom du modèle <organisation>/<équipe>/<modèle>, ou à l'organisation seule.
• Rôles d'équipe. Un rôle peut être attribué à un membre sur une équipe seulement. Ses permissions marquées « équipe » (membres, budget, usage, événements, invitations) ne valent alors que pour cette équipe ; les autres ne s'appliquent pas. L'organisation alloue, l'équipe répartit.

Voir le tutoriel Équipes.

Membres et invitations¶

Un membre est un utilisateur rattaché à une organisation, avec un ou plusieurs rôles. L'entrée d'un nouveau membre dans une organisation passe toujours par une invitation : un lien, ciblé (lié à un email) ou ouvert (utilisable par n'importe qui), avec une expiration et/ou un nombre d'usages optionnels.

Pour la marche à suivre, voir les tutoriels Membres et Invitations.