Hoe Multi-Tenant-autorisatie te implementeren met Role-Based Access Control

Multi-tenant authorizationMet 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.

Een van de meest effectieve manieren om multi-tenant autorisatie te implementeren is door het te combineren metRole-Based Access Control (RBAC) is eenRBAC vereenvoudigt toegangsbeheer door gebruikers vooraf gedefinieerde rollen toe te wijzen die hun machtigingen dicteren binnen een omgeving.

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".

amulti-tenant RBAC modeldeze problemen oplossen door gebruikerstoegang te structurerenper tenantIn 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.

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 deimportance of Multi-Tenant Authorizationen laat zien hoe het efficiënt kan worden uitgevoerd met behulp vanToestemming.nl.

We zullen bespreken hoe we beleid kunnen structureren, rollen per huurder toewijzen en handhavenfine-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 eencloud storage platformHet is cruciaal om strenge toegangscontrole te handhaven zodat een gebruiker van de ene klant de gegevens van de andere niet kan bekijken of wijzigen.

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, roles usually apply globally across an application.This means a user assigned an Editor role might have access to edit all resources, even across tenants where they shouldn’t have permissions.

  This problem can present itself as simply as:

  
  

  A project management app where a user is an Editor in one team but should only have Viewer access in another.

  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: Admin, Editor, Viewer. As more users and resource types are introduced, a role explosion 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:

  • 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.

  Multi-Tenant RBAC removes the need for tenant-specific roles by dynamically assigning roles within each tenant instead of hardcoding them.

  
  

• 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 eenEditorin een team, maar moet alleenViewerToegang tot een ander.

"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:

1. Accounts – Gebruikt in SaaS-toepassingen voor consumenten, waarbij elke gebruiker tot een onafhankelijk account behoort (bijv. Google Drive, Dropbox).
2. Organisaties – Veel voorkomend in zakelijke toepassingen, waarbij een bedrijf (organisatie) meerdere gebruikers heeft met verschillende rollen (bijv. Slack, Notion).
3. Groepen – Handig voor collaboratieve omgevingen, waar gebruikers worden gegroepeerd op basis van gedeelde toegangsbehoeften (bijv. GitHub-teams, projectwerkruimten).
4. 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.separate, manageable access controlsHier zijn enkele belangrijke elementen die u moet definiëren als u een RBAC-model gebruikt:

• 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 eenflexible and scalableAutorisatiesysteem afgestemd op de behoeften van uw aanvraag.

Begrijpen van multi-tenant doelen

Sinds asingle user can exist in multiple tenantsHet systeem moet ervoor zorgen dat:

1. Roltoewijzingen zijn per huurder - De machtigingen van een gebruiker moeten worden gespreid naar hun specifieke huurder.
2. Resources zijn gekoppeld aan huurders - Resources moeten behoren tot een specifieke huurder.
3. 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 hoeroles and policiesIn 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 derole assignmentEn deapplication datavan zichzelf.

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 eensingle source of truthom beleidsbeslissingen te nemen.

In plaats van rolinformatie en toegangsregels op te slaan in elke service of gebruikersdatabase,Politieke besluitvormingspunten (PDP)fungeert als het centrale punt waar alle toegangsbesluiten worden genomen.

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)

TerwijlRBACbiedt een solide basis voor multi-tenant autorisatie, er zijn scenario's waarinRelatiegebaseerde toegangscontrole (ReBAC)kan nog fijner gegroeide toegangscontrole bieden.

RBAC definieert rechten op basis van rollen die aan gebruikers zijn toegewezen, maarReBACeen stap verder door het definiëren van machtigingen op basis van derelationshipsDit is vooral handig in situaties waarin machtigingen afhangen van de manier waarop middelen met elkaar zijn verbonden of met elkaar zijn geassocieerd.

Denk bijvoorbeeld aan eendocument management systemWanneer een gebruiker toegang heeft tot eenfolder, en die map bevat meerdere documenten. Met RBAC moet u rollen zoalsFolder EditorofDocument ViewerEchter, metReBACJe zou dit kunnen vereenvoudigen door te zeggen:

"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 ucomplex access control scenariosWaar relaties tussen gebruikers en bronnen machtigingen dicteren.

Multi-Tenant Autorisatie metToestemming.nl

Permit.iobiedt een eenvoudige manier om autorisatie voor meerdere huurders te implementeren, zodat u rollen, beleidsregels en toegangsregels kunt definiëren in verschillende omgevingen.

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 new resource (e.g., blog) to represent the type of object you want to control access to.
  • Specify the resource's key, which will be used in your API calls.
  • Define the actions users should be able to perform on the resource (e.g., create, read, update, delete).
  • The screenshot shows an example where blog is the resource, and actions are defined for it.

• Define the Access Control Policy:

  You’ll specify what actions each role can perform on each resource. For example, in the screenshot, roles like admin, public, and Writer are defined, and the policy is set up to specify which actions are permitted for each role.

  

• Define the Tenants in the Directory:

  Each tenant can have its own set of roles, permissions, and policies.

  To create tenants:

  • Go to the Directory screen and click on Settings.
  • Define the tenants you need (e.g., Tenant 1, Tenant 2, etc.).

  

  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 Add User in the Directory screen.

  • Assign the user a unique key and other user details (e.g., email, first name).

  • In the Permissions Per Tenant section, you can assign the user roles specific to the tenant to which they belong.

    For instance, the user could be an Admin in Tenant 1 and a Writer in Tenant 2, as shown in the screenshot:

    
    

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 deimportance of multi-tenant authorizationHoe het te combineren metRole-Based Access Control (RBAC)Een efficiënter en schaalbaar beheer van gebruikersrechten in geïsoleerde omgevingen.

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.

Permit.ioHiermee 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).

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.