Aller au contenu principal
DuoKey Cockpit — one shared platformtenant resolved from the signed token — cannot be forgedTenant AisolatedKeysAccess policiesAudit trailOrganizational unitsFinance · Engineering · …Tenant BisolatedKeysAccess policiesAudit trailTenant CisolatedKeysAccess policiesAudit trail
Every record carries a tenant id; the tenant comes from the signed token, and isolation is enforced at the data layer — with organizational units for in-tenant scoping.
S'applique à :
Cockpit v2Multi-tenant au niveau des lignesTenants gérés par le host

Le modèle multi-tenant​

Cockpit v2 est multi-tenant par conception. Chaque requête s'exécute dans le contexte de sécurité d'un tenant authentifié, et tout accès aux données est automatiquement filtré pour ce tenant. Comme l'identité du tenant est dérivée de la session signée, elle ne peut pas être falsifiée par un client.

Isolation par construction

L'accès aux données est limité au tenant au niveau de la couche de données de la plateforme, et non laissé à chaque fonctionnalité individuelle pour l'appliquer.

Deux couches de périmétrage

Les unités organisationnelles ajoutent un second périmètre, à l'intérieur du tenant, afin que les équipes et les départements puissent être isolés au sein d'un même tenant.

Droits d'accès pilotés par l'édition

Ce qu'un tenant peut faire est déterminé par son édition attribuée — il n'existe aucune dérogation de fonctionnalité par tenant.

L'enregistrement de tenant​

AttributObjet
Nom uniqueUn identifiant unique pour le tenant
Nom d'affichageComment le tenant est présenté
Contact administrateurEmail de l'administrateur principal
ÉditionL'édition attribuée, qui détermine les fonctionnalités et les limites
AbonnementModalité de facturation (paiement à l'usage, mensuel, annuel, personnalisé ou gratuit)
État d'essaiSi le tenant est en période d'essai et quand elle se termine
État actifSi le tenant est activé

Cycle de vie​

1

Créer

Un administrateur host crée le tenant avec son slug, son nom, l'email de l'administrateur et son édition. Le tenant démarre actif et en période d'essai ; la création est écrite dans les journaux d'audit et d'activité.

2

Provisionner l'administrateur

Un administrateur initial est provisionné pour le nouveau tenant afin qu'il puisse être géré de manière indépendante.

3

Exploiter

Le tenant peut être activé ou désactivé, ses utilisateurs gérés, et son édition réattribuée dans les limites de compatibilité.

4

Supprimer

La suppression est douce — l'enregistrement est conservé pour l'audit et peut être exclu de l'usage actif.

La réattribution d'édition est encadrée

Un tenant ne peut passer que vers une édition dans laquelle son usage actuel tient déjà — aucun quota numérique dépassé, aucun module en cours d'utilisation désactivé, aucun type de ressource désormais indisponible présent. Toutes les violations sont signalées ensemble. Voir Éditions.

Unités organisationnelles​

À l'intérieur d'un tenant, les unités organisationnelles forment une arborescence qui limite les ressources et les attributions de rôles aux équipes ou aux départements. Une app (et d'autres ressources) peut être rattachée à une OU ; une OU nulle signifie que la ressource est visible pour tout le tenant. Voir Administration → Unités organisationnelles.

Administration gérée par le host​

La gestion des tenants est une capacité de niveau host — créer et configurer des tenants, les activer ou les désactiver, réattribuer des éditions, et effectuer une récupération d'utilisateur côté host (comme déverrouiller des comptes ou réinitialiser la MFA). Ces actions ne sont pas disponibles à l'intérieur d'un tenant ordinaire, et les actions de récupération sont auditées séparément de l'usurpation d'identité afin que les opérations sensibles restent traçables.

Référence API
Les points de terminaison API détaillés sont documentés séparément dans la Documentation développeur → API d'administration de la plateforme.