ugrás a tartalomhoz

Jogosultság kezelés - csak a szerző tudja szerkeszteni a cikkét

inf3rno · 2013. Május. 29. (Sze), 00.23
Sziasztok!

Jogosultság kezeléssel van egy problémám, amire nem tudtam kiagyalni általánosan használható rendszert. Vagy nem létezik ilyen, vagy a hiba bennem van.

Alapból úgy tárolom a szabályokat, hogy van egy listám az erőforrásokról és a műveletekről, amiket rajtuk lehet végezni. Ezt beszórtam egy táblába, aztán csináltam szerepköröket, amikhez hozzárendeltem ezeket a jogokat. A szerepköröket meg nyilván felhasználókhoz rendeltem hozzá. Ezzel így szerintem megfelelő.

A gond ott kezdődik, ha olyan dolgok jönnek be, ahol megszorítások vannak 1-1 erőforrásra. Ha mondjuk egy adminnak adok jogot a cikkek szerkesztésére, akkor "PUT article/*" jogkört kap, viszont ha egy mezei felhasználónak akarom megengedni, hogy az általa beküldött tartalmakat tudja szerkeszteni, akkor az előbbi jogkört úgy kell szűkítenem, hogy a * csak a saját cikkeinek az id-jére érvényes.

Ez egy általánosan előforduló dolog, pl a felhasználónak van egy munkamenete, aminél azt szeretném, hogy ki tudjon jelentkezni. Nyilván ilyenkor a "DELETE session/*" -re kap engedélyt, ahol a * az aktuális session ID lehet csak.

Egyelőre csak annyi jutott eszembe, hogy berakok egy flag-et a jogosultságokhoz, hogy általánosan vagy szűkítetten kell e értelmezni őket, illetve kézzel megírom minden egyes táblára az ellenőrzést, hogy az adott munkamenet felhasználójához tartozik e az adott sor... Esetleg van erre valami jobb megoldás? Egyelőre úgy vagyok vele, hogy adatbázis szinten meg tudom oldani a jogosultság kezelést, de egyre inkább úgy néz ki, hogy kénytelen leszek áttenni szerver oldali nyelvre, ahhoz, hogy rugalmas szabályokat tudjak csinálni.

Van egy másik lehetőség is, a felhasználók kapnak egyedi jogköröket, pl: "PUT article/123", és így tovább az összes cikkre külön külön. Ez nekem egy kicsit fapadosnak tűnik, de első ránézésre működőképes elgondolás. Ennek annyi a nehézsége, hogy bele kell írni a tárolt eljárásokba, hogy cikk létrehozásnál hozzáadjon és cikk törlésnél elvegyen jogköröket a rendszer az adott felhasználótól.

Mindkét megoldásnak közös problémája, hogy a kliens-nek el kéne küldenem az információt, hogy mihez van joga, hogy az alapján csak olyan menüpontokat rajzoljon ki, amik tényleg működnek is. Ez az első esetben az adatbázisban vagy php-ban tárolt szabályrendszer miatt nem megy, a második esetben meg azért, mert pusholni kellene a kliens-nek a változásokat, a php meg erre alkalmatlan. Esetleg response header-ben, vagy valami hasonlóban ki lehetne küldeni a második esetben, hogy frissítse a jogkörök listáját...

Döcögősnek érzem mindkét megoldásom. Szinte biztos, hogy van jobb. Bármi ötlet?
 
1

Egyelőre a legbiztosabbnak

inf3rno · 2013. Május. 29. (Sze), 00.40
Egyelőre a legbiztosabbnak azt érzem, ha minden új erőforráshoz külön adok jogot a szerzőjének. Így jó hosszú lesz a jogkörök táblája, de sokkal biztosabb, mintha egy erőforrás csoportba tartozó összes erőforráshoz adok jogot, és utána szűkítek a felhasználó által létrehozottakra... Amíg nincs jobb, addig ezt fogom megvalósítani.
2

Szinte biztos, hogy van

Joó Ádám · 2013. Május. 29. (Sze), 00.55
Szinte biztos, hogy van jobb.


