Adatbázis szintű jogosultságkezelés Hibernate-tel

Java

Sziasztok!

Jelenleg van egy Hibernate-tel Oracle 10g-hez kapcsolódó JSP Enterprise webalkalmazás "csonkom".
Probléma ott van, hogy nem tudom megoldani a jogosultságok kezelését.
Van egy user táblám, amihez 1:N kapcsolattal kapcsolódik egy dev tábla (meg több másik, ez szerintem irreleváns a probléma szempontjából). Három felhasználói csoportot kellene létrehoznom: user, "super-user", administrator. Ezen csoportoknak különböző jogosultságaiknak kell lennie pl. a dev táblán:
-user: csak SELECT
-"super-user": csak SELECT, és UPDATE
-administrator: INSERT, SELECT, UPDATE, DELETE

Jelenleg 1 felhasználóm van, amivel kapcsolódik a Hibernate az adatbázishoz, amiben levő User tábla rekordjai által reprezentált emberkéket kéne jogosultság szerinti csoportokra bontani. DAO-t természetesen használ az alkalmazás.
Itt már majdnem találtam megoldást, csak ekkor inicializáláskor mindig felépítem a 3 kapcsolatot a 3 userhez, akik hozzáférnek az administrator tábláihoz GRANT-tel meghatározott jogosultságokkal.

Kérdés arra irányul, nem lehet-e jobb rendszert összehozni? Még mielőtt valaki megkérdezi: szakdolgozat, és a témavezetőm sem tudta rá a megoldást, csak azt mondta, hogy ne az üzleti logikát terheljem ezzel... Persze ötletet nem mondott.

Válaszotokat köszönöm!

  • 1779 megtekintés

( atomheart v | 2010. 02. 20., szo – 23:14 )

Rossz otlet...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

( vl v | 2010. 02. 20., szo – 23:38 )

nos, szerintem a koncepciód, miszerint van n db user az oracle-ben, és oracle szinten definiálod, hogy melyik mit csinálhat, szerintem nem nyerő. akkor használják, ha az igazi felhasználók direktben (mondjuk vastag klienssel) kapcsolódnak.

2010-re a vastag klienses architektúrákon már rég túllépett az iparág. most ott tartunk, hogy az alkalmazáslogika nem a kliensben van, így az központilag felügyelhető, nem szükséges, hogy minden user saját maga jelenjen meg az adatbázis szintjén, hanem helyette egy user van az adatbázisban, az alkalmazás azzal lép be, és az alkalmazáson belül van a jogosultság-ellenőrzés.

Nyuszika szakdolgozatot ír

Nyuszika ül a fa tövében és írogat. Arra megy a róka és megkérdi:
- Mit írsz nyuszika?
- Szakdolgozatot arról, hogy a kis állatok hogyan tudják megvédeni magukat a nagyvadaktól!
- Ez hülyeség! Gyere a bokorba és mutasd meg!
A róka csupa véresen jön ki, de a nyuszikának semmi baja!
Arra jár a farkas is és ő is megkérdi a nyuszikát:
- Mit írsz nyuszika?
- Szakdolgozatot arról, hogy a kis állatok hogyan tudják megvédeni magukat a nagyvadaktól!
- Ez hülyeség! Gyere a bokorba és mutasd meg!
A farkas csupa véresen jön ki, de a nyuszikának semmi baja!
Arra jár a medve! Megkérdi:
- Mit írsz nyuszika?
- Szakdolgozatot arról, hogy a kis állatok hogyan tudják megvédeni magukat a nagyvadaktól!
- Ez hülyeség! Gyere a bokorba és mutasd meg!
A medve csupa véresen jön ki, de a nyuszikának semmi baja!
Kijön utána az oroszlán és így szól:
- Látod nyuszika, nem az számít, hogy miről írsz szakdolgozatot, hanem az, hogy ki a konzulensed!

( kispista | 2010. 02. 21., v – 10:51 )

