La guida definitiva per configurare l'autenticazione e l'autorizzazione multi-tenant
Creare un'applicazione multi-tenant può essere complesso. Questo articolo raccoglie tutti i nostri vecchi post su strategie multi-tenant e di organizzazione. Speriamo che possa aiutarti a risparmiare tempo e iniziare facilmente.
GuamianProduct & Design
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
Costruire un'app multi-tenant può essere impegnativo, con molti aspetti da considerare. Questo articolo compila tutti i nostri precedenti post del blog sulla comprensione delle pratiche multi-tenant e di organizzazione. Per iniziare rapidamente e risparmiare tempo, basta dare un'occhiata a questo articolo, contiene tutto ciò di cui hai bisogno!
Le linee guida generali sono delineate nei passaggi seguenti:
Comprendere l'architettura multi-tenant
Mappare i casi d'uso della tua app multi-tenant
Raggiungere l'isolamento dei tenant
Definire come vuoi gestire le identità
Scegliere i modelli di autorizzazione più appropriati
La multi-tenancy software è un'architettura software in cui una singola istanza di software viene eseguita su un server e serve più tenant. I sistemi progettati in questo modo sono "condivisi" (anziché "dedicati" o "isolati").
Un tenant è un gruppo di utenti che condivide un accesso comune con privilegi specifici all'istanza del software.
Uno dei concetti chiave della multi-tenancy è "condiviso". Nella definizione più ampia di multi-tenancy, essere un'applicazione multi-tenant non implica che ogni componente di una soluzione sia condiviso. Piuttosto, implica che almeno alcuni componenti di una soluzione siano riutilizzati in più tenant. Comprendere questo termine in modo ampio può aiutarti a comprendere meglio le esigenze dei tuoi clienti e da dove provengono.
Una volta compresa l'architettura multi-tenant, il passo successivo è applicare la tua app a scenari del mondo reale, concentrandosi su specifiche esigenze di prodotto e di business.
Quali sono i casi d'uso per le applicazioni multi-tenant?#
Le app multi-tenant trovano spesso il loro posto nelle soluzioni business-to-business (B2B) come strumenti di produttività, software di collaborazione e altri prodotti software-as-a-service (SaaS). In questo contesto, ogni "tenant" di solito rappresenta un cliente aziendale, che potrebbe avere più utenti (i suoi dipendenti). Inoltre, un cliente aziendale potrebbe avere più tenant per rappresentare distinte organizzazioni o divisioni aziendali.
Le applicazioni B2B vanno oltre i prodotti SaaS e spesso coinvolgono l'uso di app multi-tenant. In contesti B2B, queste app servono come piattaforma comune per vari team, clienti aziendali e aziende partner per accedere alle tue applicazioni.
Per esempio, considera un'azienda di ride-sharing che fornisce sia app B2C che B2B. Le app B2B servono più clienti aziendali e impiegare un'architettura multi-tenant può aiutare nella gestione dei loro dipendenti e risorse. Per illustrare, se l'azienda desidera mantenere un sistema di identità utente unificato, può progettare un'architettura come il seguente esempio:
Sarah ha sia un'identità personale che aziendale. Utilizza il servizio di ride-sharing come passeggero e lavora anche come autista nel suo tempo libero. Nel suo ruolo professionale, gestisce anche la sua attività e utilizza questa identità aziendale per essere partner con Business 1.
Perché dovresti impiegare la multi-tenancy in un prodotto SaaS#
Per le aziende, la multi-tenancy è la chiave per soddisfare efficacemente i loro requisiti di disponibilità, gestione delle risorse, gestione dei costi e sicurezza dei dati. A livello tecnico, adottare un approccio multi-tenant semplifica i processi di sviluppo, minimizza le sfide tecniche e promuove un'espansione senza soluzione di continuità.
Esaminando le radici dei prodotti SaaS, è come un edificio che ospita diversi appartamenti. Tutti i tenant condividono utilities comuni come acqua, elettricità e gas, eppure mantengono un controllo indipendente sulla gestione del proprio spazio e risorse. Questo approccio semplifica la gestione delle proprietà.
Garantire sicurezza attraverso l'isolamento dei tenant#
In un'architettura multi-tenancy, il termine "tenant" è introdotto per creare confini che separano e proteggono le risorse e i dati di diversi tenant all'interno di un'istanza condivisa. Questo assicura che i dati e le operazioni di ogni tenant rimangano distinti e sicuri, anche se utilizzano le stesse risorse sottostanti.
Perché dovresti raggiungere l'isolamento dei tenant?#
Quando si parla di applicazioni multi-tenant, è sempre necessario raggiungere l'isolamento dei tenant. Questo significa mantenere i dati e le risorse di diversi tenant separati e sicuri all'interno di un sistema condiviso (per esempio, un'infrastruttura cloud o un'applicazione multi-tenant). Questo previene tentativi non autorizzati di accedere alle risorse di un altro tenant.
Mentre la spiegazione potrebbe sembrare astratta, useremo esempi e dettagli chiave per spiegare ulteriormente la mentalità di isolamento e le migliori pratiche per raggiungere l'isolamento dei tenant.
L'isolamento dei tenant non va contro la mentalità "condivisa" della multi-tenancy#
Questo perché l'isolamento dei tenant non è necessariamente una costruzione a livello di risorsa dell'infrastruttura. Nel regno della multi-tenancy e dell'isolamento, alcuni vedono l'isolamento come una divisione rigorosa tra risorse infrastrutturali effettive. Questo di solito porta a un modello in cui ogni tenant ha database separati, istanze di calcolo, account, o cloud privati. In scenari di risorse condivise, come le app multi-tenant, il modo per raggiungere l'isolamento può essere una costruzione logica.
L'isolamento dei tenant si concentra esclusivamente sull'uso del contesto "tenant" per limitare l'accesso alle risorse. Valuta il contesto del tenant corrente e utilizza quel contesto per determinare quali risorse sono accessibili per quel tenant.
Autenticazione e autorizzazione non sono uguali a "isolamento"#
Usare autenticazione e autorizzazione per controllare l'accesso ai tuoi ambienti SaaS è importante, ma non è sufficiente per un isolamento completo. Questi meccanismi sono solo una parte del puzzle della sicurezza.
Le persone spesso chiedono una domanda, posso usare soluzioni di autorizzazione generale e controllo degli accessi basato sui ruoli per raggiungere l'isolamento dei tenant?
Ecco il punto, puoi costruire un'app multi-tenant ma non puoi dire di aver raggiunto e impiegato strategie di isolamento dei tenant come migliore pratica. Non lo raccomandiamo generalmente perché
Per illustrare, considera una situazione in cui hai impostato autenticazione e autorizzazione per il tuo sistema SaaS. Quando gli utenti accedono, ricevono un token contenente informazioni sul loro ruolo, dettando ciò che possono fare nell'applicazione. Questo approccio aumenta la sicurezza ma non garantisce l'isolamento.
Usa "organizzazione" per rappresentare il tenant del prodotto SaaS, per raggiungere l'isolamento dei tenant#
Affidarsi esclusivamente ad autenticazione e autorizzazione non impedirà a un utente con il giusto ruolo di accedere alle risorse di un altro tenant. Quindi dobbiamo incorporare un contesto "tenant", come un ID tenant, per limitare l'accesso alle risorse.
È qui che entra in gioco l'isolamento dei tenant. Usa identificatori specifici del tenant per stabilire confini, molto simili a muri, porte e serrature, assicurando una chiara separazione tra i tenant.
Abbiamo discusso dell'isolamento dei tenant, ma che dire delle identità? Come decidi se le tue identità devono essere "isolate" o meno?
C'è spesso confusione intorno al concetto di "isolamento dell'identità". Potrebbe riferirsi a situazioni in cui un utente nel mondo reale ha due identità nella comprensione generale delle persone.
Entrambe le identità possono esistere all'interno di un singolo sistema di identità. Per esempio, Sarah potrebbe avere un'e-mail personale registrata accanto a un'e-mail aziendale connessa tramite single sign-on (SSO).
Gli utenti mantengono due identità distinte all'interno di sistemi di identità separati, rappresentando prodotti completamente separati. Questi prodotti sono completamente non correlati tra loro.
A volte, questi scenari sono indicati come "Identità isolate". Tuttavia, questa etichetta potrebbe non aiutare a prendere una decisione.
Piuttosto che determinare se hai bisogno di "isolamento dell'identità", considera
Questa risposta può guidare il tuo design di sistema. Per una risposta concisa riguardante un'app multi-tenant,
Nelle applicazioni multi-tenant, le identità, a differenza delle risorse e dei dati specifici del tenant, sono condivise tra più tenant. Immagina di essere l'amministratore dell'edificio; non vorresti mantenere due elenchi di nomi separati per gestire le identità dei tuoi tenant.
Quando miri all'isolamento dei tenant, potresti aver notato l'enfasi ricorrente sul termine "organizzazione", spesso considerato una migliore pratica per costruire applicazioni multi-tenant.
Utilizzando il concetto di "organizzazione", puoi raggiungere l'isolamento dei tenant nella tua applicazione multi-tenant mantenendo comunque un sistema di identità unificato.
Come scegliere e progettare il modello di autorizzazione appropriato#
Quando selezioni il modello di autorizzazione giusto, considera queste domande:
Stai sviluppando un prodotto B2C, B2B o una combinazione di entrambi i tipi di prodotti?
La tua app ha un'architettura multi-tenant?
C'è bisogno di un certo livello di isolamento nella tua app, come determinato dall'unità aziendale?
Quali permessi e ruoli devono essere definiti nel contesto dell'organizzazione, e quali no?
Quali modelli di autorizzazione diversi sono disponibili in Logto?#
RBAC (Role-Based Access Control) è un metodo per concedere permessi utente in base ai loro ruoli, consentendo una gestione efficace dell'accesso alle risorse.
Questa tecnica comune sostiene il controllo degli accessi ed è un componente chiave delle funzionalità di autorizzazione di Logto. In quanto piattaforma completa di gestione delle identità, Logto offre soluzioni su misura per diversi livelli ed entità, rivolgendosi a sviluppatori e aziende per architetture di prodotto diversificate.
Per proteggere risorse API generali che non sono specifiche di alcuna organizzazione e non necessitano di restrizioni contestuali, la funzionalità API RBAC è ideale.
Basta registrare l'API e assegnare permessi a ciascuna risorsa. Quindi, controllare l'accesso attraverso la relazione tra ruoli e utenti.
Le risorse API, i ruoli e i permessi qui sono "democratizzati" sotto un sistema di identità unificato. Questo è piuttosto comune nel prodotto B2C con meno gerarchia e non ha bisogno di un livello molto profondo di isolamento.
Controllo degli accessi basato sui ruoli dell'organizzazione#
Nell'ambiente B2B e multi-tenant, l'isolamento dei tenant è necessario. Per raggiungere ciò, le organizzazioni sono utilizzate come contesto per l'isolamento, il che significa che RBAC è efficace solo quando un utente appartiene a una specifica organizzazione.
Organization RBAC si concentra sul controllo degli accessi a livello di organizzazione piuttosto che a livello di API. Questo fornisce una flessibilità significativa per l'autogestione a livello di organizzazione nel lungo periodo ma ancora all'interno di un sistema di identità unificato.
Una caratteristica chiave di organization RBAC è che ruoli e permessi sono generalmente gli stessi in tutte le organizzazioni per impostazione predefinita, il che rende il "modello di organizzazione" di Logto estremamente significativo per migliorare l'efficienza dello sviluppo. Questo si allinea con la filosofia condivisa delle app multi-tenant, dove le politiche di controllo degli accessi e le identità sono componenti infrastrutturali comuni a tutti i tenant (tenant dell'app), una pratica comune nei prodotti SaaS.
Questo articolo fornisce tutto ciò di cui hai bisogno per iniziare a preparare e configurare app multi-tenant. Prova Logto oggi e inizia ad applicare le migliori pratiche per lo sviluppo di app multi-tenant con le organizzazioni.
