Att bygga en fleranvändarapp kan vara utmanande, med många aspekter att överväga. Denna artikel sammanställer alla våra tidigare blogginlägg om att förstå fleranvändare och organisationsmetoder. För att snabbt komma igång och spara tid, kolla bara in denna artikel, den innehåller allt du behöver! De allmänna riktlinjerna anges i följande steg: 1. Förstå fleranvändararkitektur 2. Kartlägg användningsfall för din fleranvändarapp 3. Uppnå hyresgästsisolering 4. Definiera hur du vill hantera identiteterna 5. Välj lämpliga behörighetsmodeller ## Förstå fleranvändararkitektur Mjukvara fleranvändare är en [programvaruarkitektur](https://en.wikipedia.org/wiki/Software_architecture) där en enda [instans]() av [programvara](https://en.wikipedia.org/wiki/Computer_software) körs på en server och betjänar flera hyresgäster. System designade på detta sätt är "delade" (snarare än "dedikerade" eller "isolerade"). En hyresgäst är en grupp användare som delar gemensam tillgång med specifika privilegier till mjukvaruinstansen. multi-tenant

En av nyckelmentalitetena i fleranvändar är "delat". I den bredare definitionen av fleranvändare, innebär det inte att **varje** komponent i en lösning är delad. Snarare innebär det att åtminstone **vissa** komponenter i en lösning återanvänds över flera hyresgäster. Att förstå denna term brett kan bättre hjälpa dig att känna empati med dina kunders behov och varifrån de kommer. När du förstår fleranvändararkitektur är nästa steg att tillämpa din app på verkliga scenarier, med fokus på specifika produkt- och affärsbehov. ## Kartlägg användningsfall för din fleranvändarapp ### SaaS Fleranvändarappar hittar ofta sin plats i business-to-business (B2B) lösningar som produktivitetsverktyg, samarbetsprogram och andra programvara-som-tjänst (SaaS) produkter. I detta sammanhang representerar varje "hyresgäst" typiskt en affärskund, som kan ha flera användare (dess anställda). Dessutom kan en affärskund ha flera hyresgäster för att representera distinkta organisationer eller affärsenheter. ![SaaS](https://uploads.strapi.logto.io/1/saas_product_d63c736650.webp) ### Generella B2B användningsfall B2B-applikationer går bortom SaaS-produkter och involverar ofta användningen av fleranvändarappar. I B2B-sammanhang fungerar dessa appar som en gemensam plattform för olika team, affärskunder och partnerföretag att få tillgång till dina applikationer. Till exempel, överväg ett delningstjänstföretag som tillhandahåller både B2C och B2B appar. B2B-apparna betjänar flera affärskunder, och genom att använda en fleranvändararkitektur kan hanteringen av deras anställda och resurser underlättas. För att illustrera, om företaget önskar att upprätthålla ett enhetligt användaridentitetssystem, kan det designa en arkitektur som det följande exemplet: Sarah har både en personlig och en affärsidentitet. Hon använder delningstjänsten som passagerare och arbetar också som förare på fritiden. I hennes professionella roll hanterar hon också sitt företag och använder denna affärsidentitet för att vara partner med Affär 1.