Nincs. Akkor lesz a leggenerikusabb a kódod, ha létrehozáskor külön adsz jogot a felhasználónak az erőforrásra.
10

Köszi! Ez lesz, mert amúgy is

inf3rno · 2013. Május. 29. (Sze), 12.01
Köszi! Ez lesz, mert amúgy is ez a legegyszerűbb megoldás.
3

Szerintem ezt pont jól

dragi · 2013. Május. 29. (Sze), 09.00
Szerintem ezt pont jól valósították meg Zend frameworkben. Ott az acl objektum serializáltan van tárolva pl adatbázisban és abban pedig össze tudod legozni akár ilyen aprólékosan is, vagy pl vizsgáló függvényt hívni az adott erőforrásra. Tehát mikor belépett akkor phpból megy az acl nem dbből.
9

Megnézem később, hogy ez

inf3rno · 2013. Május. 29. (Sze), 12.00
Megnézem később, hogy ez milyen jelenleg gyorsabb egy egyszerűbb megoldást megvalósítanom.
4

Zed Shaw - The ACL is Dead

complex857 · 2013. Május. 29. (Sze), 09.10
Zed Shaw -nak van egy igen szórakoztató war-story jellegű előadása ACL-ekről. Ha van egy szabad órád érdemes rászánni, még ha nem is kell igazi törvényeket implementálnod kódban mint nekik, ha egy "jobb" megoldás után kutatsz (távolról sem biztos, hogy te konkréd problémádra jó lenne, de izgalmas).
5

Te miért nem jöttél a

Hidvégi Gábor · 2013. Május. 29. (Sze), 09.19
Te miért nem jöttél a sörözésre?
7

Jó a szövege a csávónak :D

inf3rno · 2013. Május. 29. (Sze), 11.42
Jó a szövege a csávónak :D
6

azonosítók

razielanarki · 2013. Május. 29. (Sze), 10.55
ha pl úgy oldod meg az egyes elemek azonosítóitm ahogy írtad (pl "article/117"), esetleg variálhatnád az id-tm pl ebben a formában: "article/<id>:<author_id>" azaz pl "article/177:19", és a jog lehetne pl "PUT article/*:*" vagy ilyesmi.

én hasonló rendszert találtam ki, nálam reguláris kifejezések vannak a jogok táblában, amik matchelnek egy adott instance stringre, amit a model (article) dönt el hogy néz ki nála, pl néha benne van a slug is, vagy mondjuk egy category_id, illetve egyéb dolgok amikre szűkíteni lehet a jogokat.

(az ellenörző lekérdezés eredményei persze gyorítótárazva vannak adott sessiönön belül.)
8

Ja, ez is egy megoldás, hogy

inf3rno · 2013. Május. 29. (Sze), 12.00
Ja, ez is egy megoldás, hogy beteszed a linkekbe a szerző id-jét. Nem rossz ez sem.
11

nem a linkekbe

razielanarki · 2013. Május. 29. (Sze), 15.45
nem feltétlen a linkekbe, az macerásabb volna seo miatt. a link marad pl "cikkek/a-cikk-cime"

"a-cikk-cime" alapján kikeresi a controller, megkapjuk az entity-t, amin vagy egy method (->instance()) ami visszadja h "én az articles/117:a-cikk-cime:19:2 (itt pl "table/id:slug:author:cat" van) belső azonosítójú példány vagyok", és ezt ellenőrzöm az acles patternekre h van e megfelelő jog rá.
12

Második

Pepita · 2013. Május. 29. (Sze), 20.13
felhasználók kapnak egyedi jogköröket, pl: "PUT article/123"
Szerintem ez a jobb, illetve jobbat nem tudok. Ha viszont biztos, hogy csak a saját tartalom szerkesztése ilyen egyedi elbírálású, tehát a többi jogosultság tartalomtípus~jogkör szintű, akkor egyszerűen a szoftverben is ("beégetve") meg tudod oldani a saját szerkesztés logikáját, mivel nyilván minden tartalomhoz hozzámented a user_id-t is. De ez "beégetős" módszer, nem a legjobb - viszont gyors és egyszerű...
13

