Met multi-tenancy werkt elke huurder (bijvoorbeeld een account of organisatie) in een geïsoleerde omgeving, waarvoor unieke toegangscontroles nodig zijn die zijn afgestemd op specifieke gebruikersrollen binnen die omgeving. Multi-tenant authorization Een van de meest effectieve manieren om multi-tenant autorisatie te implementeren is door het te combineren met RBAC vereenvoudigt toegangsbeheer door gebruikers vooraf gedefinieerde rollen toe te wijzen die hun machtigingen dicteren binnen een omgeving. Role-Based Access Control (RBAC) is een Role-Based Access Control (RBAC) is een RBAC alleen wordt geconfronteerd met drie grote uitdagingen als toepassingen schaal en vereisen meer fijne-grain machtigingen: Omdat het beperkt is tot rollen (en niet attributen en relaties), kan RBAC geen granulariteit hebben. De statische rollen ontbreken de mogelijkheid om te schalen over huurders. Naarmate applicaties groeien, kan het aantal rollen onbeheersbaar worden, wat resulteert in een zogenaamde "Role Explosion". a deze problemen oplossen door gebruikerstoegang te structureren In plaats van een gebruiker een enkele wereldwijde rol toe te wijzen, hangen hun machtigingen af van welke huurder ze zijn en welke rol ze binnen die huurder hebben. multi-tenant RBAC model per tenant Here’s a quick example of when this can be useful: Denk aan een SaaS projectmanagementplatform waar gebruikers lid kunnen zijn van meerdere organisaties, elk met verschillende toegangsniveaus: Een gebruiker kan een beheerder zijn in een organisatie met volledige controle, terwijl alleen een editor in een andere, beperkt tot het wijzigen van taken, maar niet om gebruikers te beheren. Denk aan een SaaS projectmanagementplatform waar gebruikers lid kunnen zijn van meerdere organisaties, elk met verschillende toegangsniveaus: Een gebruiker kan een beheerder zijn in een organisatie met volledige controle, terwijl alleen een editor in een andere, beperkt tot het wijzigen van taken, maar niet om gebruikers te beheren. Multi-tenant RBAC zorgt ervoor dat machtigingen worden toegepast op de juiste omgeving zonder onnodige complexiteit. In deze gids verkennen we de en laat zien hoe het efficiënt kan worden uitgevoerd met behulp van . importance of Multi-Tenant Authorization Toestemming.nl Toestemming.nl We zullen bespreken hoe we beleid kunnen structureren, rollen per huurder toewijzen en handhaven . fine-grained permissions Laten we erin duiken. Waarom is multi-tenant autorisatie belangrijk? Multi-tenant autorisatie is handig voor toepassingen waar gebruikers behoren tot meerdere onafhankelijke omgevingen, elk met zijn eigen toegangsregels - een veel voorkomende in de meeste moderne cloud-gebaseerde toepassingen. Handelen met vergunningen in geïsoleerde omgevingen Met multi-tenancy kan elke gebruiker een op maat gemaakte benadering van hun toegangscontrole krijgen op basis van hun huurder.Aangezien een gebruiker verschillende rollen en verantwoordelijkheden over verschillende huurders kan hebben, kan het gebruik van multi-tenancy deze rollen onafhankelijk beheren en handhaven. Dit betekent dat we multi-tenant-autorisatie kunnen gebruiken om duidelijke grenzen tussen omgevingen te behouden en tegelijkertijd ervoor te zorgen dat gebruikers de juiste machtigingen binnen elk hebben. Denk bijvoorbeeld aan een Het is cruciaal om strenge toegangscontrole te handhaven zodat een gebruiker van de ene klant de gegevens van de andere niet kan bekijken of wijzigen. cloud storage platform Maar waarom kunnen we dit niet alleen met RBAC oplossen? Waarom traditionele RBAC niet genoeg is voor multi-tenant-autorisatie Er kan veel gezegd worden over de beperkingen van RBAC. Bij het omgaan met toepassingen in de productie kan RBAC te stijf blijken te zijn en te complex worden om te schalen. Static Roles Don't Scale Across Tenants: In a traditional RBAC implementation, across an application.This means a user assigned an role might have access to edit all resources, even across tenants where they shouldn’t have permissions. roles usually apply globally Editor This problem can present itself as simply as: A project management app where a user is an in one team but should only have access in another. Editor Viewer Multi-Tenant RBAC allows roles to be scoped per tenant, so a user can be an Editor in one organization and a Viewer in another without unnecessary role duplication. Speaking of role duplication - The Role Explosion Problem A basic RBAC model can start simple: . As more users and resource types are introduced, a can occur. If we take our previous example where a single user needs to be an Editor in one team but a Viewer in another, you can easily end up with something like this: Admin, Editor, Viewer role explosion Editor_TeamA Editor_TeamB Viewer_TeamA Viewer_TeamB … and so on for every additional team / potential tenant. This makes the system hard to manage and difficult to update without breaking access rules. by dynamically assigning roles within each tenant instead of hardcoding them. Multi-Tenant RBAC removes the need for tenant-specific roles Multi-Tenant Authorization Requires Granularity RBAC is often too restricted when handling permissions at a granular level. It typically lacks built-in mechanisms to define resource-level or conditional access policies. Think of this policy: "Editors can only modify their own photos" How simple is that? The thing is - there’s no way RBAC can support such a policy without implementing additional logic. Especially at scale. Een projectmanagementapp waar een gebruiker een in een team, maar moet alleen Toegang tot een ander. Editor Viewer "Editeurs kunnen alleen hun eigen foto's wijzigen" Voordat we onderdompelen in implementatie en beste praktijken, laten we een paar veelgebruikte multi-tenancy modellen noemen: Gemeenschappelijke multi-tenant modellen Multi-tenant-autorisatie is van toepassing op een breed scala aan toepassingen. Hier zijn enkele van de meest voorkomende manieren waarop huurders zijn gestructureerd: Accounts – Gebruikt in SaaS-toepassingen voor consumenten, waarbij elke gebruiker tot een onafhankelijk account behoort (bijv. Google Drive, Dropbox). Organisaties – Veel voorkomend in zakelijke toepassingen, waarbij een bedrijf (organisatie) meerdere gebruikers heeft met verschillende rollen (bijv. Slack, Notion). Groepen – Handig voor collaboratieve omgevingen, waar gebruikers worden gegroepeerd op basis van gedeelde toegangsbehoeften (bijv. GitHub-teams, projectwerkruimten). In systemen waar bedrijven werken onder een franchise-model, functioneert elke franchise onafhankelijk, maar volgt een centrale structuur (bijv. restaurantmanagementsystemen). Elk van deze modellen profiteert van Multi-Tenant-autorisatie om de juiste isolatie en rolgebaseerde machtigingen per huurder te garanderen. Begrijpen van de voordelen van multi-tenant autorisatie, laten we doorgaan met het bespreken van de implementatie. Beste praktijken voor het implementeren van multi-tenant autorisatie Effectieve strategieën voor het beheren van rollen, machtigingen en schaalbaarheid in geïsoleerde omgevingen in multi-tenant-applicaties. Plan uw multi-tenant autorisatiestrategie Voordat u iets implementeert, is het essentieel om te plannen hoe uw multi-tenant-model zal werken. Hier zijn enkele belangrijke elementen die u moet definiëren als u een RBAC-model gebruikt: separate, manageable access controls Gebruikers: Individuen die toegang hebben tot het systeem. Ieder kan tot meerdere huurders behoren. Huurders: Afzonderlijke omgevingen waarin gebruikers werken (zoals account, organisatie of werkruimte). Rollen: vooraf gedefinieerde machtigingsniveaus toegewezen aan gebruikers binnen een huurder. Resources: Objecten (bijv. foto's, documenten) waarmee gebruikers communiceren, beheerst door machtigingen. Toelatingen: regels die de acties definiëren die rollen op specifieke bronnen kunnen uitvoeren. Door deze vragen van tevoren aan te pakken, kunt u een Autorisatiesysteem afgestemd op de behoeften van uw aanvraag. flexible and scalable Begrijpen van multi-tenant doelen Sinds a Het systeem moet ervoor zorgen dat: single user can exist in multiple tenants Roltoewijzingen zijn per huurder - De machtigingen van een gebruiker moeten worden gespreid naar hun specifieke huurder. Resources zijn gekoppeld aan huurders - Resources moeten behoren tot een specifieke huurder. Toelatingen worden dynamisch geëvalueerd – Wanneer een gebruiker een verzoek indient, controleert het systeem zowel hun rol in de huurder als de eigendom van de bron. Multi-Tenant-autorisatie optimaliseren: schema loskoppelen van gegevens Een gemeenschappelijke uitdaging in multi-tenant systemen is het beheren van hoe In traditionele systemen zijn rollen en machtigingen vaak nauw gekoppeld aan de applicatiegegevens. Dit kan complicaties veroorzaken wanneer machtigingen moeten worden gewijzigd, omdat u mogelijk zowel de En de van zichzelf. roles and policies role assignment application data Optimaliseren voor schaalbaarheid: Bewaar rollen, toewijzingen en beleidslijnen in een toegewijd autorisatiesysteem (zoals Permit.io) en houd de applicatiegegevens gescheiden van de autorisatielogica. Met deze ontkoppeling kunt u rollen of machtigingen dynamisch bijwerken zonder de kerngegevens of codebase van de applicatie aan te raken. Gebruik één bron van waarheid - het PDP (Policy Decision Point) Een van de kritieke concepten bij het optimaliseren van multi-tenant autorisatie is het gebruik van een om beleidsbeslissingen te nemen. single source of truth In plaats van rolinformatie en toegangsregels op te slaan in elke service of gebruikersdatabase, fungeert als het centrale punt waar alle toegangsbesluiten worden genomen. Politieke besluitvormingspunten (PDP) Politieke besluitvormingspunten (PDP) Benefits of using a PDP: Consistentie: De PDP zorgt ervoor dat alle diensten in de applicatie dezelfde reeks regels verwijzen bij het nemen van autorisatiebeslissingen. Dynamische beleidsbeoordeling: wijzigingen in beleidslijnen of roltoewijzingen hoeven alleen op één locatie te worden bijgewerkt – de PDP. Deze centralisatie elimineert de noodzaak om meerdere plaatsen in uw codebase of databases bij te werken. Minder risico op fouten: Door te vertrouwen op een enkel, gecentraliseerd besluitpunt, vermindert u het risico van inconsistente machtigingen over huurders en toepassingen. RBAC uitbreiden met relatie-gebaseerde toegangscontrole (ReBAC) Terwijl biedt een solide basis voor multi-tenant autorisatie, er zijn scenario's waarin kan nog fijner gegroeide toegangscontrole bieden. RBAC Relatiegebaseerde toegangscontrole (ReBAC) Relatiegebaseerde toegangscontrole (ReBAC) RBAC definieert rechten op basis van rollen die aan gebruikers zijn toegewezen, maar een stap verder door het definiëren van machtigingen op basis van de Dit is vooral handig in situaties waarin machtigingen afhangen van de manier waarop middelen met elkaar zijn verbonden of met elkaar zijn geassocieerd. ReBAC relationships Denk bijvoorbeeld aan een Wanneer een gebruiker toegang heeft tot een , en die map bevat meerdere documenten. Met RBAC moet u rollen zoals of Echter, met Je zou dit kunnen vereenvoudigen door te zeggen: document management system folder Folder Editor Document Viewer ReBAC "Een gebruiker mag een document bewerken als hij een editor is van de map waartoe het document behoort." "Een gebruiker mag een document bewerken als hij een editor is van de map waartoe het document behoort." Dit maakt meer dynamische en contextsensitieve toewijzingen mogelijk zonder rolduplicaties voor elke bron. : Benefits of ReBAC Contextuele machtigingen: Geeft toegangscontrole mogelijk op basis van dynamische relaties (bijvoorbeeld een gebruiker die een editor is in een project en dus toegang heeft tot alle gerelateerde taken). Verminderde rolexplosie: u hoeft geen rollen te maken voor elke combinatie van gebruikers- en hulpbronnentype, omdat relaties toegang dynamisch kunnen definiëren. Door RBAC met ReBAC uit te breiden, kunt u Waar relaties tussen gebruikers en bronnen machtigingen dicteren. complex access control scenarios Multi-Tenant Autorisatie met Toestemming.nl Toestemming.nl biedt een eenvoudige manier om autorisatie voor meerdere huurders te implementeren, zodat u rollen, beleidsregels en toegangsregels kunt definiëren in verschillende omgevingen. Permit.io if (user.role == admin && user.tenant == resource.tenant) { return true; } Een traditionele, statische if De benadering van multi-tenancy. const permitted = await permit.check(user, "read", { resource: "document", tenant: "default" }); if (permitted) { return true; } Een schone permit.check() Functie die controleert voor multi-tenance RBAC. Hier is een breed overzicht van hoe multi-tenant RBAC-autorisatie kan worden ingesteld in Permit.io: Define Roles, Resources, and Actions: To get started, first define your resources (e.g., documents, photos, tasks) and the actions that can be performed on them (e.g., create, read, update, delete). Add a (e.g., ) to represent the type of object you want to control access to. new resource blog Specify the resource's , which will be used in your API calls. key Define the users should be able to perform on the resource (e.g., create, read, update, delete). actions The screenshot shows an example where is the resource, and actions are defined for it. blog Define the Access Control Policy: You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like , , and are defined, and the policy is set up to specify which actions are permitted for each role. admin public Writer Define the Tenants in the Directory: Each tenant can have its own set of roles, permissions, and policies. To create tenants: Go to the screen and click on . Directory Settings Define the tenants you need (e.g., , , etc.). Tenant 1 Tenant 2 Create Users and Assign Roles: Once the tenants are defined, you can create users and assign them roles specific to each tenant. This ensures that the same user can have different roles in each tenant, depending on what permissions they need. To create a new user: Click in the screen. Add User Directory Assign the user a unique and other user details (e.g., email, first name). key In the section, you can assign the user roles specific to the tenant to which they belong. Permissions Per Tenant For instance, the user could be an in and a in , as shown in the screenshot: Admin Tenant 1 Writer Tenant 2 Hier zien we al onze gebruikers en welke rollen ze hebben in elke huurder die ze behoren: Enkele van de voordelen van het gebruik van Permit.io voor multi-tenant autorisatie zijn: Gecentraliseerd beleidbeheer: Definieer en beheer al uw autorisatieregels en -beleid vanuit een gecentraliseerd platform. Huurder-specifieke roltoewijzing: rolten per huurder gemakkelijk toewijzen en beheren, waardoor gebruikers verschillende rollen kunnen hebben in verschillende omgevingen (bijv. Admin in een huurder, Viewer in een andere). Fine graned permissions: Implementeer gedetailleerde machtigingen voor elke bron en handhaaf complexe fine graned machtigingen (zoals die gebaseerd zijn op attributen of relaties) zonder de noodzaak van extra aangepaste logica. ReBAC-ondersteuning: Permit.io breidt het traditionele RBAC-model uit met ReBAC, waardoor u machtigingen kunt definiëren op basis van niet alleen gebruikersrollen, maar ook de relaties tussen gebruikers en middelen. Samenvatting: Multi-Tenant Autorisatie met RBAC In dit blog hebben we de Hoe het te combineren met Een efficiënter en schaalbaar beheer van gebruikersrechten in geïsoleerde omgevingen. importance of multi-tenant authorization Role-Based Access Control (RBAC) We hebben de uitdagingen van traditionele RBAC in multi-tenant-toepassingen besproken en hoe Multi-Tenant RBAC problemen oplost zoals statische rollen, rolexplosie en fijne toegangscontrole. Met multi-tenant-autorisatie kan elke huurder zijn eigen geïsoleerde toegangscontrole hebben, waardoor gebruikers alleen toegang hebben tot wat ze zijn gemachtigd binnen hun specifieke omgevingen. Hiermee kunt u multi-tenant-autorisatie op een meer gestroomlijnde manier implementeren, dankzij gecentraliseerd beleidsbeheer, huurderspecifieke roltoewijzing, fijne machtigingen en ondersteuning voor Relationship-Based Access Control (ReBAC). Permit.io What’s Next? Ontdek de documentatie van Permit.io om te beginnen met het implementeren van multi-tenant-autorisatie in uw applicatie. Word lid van de Permit.io-gemeenschap om beste praktijken te bespreken en ondersteuning te krijgen.
