Lényegében RBAC, csak nem a Membernek (~User) vannak szerepei, hanem a kör tagságoknak (Membership). A szerepeket esetünkben posztoknak hívják és ezeknek vannak jogaik vagyis engedélyeik. A jogok egy előre jól definiált halmazból kerülnek ki. Dinamikusan nem hozhatóak újak létre. Ezekhez a kód változtatása kell. Hátránya ennek, hogy nagyjából minden tevékenységre kénytelenek vagyunk egy-egy jogosultságot létrehozni. És ráadásul a felületen is megjelenik egy felesleges komplexitás a jogosultságok nagy számával.
A posztok a körben betöltött szerepet jelölik. Posztok lehetnek például:
- körvezető
- HR
- gazdaságis
- szakkoli elnök
- vezető senior
Minden poszt értelemszerűen egy körhöz kapcsolódik a tagságon (Membership) keresztül. Ettől függetlenül a posztoknak lehetnek olyan jogosultságai, amik a rendszerben globálisak, azaz nem függnek az adott körtől. Például ilyen lehet, hogy a féléves beszámolókat a körvezetők más körökben is el tudják olvasni.
Ezek olyan jogosultságok, amiknek kontextusra van szükségük. Ez a kontextus maga a kör. Lényegében itt az egy körhöz tartozó rendszerfunckiókról beszélhetünk. Például egy új körtag hozzáadása egy körhöz csak az adott kör függvényében értelmes.
A kontextust a jogosultság ellenőrzés során kívülről kell biztosítani. A kontextus (kör) ellenőrzése a Post -> Membership -> Group kapcsolaton keresztül valósítható meg. Implementációban ez azt jelenti, hogy minden jogosultság ellenőrzéshez 4 paraméter tartozik:
- ki
- milyen erőforráson
- mit
- és ezt milyen kontextusban (körön belül)
szeretne csinálni.
Mikor ellenőrizzük egy felhasználó jogosultságát, akkor elég az adott körön belül betöltött posztjait vizsgálni.
Vannak olyan feladatok a rendszerben, amik nem köthetőek egyetlen körhöz sem. Vagy esetleg túlmutatnak körökön. Ellenőrzéskor az adott felhasználó összes körben betöltött összes posztját ellenőrizni kell, mert bármelyik rendelkezhet az adott művelet végrehajtásához szükséges jogosultsággal. Ebben az esetben nem 4 hanem csak 3 paraméter szükséges:
- ki
- milyen erőforráson
- mit
szeretne csinálni.
Az előző részben tárgyalt kettős tulajdonság miatt egy jogosultságnak tudnia kell magáról, hogy kontextus függő-e vagy független. Ez befolyásolja majd a keresési stratégiánkat az ellenőrzés során.
Variációk:
-
minden permission egy osztály és tudja hogy mit kell checkelni (attribútumok és hasonló) és mindegyiknek van azonosítója. ezt az azonosítót tároljuk a Post modellben egy tömbben.
pozitív: könnyű őket egy poszthoz kapcsolni, mert van egyedi azonosítójuk. Self-contained elenőrző logika.
negatív: a szabályok nem flexibilisek és sokat kell belőlük írni, sokszor lehet olyan, hogy ismétlődnek a dolgok. Pl létrehozhat XY-t és létrehozhat XZ-t az lényegében ugyanaz a vizsgálat. Ezen kívül még azzal is számolni kell, hogy a felületen nehéz kezelni a nagy számú jogosultságot.
-
a permissionök kb egy predikátumként állnak elő.
- ki -> mindig ugye a bejelentkezett user
- mit -> lényegében egy string/symbol. sokszor create, update, delete, read négyesből, de lehet egyedi is.
- min -> ez lehet egy objektum példány vagy egy osztály is
- kontextus kell-e vagy sem
- a group az úgy is külön kell beletölteni a csőbe, itt nem lehet erre külön megkötést adni
pozitív: újra felhasználható ellenőrző kód. Könnyű új szabályt alkotni. A mostani implementáció már nagyjából ilyen, kisebb átalakításokat igényelne csak.
negatív: hogyan kötjük az egyes jogot a posztokhoz -> lehet megoldás ha itt is van egyedi név, amit a Postban tárolunk. Megint probléma a jogosultságok nagy száma a rendszerben -> felületen nehézkes kezelés.
Mindkettőnél probléma, hogy lényegében minden esetben a szerepet a nulláról kell újra felépíteni (jogosultságokat hozzáadni). Szintén gond, hogy a felületen megjelenő nagy számú jogosultság átlátása felesleges komplexitást visz a felhasználói élménybe. És akkor még nem is beszéltünk arról, hogy ki és mit oszthat újra a jogosultságok közül.
Jó viszont, hogy dinamikusan hozhatóak létre szerepek és a jogosultságok.
Mindenképpen szükség van arra, hogy a már valamilyen jogosultsággal rendelkező tagok tovább tudjanak adni jogosultságokat. Lényegében arról van szó, hogy felhatalmazhassanak más felhasználókat is a rendszer adminisztrátorai nélkül.
Egyszerű megvalósítás, ha minden poszthoz tartozik az engedélyek listája mellett egy második lista, ahol azt tároljuk, hogy milyen engedélyeket oszthat ki, ha egyáltalán hozhat létre új posztokat. Az egyetlen kérdés, hogy ki határozza meg, hogy ki mit oszthat ki. Lehetne megoldás itt, hogy van pár előre definiált sablon (pl körvezető), aminek előre definiált listája van arról, hogy milyen jogokat oszthat tovább. Itt viszont a későbbiekben a lista bővítése nehézkes, az adatbázis túrását eredményezi. Jó lenne tehát, ha a szerepek csak egyszer szerepelnének az adatbázisban/kódban, hogy a bővíthetőségük és karbantarthatóságuk megmaradjon. Ez viszont teljesen borítja az eddigi elképzelést.
A karbantarthatóság előre és központilag definiált szerepekkel oldható meg. A szerep és poszt fogalom szétválasztása megoldaná ezt. Ekkor elveszne a jelenleg meglévő dinamizmus a rendszerből.
Szerintem az 1. variáció jobban átlátható, esetleg örökléssel, vagy kód kiemeléssel megoldható a negatívum.
Az írás nem említi, de nem emlékszem, hogy mire jutottunk végül a központi posztokkal (pl. körvez., gazdaságis, stb.). A fentiek szerint egy poszt teljesen független az összes többitől és csak a permissionok másolódnak (sablonok, vagy poszt átadás esetén). Viszont el tudom képzelni azt az esetet, hogy készítünk egy új funkciót, amihez új permission szükséges, ezt az admin szeretné az összes körvezetőnek kiosztani. Jelenleg nem tudjuk megmondani, hogy melyik poszt a körvezető vagy a gazdaságis, csak a permissionok halmazát ismerjük.
Egy hivatkozás az ős posztra megoldás lehetne az általam felvetett problémára, de növeli a komplexitást és ki kellene zárni az ős posztból származó posztok szűkítését (ez csak központilag lehetséges, az admin által). Egy ősposztból származó poszt bővítése további permissionökkel talán nem okozhat problémát.