Come implementare l'autorizzazione multi-tenant con controllo di accesso basato su ruoli

Multi-tenant authorizationCon multi-tenancy, ogni inquilino (ad esempio, un account o un'organizzazione) funziona in un ambiente isolato, richiedendo controlli di accesso unici su misura per ruoli specifici dell'utente all'interno di quel ambiente.

Uno dei modi più efficaci per implementare l'autorizzazione multi-tenant è combinandola conControllo di accesso basato su ruoli (RBAC)RBAC semplifica la gestione dell'accesso assegnando agli utenti ruoli predefiniti che dettano le loro autorizzazioni all'interno di un ambiente.

Solo RBAC affronta tre grandi sfide in quanto le applicazioni crescono e richiedono autorizzazioni più sottili:

• Essendo limitato ai ruoli (e non agli attributi e alle relazioni), il RBAC può mancare di granularità.
• I suoi ruoli statici mancano della capacità di scalare tra gli inquilini.
• Con la crescita delle applicazioni, il numero di ruoli può diventare incontrollabile, con il risultato di una cosiddetta “Role Explosion”.

amulti-tenant RBAC modelrisolve questi problemi strutturando l'accesso utenteper tenant, consentendo assegnazioni di ruoli e autorizzazioni dinamiche all'interno di ambienti isolati. Invece di assegnare a un utente un singolo ruolo globale, le loro autorizzazioni dipendono da quale inquilino si trovano e quale ruolo hanno all'interno di quel inquilino.

Here’s a quick example of when this can be useful:

Pensate a una piattaforma di gestione del progetto SaaS in cui gli utenti possono essere membri di più organizzazioni, ognuna con livelli di accesso distinti:

Un utente potrebbe essere un amministratore in un'organizzazione con il controllo completo, mentre solo un editor in un'altra, limitato a modificare le attività ma non a gestire gli utenti.

Pensate a una piattaforma di gestione del progetto SaaS in cui gli utenti possono essere membri di più organizzazioni, ognuna con livelli di accesso distinti:

Un utente potrebbe essere un amministratore in un'organizzazione con il controllo completo, mentre solo un editor in un'altra, limitato a modificare le attività ma non a gestire gli utenti.

RBAC multi-tenant assicura che le autorizzazioni siano estese all'ambiente giusto senza inutili complessità.

In questa guida, esploreremo ilimportance of Multi-Tenant Authorizatione mostrare come può essere implementato in modo efficientePermit.io.

Discuteremo di come strutturare le politiche, assegnare ruoli per inquilino e applicarefine-grained permissions.

Andiamo a immergersi.

Perché è importante l’autorizzazione multinazionale?

L'autorizzazione multi-tenant è utile per le applicazioni in cui gli utenti appartengono a più ambienti indipendenti, ognuno con le proprie regole di accesso - un fenomeno comune nella maggior parte delle moderne applicazioni basate sul cloud.

Permessi di gestione in ambienti isolati

Con multi-tenancy, ogni utente può ricevere un approccio su misura al controllo dell'accesso in base al suo inquilino. Poiché un utente potrebbe avere ruoli e responsabilità diversi tra diversi inquilini, l'uso di multi-tenancy consente che questi ruoli debbano essere gestiti e applicati in modo indipendente.

Ciò significa che possiamo utilizzare l'autorizzazione multi-tenant per mantenere limiti chiari tra gli ambienti, assicurando al contempo che gli utenti abbiano le autorizzazioni appropriate all'interno di ciascuno.

Per esempio, considerare acloud storage platformÈ fondamentale imporre un rigoroso controllo di accesso in modo che un utente di un cliente non possa visualizzare o modificare i dati di un altro.

Ma perché non possiamo risolvere questo con il RBAC?

Perché il RBAC tradizionale non è sufficiente per l'autorizzazione multi-tenant

Molto si può dire sulle limitazioni del RBAC. Quando si tratta di applicazioni in produzione, il RBAC può rivelarsi troppo rigido e diventare troppo complesso per scalare.

• Static Roles Don't Scale Across Tenants:

  In a traditional RBAC implementation, roles usually apply globally across an application.This means a user assigned an Editor role might have access to edit all resources, even across tenants where they shouldn’t have permissions.

  This problem can present itself as simply as:

  
  

  A project management app where a user is an Editor in one team but should only have Viewer access in another.

  Multi-Tenant RBAC allows roles to be scoped per tenant, so a user can be an Editor in one organization and a Viewer in another without unnecessary role duplication. Speaking of role duplication -

  
  

• The Role Explosion Problem

  A basic RBAC model can start simple: Admin, Editor, Viewer. As more users and resource types are introduced, a role explosion can occur. If we take our previous example where a single user needs to be an Editor in one team but a Viewer in another, you can easily end up with something like this:

  • Editor_TeamA
  • Editor_TeamB
  • Viewer_TeamA
  • Viewer_TeamB
  • … and so on for every additional team / potential tenant.

  This makes the system hard to manage and difficult to update without breaking access rules.

  Multi-Tenant RBAC removes the need for tenant-specific roles by dynamically assigning roles within each tenant instead of hardcoding them.

  
  

• Multi-Tenant Authorization Requires Granularity

  RBAC is often too restricted when handling permissions at a granular level. It typically lacks built-in mechanisms to define resource-level or conditional access policies.

  Think of this policy:

  
  

  "Editors can only modify their own photos"

  How simple is that? The thing is - there’s no way RBAC can support such a policy without implementing additional logic. Especially at scale.

Un’applicazione di gestione del progetto in cui un utente è unEditorin una sola squadra, ma dovrebbe essereVieweraccesso ad un altro.

"Gli editori possono modificare solo le proprie foto"

Prima di immergersi nell'implementazione e nelle migliori pratiche, menzioneremo alcuni modelli di multi-tenancy comunemente usati:

Modelli multi-tenant comuni

L'autorizzazione a più inquilini si applica a una vasta gamma di applicazioni. Ecco alcuni dei modi più comuni in cui i inquilini sono strutturati:

1. Conti – Utilizzati nelle applicazioni SaaS di consumo, in cui ogni utente appartiene a un account indipendente (ad esempio, Google Drive, Dropbox).
2. Organizzazioni – comune nelle applicazioni aziendali, dove un'azienda (organizzazione) ha più utenti con ruoli diversi (ad esempio, Slack, Notion).
3. Gruppi – Utile per gli ambienti collaborativi, dove gli utenti sono raggruppati in base alle esigenze di accesso condiviso (ad esempio, team GitHub, spazi di lavoro del progetto).
4. In sistemi in cui le imprese operano in base a un modello di franchising, ogni franchising funziona in modo indipendente ma segue una struttura centrale (ad esempio, sistemi di gestione del ristorante).

Ciascuno di questi modelli beneficia dell'autorizzazione Multi-Tenant per garantire un adeguato isolamento e autorizzazioni basate su ruoli per inquilino.

Comprendendo i vantaggi dell'autorizzazione multi-tenant, procediamo a discutere dell'implementazione.

Le migliori pratiche per l’autorizzazione multi-tenant

Strategie efficaci per la gestione dei ruoli, delle autorizzazioni e della scalabilità in ambienti isolati in applicazioni multi-tenant.

Pianifica la tua strategia di autorizzazione multi-tenant

Prima di immergersi nell'implementazione di qualsiasi cosa, è essenziale pianificare come funzionerà il modello multi-tenant.separate, manageable access controlsEcco alcuni elementi chiave che dovresti definire se stai usando un modello RBAC:

• Utenti: individui che accedono al sistema. Ognuno può appartenere a più inquilini.
• Locatari: ambienti separati in cui gli utenti operano (come account, organizzazione o spazio di lavoro).
• Ruoli: livelli di autorizzazione predefiniti assegnati agli utenti all'interno di un inquilino.
• Risorse: oggetti (ad esempio foto, documenti) con cui gli utenti interagiscono, controllati da autorizzazioni.
• Permessi: regole che definiscono le azioni che i ruoli possono eseguire su risorse specifiche.

Rispondendo a queste domande in anticipo, si può costruire unflexible and scalablesistema di autorizzazione adattato alle esigenze della tua applicazione.

Comprendere gli obiettivi multi-tenant

Dal momento che asingle user can exist in multiple tenantsIl sistema deve garantire:

1. Le assegnazioni di ruoli sono per inquilino – Le autorizzazioni di un utente dovrebbero essere estese al loro inquilino specifico.
2. Le risorse sono collegate ai locatari – le risorse dovrebbero appartenere a un locatario specifico.
3. I permessi vengono valutati dinamicamente: quando un utente effettua una richiesta, il sistema controlla sia il loro ruolo nel locatore che la proprietà della risorsa.

Ottimizzazione dell'autorizzazione multi-tenant: disconnettere lo schema dai dati

Una sfida comune nei sistemi multi-tenant è quello di gestire comeroles and policiesIn sistemi tradizionali, ruoli e autorizzazioni sono spesso strettamente associati ai dati dell'applicazione. Questo può creare complicazioni quando le autorizzazioni devono cambiare, in quanto potrebbe essere necessario aggiornare entrambi i dati dell'applicazione.role assignmente ilapplication datadi sé.

Per ottimizzare la scalabilità:

• Conservare ruoli, assegnazioni e politiche in un sistema di autorizzazione dedicato (come Permit.io) e tenere separati i dati dell'applicazione dalla logica di autorizzazione.
• Questa disconnessione consente di aggiornare i ruoli o le autorizzazioni in modo dinamico senza toccare i dati di base o la base di codice dell'applicazione.

Usare una fonte di verità - il PDP (Political Decision Point)

Uno dei concetti critici nell'ottimizzazione dell'autorizzazione multi-tenant è l'utilizzo di unsingle source of truthper prendere decisioni politiche.

Invece di memorizzare le informazioni di ruolo e le regole di accesso all'interno di ciascun servizio o database utente, ilPolicy Decision Point (PDP)agisce come il punto centrale in cui vengono prese tutte le decisioni di accesso.

Benefits of using a PDP:

• Consistenza: il PDP assicura che tutti i servizi in tutta l'applicazione si riferiscono allo stesso insieme di regole quando si prendono decisioni di autorizzazione.
• Valutazione dinamica delle politiche: le modifiche alle politiche o alle assegnazioni di ruoli devono essere aggiornate solo in una posizione, il PDP. Questa centralizzazione elimina la necessità di aggiornare più posizioni nel database o nel codice.
• Meno rischio di errori: affidandosi a un unico punto decisionale centralizzato, si riduce il rischio di autorizzazioni inconsistenti tra inquilini e applicazioni.

Controllo di accesso basato su relazioni (ReBAC)

MentreRBACfornisce una solida base per l'autorizzazione multi-tenant, ci sono scenari in cuirelationship-based access control (ReBAC)può offrire un controllo di accesso ancora più fine-grain.

RBAC definisce le autorizzazioni in base ai ruoli assegnati agli utenti, maReBACun ulteriore passo per definire le autorizzazioni basate sulrelationshipsQuesto è particolarmente utile in situazioni in cui le autorizzazioni dipendono dal modo in cui le risorse sono collegate o associate tra loro.

Per esempio, immaginate adocument management systemQuando un utente ha accesso afolder, e quella cartella contiene più documenti. Con RBAC, dovresti definire ruoli comeFolder EditoroDocument ViewerTuttavia, conReBACPotresti semplificarlo dicendo:

“Un utente può modificare un documento se è un editor della cartella alla quale appartiene il documento.”

“Un utente può modificare un documento se è un editor della cartella alla quale appartiene il documento.”

Ciò consente assegnazioni di autorizzazioni più dinamiche e sensibili al contesto senza duplicare ruoli per ogni risorsa.

Benefits of ReBAC:

• Permessi contestuali: consente il controllo dell'accesso basato su relazioni dinamiche (ad esempio, un utente che è un editor in un progetto e quindi ha accesso a tutte le attività correlate).
• Riduzione dell'esplosione dei ruoli: non è necessario creare ruoli per ogni combinazione di tipo utente e risorsa, poiché le relazioni possono definire l'accesso in modo dinamico.

Estendendo RBAC con ReBAC, è possibile gestirecomplex access control scenariosdove le relazioni tra utenti e risorse dettano autorizzazioni.

Implementazione dell'autorizzazione multinazionale conPermesso io

Permit.iooffre un modo semplice per implementare l'autorizzazione a più inquilini, consentendo di definire ruoli, politiche e regole di accesso in diversi ambienti.

if (user.role == admin && user.tenant == resource.tenant) {
    return true;
}

Tradizionale e statica if L’approccio per la multi-tenance.

const permitted = await permit.check(user, "read", {
    resource: "document",
    tenant: "default"
});

if (permitted) {
    return true;
} 

Una pulizia permit.check() funzione che controlla per multi-tenance RBAC.

Ecco un'ampia panoramica di come l'autorizzazione RBAC multi-tenant può essere impostata in Permit.io:

• Define Roles, Resources, and Actions: To get started, first define your resources (e.g., documents, photos, tasks) and the actions that can be performed on them (e.g., create, read, update, delete).
  • Add a new resource (e.g., blog) to represent the type of object you want to control access to.
  • Specify the resource's key, which will be used in your API calls.
  • Define the actions users should be able to perform on the resource (e.g., create, read, update, delete).
  • The screenshot shows an example where blog is the resource, and actions are defined for it.

• Define the Access Control Policy:

  You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like admin, public, and Writer are defined, and the policy is set up to specify which actions are permitted for each role.

  

• Define the Tenants in the Directory:

  Each tenant can have its own set of roles, permissions, and policies.

  To create tenants:

  • Go to the Directory screen and click on Settings.
  • Define the tenants you need (e.g., Tenant 1, Tenant 2, etc.).

  

  Create Users and Assign Roles:

  Once the tenants are defined, you can create users and assign them roles specific to each tenant. This ensures that the same user can have different roles in each tenant, depending on what permissions they need.

  To create a new user:

  
  

  • Click Add User in the Directory screen.

  • Assign the user a unique key and other user details (e.g., email, first name).

  • In the Permissions Per Tenant section, you can assign the user roles specific to the tenant to which they belong.

    For instance, the user could be an Admin in Tenant 1 and a Writer in Tenant 2, as shown in the screenshot:

    
    

Qui, possiamo vedere tutti i nostri utenti e quali ruoli hanno in ciascun inquilino a cui appartengono:

Alcuni dei vantaggi dell'utilizzo di Permit.io per l'autorizzazione multi-tenant includono:

• Gestione centralizzata delle politiche: definire e gestire tutte le regole e le politiche di autorizzazione da una piattaforma centralizzata.
• Assegnazione di ruoli specifici per inquilini: assegna e gestisce facilmente ruoli per inquilino, consentendo agli utenti di avere ruoli diversi in ambienti diversi (ad esempio, amministratore in un inquilino, visualizzatore in un altro).
• Implementare autorizzazioni dettagliate per ciascuna risorsa e imporre autorizzazioni complesse a grani sottili (come quelle basate su attributi o relazioni) senza la necessità di ulteriori logiche personalizzate.
• Supporto ReBAC: Permit.io estende il tradizionale modello RBAC con ReBAC, consentendo di definire autorizzazioni basate non solo sui ruoli degli utenti, ma anche sulle relazioni tra utenti e risorse. Questo è particolarmente utile quando hai bisogno di autorizzazioni contextuali, come consentire l'accesso a risorse a seconda della loro struttura organizzativa o gerarchie.

Summing Up: Autorizzazione Multi-Tenant con RBAC

In questo blog abbiamo esplorato ilimportance of multi-tenant authorizationCome combinare conRole-Based Access Control (RBAC)consente una gestione delle autorizzazioni degli utenti più efficiente e scalabile in ambienti isolati.

Abbiamo discusso delle sfide del RBAC tradizionale nelle applicazioni multi-tenant e di come Multi-Tenant RBAC risolve problemi come i ruoli statici, l'esplosione del ruolo e il controllo dell'accesso a grani sottili.

Con l'autorizzazione a più inquilini, ogni inquilino può avere il proprio controllo di accesso isolato, assicurando che gli utenti abbiano accesso solo a ciò per cui sono autorizzati all'interno dei loro ambienti specifici.

Permit.ioconsente di implementare l'autorizzazione a più inquilini in modo più semplificato, grazie alla gestione centralizzata delle politiche, allocazione di ruoli specifici per inquilini, autorizzazioni a grano sottile e supporto per il controllo di accesso basato sulla relazione (ReBAC).

What’s Next?

• Esplora la documentazione di Permit.io per iniziare a implementare l'autorizzazione multi-tenant nella tua applicazione.
• Unisciti alla comunità Permit.io per discutere le migliori pratiche e ottenere supporto.