Logtos multitenansmodell förklarad
Ta en titt på hur vi designade Logtos multitenansmodell och de fördelar den medför för SaaS-appar.
Förvirringen
Du kanske har hört talas om några produkter som använder termen "multitenancy" för att representera identitetsisolering: varje tenant har sitt eget uppsättning av användare, roller, behörigheter och data.
Det kan verka kontraintuitivt, men faktiskt indikerar "multitenancy" motsatsen: flera tenants delar resurser i ett enda instans. För användare är en identitet i en app som ett körkort. Till exempel, med ett körkort kan du köra i olika stater (en identitet för flera organisationer), istället för att söka ett nytt körkort för varje stat.
Logtos modell
På Logto märkte vi denna förvirring i början av vår design, och vi uppmanade att göra det rätt för dina appar och dina användare. Här är vår design:
- En tenant kan betraktas som en enda Logto-instans, som har sitt eget uppsättning av användare, behörigheter och data.
- Inom en tenant kan det finnas flera organisationer. En användare kan vara medlem i flera organisationer.
- För varje organisation följer det mönstret för ansvarighetsbaserad åtkomstkontroll (RBAC) och använder samma uppsättning av organisationsroller och organisationsbehörigheter. Uppsättningen kallas organisationsmall.
- Organisationsrollerna och organisationsbehörigheterna är effektiva om och endast om i kontexten av en organisation.
- Till exempel kan en användare vara en "admin" (roll) i en organisation, men en "medlem" (roll) i en annan organisation.
- Utan kontext för en organisation är organisationsroller och organisationsbehörigheter meningslösa.
- Använd organisationsbehörigheter för att kontrollera åtkomst i en organisation, istället för att använda organisationsroller.
Denna modell ger flexibilitet och återanvändbarhet för hantering av identiteter, särskilt för SaaS-appar. Om vi tittar på några populära SaaS-appar kan vi finna att de alla passar in i denna modell. Termen "organisation" kan vara olika i olika appar, såsom "arbetsyta", "team" osv. Men konceptet är detsamma.
Till exempel, i Notion (ett populärt samarbetsverktyg):
- Du kan skapa och gå med i flera arbetsytor med ett konto, istället för att registrera dig för varje arbetsyta med olika konton.
- För varje arbetsyta definierar Notion en samma uppsättning av åtkomstnivåer: "Arbetsytans ägare" och "medlem", medan du kanske förväntar dig olika åtkomstnivåer för olika arbetsytor.
Därmed kan användare enkelt växla mellan arbetsytor utan att byta konton eller logga in igen, och det behåller isoleringen mellan arbetsytor. Översätt detta till Logtos modell, det betyder:
- Organisationsmall definierar två roller: "ägare" och "medlem".
- Om en användare gick med i en arbetsyta, betyder det att användaren är medlem av en organisation, och de har rollen "medlem" i organisationen.
- Om en användare skapade en arbetsyta, betyder det att användaren är medlem av en organisation, och de har rollen "ägare" i organisationen.
Enligt olika roller kan en användare ha olika behörigheter i olika arbetsytor (organisationer).
Fördelarna
Användarupplevelse
För användare, kan de njuta av den sanna single sign-on-upplevelsen. Att växla mellan organisationer är lika enkelt som att växla mellan flikar.
Återanvändbarhet
En fördel med SaaS-appar är att de är standardiserade och skalbara. Till exempel kan du skapa en ny arbetsyta i Notion med några få klick, och den är redo att användas.
När din app växer, kanske du vill lägga till fler roller och behörigheter till varje organisation. Till exempel en ny roll "gäst" och en ny behörighet "inbjuda:gäst". Det kan vara en mardröm om du behöver uppdatera alla befintliga organisationer en efter en.
Med Logto kan du uppdatera organisationsmallen, och alla befintliga organisationer kommer att uppdateras automatiskt.
En åtkomstkontrollmodell, flera användningsfall
I Logto använder vi samma åtkomstkontrollmodell (RBAC) för både organisationer och API-resurser. Det betyder att du inte behöver lära dig en ny åtkomstkontrollmodell om du är bekant med RBAC. Samtidigt är de isolerade från varandra, så du kan använda dem för olika användningsfall.
Det mest spännande är att du kan använda dem samtidigt. Låt oss förlänga Notion-exemplet:
- För att komma åt arbetsytor, kan du använda Logto-organisation RBAC.
- För att komma åt och uppdatera resursnivåkonton (som profil och faktureringsinformation), kan du använda Logto-API-resurs RBAC.
De flesta av Logto SDKs stöder båda typer av RBAC.
Skillnaderna
Organisation RBAC och API-resurs RBAC skiljer sig i följande aspekter:
- Organisation RBAC kräver kontexten av en organisation, medan API-resurs RBAC inte gör det.
- Organisation RBAC används för att kontrollera åtkomst i en organisation, medan API-resurs RBAC används för att kontrollera åtkomst till API-resurser.
- En användare kan ha olika organisationsroller i olika organisationer, medan rollerna för API-resurs är universella i tenanten.
- Roller och behörigheter är isolerade för dessa två typer av RBAC.
Avslutande anteckningar
Att bygga en SaaS-app är svårt, och vi hoppas Logto kan hjälpa dig att fokusera på din kärnverksamhet. Tveka inte att ge oss feedback om du har några frågor eller förslag.