### Varför du bör använda fleranvändare i SaaS-produkter #### Skalning med fleranvändare För företagsverksamheter är fleranvändare nyckeln till att effektivt uppfylla deras krav på tillgänglighet, resursförvaltning, kostnadshantering och datasäkerhet. På en teknisk nivå, att anta ett fleranvändarsätt förenklar dina utvecklingsprocesser, minimerar tekniska utmaningar och främjar sömlös expansion. #### Skapa en enhetlig upplevelse När du granskar rötterna till SaaS-produkter är det likt en byggnad som rymmer olika lägenheter. Alla hyresgäster delar vanliga nyttigheter som vatten, el och gas, men de behåller självständig kontroll över att hantera sitt eget utrymme och resurser. Denna metod förenklar fastighetsförvaltningen. #### Säkerställa säkerhet genom hyresgästsisolering I en fleranvändararkitektur introduceras termen "hyresgäst" för att skapa gränser som separerar och säkrar resurserna och data för olika hyresgäster inom en delad instans. Detta säkerställer att varje hyresgästs data och operationer förblir distinkta och säkra, även om de använder samma underliggande resurser. ## Uppnå hyresgästsisolering När man diskuterar fleranvändarapplikationer är det alltid nödvändigt att uppnå **hyresgästsisolering**. Detta innebär att hålla datan och resurserna för olika hyresgäster separerade och säkra inom ett delat system (till exempel en molninfrastruktur eller en fleranvändarapplikation). Detta förhindrar obehöriga försök att få tillgång till en annan hyresgästs resurser. Medan förklaringen kan verka abstrakt, kommer vi att använda exempel och viktiga detaljer för att ytterligare förklara isoleringsmentaliteten och den bästa praxisen för att uppnå hyresgästsisolering. ### Hyresgästsisolering motsäger inte fleranvändares "delade" mentalitet Det är för att hyresgästsisolering inte nödvändigtvis är en infrastrukturresursnivåkoncept. I fleranvändarens och isoleringens rike ser vissa isoleringen som en strikt uppdelning mellan faktiska infrastruktureresurser. Detta leder vanligtvis till en modell där varje hyresgäst har separata databaser, datorinstanser, konton eller privata moln. I delade resurs-scenarier, som fleranvändarappar, kan sättet att uppnå isolering vara en logisk konstruktion. Hyresgästsisolering fokuserar uteslutande på att använda "hyresgäst"-kontext för att begränsa åtkomst till resurser. Den utvärderar kontexten för den nuvarande hyresgästen och använder den kontexten för att avgöra vilka resurser som är tillgängliga för den hyresgästen. ### Autentisering och auktorisation är inte lika med "isolering" Att använda autentisering och auktorisation för att kontrollera tillgången till dina SaaS-miljöer är viktigt, men det är inte tillräckligt för fullständig isolering. Dessa mekanismer är bara en del av säkerhetspusslet. Folk frågar ofta en fråga, kan jag använda allmänna auktoriseringslösningar och rollbaserad åtkomstkontroll för att uppnå hyresgästsisolering? Här är saken, du kan bygga en fleranvändarapp men du kan inte säga att du uppnått och använt hyresgästsisoleringstrategier som en bästa praxis. Vi rekommenderar det inte generellt eftersom Hyresgästsisolering är separat från autentisering och auktorisation. För att illustrera, överväg en situation där du har ställt in autentisering och auktorisation för ditt SaaS-system. När användare loggar in får de en token med information om sin roll, som dikterar vad de kan göra i applikationen. Denna metod ökar säkerheten men säkerställer inte isolering. ### Använd "organisation" för att representera SaaS-produktens hyresgäst, för att uppnå hyresgästsisolering Att bara förlita sig på autentisering och auktorisation förhindrar inte en användare med rätt roll att få tillgång till en annan hyresgästs resurser. Så vi behöver inkorporera en "hyresgäst"-kontext, såsom ett hyresgäst-ID, för att begränsa tillgång till resurser. Det är här hyresgästsisolering kommer in i bilden. Den använder hyresgästspecifika identifierare för att etablera gränser, mycket som väggar, dörrar och lås, och säkerställer en tydlig separation mellan hyresgäster. ## Identiteter i fleranvändarappar Vi diskuterade hyresgästsisolering, men vad sägs om identiteter? Hur bestämmer du om dina identiteter bör vara "isolerade" eller inte? Det finns ofta förvirring kring begreppet "identitetsisolering." Det kan hänvisa till situationer där en verklig användare har två identiteter i människors allmänna förståelse. 1. Båda identiteterna kan finnas inom ett enda identitetssystem. Till exempel, Sarah kan ha en personlig e-post registrerad tillsammans med en företagsmejl kopplad genom en enda inloggning (SSO). 2. Användare bibehåller två distinkta identiteter inom separata identitetssystem, som representerar helt olika produkter. Dessa produkter är helt orelaterade till varandra. Ibland kallas dessa scenarier "Identitetsisolerade." Ändå, denna etikett kanske inte hjälper i att fatta ett beslut. Istället för att avgöra om du behöver "identitetsisolering," överväg om du eller ett segment av din verksamhet eller produkt behöver bibehålla separata identitetssystem Detta svar kan vägleda din systemdesign. För ett kort svar angående en fleranvändarapp, I de flesta fall, i fleranvändarappar, delas identiteter medan varje hyresgästs resurser är isolerade. I fleranvändarapplikationer delas identiteter, till skillnad från hyresgästspecifika resurser och data, mellan flera hyresgäster. Föreställ dig själv som byggadministratören; du skulle inte vilja bibehålla två separata namnlappar för att hantera dina hyresgästers identiteter. När du siktar på hyresgästsisolering, kanske du har observerat det återkommande fokuset på termen "organisation," ofta betraktad som en bästa praxis för att bygga fleranvändarapplikationer. Genom att använda begreppet "organisation," kan du uppnå hyresgästsisolering i din fleranvändarapplikation medan du bibehåller ett enhetligt identitetssystem. ## Välj behörighetsmodeller för bättre åtkomstkontroll ### Välja och designa rätt auktorisationsmodell När du väljer rätt auktorisationsmodell, överväg dessa frågor: 1. Utvecklar du en B2C, B2B eller en kombination av båda typerna av produkter? 2. Har din app en fleranvändararkitektur? 3. Finns det ett behov av en viss isoleringsnivå i din app, bestämt av affärsenheten? 4. Vilka behörigheter och roller behöver definieras inom organisationens kontext, och vilka gör det inte? ### Förstå olika auktorisationsmodeller i Logto #### Rollbaserad åtkomstkontroll RBAC (Role-Based Access Control) är en metod för att ge användarnas tillstånd 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 nyckelkomponent i Logtos auktorisationsfunktioner. Som en omfattande identitetshanteringsplattform erbjuder Logto skräddarsydda lösningar för olika lager och enheter, som vänder sig till utvecklare och företag för olika produktarkitekturer. #### API rollbaserad åtkomstkontroll För att skydda generella API-resurser som inte är specifika för någon organisation och inte behöver kontextrestriktioner, är **_API RBAC_** funktionen idealisk. Registrera bara API och tilldela behörigheter till varje resurs. Kontrollera sedan åtkomst genom förhållandet 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-produkter med mindre hierarki och behöver inte en mycket djup nivå av isolering. #### Organisations rollbaserad åtkomstkontroll I B2B- och fleranvändarmiljön är hyresgästsisolering nödvändig. För att uppnå detta används organisationer som ett kontext för isolering, vilket innebär att RBAC är effektivt endast när en användare tillhör en specifik organisation. Organisation RBAC fokuserar på att kontrollera åtkomst 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 hos organisation RBAC är att roller och behörigheter vanligtvis är desamma över alla organisationer som standard, vilket gör Logto "organisationstemplate" extremt meningsfullt för att förbättra utvecklingseffektiviteten. Detta överensstämmer med den delade filosofin om fleranvändarappar, där åtkomstkontrollpolicyer och identiteter är vanliga infrastrukturkomponenter över alla hyresgäster (applikationshyresgäster), en vanlig praxis i SaaS-produkter. ## Avslutning Denna artikel ger allt du behöver för att komma igång med att förbereda och konfigurera fleranvändarappar. Prova Logto idag och börja tillämpa bästa praxis för fleranvändarsapputveckling med organisationer. Testa Logto Cloud gratis