Ja közben agyaltam egy sort.

inf3rno · 2013. Szep. 5. (Cs), 01.01
Ja közben agyaltam egy sort. Szoftverbe égetés is megoldás, de nem szeretném, mert csomó felesleges átláthatatlan kód születik csak belőle. Jobb egy általános rendszert írni, és minden ilyesmit arra bízni. Átgondoltam több vonalon is a dolgot, és ez a lehető legrugalmasabb rendszer. Lehetne még whitelist&exceptions alapon még rugalmasabbá tenni.

Pl van egy felhasználód, és azt szeretnéd, hogy ő maga ne lássa a jogköreit, csak a nevét és esetleg az email címét:

A lekérdezés:
GET users/13?fields=email,name,userPermissions

+ GET users/13
+ GET users/13/name
+ GET users/13/email
vagy

+ GET users/13
- GET users/13/userPermissions
A fentit gyorsabb ellenőrizni, de több adatot kell tárolni a szerveren ha sok mező van...

Azért annyira bonyolult ez a kérdéskör, mert sok esetben a queryString-ben beállítot szűrők is beleszólnak a dologba. Aztán vagy a visszatérő adatból kell utólag kiszűrni azt, amire nincs joga az illetőnek, vagy a mezők listájából.

Pl a
GET users
csak a 13-asat szabad, hogy visszaadja ha csak arra van joga. A REST linking legalábbis inkább ezt a megközelítést díjazza, mint azt, hogy no permissiont szórjon vissza... Szívesen keresnék egy már kész megoldást, és másolnám le... :D

Nehéz kiválasztani, hogy az egyes url-ek között milyen kapcsolat legyen, pl ha a /users/13 engedélyezve van, akkor a /users/13/usersPermissions engedélyezve legyen-e, mert az a /users/13 alatt található, vagy egyenként meg kelljen e adni az ilyen alsóbb erőforrásokat. Az sem teljesen tiszta, hogy a router-rel milyen kapcsolata legyen, mert ha nem implementálom mondjuk a /user/13/userPermissions-t - ha ráhívok arra az url-re, akkor 404-et - akkor mi alapján veszem fel a jogosultságok közé, hiszen nem is létezik... Egyelőre még nem tiszta az algoritmus, ami alapján el fogja dönteni, hogy mire ad engedélyt, és mire nem. Azt hiszem utánanézek jobban a resource linking & expansion témaköröknek, hátha ott választ kapok...
18

Nem sok

Pepita · 2013. Szep. 5. (Cs), 23.49
Szoftverbe égetés is megoldás, de nem szeretném, mert csomó felesleges átláthatatlan kód születik csak belőle.
De csak abban az esetben, ha tényleg erről van szó, hogy csak sajátot. Hát pl. a felhasználó adatlapját hogy csinálod? Ott a user_id valahol a sessionhöz kapcsolva (ahogy megoldottad), valamint a tartalom adott oszlopában is. Egyetlen if. Viszont kizártad a lehetőségét, hogy bárki más szerkessze. Mondjuk ezt meg egy másik, "szuper"jogosultsággal tudod kezelni, ha az adott júzert elütné a villamos.
Mint itt egy-egy komment: ha (még nem válaszoltak rá és a tiéd) vagy (moderátor vagy), akkor szerkesztheted. Ez nem sok kód, ezért nem érdemes szerintem bonyolítani. Én jobban híve vagyok a jogok~júzerek párosításnak, de nem mindenhova elég, gyanítom nem szórakozásból keresel más megoldást.
SZERK.: én elég sokat "lestem" a Drupal adatbázisából, mind felhasználó- és jogosultságkezelés, mind tartalomtípusok terén. De legtöbbször (nekem) sokkal egyszerűbb is elég: felhasználók - jogok - merge tábla. A tartalomtípusok másik kérdés.
19

Minden megoldható lenne

