Skip to Content

Multi-Tenancy

Auris è una piattaforma di identity and access management multi-tenant. Ogni deployment serve uno o più tenant, ognuno rappresentante un’unità organizzativa isolata con i propri utenti, applicazioni, ruoli, permessi, policy di sicurezza e branding.

Il Modello Tenant Auris

Un tenant in Auris rappresenta una singola organizzazione, azienda o ambiente che usa Auris per l’autenticazione e l’autorizzazione. Ogni tenant ottiene:

  • Il proprio set di utenti (nessun utente è condiviso tra tenant per default)
  • Le proprie applicazioni (ognuna con le proprie credenziali client OAuth)
  • I propri ruoli e permessi (RBAC, modelli FGA, custom claim)
  • Le proprie policy di sicurezza (enforcement MFA, policy sessioni, rate limit, regole IP, CAPTCHA)
  • Il proprio branding (logo, colori, nome azienda, dominio personalizzato)
  • La propria sottoscrizione billing (piano, metodo di pagamento, fatture)
  • I propri log di audit (eventi di autenticazione, azioni admin, modifiche policy)

I tenant sono il confine di isolamento di primo livello in Auris. Nulla trapela tra tenant.

Un Tenant = Un Realm Keycloak

Internamente, ogni tenant Auris si mappa esattamente a un realm Keycloak. Keycloak è l’identity provider che Auris avvolge con la sua API di più alto livello.

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

Questo mapping fornisce diverse garanzie:

Isolamento Completo dei Dati

I realm Keycloak sono completamente isolati a livello di database. Gli utenti, i client, i ruoli, le sessioni e le credenziali in un realm non possono essere accessibili da un altro realm. Questo non è un filtro a livello applicativo — è applicato dal modello dati di Keycloak.

Infrastruttura di Autenticazione Separata

Ogni realm ha il proprio:

  • Endpoint di login e gestione delle sessioni
  • Cookie SSO (un utente loggato nel realm A non è loggato nel realm B)
  • Configurazioni dell’identity provider (login social, SAML, federazioni OIDC)
  • Flussi di autenticazione e azioni richieste
  • Policy password e gestione delle credenziali

Materiale Crittografico Indipendente

Ogni realm può avere le proprie chiavi di firma per i JWT. Ciò significa che i token emessi per un tenant non possono essere verificati contro l’endpoint JWKS di un altro tenant.

Isolamento dei Dati in Dettaglio

LayerDatiMeccanismo di Isolamento
KeycloakCredenziali utente, sessioni, client OAuthSeparazione per realm
Prisma AurisRuoli, permessi, modelli FGACampo tenantId su tutti i modelli
API AurisTutte le richiesteHeader x-tenant richiesto

Identificazione del Tenant

Ogni richiesta all’API Auris deve identificare il tenant. Questo avviene tramite:

  1. Header x-tenant: Impostato dall’applicazione in ogni richiesta API
  2. Sottodominio: Se il tenant ha un dominio personalizzato, viene rilevato automaticamente dall’hostname
  3. Slug del tenant: Dall’URL (es. /api/tenant/acme-corp/users)

Gli SDK Auris gestiscono automaticamente il x-tenant quando configurati con un domain o clientId.

Organizzazioni all’Interno dei Tenant

Auris supporta anche organizzazioni all’interno dei tenant — utili per scenari B2B in cui il tuo prodotto serve più aziende, ognuna con i propri utenti e configurazioni SSO.

Tenant (la tua piattaforma SaaS)
  └── Organizzazione: Acme Corp
  │     ├── Utenti
  │     ├── Connessione SSO Enterprise (Okta)
  │     └── Ruoli specifici per l'organizzazione
  └── Organizzazione: Beta Inc
        ├── Utenti
        ├── Connessione SSO Enterprise (Azure AD)
        └── Ruoli specifici per l'organizzazione

Le organizzazioni esistono all’interno di un singolo realm Keycloak. Non sono isolate tanto quanto i tenant, ma forniscono confini logici di raggruppamento degli utenti con:

  • Gestione delle appartenenze
  • Inviti con link di accettazione con scadenza
  • Connessioni SSO per organizzazione (SAML, OIDC)
  • Ruoli e permessi per organizzazione
  • Provisioning SCIM per organizzazione

Creazione del Tenant

Quando viene creato un nuovo tenant in Auris:

  1. Viene creato un record Tenant nel database Auris (Prisma)
  2. Viene creato un realm Keycloak corrispondente con la stessa chiave (tenantId)
  3. Vengono configurate le impostazioni default del realm (politiche password, policy sessioni)
  4. Viene creato un AdminClient Keycloak per l’API di gestione
  5. Viene creato un abbonamento billing Stripe (piano Free per default)
  6. L’utente fondatore riceve il ruolo super_admin nel nuovo tenant

Implicazioni per lo Sviluppatore

Ogni Richiesta API Richiede un Tenant

// Con l'SDK — il tenant viene gestito automaticamente
const auris = new AurisClient({
  domain: 'tuo-dominio.com',
  clientId: 'client-id',
})
 
// Senza SDK — devi includere l'header x-tenant
const response = await fetch('https://tuo-dominio.com/api/users', {
  headers: {
    'Authorization': `Bearer ${accessToken}`,
    'x-tenant': 'il-tuo-tenant-id',
  },
})

La Multi-Tenancy Influisce sui Token

Il claim iss in ogni JWT riflette il dominio Auris. Per i tenant con domini personalizzati, l’issuer sarà il loro dominio personalizzato. I resource server che validano i token devono aspettarsi l’issuer del tenant corretto.

Concetti Correlati

Architettura