Szia!

Muszáj a db level? Szerintem jobb az üzleti logikát terhelni ezzel ilyen helyzetben, sőt! Sokkal absztraktabb és jobban konfigolható securityt tudsz létrehozni így.

Szerk.:
Egyébként Hibernate támogat mindenféle interceptort. Nekem most jött elő egy audit probléma entitásokra (createdBy, modifiedBy, stb...) és EntityListener csodálatosan megoldotta a dolgot.
Szvsz security (és logging) sok esetben metszi a különböző rétegeket és erre a problémára már nagyon klassz dolgokat találtak ki, ha teheted nézzél körül AOP háza táján :)

"Szakdolgozat téma, témavezető nagy Oracle-ös, és ő mondta."

"Még mielőtt valaki megkérdezi: szakdolgozat, és a témavezetőm sem tudta rá a megoldást, csak azt mondta, hogy ne az üzleti logikát terheljem ezzel... Persze ötletet nem mondott."

En nem adnek ilyen temavezeto velemenyere. Persze a te szakdolgozatod.

Tyrael

( hrgy84 | 2010. 02. 22., h – 16:30 )

Az authentikacio egy dolog, az authorizacio meg egy masik.

Mindenkeppen van alkalmazas oldali overhead, csak nem mindegy, hogy hol es mennyi. Ha azt az alapesetet veszem, hogy Oracle DB-vel szeretnel authentikalni, akkor az a baj, hogy a belogin utan ellenorzott ervenyes user/pass-t le kell nyomni egeszen a DB layerig, ami aztan kiepiti a valodi kapcsolatot. Ezzel reszben az a gond, hogy az authentikacio utan tovabb el a jelszo a memoriaban, reszben pedig az, hogy csunyan ki kell nyulnod az adatbazis reteghez, hogy atadd azt a nyomoronc user/pass parost. Most teljesen mindegy, hogy honnet nyulsz ki, ha az uzleti logika parameterezi az adatbazisreteg kapcsolatait, az mar nagyon regen rossz irany.

En is azt mondanam, hogy inkabb valositsd meg te az authorizaciot. Az authentikacio mehet Oracle-hez, adott esetben - ha van erre lehetoseg - az illeto user jogait is kiolvashatod, de a hozzaferesvezerles maradjon a te oldaladon.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Még egy vonal a saját authorizáció mellé :)

Egyre jobban hajlok ez utóbbi felé (hiába van már gyakorlatilag kész ez "multi-session" megvalósítással, és kiválasztással). Akkor is probléma például az, hogy:
-BL-ben is le kell ugyanúgy kódolni, hogy az UIn ne jelenjenek meg elemek
-nem minden valósítható meg (pl. hogyan oldanám meg, hogy egy "super-user" felhasználó ne tudja írni másik "super-user" felhasználó sorait. Egy hasonló technikát ismerek, a VPD-t, ami meg tudomásom szerint nem képes erre, csak ha paraméterként átadom neki BL-ből, akkor meg megint ott vagyok, ahol a part szakad...)

Csak az "esetlegesen megnövelt biztonság" van a database-level mellett, meg a témavezetőm, aki, mint a mai beszélgetésünkben kiderült, már nem is emlékezett rá, hogy ilyesmit mondott...

Record, or didn't happened? :-)

Pont ez az, amit mondasz: db-levelnel ugyan valoban van egy adott biztonsagod, de ez messze nem eleg, ket hasonlo role-val rendelkezo user akkor is bele tud nyulni a masik cuccaba, ha a BL terve szerint nem lenne ra joga. Ha ezt el akarod kerulni, akkor nem uszod meg a sajat authorizacio megirasat, csak akkor van annyi konnyebbseged, hogy csak par dologra kell figyelni. Viszont... ha mar ugyis ott az authorizacio terve, akkor jobb azt kifejteni, mint ilyen stubokat generalni az appba.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.