inf3rno · 2013. Szep. 6. (P), 01.53
Minden megoldható lenne ugyanúgy a csak url alapú megközelítéssel, de ahogy nőne az adatbázis baromira belassulna az egész. Egy részét meg lehet oldani vele, a másik részét meg jobb beégetni bizonyos szintig a kódba. Többek között ezt is, hogy csak saját tartalmat lehet szerkeszteni, ha valaki nem admin. Én viszont ezt is úgy csinálnám, hogy az adatbázis módosításával lehessen szabályozni pl annak a jogosultságnak a meglétét, hogy a saját tartalmakat szerkesztheti e az ember, vagy sem... Így végülis elfogadható ez az egész legjobb megoldásnak, de még olvasni fogok a témában, meg nézek kész megoldásokat. Általában nem url alapján szokták megközelíteni a dolgot, hanem minden egyes controllerhez kiteszik, hogy admin, etc... szerepkör kell hozzá. Ez egy kicsit jobban beégeti a kódba a dolgot, mint amire én gondoltam, de még ez is elfogadható. Átgondolva a dolgot még talán jobb is, mert nevén lehet neveni, hogy pontosan mire adsz jogot, nem kell tudnod, hogy egy-egy url pontosan mit csinál. Pl egy angolt nem ismerő emberkének ha odateszed, a magyar leírását a jogkörnek, akkor tudni fogja, hogy mire jó, ellenben ha megnéz egy endpoint-ot (method + url minta) esetleg még egy angol nyelvű filter nevet, attól még fogalma sem lesz róla, hogy mi az. Adatbázissal is kisebb munka, http szerveren valamivel nagyobb, plusz nagyobb az esélye a hibázásnak is, de ezzel együtt lehet élni.
14

Specialis felhasznalo

janoszen · 2013. Szep. 5. (Cs), 08.23
A Windows ugy kezeli az NTFS eseten a problemat, hogy van egy specialis user, az OWNER es a tulajdonosra vonatkozo jogosultsagokat onnan nezi meg.
15

kétszintű szűrő?

szabo.b.gabor · 2013. Szep. 5. (Cs), 08.32
amit te szerepkörnek hívsz, azt én átnevezném jogosultságnak.

