De ultieme gids voor het instellen van multi-tenant authenticatie en autorisatie
Het maken van een multi-tenant applicatie kan complex zijn. Dit artikel verzamelt al onze eerdere berichten over multi-tenant en organisatie strategieën. We hopen dat het je kan helpen tijd te besparen en gemakkelijk te beginnen.
GuamianProduct & Design
Stop met weken verspillen aan gebruikersauthenticatie
Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.
Het bouwen van een multi-tenant app kan uitdagend zijn, met veel aspecten om rekening mee te houden. Dit artikel verzamelt al onze vorige blogposts over het begrijpen van multi-tenant en organisatiepraktijken. Voor een snelle start en om tijd te besparen, bekijk gewoon dit artikel, het bevat alles wat je nodig hebt!
De algemene richtlijnen worden beschreven in de volgende stappen:
Begrijp multi-tenant architectuur
Breng de gebruiksscenario's van je multi-tenant app in kaart
Softwaremulti-tenancy is een softwarearchitectuur waarin een enkele instantie van software draait op een server en meerdere tenants bedient. Systemen die op deze manier zijn ontworpen zijn "gedeeld" (in plaats van "dedicated" of "geïsoleerd").
Een tenant is een groep gebruikers die gemeenschappelijke toegang delen met specifieke privileges tot de software-instatie.
Een van de belangrijkste denkwijzen van multi-tenancy is "gedeeld". In de bredere definitie van multi-tenancy, betekent een multi-tenant applicatie niet dat elk onderdeel in een oplossing gedeeld is. Het betekent eerder dat in ieder geval sommige onderdelen van een oplossing hergebruikt worden over meerdere tenants. Door deze term breed te begrijpen, kun je beter empathie tonen voor de behoeften van je klant en waar ze vandaan komen.
Zodra je de multi-tenant architectuur begrijpt, is de volgende stap om je app toe te passen op real-world scenario's, met focus op specifieke product- en zakelijke behoeften.
Wat zijn de gebruiksscenario's voor multi-tenant applicaties?#
Multi-tenant apps vinden vaak hun plek in business-to-business (B2B) oplossingen zoals productiviteitstools, samenwerkingssoftware en andere software-as-a-service (SaaS) producten. In deze context vertegenwoordigt elke "tenant" meestal een zakelijke klant, die meerdere gebruikers (zijn werknemers) kan hebben. Daarnaast kan een zakelijke klant meerdere tenants hebben om verschillende organisaties of bedrijfsafdelingen te vertegenwoordigen.
B2B applicaties gaan verder dan SaaS producten en omvatten vaak het gebruik van multi-tenant apps. In B2B contexten dienen deze apps als een gemeenschappelijk platform voor verschillende teams, zakelijke klanten en partnerbedrijven om toegang te krijgen tot je applicaties.
Bijvoorbeeld, overweeg een ritdelingsbedrijf dat zowel B2C als B2B apps aanbiedt. De B2B apps bedienen meerdere zakelijke klanten, en door een multi-tenant architectuur te gebruiken, kan het beheer van hun werknemers en middelen worden vergemakkelijkt. Ter illustratie, als het bedrijf een verenigd gebruikersidentiteitssysteem wil behouden, kan het een architectuur ontwerpen zoals het volgende voorbeeld:
Sarah heeft zowel een persoonlijke als een zakelijke identiteit. Ze gebruikt de ritdelingsdienst als een passagier en werkt in haar vrije tijd ook als chauffeur. In haar professionele rol beheert ze ook haar bedrijf en gebruikt ze deze zakelijke identiteit om een partner te zijn met Bedrijf 1.
Waarom zou je multi-tenancy toepassen in een SaaS-product?#
Voor ondernemingsbedrijven is multi-tenancy de sleutel tot het effectief voldoen aan hun eisen voor beschikbaarheid, middelenbeheer, kostenbeheer en gegevensbeveiliging. Op technisch niveau stroomlijnt het aannemen van een multi-tenant aanpak je ontwikkelingsprocessen, minimaliseert het technische uitdagingen en bevordert het naadloze uitbreiding.
Als je de roots van SaaS-producten onderzoekt, is het vergelijkbaar met een gebouw dat verschillende appartementen huisvest. Alle huurders delen gemeenschappelijke voorzieningen zoals water, elektriciteit en gas, maar ze behouden de onafhankelijke controle over het beheren van hun eigen ruimte en middelen. Deze aanpak vereenvoudigt het vastgoedbeheer.
In een multi-tenancy architectuur wordt de term "tenant" geïntroduceerd om grenzen te creëren die de middelen en gegevens van verschillende tenants scheiden en beveiligen binnen een gedeelde instantie. Dit zorgt ervoor dat de gegevens en activiteiten van elke tenant duidelijk gescheiden en veilig blijven, zelfs als ze dezelfde onderliggende middelen gebruiken.
Bij het bespreken van multi-tenant applicaties is het altijd noodzakelijk om tenant isolatie te bereiken. Dit betekent het scheiden en beveiligen van de gegevens en middelen van verschillende tenants binnen een gedeeld systeem (bijvoorbeeld een cloudinfrastructuur of een multi-tenant applicatie). Dit voorkomt ongeoorloofde pogingen om toegang te krijgen tot de middelen van een andere tenant.
Hoewel de uitleg abstract lijkt, zullen we voorbeelden en belangrijke details gebruiken om de isolatie-geest verder uit te leggen en de beste praktijken te laten zien om tenant isolatie te bereiken.
Tenant isolatie gaat niet tegen de "gedeelde" denkwijze van multi-tenancy in#
Dat komt omdat tenant isolatie niet per se een infrastructuurmiddelenniveau construct is. In de wereld van multi-tenancy en isolatie zien sommigen isolatie als een strikte scheiding tussen werkelijke infrastructuurmiddelen. Dit leidt meestal tot een model waarin elke tenant gescheiden databases, computerinstanties, accounts of privéclouds heeft. In gedeelde middelen scenario's, zoals multi-tenant apps, kan de manier om isolatie te bereiken een logisch construct zijn.
Tenant isolatie richt zich exclusief op het gebruik van het "tenant" context om toegang tot middelen te beperken. Het evalueert de context van de huidige tenant en gebruikt die context om te bepalen welke middelen toegankelijk zijn voor die tenant.
Authenticatie en autorisatie zijn niet gelijk aan "isolatie"#
Het gebruik van authenticatie en autorisatie om de toegang tot je SaaS omgevingen te beheren is belangrijk, maar het is niet genoeg voor volledige isolatie. Deze mechanismen zijn slechts een onderdeel van de beveiligingspuzzel.
Mensen vragen vaak of ze algemene autorisatie oplossingen en rolgebaseerde toegangscontrole kunnen gebruiken om tenant isolatie te bereiken?
Dit is de zaak: je kunt een multi-tenant app bouwen maar je kunt niet zeggen dat je tenant isolatie strategieën hebt bereikt en toegepast als een best practice. We raden het over het algemeen niet aan omdat
Om te illustreren, overweeg een situatie waarin je authenticatie en autorisatie voor je SaaS systeem hebt ingesteld. Wanneer gebruikers inloggen, ontvangen ze een token met informatie over hun rol, die bepaalt wat ze kunnen doen in de applicatie. Deze aanpak verhoogt de beveiliging maar verzekert geen isolatie.
Gebruik "organisatie" om de SaaS-product tenant te representeren, voor het bereiken van tenant isolatie#
Alleen op authenticatie en autorisatie vertrouwen, voorkomt niet dat een gebruiker met de juiste rol toegang krijgt tot de middelen van een andere tenant. Dus we moeten een "tenant" context opnemen, zoals een tenant-ID, om toegang tot middelen te beperken.
Dit is waar tenant isolatie in het spel komt. Het gebruikt tenant-specifieke identificatoren om grenzen te stellen, vergelijkbaar met muren, deuren en sloten, waarmee een duidelijke scheiding tussen tenants wordt gewaarborgd.
We bespraken tenant isolatie, maar hoe zit het met identiteiten? Hoe bepaal je of je identiteiten "geïsoleerd" moeten zijn of niet?
Er is vaak verwarring rond het concept van "identiteitsisolatie." Het kan verwijzen naar situaties waarin één echte gebruiker twee identiteiten heeft in de algemene opvattingen van mensen.
Beide identiteiten kunnen bestaan binnen een enkel identiteitssysteem. Bijvoorbeeld, Sarah zou een persoonlijk e-mailadres kunnen hebben dat samen met een zakelijk e-mailadres geregistreerd is via single sign-on (SSO).
Gebruikers behouden twee afzonderlijke identiteiten binnen aparte identiteitssystemen, die volledig aparte producten vertegenwoordigen. Deze producten zijn volledig ongegerelateerd aan elkaar.
Soms worden deze scenario's "Identiteitsgeïsoleerd" genoemd. Toch helpt dit label misschien niet bij het nemen van een beslissing.
Weliswaar bepaal je of je "identiteitsisolatie" nodig hebt, overweeg
Dit antwoord kan je systeemontwerp begeleiden. Voor een kort antwoord met betrekking tot een multi-tenant app,
In multi-tenant applicaties worden identiteiten, anders dan tenant-specifieke middelen en gegevens, gedeeld tussen meerdere tenants. Stel je voor dat je de gebouwbeheerder bent; je zou niet twee aparte namenlijsten willen bijhouden om de identiteiten van je huurders te beheren.
Als je streeft naar tenant isolatie, heb je mogelijk de herhaalde nadruk op de term "organisatie" opgemerkt, vaak beschouwd als een best practice voor het bouwen van multi-tenant applicaties.
Door het gebruik van het concept "organisatie" kun je tenant isolatie bereiken in je multi-tenant applicatie, terwijl je een verenigd identiteitssysteem behoudt.
Hoe kies en ontwerp je het juiste autorisatiemodel?#
Bij het kiezen van het juiste autorisatiemodel, overweeg deze vragen:
Ontwikkel je een B2C, B2B, of een combinatie van beide soorten producten?
Heeft je app een multi-tenant architectuur?
Is er behoefte aan een bepaald isolatieniveau in je app, zoals bepaald door de business unit?
Welke permissies en rollen moeten worden gedefinieerd binnen de context van de organisatie, en welke niet?
Welke verschillende autorisatiemodellen zijn beschikbaar in Logto?#
RBAC (Role-Based Access Control) is een methode om gebruikersrechten toe te kennen op basis van hun rollen, waardoor effectief middelenbeheer mogelijk is.
Deze veelgebruikte techniek vormt de basis voor toegangscontrole en is een belangrijk onderdeel van Logto's autorisatiefuncties. Als een uitgebreid identiteitsbeheerplatform biedt Logto op maat gemaakte oplossingen voor verschillende lagen en entiteiten, die tegemoetkomen aan ontwikkelaars en bedrijven voor diverse productarchitecturen.
Om algemene API-middelen te beschermen die niet specifiek zijn voor een organisatie en geen contextuele beperkingen nodig hebben, is de API RBAC functie ideaal.
Registreer gewoon de API en ken permissies toe aan elke bron. Beheer vervolgens de toegang door de relatie tussen rollen en gebruikers.
API-middelen, rollen en permissies hier zijn "gedemocratieerd" onder een verenigd identiteitssysteem. Dit is vrij gebruikelijk in het B2C-product met minder hiërarchie en heeft geen behoefte aan een zeer diep isolatieniveau.
In de B2B en multi-tenant omgeving is tenant isolatie noodzakelijk. Om dit te bereiken, worden organisaties gebruikt als een context voor isolatie, wat betekent dat RBAC alleen effectief is wanneer een gebruiker tot een specifieke organisatie behoort.
Organisatie RBAC richt zich op het beheren van toegang op het organisatie niveau in plaats van op het API niveau. Dit biedt aanzienlijke flexibiliteit voor organisatie niveau zelfbeheer op de lange termijn maar nog steeds binnen een verenigd identiteitssysteem.
Een belangrijk kenmerk van organisatie RBAC is dat rollen en permissies over het algemeen dezelfde zijn in alle organisaties bij default, wat de "organisatie sjabloon" van Logto uiterst betekenisvol maakt voor het verbeteren van de ontwikkelings efficiëntie. Dit komt overeen met de gedeelde filosofie van multi-tenant apps, waar toegangscontrole beleid en identiteiten gemeenschappelijke infrastructuur componenten zijn over alle tenants (app tenants), een gangbare praktijk in SaaS-producten.
Dit artikel biedt alles wat je nodig hebt om te beginnen met het voorbereiden en configureren van multi-tenant apps. Probeer vandaag Logto en begin met het toepassen van best practices voor multi-tenant app ontwikkeling met organisaties.
