Како имплементирати мулти-тенант овлашћење са контролом приступа заснованим на улози

Multi-tenant authorizationje model za upravljanje dozvolama korisnika u više naloga, organizacija ili grupa.U multi-tenancy, svaki stanar (npr. nalog ili organizacija) radi u izolovanom okruženju, što zahteva jedinstvene kontrole pristupa prilagođene specifičnim ulogama korisnika u tom okruženju.

Један од најефикаснијих начина за имплементацију мулти-најмјесника овлашћења је комбиновањем саКонтрола приступа заснована на улози (Role-Based Access Control – RBAC)RBAC pojednostavljuje upravljanje pristupom tako što dodeljuje korisnicima unapred definisane uloge koje diktiraju njihove dozvole u okruženju.

Само РБАЦ се суочава са три главне изазове као апликације скали и захтевају више фино зрна дозвола:

• Будући да је ограничен на улоге (а не атрибуте и односе), РБАЦ-у можда недостаје грануларност.
• Његове статичке улоге немају могућност скалације преко станара.
• Како апликације расту, број улога може постати неконтролисан, што доводи до онога што се зове "Екплозија улога".

Аmulti-tenant RBAC modelрешава ове проблеме структурирањем приступа корисникаper tenant, омогућавајући динамичко додељивање улога и дозвола у изолованим окружењима. Уместо да кориснику доделите једну глобалну улогу, њихове дозволе зависе од тога у којем се станару налазе и коју улогу имају унутар тог станара.

Here’s a quick example of when this can be useful:

Размислите о СааС платформи за управљање пројектима где корисници могу бити чланови више организација, свака са различитим нивоима приступа:

Корисник може бити администратор у једној организацији са пуном контролом, док је само уредник у другој, ограничен на модификацију задатака, али не и на управљање корисницима.

Размислите о СааС платформи за управљање пројектима где корисници могу бити чланови више организација, свака са различитим нивоима приступа:

Корисник може бити администратор у једној организацији са пуном контролом, док је само уредник у другој, ограничен на модификацију задатака, али не и на управљање корисницима.

Multi-tenant RBAC obezbeđuje da dozvole budu obuhvaćene pravim okruženjem bez nepotrebne kompleksnosti.

У овом водичу ћемо истражитиimportance of Multi-Tenant Authorizationи показати како се може ефикасно применити користећиДозволите ми.

Разговараћемо о томе како структурирати политике, доделити улоге по станару и спровестиfine-grained permissions.

Hajde da uđemo.

Zašto je važna autorizacija za više stanara?

Autorizacija za više stanara je korisna za aplikacije u kojima korisnici pripadaju više nezavisnih okruženja, od kojih svaka ima svoja pravila pristupa – što je uobičajeno u većini modernih aplikacija zasnovanih na oblaku.

Управљање дозволама преко изолованих окружења

Са мулти-тенанцијом, сваки корисник може добити прилагођени приступ њиховој контроли приступа на основу њиховог станара.Као што корисник може имати различите улоге и одговорности преко различитих станара, употреба мулти-тенанције омогућава да се те улоге управљају и спроводе независно.

To znači da možemo da koristimo autorizaciju za više stanara kako bismo održali jasne granice između okruženja, a istovremeno osigurali da korisnici imaju odgovarajuće dozvole unutar svakog okruženja.

На пример, размотрите аcloud storage platformКључно је да се спроведе строга контрола приступа тако да корисник од једног клијента не може прегледати или модификовати податке од другог.

Ali zašto to ne možemo rešiti samo sa RBAC-om?

Зашто традиционални РБАЦ није довољан за мулти-тенант овлашћење

Много се може рећи о ограничењима РБАЦ-а. Када се бави апликацијама у производњи, РБАЦ се може показати превише ригидним и постати превише сложен за скалирање.

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

Апликација за управљање пројектима у којој је корисникEditorу једној екипи, али треба да има самоViewerПриступ у другом.

"Уредници могу да мењају само своје фотографије"

Пре него што се бавимо имплементацијом и најбољим праксама, помињемо неколико често коришћених модела мулти-тенанци:

Заједнички мулти-тенант модели

Повећана овлашћења за станаре примењују се на широк спектар апликација. Ево неких од најчешћих начина на који су станари структурирани:

1. Налози – Користи се у потрошачким SaaS апликацијама, где сваки корисник припада независном налогу (нпр.
2. Организације - Уобичајено у пословним апликацијама, где компанија (организација) има више корисника са различитим улогама (нпр.
3. Grupe – Korisno za okruženja za saradnju, gde su korisnici grupisani na osnovu potreba za deljenim pristupom (na primer, GitHub timovi, radni prostori projekata).
4. Franšize – U sistemima gde preduzeća posluju po modelu franšize, svaka franšiza funkcioniše nezavisno, ali sledi centralnu strukturu (npr. sistem upravljanja restoranima).

Сваки од ових модела има користи од мулти-тенант овлашћења како би се осигурала правилна изолација и дозволе засноване на улози по станару.

Разумејући предности мулти-најмодавца овлашћења, наставимо да разговарамо о имплементацији.

Најбоље праксе за имплементацију мулти-тенант овлашћења

Ефективне стратегије за управљање улогама, дозволама и скалирањем у изолованим окружењима у апликацијама са више станара.

Планирајте своју стратегију вишенаменског овлашћења

Пре него што уроните у имплементацију било чега, неопходно је планирати како ће ваш модел за више станара радити.separate, manageable access controlsЕво неких кључних елемената које треба дефинисати ако користите РБАЦ модел:

• Корисници: Појединци који приступају систему. Сваки може припадати више станара.
• Станодавци: Одвојена окружења у којима корисници раде (као налог, организација или радни простор).
• Uloge: unapred definisane nivoe dozvola dodeljene korisnicima unutar stanara.
• Ресурси: објекти (нпр. фотографије, документи) са којима корисници комуницирају, контролисани дозволама.
• Дозволе: Правила која дефинишу акције које улоге могу да обављају на одређеним ресурсима.

Узимајући у обзир ова питања рано, можете изградитиflexible and scalableсистем овлашћења прилагођен потребама ваше апликације.

Разумевање вишенаменских циљева

Од аsingle user can exist in multiple tenantsSistem mora da obezbedi:

1. Додељивање улога је по станару - дозволе корисника треба да буду подељене на њиховог одређеног станара.
2. Ресурси су повезани са станарима - Ресурси треба да припадају одређеном станару.
3. Дозволе се процењују динамички - Када корисник направи захтев, систем проверава и њихову улогу у станару и власништво ресурса.

Оптимизација мулти-тенант ауторизације: одвајање шеме од података

Заједнички изазов у мулти-тенантним системима је управљање какоroles and policiesУ традиционалним системима, улоге и дозволе су често чврсто спојене са подацима апликације. Ово може створити компликације када се дозволе морају променити, јер можда ћете морати да ажурирате оба апликација.role assignmentИ оapplication datasamom sebi.

За оптимизацију за скалабилност:

• Skladištite uloge, dodele i politike u dedikovanom sistemu za autorizaciju (kao što je Permit.io) i odvojite podatke o aplikaciji od logike za autorizaciju.
• Ово одвајање вам омогућава да динамички ажурирате улоге или дозволе без додиривања кључних података или базе кода апликације.

Коришћење једног извора истине - ПДП (Политичка тачка одлуке)

Један од критичних концепта у оптимизацији мулти-терент ауторизације је коришћењеsingle source of truthДа доносе политичке одлуке.

Уместо складиштења информација о улози и правила приступа унутар сваке услуге или корисничке базе,Политичка тачка за одлучивање (ПДП)делује као централна тачка у којој се доносе све одлуке о приступу.

Benefits of using a PDP:

• Конзистентност: ПДП осигурава да све услуге широм апликације користе исти скуп правила приликом доношења одлука о овлашћењу.
• Dinamička evaluacija politika: Promene politika ili dodeljivanja uloga treba da se ažuriraju samo na jednoj lokaciji – PDP. Ova centralizacija uklanja potrebu za ažuriranjem više mesta u bazi podataka.
• Manje rizika od grešaka: Oslanjajući se na jednu centralizovanu tačku odlučivanja, smanjujete rizik od nedoslednih dozvola preko stanara i aplikacija.

Проширење РБАЦ са контролом приступа заснованим на односу (РеБАЦ)

dokRBACпружа солидну основу за мулти-најмодавца овлашћења, постоје сценарији у којимаKontrola pristupa na osnovu odnosa (ReBAC)може понудити још финије зрно контролу приступа.

RBAC дефинише дозволе на основу улога додељених корисницима, алиReBACдаје још један корак даље дефинисањем дозвола заснованих наrelationshipsTo je posebno korisno u situacijama u kojima dozvole zavise od toga kako su resursi povezani ili povezani.

Na primer, zamislite adocument management systemКада корисник има приступ afolder, а та фолдер садржи више докумената. Са РБАЦ-ом, требало би да дефинишете улоге као што суFolder EditorилиDocument ViewerМеђутим, саReBACMožete to pojednostaviti tako što ćete reći:

Korisniku je dozvoljeno da uređuje dokument ako je urednik fascikle kojoj dokument pripada.

Korisniku je dozvoljeno da uređuje dokument ako je urednik fascikle kojoj dokument pripada.

Ово омогућава динамичније и контекстуално осјетљивије доделе дозвола без дуплирања улога за сваки ресурс.

Benefits of ReBAC:

• Kontekstualne dozvole: Omogućava kontrolu pristupa na osnovu dinamičkih odnosa (npr. korisnik koji je urednik u projektu i stoga ima pristup svim povezanim zadatcima).
• Смањена експлозија улога: Не морате да креирате улоге за сваку комбинацију типа корисника и ресурса, јер релације могу да дефинишу приступ динамички.

Проширењем RBAC-а са ReBAC-ом, можете да управљатеcomplex access control scenariosгде односи између корисника и ресурса диктирају дозволе.

Имплементација вишенаменске овлашћења саДозволите ми

Permit.ionudi jednostavan način za sprovođenje autorizacije za više stanara tako što će vam omogućiti da definišete uloge, politike i pravila pristupa u različitim okruženjima.

if (user.role == admin && user.tenant == resource.tenant) {
    return true;
}

Традиционална, статична if Поступак изјаве за мулти-тенанце.

const permitted = await permit.check(user, "read", {
    resource: "document",
    tenant: "default"
});

if (permitted) {
    return true;
} 

чистим permit.check() функција која проверава за мулти-тенанце РБАЦ.

Ево широког прегледа како се мулти-терент РБАЦ овлашћење може поставити у Пермит.ио:

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

    
    

Овде можемо видети све наше кориснике и које улоге имају у сваком станару којима припадају:

Neke od prednosti korišćenja Permit.io za autorizaciju više stanara uključuju:

• Централизовано управљање политиком: Дефинишите и управљајте свим правилима и политикама о овлашћењу са централизоване платформе.
• Додељивање улога специфичних за станаре: лако доделити и управљати улогама по станару, омогућавајући корисницима да имају различите улоге у различитим окружењима (нпр.
• Детаљне дозволе: имплементирајте детаљне дозволе за сваки ресурс и спроводите сложене фине дозволе (као и оне засноване на атрибутима или односима) без потребе за додатном прилагођеном логиком.
• ReBAC Podrška: Permit.io proširuje tradicionalni model RBAC sa ReBAC, omogućavajući vam da definišete dozvole zasnovane ne samo na korisničkim ulogama, već i na odnosima između korisnika i resursa.

Сумирање: Мулти-тенант овлашћење са РБАЦ-ом

Na ovom blogu smo istražiliimportance of multi-tenant authorizationКако га комбиновати саRole-Based Access Control (RBAC)омогућава ефикасније и скалабилније управљање корисничким дозволама у изолованим окружењима.

Разговарали смо о изазовима традиционалног РБАЦ-а у апликацијама за више станара и како Мулти-Тенант РБАЦ решава проблеме као што су статичке улоге, експлозија улога и контрола приступа са финим зрном.

Sa dozvolom za više stanara, svaki stanar može imati sopstvenu izolovanu kontrolu pristupa, osiguravajući da korisnici imaju pristup samo onome za šta su ovlašćeni u svojim specifičnim okruženjima.

Permit.ioомогућава вам да имплементирате овлашћење за више станара на поједностављивији начин, захваљујући централизованом управљању политикама, додељивању улога специфичних за станаре, фино израженим дозволама и подршци за контролу приступа засновану на односу (РЕБАЦ).

What’s Next?

• Истражите документацију Permit.io да бисте започели имплементацију мулти-тенитера овлашћења у вашој апликацији.
• Придружите се Permit.io заједници да бисте разговарали о најбољим праксама и добили подршку.