PUT article/*
DELETE session/*

szerepkör pedig lenne a következő
admin
user
és egyéb felhasználóhierarchia ha szükséges (csoportadmin)

és a felhasználókhoz egy jogosultság + szűrő párost kellene rendelned.

-bejön a kérés
-átmegy a PUT article/* feltételen, megvan az adott erőforrás
-ezután az erőforrást és a felhasználót még átadod egy szűrőnek is, pl isOwner(), ami admin-nál mindig true, groupadmin-nál, sima user-nél pedig már nem.

ha itt sem bukik meg a dolog, akkor csinálhatod a dolgod.

amúgy tényleg a zend-et kellene megnézned egy kicsit.

gondolom már késő a válasz, de hátha segít.
16

Ez a szűrő nem rossz ötlet,

inf3rno · 2013. Szep. 5. (Cs), 15.03
Ez a szűrő nem rossz ötlet, de hogyan lehet letárolni adatbázisban?

Nem számít, hogy késő válasz, vagy ilyesmi, így is lehet tanulni belőle...

Na közben rájöttem magamtól, hogy max szövegként lehet letárolni, és a megvalósítást a php-ben megoldani:

method resource filter
GET /users/13 projection=basic
GET /users/* owner=1
GET /users/*
Lehet több filtert is megadni, aztán összesíteni a kérésre illő minták alapján.

amit te szerepkörnek hívsz, azt én átnevezném jogosultságnak.

Lehet, hogy valami kavarodás volt régen, nem olvasom vissza, de úgy emlékszem, hogy már akkor is elég jól elkülönült a szerepkör és a jogkör fogalma.

Ez az endpoint + filter egyértelműen jogkör, a szerepkörökhöz pedig jogköröket és felhasználókat lehet társítani. Amiben nálam más volt az előző változat, hogy pl owner filter helyett felsoroltam az összes endpoint-ot, ami a felhasználóhoz tartozik. Ez kevésbé takarékos sorok terén, mint a filterezés, de ugyanúgy működik. A filter azért jobb, mert az aktuális projection-t queryString-ben szokták megadni, így akár arra is lehet külön jogosultságot ellenőrizni. A másik, ami miatt jobb, hogyha a munkamenetben akarom cachelni a jogokat, akkor nem kell több ezer sort beolvasni onnan minden lekéréskor - ha olyan sok tartalmat hozott létre az illető - hanem elég csak egyet. Szóval a méret növekedésével nem fog lassulni a jogosultság ellenőrzés, szemben az én megoldásommal.
17

Közben kiderült, hogy kétféle

inf3rno · 2013. Szep. 5. (Cs), 19.56
Közben kiderült, hogy kétféle access control is van, és a filteres megoldásnál ez a kettő szépen szét is vált: coarse grained és fine grained access control... A durva szemcséset lehet endpoint alapján ellenőrizni a finomszemcséshez meg kellenek a filterek. Az este utánaolvasok mindkettőnek...
20

Átgondoltam több aspektusból

inf3rno · 2013. Szep. 6. (P), 03.22
Átgondoltam több aspektusból is a dolgot:

Két megközelítése van a témának, az egyik a hardcodolt, amikor az endpoint controllerébe tesszük be a hozzáférés ellenőrzéséhez dolgokat:
if user
has role 1
and (passes filter 1 or filter 2)
or has role 2
or passes filter 3
then grant access
A másik az én megközelítésem, amikor ugyanezt a logikát transzformáljuk, és lementjük az adatbázisban, és szabadon belenyúlhatunk, hogy a program egyes részeihez ki fér hozzá.
table role_permissions
role=1 permission="endpoint filter1,filter2"
role=2 permission="endpoint"
role=0 permission="endpoint filter3" // public role, every user - except banned - has this
Annyi biztonsági kockázata lehet a dolognak, hogyha illetéktelenek hozzáférnek az adatbázishoz, akkor átírhatják a hozzáféréshez szükséges jogokat. A másik esetben ha illetéktelenek férnek hozzá az adatbázishoz, akkor csak a felhasználók szerepköreit írhatják át, amivel körülbelül pont ugyanannyira mennek. Szóval szerintem ennek a megközelítésnek nincs plusz biztonsági kockázata, hacsak az nem, hogy egy adatbázis visszaállításnál elveszhetnek ezek az információk, előnye viszont az, hogy sokkal finomabban be lehet állítani vele, hogy kinek mihez van hozzáférése. Akár adhatunk külön ideiglenes jogot is egy-egy felhasználónak egy-egy objektumra anélkül, hogy bele kelljen nyúlnunk az eddigi kódba. Nem tudom, hogy ez spanyolviasz, vagy sem, de nem igazán láttam még eddig egyetlen rendszerben sem, amikbe belenéztem.

Plusz példa wikipediaról:

XACML (extendable access control markup laguage):
Allow access to resource MedicalJournal with attribute patientID=x
           if Subject match DesignatedDoctorOfPatient
           and action is read
     with obligation
          on Permit: doLog_Inform(patientID, Subject, time)
          on Deny  : doLog_UnauthorizedLogin(patientID, Subject, time)


transzformálva:
permission 1 GET /resources/MedicalJournal filter:DesignatedDoctorOfPatient(x)


Az obligation-ös részhez nyilván új táblák kellenek, de azt sem lehet valami nehéz letárolni adatbázisban. És akkor ez egy direkt ilyen célra alkotott nyelv volt... (Biztosan többet is tud az a nyelv, de azt hiszem, hogy a megközelítésem elég jó. Hízik a májam :D)

A kimenő dolgok szűrését is meg lehet oldani ugyanilyen ellenőrzéssel. Azt nyilván már muszáj hardcodolni és kézzel hívni... Továbbá kell majd egy megoldás a szűrők összepárosítására a megfelelő osztályokkal, de azzal sem hiszem, hogy probléma lesz. Az egyedüli hátránya az egésznek, hogy a rugalmasságért cserébe lassabb valamivel, mert az összes - a felhasználóhoz tartozó - szabályt le kell rántani bejelentkezéskor a munkamenetbe, aztán kikeresni, hogy illik e valamelyik az aktuális kérésre. Ha elég gyors az algoritmus, és nincs indokolatlanul sok szabály, akkor szerintem megéri a használata.

Még majd tuningolni kellene az alkalmazás kódján annotációkkal, és akkor egész pofásan lehet majd használni ezt a megoldást. Neki fogok ülni, megvalósítom, aztán majd kiszórom github-ra.

szerk: Közben találtam olyat, aki hasonló eredményre jutott: http://wuher-random.blogspot.hu/2011/09/access-control-for-your-restful-api.html pythonban fejlesztett egy hasonló middleware-t...
21

Körülbelül általánosságban az

inf3rno · 2013. Szep. 7. (Szo), 00.35
Körülbelül általánosságban az jött le, hogy 3 dolog van összesen, ami szóba jöhet access control-nál: filters/rules, projections/modifiers, obligations/events.
- A filterek döntik el, hogy joga van e az illetőnek az adott műveletre. Ha listázzuk az illető összes jogosultságát, és egy jogosultságnál sem mennek át a filterek az adott kérésre, akkor nincs joga a műveletre. Két filter típus lehet, a global és a local. A global a method és az url szűrő, mert azokat minden kérésnél meg lehet mondani. De ugyanígy lehet http header-re és minden másra szűrni... A local mondjuk az isOwner, azt máshogy kell lekérdezni egy profil oldalnál és egy cikknél is, más az sql mögötte, így helyben kell megvalósítani.
- A projection a művelet lefutását módosíthatja, pl ha csak olyan projection-re van joga valakinek, ami id-t és felhasználói nevet tartalmaz, akkor nem kaphat vissza email címet, vagy ha törlést hív, és csak elrejtéshez van joga, akkor nyilván elrejteni fogja a rendszer a hozzászólást.
- Az obligations tartalmazza a jogosultság ellenőrzéssel kapcsolatos eseménykezelőket. Mondjuk ha sikertelenül próbálkozik valaki a belépéssel egy fiókba, akkor arról lehet üzenetet küldeni a fiók tulajdonosának.
Ezeket mind le lehet tárolni adatbázisban, vagy többé-kevésbé beleégetni a kódba. Az, hogy melyiket válasszuk attól függ, hogy mennyire rugalmas rendszer felel meg az igényeinknek. Ha mondjuk két csoport van: olvasók, szerkesztők, akkor teljesen felesleges emiatt egy bonyolult rendszert felépíteni, elég az adatbázisban csak a csoportokat letárolni és hardcodolni a csoport tagság ellenőrzését. Ha ennél bonyolultabb a helyzet, az egyre inkább a kevesebb hardcodolás és több automatizálás + adatbázisban mentés felé tolja el a mérleget.

Na általános rendszert se ma csinálok erre, nekem jelenleg simán elég egy durva szemcsés hardcodolt megoldás 2 csoporttal meg egy isOwner szűrővel, viszont ezt az egészet beteszem egy külön projektbe, aztán ha több időm lesz, akkor foglalkozom vele.

Példának szerintem elég ennyi:

hardcode:

@/articles

ArticleController
	@GET /
	readAll () {
		if (!session.loggedIn())
			throw 403;
		if (session.hasRole("editor"))
			return articleModel.readAll();
		else
			return articleModel.readAllByUserId(session.getUserId());
	}
általános:

@db
	
	role 1 editor permissions: 1
	permission 1 GET /articles constraints: -; modifiers: full, owner
	role 0 public permissions: 2
	permission 2 GET /articles constraints: loggedIn; modifiers: owner
 	

@/articles

ArticleController
	@GET /
	readAll () {
		if (session.hasModifier(full))
			return articleModel.readAll();
		else if (session.hasModifier(owner))
			return articleModel.readAllByUserId(session.getUserId());
	}
Azért szerintem érződik, hogy mennyivel egyszerűbb a fejlesztés, ha a controller-ből kiszedjük a jogosultság ellenőrzést, ami nem oda való.
22

Lehet...

Pepita · 2013. Szep. 8. (V), 00.08
Azért szerintem érződik, hogy mennyivel egyszerűbb a fejlesztés, ha a controller-ből kiszedjük a jogosultság ellenőrzést, ami nem oda való.
Van benne valami, de az még mindig a kérdés, hogy mikor mi éri meg jobban? De igencsak gondolkodóba ejtettél, hogyan javítsam eddigi ötleteimet, főleg ha bonyolultabbá válik egy helyzet. Köszi!
23

A jogosultság ellenőrzés

inf3rno · 2013. Szep. 8. (V), 00.15
A jogosultság ellenőrzés nagyon egyszerű, mindig ugyanazokból az egységekből épül fel. Vannak megkötéseid, amik ha teljesülnek, akkor az adott munkamenet jogot kap valamire. Minél bonyolultabbak a megkötések, és minél kidolgozottabb, hogy mire kap jogot, annál finomabb szerkezetű a jogosultság kezelő rendszered. Vannak fokozatok ebben: ACL, RBAC, ABAC, stb... Szét is lehet szedni több részre (bad practice), pl whitelist az erőforrásra, blacklistes utólagos szűrés a visszaadott értékekre, stb...
Egy komolyabb jogosultság ellenőrző rendszerhez kb ennyi kell:
User 1 : n Session
User 1 : n Role
User||Role n : m Policy
Policy 1 : n Constraint + at least 1 Permission
Kell még egy SecurityGuard (sokan AccessManager-nek hívnák, de ilyen melót nem szívesen bíznék menedzserekre), ami végigfuttatja a Session-höz tartozó összes Policy-t a bennük található Constraint-ekkel az adott kérésre, és ahol minden Constraint stimmel, ott megkapja a munkamenet az összes Permission-t, ami a Policy-hez tartozik. (Általában ezt meg szokták optimalizálni, hogy szűrjön endpointonként, stb.. különben baromi lassú lenne.) Ezek után lefut a Controller és a Permission-ök alapján megcsinálja, amit kell. Ha egy Policy-t sem sikerül begyűjteni, akkor a játéknak vége, és 403-as status-t küld vissza a szerver. (Egy perc és nyersz, vagy miben tolnak ilyen szövegeket?! :D Na mindegy, ez csak úgy jött...)

Onnan tudom, hogy valamit már értek, hogy a lehető legtömörebben el tudom mondani. Általában ez van, mint ennél a témánál, hogy futok 10-20 kört, újra, és újra átfogalmazom, míg a végén teljesen betömörödik az egész pár mondatba. A gond akkor szokott kezdődni, ha közben valakinek magyarázok erről, mert a végén bele szoktak őrülni az emberek :D

Lábjegyzet: az XACML szabvánnyal is hasonlóan oldják meg a dolgot, mint én, szóval ha egy adott nyelven implementálva van az a szabvány, akkor érdemes azt használni saját könyvtár gányolása helyett.
24

Unix

Hidvégi Gábor · 2013. Szep. 8. (V), 11.18
Nem olvastam újra végig a hozzászólásokat, de lehet, hogy már volt: unix-szerű tulajdonos/csoport/többiek jogosultságkezelésen gondolkoztál már? Érzésre egyszerű bitműveletekkel lehetne operálni, ami nagyon gyorssá tenné a műveletet.
25

Nem elég általános, egy

inf3rno · 2013. Szep. 8. (V), 15.06
Nem elég általános, egy komolyabb rest-es oldalhoz szerintem nem elég. Az utolsó hozzászólásaimat van értelme esetleg megnézni, abban leírok egy általános rendszert, ami az oldalak 99%-ára elég lehet. Egyébként meg lehet használni XACML megvalósítást, ami meg 10x többet tud, és sok helyen implementálva van, de abba én nem folytam bele.