Logto's multi-tenant model uitgelegd

De verwarring#

Je hebt misschien gehoord van sommige producten die de term "multi-tenancy" gebruiken om de identiteitsisolatie weer te geven: elke tenant heeft zijn eigen set gebruikers, rollen, rechten en gegevens.

Het kan contra-intuïtief zijn, maar in feite geeft "multi-tenancy" het tegenovergestelde aan: meerdere tenants delen middelen in een enkele instantie. Voor gebruikers is een identiteit in een app als een rijbewijs. Met één rijbewijs kun je bijvoorbeeld in verschillende staten rijden (één identiteit voor meerdere organisaties) in plaats van voor elke staat een nieuw rijbewijs aan te vragen.

Logto's model#

Bij Logto merkten we deze verwarring op aan het begin van ons ontwerp, en we drongen erop aan om het goed te maken voor jouw apps en jouw gebruikers. Hier is ons ontwerp:

• Een tenant kan worden behandeld als een enkele Logto-instantie, die zijn eigen set gebruikers, rechten en gegevens heeft.
• Binnen een tenant kunnen meerdere organisaties zijn. Een gebruiker kan lid zijn van meerdere organisaties.
• Voor elke organisatie volgt het het role-based access control patroon (RBAC) en gebruikt het dezelfde set van organisatie rollen en organisatie rechten. Deze set wordt organisatie sjabloon genoemd.
• De organisatie rollen en organisatie rechten zijn van toepassing als en alleen als in de context van een organisatie.
  • Bijvoorbeeld, een gebruiker kan een "admin" (rol) zijn in de ene organisatie, maar een "lid" (rol) in een andere organisatie.
  • Zonder de context van een organisatie, zijn organisatie rollen en organisatie rechten zinloos.
• Gebruik organisatie rechten om toegang binnen een organisatie te beheersen, in plaats van organisatie rollen te gebruiken.

Dit model biedt flexibiliteit en herbruikbaarheid voor het beheren van identiteiten, vooral voor SaaS-apps. Als we kijken naar enkele populaire SaaS-apps, kunnen we zien dat ze allemaal in dit model passen. De term "organisatie" kan verschillend zijn in verschillende apps, zoals "werkruimte", "team", etc. Maar het concept is hetzelfde.

Bijvoorbeeld, in Notion (een populaire samenwerkingstool):

• Je kunt meerdere werkruimtes maken en eraan deelnemen met één account, in plaats van voor elke werkruimte met verschillende accounts aan te melden.
• Voor elke werkruimte definieert Notion een zelfde set toegangsniveaus: "Werkruimte eigenaar" en "lid", terwijl je misschien verschillende toegangsniveaus verwacht voor verschillende werkruimtes.

Daardoor kunnen gebruikers gemakkelijk schakelen tussen werkruimtes zonder accounts te wisselen of opnieuw in te loggen, en het behoudt de isolatie tussen werkruimtes. Vertaal dit naar Logto's model, het betekent:

• Organisatie sjabloon definieert twee rollen: "eigenaar" en "lid".
• Als een gebruiker lid werd van een werkruimte, betekent dit dat de gebruiker lid is van een organisatie, en de "lid" rol heeft in de organisatie.
• Als een gebruiker een werkruimte heeft aangemaakt, betekent dit dat de gebruiker lid is van een organisatie, en de "eigenaar" rol heeft in de organisatie.

Volgens verschillende rollen kan een gebruiker verschillende rechten hebben in verschillende werkruimtes (organisaties).

De voordelen#

Gebruikerservaring#

Voor gebruikers kunnen ze genieten van de echte single sign-on ervaring. Schakelen tussen organisaties is net zo gemakkelijk als schakelen tussen tabbladen.

Herbruikbaarheid#

Een voordeel van SaaS-apps is dat ze gestandaardiseerd en schaalbaar zijn. Je kunt bijvoorbeeld met een paar klikken een nieuwe werkruimte in Notion maken, en het is klaar voor gebruik.

Wanneer je app groeit, wil je misschien meer rollen en rechten toevoegen aan elke organisatie. Bijvoorbeeld, een nieuwe rol "gast" en een nieuw recht "uitnodigen:gast". Het kan een nachtmerrie zijn als je alle bestaande organisaties één voor één moet bijwerken.

Met Logto kun je het organisatie sjabloon bijwerken, en alle bestaande organisaties worden automatisch bijgewerkt.

Eén toegangscontrolemodel, meerdere gebruikssituaties#

In Logto gebruiken we hetzelfde toegangscontrolemodel (RBAC) voor zowel organisaties als API-resource. Het betekent dat je geen nieuw toegangscontrolemodel hoeft te leren als je bekend bent met RBAC. Ondertussen zijn ze van elkaar geïsoleerd, zodat je ze voor verschillende gebruikssituaties kunt gebruiken.

Het spannendste is dat je ze tegelijkertijd kunt gebruiken. Laten we het Notion voorbeeld uitbreiden:

• Voor toegang tot werkruimtes kun je Logto organisatie RBAC gebruiken.
• Voor toegang tot en bijwerken van accountniveau-resources (zoals profiel- en betalingsinformatie), kun je Logto API-resource RBAC gebruiken.

De meeste Logto SDK's ondersteunen beide soorten RBAC.

De verschillen

Organisatie RBAC en API-resource RBAC verschillen in de volgende aspecten:

• Organisatie RBAC vereist de context van een organisatie, terwijl API-resource RBAC dat niet doet.
• Organisatie RBAC wordt gebruikt om toegang binnen een organisatie te beheersen, terwijl API-resource RBAC wordt gebruikt om toegang tot API-resources te beheersen.
• Een gebruiker kan verschillende organisatie rollen hebben in verschillende organisaties, terwijl de rollen voor API-resource universeel zijn binnen de tenant.
• Rollen en rechten zijn geïsoleerd voor deze twee soorten RBAC.

Afsluitende opmerkingen#

Het bouwen van een SaaS-app is moeilijk, en we hopen dat Logto je kan helpen je te concentreren op je kernactiviteiten. Aarzel niet om ons feedback te geven als je vragen of suggesties hebt.