Skip to Content

Multi-Tenancy

Auris est une plateforme d’identity and access management multi-tenant. Chaque déploiement sert un ou plusieurs tenants, chacun représentant une unité organisationnelle isolée avec ses propres utilisateurs, applications, rôles, permissions, policies de sécurité et branding.

Le Modèle Tenant Auris

Un tenant dans Auris représente une seule organisation, entreprise ou environnement qui utilise Auris pour l’authentification et l’autorisation. Chaque tenant obtient :

  • Son propre ensemble d’utilisateurs (aucun utilisateur n’est partagé entre tenants par défaut)
  • Ses propres applications (chacune avec ses propres credentials client OAuth)
  • Ses propres rôles et permissions (RBAC, modèles FGA, custom claims)
  • Ses propres policies de sécurité (enforcement MFA, policies de session, rate limits, règles IP, CAPTCHA)
  • Son propre branding (logo, couleurs, nom d’entreprise, domaine personnalisé)
  • Son propre abonnement billing (plan, moyen de paiement, factures)
  • Ses propres logs d’audit (événements d’authentification, actions admin, modifications de policy)

Les tenants sont la frontière d’isolation de premier niveau dans Auris. Rien ne fuit entre les tenants.

Un Tenant = Un Realm Keycloak

En interne, chaque tenant Auris se mappe exactement à un realm Keycloak. Keycloak est l’identity provider qu’Auris enveloppe avec son API de plus haut niveau.

Tenant Auris "acme-corp"  ←→  Realm Keycloak "acme-corp"
Tenant Auris "beta-inc"   ←→  Realm Keycloak "beta-inc"
Tenant Auris "staging"    ←→  Realm Keycloak "staging"

Ce mapping fournit plusieurs garanties :

Isolation Complète des Données

Les realms Keycloak sont complètement isolés au niveau de la base de données. Les utilisateurs, clients, rôles, sessions et credentials d’un realm ne peuvent pas être accessibles depuis un autre realm. Ce n’est pas un filtre au niveau applicatif — c’est appliqué par le modèle de données Keycloak.

Infrastructure d’Authentification Séparée

Chaque realm a son propre :

  • Endpoint de login et gestion des sessions
  • Cookies SSO (un utilisateur connecté dans le realm A n’est pas connecté dans le realm B)
  • Configurations d’identity provider (login social, SAML, fédérations OIDC)
  • Flux d’authentification et actions requises
  • Policies de mots de passe et gestion des credentials

Matériel Cryptographique Indépendant

Chaque realm peut avoir ses propres clés de signature pour les JWT. Cela signifie que les tokens émis pour un tenant ne peuvent pas être vérifiés contre l’endpoint JWKS d’un autre tenant.

Isolation des Données en Détail

LayerDonnéesMécanisme d’Isolation
KeycloakCredentials utilisateur, sessions, clients OAuthSéparation par realm
Prisma AurisRôles, permissions, modèles FGAChamp tenantId sur tous les modèles
API AurisToutes les requêtesHeader x-tenant requis

Identification du Tenant

Chaque requête à l’API Auris doit identifier le tenant. Cela se fait via :

  1. Header x-tenant : Défini par l’application dans chaque requête API
  2. Sous-domaine : Si le tenant a un domaine personnalisé, il est détecté automatiquement depuis le hostname
  3. Slug du tenant : Depuis l’URL (ex. /api/tenant/acme-corp/users)

Les SDKs Auris gèrent automatiquement le x-tenant quand configurés avec un domain ou clientId.

Organisations au Sein des Tenants

Auris supporte également les organisations au sein des tenants — utiles pour les scénarios B2B où ton produit sert plusieurs entreprises, chacune avec ses propres utilisateurs et configurations SSO.

Tenant (ta plateforme SaaS)
  └── Organisation : Acme Corp
  │     ├── Utilisateurs
  │     ├── Connexion SSO Enterprise (Okta)
  │     └── Rôles spécifiques à l'organisation
  └── Organisation : Beta Inc
        ├── Utilisateurs
        ├── Connexion SSO Enterprise (Azure AD)
        └── Rôles spécifiques à l'organisation

Les organisations existent au sein d’un seul realm Keycloak. Elles ne sont pas aussi isolées que les tenants, mais fournissent des frontières logiques de regroupement des utilisateurs avec :

  • Gestion des appartenances
  • Invitations avec liens d’acceptation avec expiration
  • Connexions SSO par organisation (SAML, OIDC)
  • Rôles et permissions par organisation
  • Provisioning SCIM par organisation

Création du Tenant

Quand un nouveau tenant est créé dans Auris :

  1. Un enregistrement Tenant est créé dans la base de données Auris (Prisma)
  2. Un realm Keycloak correspondant est créé avec la même clé (tenantId)
  3. Les paramètres par défaut du realm sont configurés (policies de mots de passe, policies de session)
  4. Un AdminClient Keycloak est créé pour l’API de gestion
  5. Un abonnement billing Stripe est créé (plan Free par défaut)
  6. L’utilisateur fondateur reçoit le rôle super_admin dans le nouveau tenant

Implications pour le Développeur

Chaque Requête API Nécessite un Tenant

// Avec le SDK — le tenant est géré automatiquement
const auris = new AurisClient({
  domain: 'votre-domaine.com',
  clientId: 'client-id',
})
 
// Sans SDK — tu dois inclure le header x-tenant
const response = await fetch('https://votre-domaine.com/api/users', {
  headers: {
    'Authorization': `Bearer ${accessToken}`,
    'x-tenant': 'votre-tenant-id',
  },
})

La Multi-Tenancy Affecte les Tokens

Le claim iss dans chaque JWT reflète le domaine Auris. Pour les tenants avec des domaines personnalisés, l’issuer sera leur domaine personnalisé. Les resource servers qui valident les tokens doivent s’attendre à l’issuer du tenant correct.

Concepts Associés

Architecture