Modèle de tenancy — deux formes prises en charge
Audact prend en charge à la fois la création publique de tenants sans clé et la création de tenants rattachés à une organisation. Choisissez la forme qui convient à votre intégration.
Audact prend en charge les deux formes de création de tenants entre lesquelles un intégrateur peut avoir à choisir — il s’agit d’une décision de conception du côté de l’appelant, et non d’une lacune de l’API.
Forme 1 — Création publique de tenant, sans clé
POST /v1/tenants (tenant-management, non authentifié)
- Aucune clé API ni compte d’organisation n’est requis pour appeler ce point de terminaison.
- Limité par IP à 5 créations par IP et par heure, car il est par ailleurs ouvert.
- Cycle de vie du tenant à partir de là :
GET /v1/tenants/{tenant_id}(viewer et plus),PUT /v1/tenants/{tenant_id}(owner), clés API viaPOST/GET/DELETE /v1/tenants/{tenant_id}/keys[/{key_id}](owner pour créer ou révoquer, developer et plus pour lister).
Forme 2 — Tenants rattachés à une organisation, avec cycle de vie complet
POST /v1/org/tenants (org-management, exige une organisation authentifiée et vérifiée) —
crée un tenant appartenant à l’organisation de l’appelant, volontairement sans clé API ni
configuration par défaut ; celles-ci sont reportées à une étape initialize distincte, de sorte que la création du tenant et
son activation soient deux actions auditables.
Cycle de vie complet dans le modèle rattaché à une organisation :
| Point de terminaison | Effet |
|---|---|
POST /v1/org/tenants | Crée la ligne du tenant, rattachée à l’organisation. Pas encore de clé ni de configuration. |
POST /v1/org/tenants/{id}/initialize | Initialise la première configuration par défaut figée du tenant et révèle sa première clé API owner (idempotent — renvoie 409 already_initialized lors d’un second appel au lieu de dupliquer). |
POST /v1/org/tenants/{id}/keys | Crée une clé API owner supplémentaire sans toucher à la configuration. |
POST /v1/org/tenants/{id}/enable | Définit status=active et efface le marqueur Redis org:tenant-disabled. |
POST /v1/org/tenants/{id}/disable | C’est une PAUSE — voir ci-dessous. |
DELETE /v1/org/tenants/{id} | Suppression logique : définit deleted_at et pose le marqueur org:tenant-disabled. La clé HMAC KMS du tenant est conservée, jamais déprovisionnée. |
POST /v1/org/tenants/{id}/restore | Efface deleted_at sur un tenant supprimé logiquement ; réutilise telle quelle la hmac_key_arn d’origine (pas de nouvel approvisionnement, ni nouvelle configuration ni nouvelle clé). |
POST /v1/org/tenants/{id}/impersonate | Crée un JWT de courte durée (~20 min) limité au tenant, afin que l’administrateur de l’organisation puisse agir comme owner du tenant auprès des services destinés aux tenants ; chaque appel est consigné dans le journal d’audit. |
disable est une véritable PAUSE
POST /v1/org/tenants/{id}/disable fait passer le tenant à status=disabled et pose le
marqueur Redis org:tenant-disabled:{tenant_id}. À partir de là :
- Le middleware d’authentification par clé API vérifie ce marqueur sur le chemin critique et rejette toute
requête authentifiée avec les clés API de ce tenant par un
403, code d’erreurtenant_disabled— y compris les jetons créés par impersonation. - La vérification se replie en mode ouvert (laisse passer la requête et consigne un avertissement) si Redis lui-même est injoignable, de sorte qu’une panne de Redis ne puisse pas devenir en soi un incident de disponibilité pour les tenants qui ne sont pas désactivés.
enableefface le marqueur et rétablitstatus=active; l’inversion est immédiate.
C’est l’équivalent d’une PAUSE à la granularité du tenant. La pause au niveau du DID — conserver un numéro de téléphone sans l’acheminer — est un concept distinct.
Isolation par tenant dans les deux formes
- Les clés API et le secret de signature HMAC des webhooks sont propres à chaque tenant, quelle que soit la forme qui a créé le tenant — il n’existe aucun secret de signature partagé ou global.
- Chaque requête dans tenant-management/org-management est limitée par
tenant_id, pris dans le contexte authentifié, jamais dans un champ du corps de la requête.
Recommandation
Un tenant Audact par tenant côté intégrateur vous donne l’isolation des clés API et des secrets par tenant, la
correspondance disable → PAUSE exactement à la granularité que vous souhaitez probablement, et la frontière d’isolation
entre tenants existante d’Audact — sans frais, sans câblage supplémentaire. L’API n’impose pas cette
correspondance, mais c’est la plus simple à raisonner.