Il modello multi-tenancy di Logto spiegato

La confusione#

Potresti aver sentito parlare di alcuni prodotti che usano il termine "multi-tenancy" per rappresentare l'isolamento dell'identità: ogni tenant ha il proprio insieme di utenti, ruoli, permessi e dati.

Potrebbe sembrare controintuitivo, ma in realtà, "multi-tenancy" indica il contrario: più tenant condividono risorse in un'unica istanza. Per gli utenti, un'identità in un'app è come una patente di guida. Ad esempio, con una patente di guida, puoi guidare in diversi stati (un'identità per più organizzazioni), invece di richiedere una nuova patente per ogni stato.

Il modello di Logto#

In Logto, abbiamo notato questa confusione all'inizio del nostro design, e ci siamo impegnati a renderlo corretto per le tue app e i tuoi utenti. Ecco il nostro design:

• Un tenant può essere trattato come una singola istanza di Logto, che ha il proprio insieme di utenti, permessi e dati.
• All'interno di un tenant, possono esserci più organizzazioni. Un utente può essere membro di più organizzazioni.
• Per ogni organizzazione, segue il modello di controllo degli accessi basato sui ruoli (RBAC) e utilizza lo stesso insieme di ruoli e permessi dell'organizzazione. Questo insieme è chiamato modello dell'organizzazione.
• I ruoli e i permessi dell'organizzazione sono efficaci se e solo se nel contesto di un'organizzazione.
  • Ad esempio, un utente può essere un "admin" (ruolo) in un'organizzazione, ma un "membro" (ruolo) in un'altra organizzazione.
  • Senza il contesto di un'organizzazione, i ruoli e i permessi dell'organizzazione sono privi di significato.
• Usa i permessi dell'organizzazione per controllare l'accesso all'interno di un'organizzazione, invece di usare i ruoli dell'organizzazione.

Questo modello offre flessibilità e riusabilità nella gestione delle identità, specialmente per le app SaaS. Se diamo un'occhiata ad alcune app SaaS popolari, possiamo vedere che possono adattarsi a questo modello. Il termine "organizzazione" può differire a seconda delle app, come "workspace", "team", ecc. Ma il concetto è lo stesso.

Ad esempio, in Notion (un popolare strumento di collaborazione):

• Puoi creare e unirti a più workspace con un solo account, invece di registrarti ogni volta con un account diverso per ogni workspace.
• Per ogni workspace, Notion definisce un insieme fisso di livelli di accesso: "Proprietario del workspace" e "membro", mentre potresti aspettarti livelli di accesso differenti per ogni workspace.

Pertanto, gli utenti possono facilmente passare tra i workspace senza dover cambiare account o rientrare, mantenendo l'isolamento tra i workspace. Tradotto nel modello di Logto, significa:

• Il modello dell'organizzazione definisce due ruoli: "proprietario" e "membro".
• Se un utente si unisce a un workspace, significa che l'utente è un membro di un'organizzazione, ed ha il ruolo di "membro" nell'organizzazione.
• Se un utente crea un workspace, significa che l'utente è un membro di un'organizzazione, ed ha il ruolo di "proprietario" nell'organizzazione.

Secondo i diversi ruoli, un utente può avere permessi diversi in diversi workspace (organizzazioni).

I benefici#

Esperienza utente#

Per gli utenti, possono godere della vera esperienza di single sign-on. Cambiare organizzazione è semplice come passare da una scheda all'altra.

Riusabilità#

Uno dei vantaggi delle app SaaS è che sono standardizzate e scalabili. Ad esempio, puoi creare un nuovo workspace in Notion con pochi clic, ed è pronto all'uso.

Quando la tua app cresce, potresti voler aggiungere più ruoli e permessi per ogni organizzazione. Ad esempio, un nuovo ruolo "ospite" e un nuovo permesso "invita:ospite". Può essere un incubo se devi aggiornare tutte le organizzazioni esistenti una per una.

Con Logto, puoi aggiornare il modello dell'organizzazione, e tutte le organizzazioni esistenti saranno aggiornate automaticamente.

Un unico modello di controllo degli accessi, molteplici casi d'uso#

In Logto, utilizziamo lo stesso modello di controllo degli accessi (RBAC) sia per le organizzazioni che per le risorse API. Significa che non devi imparare un nuovo modello di controllo degli accessi se sei già familiare con RBAC. Nel frattempo, sono isolati l'uno dall'altro, quindi puoi usarli per casi d'uso differenti.

La parte più emozionante è che puoi usarli contemporaneamente. Estendiamo l'esempio di Notion:

• Per accedere ai workspace, puoi utilizzare RBAC dell'organizzazione di Logto.
• Per accedere e aggiornare le risorse a livello di account (come il profilo e le informazioni di fatturazione), puoi utilizzare RBAC delle risorse API di Logto.

La maggior parte degli SDK di Logto supporta entrambi i tipi di RBAC.

Le differenze

RBAC dell'organizzazione e RBAC delle risorse API sono differenti nei seguenti aspetti:

• RBAC dell'organizzazione richiede il contesto di un'organizzazione, mentre RBAC delle risorse API no.
• RBAC dell'organizzazione è utilizzato per controllare l'accesso all'interno di un'organizzazione, mentre RBAC delle risorse API è utilizzato per controllare l'accesso alle risorse API.
• Un utente può avere ruoli diversi in diverse organizzazioni, mentre i ruoli per le risorse API sono universali nel tenant.
• Ruoli e permessi sono isolati per questi due tipi di RBAC.

Conclusione#

Costruire un'app SaaS è difficile, e speriamo che Logto possa aiutarti a concentrarti sul tuo core business. Non esitare a darci feedback se hai domande o suggerimenti.