Den ultimata guiden till konfiguration av multi-tenant autentisering och auktorisering
Att skapa en multi-tenant applikation kan vara komplext. Denna artikel samlar alla våra tidigare inlägg om multi-tenant och organisationsstrategier. Vi hoppas att den kan hjälpa dig spara tid och komma igång lätt.
GuamianProduct & Design
Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Att bygga en multi-tenant app kan vara utmanande, med många aspekter att överväga. Denna artikel sammanställer alla våra tidigare blogginlägg om förståelse för multi-tenant och organisationspraxis. För en snabb start och för att spara tid, kolla bara in denna artikel, den innehåller allt du behöver!
De allmänna riktlinjerna är beskrivna i följande steg:
Programvaru-multi-tenancy är en programvaruarkitektur där en enda instans av programvara körs på en server och betjänar flera tenants. System som är designade på detta sätt är "delade" (snarare än "dedikerade" eller "isolerade").
En tenant är en grupp av användare som delar gemensam åtkomst med specifika privilegier till programvaruinstansen.
En av de centrala tankesätten för multi-tenancy är "delad". I en bredare definition av multi-tenancy innebär att vara en multi-tenant applikation inte att varje komponent i en lösning är delad. Snarare innebär det att åtminstone några komponenter av en lösning är återanvänds över flera tenants. Att förstå denna term brett kan bättre hjälpa dig empatiera med dina kunders behov och var de kommer ifrån.
När du har förstått multi-tenant arkitektur, är nästa steg att tillämpa din app på verkliga scenarier, med fokus på specifika produkt- och affärsbehov.
Vad är användningsfallen för multi-tenant applikationer?#
Multi-tenant appar finner ofta sin plats i business-to-business (B2B) lösningar som produktivitetsverktyg, samarbetsprogram och andra software-as-a-service (SaaS) produkter. I detta sammanhang representerar varje "tenant" vanligtvis en affärskund, som kan ha flera användare (dess anställda). Dessutom kan en affärskund ha flera tenants för att representera olika organisationer eller affärsdivisioner.
B2B-applikationer går bortom SaaS-produkter och involverar ofta användningen av multi-tenant-appar. I B2B-sammanhang fungerar dessa appar som en gemensam plattform för olika team, affärsklienter och partnerföretag för att få tillgång till dina applikationer.
Till exempel, överväg ett samåkningsföretag som tillhandahåller både B2C och B2B-appar. B2B-apparna betjänar flera affärsklienter, och att använda en multi-tenant arkitektur kan hjälpa hanteringen av deras anställda och resurser. För att illustrera, om företaget vill upprätthålla ett enhetligt användaridentitetssystem, kan det designa en arkitektur som följande exempel:
Sarah har både en personlig och en affärsidentitet. Hon använder samåkningstjänsten som passagerare och arbetar också som förare på sin fritid. I sin professionella roll hanterar hon också sitt företag och använder denna affärsidentitet för att vara partner med Företag 1.
Varför ska du använda multi-tenancy i SaaS produkter#
För företagsverksamheter är multi-tenancy nyckeln till att effektivt uppfylla deras krav på tillgänglighet, resurshantering, kostnadshantering och datasäkerhet. På en teknisk nivå strömlinjeformar antagandet av en multi-tenant-strategi dina utvecklingsprocesser, minimerar tekniska utmaningar och främjar sömlös expansion.
När man undersöker rötterna för SaaS-produkter, är det som en byggnad som rymmer olika lägenheter. Alla hyresgäster delar gemensamma tjänster som vatten, el och gas, men de har självständigt kontroll över att hantera sitt eget utrymme och sina resurser. Detta tillvägagångssätt förenklar fastighetshantering.
I en multi-tenancy arkitektur introduceras termen "tenant" för att skapa gränser som separerar och säkrar resurserna och datan för olika tenants inom en delad instans. Detta säkerställer att varje tenants data och operationer förblir distinkta och säkra, även om de använder samma underliggande resurser.
När man diskuterar multi-tenant applikationer, är det alltid nödvändigt att uppnå tenant isolering. Detta innebär att hålla de olika tenants data och resurser åtskilda och säkra inom ett delat system (till exempel en molninfrastruktur eller en multi-tenant applikation). Detta förhindrar obehöriga försök att få åtkomst till en annan tenants resurser.
Även om förklaringen kan verka abstrakt, kommer vi använda exempel och nyckeldetaljer för att ytterligare förklara isoleringsmentaliteten och bästa praxis för att uppnå tenant isolering.
Tenant isolering motsäger inte multi-tenancys "delade" tänkesätt#
Detta beror på att tenant isolering inte nödvändigtvis är en infrastrukturresurs-nivå konstruktion. Inom multi-tenancy och isolering ser vissa isolering som en strikt uppdelning mellan faktiska infrastrukturresurser. Detta leder vanligtvis till en modell där varje tenant har separata databaser, datorkapaciteter, konton eller privata moln. I delade resurs-scenarion, som multi-tenant appar, kan sättet att uppnå isolering vara en logisk konstruktion.
Tenant isolering fokuserar uteslutande på att använda "tenant"-context för att begränsa åtkomst till resurser. Den utvärderar contexten för den nuvarande tenanten och använder den contexten för att avgöra vilka resurser som är åtkomliga för den tenanten.
Autentisering och auktorisering är inte lika med "isolering"#
Att använda autentisering och auktorisering för att kontrollera åtkomsten till dina SaaS-miljöer är viktigt, men det räcker inte för fullständig isolering. Dessa mekanismer är bara en del av säkerhetspusslet.
Människor frågar ofta en fråga, kan jag använda allmänna auktoriseringslösningar och rollbaserad åtkomstkontroll för att uppnå tenant isolering?
Saken är den, du kan bygga en multi-tenant app men du kan inte säga att du har uppnått och infört tenant isolationsstrategier som en bästa praxis. Vi rekommenderar det vanligtvis inte eftersom
För att illustrera, överväg en situation där du har satt upp autentisering och auktorisering för ditt SaaS-system. När användare loggar in, får de en token som innehåller information om deras roll, vilket dikterar vad de kan göra i applikationen. Detta tillvägagångssätt ökar säkerheten men säkerställer inte isolering.
Använd "organisation" för att representera SaaS produktens tenant, för att uppnå tenant isolering#
Att enbart förlita sig på autentisering och auktorisering kommer inte förhindra en användare med rätt roll från att få tillgång till en annan tenants resurser. Så vi behöver införliva en "tenant"-context, såsom en tenant-ID, för att begränsa åtkomst till resurser.
Detta är där tenant isolering kommer in i bilden. Den använder tenant-specifika identifikatorer för att etablera gränser, precis som väggar, dörrar och lås, och säkerställer en tydlig separation mellan tenants.
Vi diskuterade tenant isolering, men vad sägs om identiteter? Hur avgör du om dina identiteter ska vara "isolerade" eller inte?
Det finns ofta förvirring kring konceptet "identitetsisolering." Det kan hänvisa till situationer där en verklig användare har två identiteter i människors allmänna förståelse.
Båda identiteterna kan existera inom ett enda identitetssystem. Till exempel kan Sarah ha ett personligt e-postkonto registrerat tillsammans med en företagsmail kopplad via single sign-on (SSO).
Användarna behåller två distinkta identiteter inom separata identitetssystem, som representerar helt separata produkter. Dessa produkter är helt orelaterade till varandra.
Ibland refereras dessa scenarion som "Identitetsisolerade." Ändå kanske denna etikett inte hjälper till att fatta ett beslut.
Istället för att avgöra om du behöver "identitetsisolering," överväg
Detta svar kan vägleda din systemdesign. För ett kort svar angående en multi-tenant app,
I multi-tenant applikationer delas identiteter, till skillnad från tenant-specifika resurser och data, mellan flera tenants. Föreställ dig själv som byggnadsadministratören; du skulle inte vilja upprätthålla två separata namnlistor för att hantera dina tenants identiteter.
När du strävar efter tenant isolering, kanske du har observerat den återkommande betoningen på termen "organisation," ofta ansedd som en bästa praxis för att bygga multi-tenant applikationer.
Genom att använda begreppet "organisation" kan du uppnå tenant isolering i din multi-tenant applikation samtidigt som du behåller ett enhetligt identitetssystem.
Hur du väljer och designar en lämplig auktoriseringsmodell#
När du väljer rätt auktoriseringsmodell, överväg dessa frågor:
Utvecklar du en B2C, B2B, eller en kombination av båda typerna av produkter?
Har din app en multi-tenant arkitektur?
Finns det ett behov av en viss isoleringsnivå i din app, som bestäms av affärsenheten?
Vilka rättigheter och roller behöver definieras inom organisationens context, och vilka inte?
Vilka olika auktoriseringsmodeller finns tillgängliga i Logto?#
RBAC (Roll-Based Access Control) är en metod för att bevilja användarbehörigheter baserat på deras roller, vilket möjliggör effektiv hantering av resursåtkomst.
Denna vanliga teknik ligger till grund för åtkomstkontroll och är en viktig komponent i Logtos auktoriseringsfunktioner. Som en omfattande identitetshanteringsplattform erbjuder Logto skräddarsydda lösningar för olika lager och entiteter, anpassade för utvecklare och företag för olika produktarkitekturer.
För att skydda allmänna API-resurser som inte är specifika för någon organisation och inte behöver contextbegränsningar är API RBAC funktionen idealisk.
Registrera bara API:et och tilldela behörigheter till varje resurs. Kontrollera sedan åtkomsten genom relationen mellan roller och användare.
API-resurser, roller och behörigheter här är "demokratiserade" under ett enhetligt identitetssystem. Detta är ganska vanligt i B2C-produkten med mindre hierarki och behöver inte en mycket djup isoleringsnivå.
I B2B och multi-tenant miljöer är tenant isolering nödvändig. För att uppnå detta används organisationer som context för isolering, vilket innebär att RBAC är effektivt endast när en användare tillhör en specifik organisation.
Organisations RBAC fokuserar på att kontrollera åtkomsten på organisationsnivå snarare än API-nivå. Detta ger betydande flexibilitet för organisationsnivåns självhantering på lång sikt men fortfarande inom ett enhetligt identitetssystem.
En nyckelfunktion med organisations RBAC är att roller och behörigheter i allmänhet är desamma över alla organisationer som standard, vilket gör Logto "organisation template" extremt meningsfullt för att förbättra utvecklingseffektiviteten. Detta stämmer överens med den delade filosofin om multi-tenant appar, där åtkomstkontrollpolicier och identiteter är gemensamma infrastrukturkomponenter över alla tenants (app tenants), en vanlig praxis i SaaS-produkter.
Denna artikel ger allt du behöver för att komma igång med att förbereda och konfigurera multi-tenant appar. Prova Logto idag och börja tillämpa bästa praxis för multi-tenant apputveckling med organisationer.
