[ALG/J2EE] Role based security engine

[Antediluvian]

Bij het designen van de database voor een ERP systeem heb ik voor user rights management de volgende structuur uitgewerkt.



Er ontbreken vrij veel attributen in de kolommen maar die zijn nu niet relevant.

Een rule permission wordt is op 3 verschillende manieren in te stellen. Namelijk: “Allow”, “Disallow” en “Not Specified”.

Een voorbeeld:
- Er bestaat een ProductRule R (bv View product prices).
- User U wil van Product P de prijzen bekijken.
- User U is lid van usergroep UG en UH.
- Product P is lid van productGroep PG

Er zijn hier in totaal 6 policies van kracht, namelijk:
- R -> PG -> UG
- R -> PG -> UH
- R -> PG -> U
- R -> P -> UG
- R -> P -> UH
- R -> P -> U

Normaal zullen de meeste van deze permissions “Not Specified” zijn

Strong security is van kracht. Hiermee bedoel ik dat eenmaal er een “Disallow” aanwezig is het eindresultaat van de security check “Disallow” is.

Vb:
A = Allow | DA = Disallow | NS = Not Specified
A + DA + A => DA
A + NS + NS => A
A + NS + DA => DA
NS + NS + NS => DA

Voor de algemene regels (tabel Rule) heb ik een policy parser uitgewerkt die bij het inloggen van de gebruiker zijn SecurityPolicy en de SecurityPolicies van de usergroeps waarvan hij lid is ophaalt uit de database en een eenduidige policy opstelt die actief zal zijn.

Nu zoeken ik een oplossing voor het ontwerpen/ontwikkelen van een security engine die zowel makkelijk in gebruik en snel genoeg is.

Het grootste performance probleem doet zich wellicht voor als een gebruiker een ongestructureerde (fulltext search) productlijst opvraagt.

Ik ben reeds tot de volgende oplossingen gekomen:
Oplossing 1



Hoofdprobleem hier is volgens mij performance wegens de vele queries die moeten uitgevoerd worden.

Oplossing 2



Hier kan een groot gedeelte van de security checks ingebouwd worden in het search sql statement. Dus goeie performance; enkel de modulariteit is niet meer aanwezig aangezien de security engine een sterke notie moet hebben over alle objecten waar security van kracht is (bv producten, klanten, orders, …)

Oplossing 3

Zoals het voorgaande maar in plaats van de Security Engine die het search statement uitvoert dit door de Search Engine laten doen en deze dus een notie van security geven.

Oplossing 4

De security inbouwen in de DAO zodat alle checks daar afgehandeld worden. Het nadeel is dat alle security logica gedecentraliseerd is en zich her en der tussen alle DAO logica zal bevinden.

===============================================================

Sorry dat het zo een chaotisch geworden is. Hopelijk is het duidelijk en ander vraag je het maar dan zal ik nogmaals mijn best doen om het geheel te verduidelijken.

Zoals je ziet is dit een vrij complex geheel. Aangezien ik er zelf niet uit raak stel ik hier de vraag of er mensen zijn die ervaring hebben met dergelijke dingen en advies kunnen geven of gewoon een betere oplossingen kennen.

De taal die gebruikt zal worden voor ontwikkeling is Java in combinatie met het Spring framework en J2EE. Misschien dat Spring of J2EE voor dergelijke zaken reeds een standaard oplossing voor heeft waar ik nog niet van weet.

[Verwijderd]

Antediluvian schreef op maandag 27 december 2004 @ 01:19:
Oplossing 1

[afbeelding]

Hoofdprobleem hier is volgens mij performance wegens de vele queries die moeten uitgevoerd worden.

misschien kan het helpen eerst de security te controleren en indien de security de user het recht tot die zoekopdracht verleent DAN pas de zoekopdracht echt uitvoeren. Je zegt zelf dat je security nogal restrictief is (eenmaal disallowed is onherroepelijk disallowed).
Tenslotte voer je iets uit dat later gewoon weggegooid wordt. Security zou dus je allereerste call moeten zijn. En mits wat cachen en intelligent vergelijken moet dat toch tamelijk te optimaliseren zijn.

En ik zou security en je echte business niet mengelen (ook al is security natuurlijk een belangrijk deel van je business, het zou leuk zijn als elk personeelslid zijn eigen evaluatie, promotie, ... mag schrijven én evalueren én valideren in een HRM systeem )


(en nu wat geblaat waar ik eigenlijk niets van afweet, heb je al naar Acegi gekeken? dat is security voor Spring, maar ik weet neit of je er iets dergelijks mee kan bouwen... maar misschien loont het de moeite )

[Alarmnummer]

Verwijderd schreef op maandag 27 december 2004 @ 08:33:
[...]
En ik zou security en je echte business niet mengelen (ook al is security natuurlijk een belangrijk deel van je business, het zou leuk zijn als elk personeelslid zijn eigen evaluatie, promotie, ... mag schrijven én evalueren én valideren in een HRM systeem )

Idd.. dit soort aspecten van je systeem wil je niet haaks over je business logic hebben.

(en nu wat geblaat waar ik eigenlijk niets van afweet, heb je al naar Acegi gekeken? dat is security voor Spring, maar ik weet neit of je er iets dergelijks mee kan bouwen... maar misschien loont het de moeite )

Het enigste wat ik vervelend vond is het volgende:

The security architecture does not have a notion of roles or groups, which you may be familiar with from other security implementations, although equivalent functionality is fully accommodated by Acegi Security.

Ik erger me eigelijk aan het feit dat ze geen standaard oplossing hebben gekozen met standaard termen. Ze zullen er wel een reden voor hebben gehad, maar ik ben niet overtuigd en ik wil niet een andere reeks met begrippen leren.

[@TopicStarter]
Als je die searchengine ziet als een service, dan zou je daar de security aan kunnen toevoegen. Hierdoor verhinder je onnodige searchs.

voorbeeld.

code:

class SearchEngine{

      /**
       *  @@SecurityConfig("ROLE_ADMIN")
       */
     public List search(String productName){
     }
}

En als je niet wilt werken met attributen kan je het doen in de sprig container, of anders programmeren in de searchengine zelf.

Services zijn over het algemeen de objecten in de bovenste laag van de domain laag waarin oa security en transacties gecoordineerd worden.

En heb je verder al gekeken naar het optimaliseren van de searchqueue zelf? Ik weet niet welke database je gebruikt, maar je zou anders de tabel waarover je een textsearch doet kunnen indexeren. Dit scheelt al enorm in de kosten van de query.

[ Voor 30% gewijzigd door Alarmnummer op 27-12-2004 09:17 ]

[zneek]

Alarmnummer schreef op maandag 27 december 2004 @ 09:06:
[...]

Idd.. dit soort aspecten van je systeem wil je niet haaks over je business logic hebben.


[...]


Het enigste wat ik vervelend vond is het volgende:

[...]


Ik erger me eigelijk aan het feit dat ze geen standaard oplossing hebben gekozen met standaard termen. Ze zullen er wel een reden voor hebben gehad, maar ik ben niet overtuigd en ik wil niet een andere reeks met begrippen leren.

[@TopicStarter]
Als je die searchengine ziet als een service, dan zou je daar de security aan kunnen toevoegen. Hierdoor verhinder je onnodige searchs.

voorbeeld.

code:

class SearchEngine{

      /**
       *  @@SecurityConfig("ROLE_ADMIN")
       */
     public List search(String productName){
     }
}

En als je niet wilt werken met attributen kan je het doen in de sprig container, of anders programmeren in de searchengine zelf.

Services zijn over het algemeen de objecten in de bovenste laag van de domain laag waarin oa security en transacties gecoordineerd worden.

En heb je verder al gekeken naar het optimaliseren van de searchqueue zelf? Ik weet niet welke database je gebruikt, maar je zou anders de tabel waarover je een textsearch doet kunnen indexeren. Dit scheelt al enorm in de kosten van de query.

Probleem van de TS is volgens mij niet dat ie de functie niet weet af te schermen, maar dat het resultaat wat terug komt een extra security slag nodig heeft. Je moet een bepaalde rol/recht hebben om te mogen zoeken, maar wat je vindt daar kunnen zaken tussen zitten die je niet mag zien. Bijv een verkoopmedewerker die (nog) niet de nieuwe artikelen waar nog geen definitieve verkoopprijs aan hangt mag zien in zijn zoekresultaat.

imho een rotprobleem, waar ik zelf ook al eens mee geworsteld heb in een HRM omgeving. Daar heb ik toen gekozen om de DAO methodes bewust te maken van de rol van de ingelogde werknemer. Een normale werknemer krijgt altijd alleen zichzelf terug bij een zoekWerknemers aanroep, een afdelingshoofd alleen de werknemers van de betreffende afdeling en de PenO medewerker krijgt alle werknemers terug. Niet echt de meest elegante oplossing, maar in die situatie afdoende.

Volgens mij ga je hoe dan ook je business, dao of view logica vervuilen als je dit af moet dwingen. Lastige keuze...

[Alarmnummer]

zneek schreef op maandag 27 december 2004 @ 10:34:
[...]
Probleem van de TS is volgens mij niet dat ie de functie niet weet af te schermen, maar dat het resultaat wat terug komt een extra security slag nodig heeft.

Dat heb ik niet uit zijn verhaal kunnen opmaken.

Je moet een bepaalde rol/recht hebben om te mogen zoeken, maar wat je vindt daar kunnen zaken tussen zitten die je niet mag zien. Bijv een verkoopmedewerker die (nog) niet de nieuwe artikelen waar nog geen definitieve verkoopprijs aan hangt mag zien in zijn zoekresultaat.

imho een rotprobleem, waar ik zelf ook al eens mee geworsteld heb in een HRM omgeving. Daar heb ik toen gekozen om de DAO methodes bewust te maken van de rol van de ingelogde werknemer. Een normale werknemer krijgt altijd alleen zichzelf terug bij een zoekWerknemers aanroep, een afdelingshoofd alleen de werknemers van de betreffende afdeling en de PenO medewerker krijgt alle werknemers terug. Niet echt de meest elegante oplossing, maar in die situatie afdoende.

Volgens mij ga je hoe dan ook je business, dao of view logica vervuilen als je dit af moet dwingen. Lastige keuze...

Wat je zou kunnen doen is aan een Role een ViewFilter te hangen waarin je kan coordineren welke resultaten hij zou mogen zien. Je kan dan je dao de user object laten navragen (die misschien in een threadlocal zit) naar de viewfilter. Op die manier kan de dao dus beslissinge nemen over de velden die zichtbaar gemaakt mogen worden, maar zonder dat de dao is besmet met allerlei role specifieke zaken.

[ Voor 3% gewijzigd door Alarmnummer op 27-12-2004 10:49 ]

[Antediluvian]

zneek schreef op maandag 27 december 2004 @ 10:34:
Probleem van de TS is volgens mij niet dat ie de functie niet weet af te schermen, maar dat het resultaat wat terug komt een extra security slag nodig heeft. Je moet een bepaalde rol/recht hebben om te mogen zoeken, maar wat je vindt daar kunnen zaken tussen zitten die je niet mag zien. Bijv een verkoopmedewerker die (nog) niet de nieuwe artikelen waar nog geen definitieve verkoopprijs aan hangt mag zien in zijn zoekresultaat.

Het probleem is idd niet van een technische maar van een conceptuele aard.
Waar de security rules checken en toepassen zonder dat security gedecentraliseerd wordt?
De algemene rules zijn makkelijke aangezien dit het parsen van enkele policies zijn. Als rules betrekking hebben tot een product (tabel ProductRule) dan stijgt het aantal te controleren policies enorm.

Stel:
User U, die lid van UserGroep UG1 en UG2, vraagt een lijst op waar de verkoopprijs zichtbaar is.
We hebben reeds 3 security entities en 2 rules (view product & view product sell price)
Die lijst die user U opvraag van bevat 1200 producten die verspreid zijn over 30 groepen.

Het aantal te controleren Permissions zijn in dit geval:
3x2x1230 = 7380 Help

Is dit ongeveer wat je bedoelt, Alarmnummer:


Volgens mij kan dit inderdaad een goeie oplossing zijn aangezien de search engine de mogelijk heeft om de query te optimaliseren. Echter, zoals in Oplossing 3, heeft bij deze oplossing de klassen die verantwoordelijk zijn voor de search nog altijd kennis nodig over security en hoe deze is opgebouwd.

Alarmnummer schreef op maandag 27 december 2004 @ 09:06:
En heb je verder al gekeken naar het optimaliseren van de searchqueue zelf? Ik weet niet welke database je gebruikt, maar je zou anders de tabel waarover je een textsearch doet kunnen indexeren. Dit scheelt al enorm in de kosten van de query.

De Product Tabel krijgt uiteraard een speciaal geïndexeerd veld waar alle velden, waarop fulltext search mogelijk moet zijn, worden samengevoegd tot 1 string.

[ Voor 14% gewijzigd door Antediluvian op 27-12-2004 11:35 . Reden: Typo + voorbeeld ]

[Alarmnummer]

Antediluvian schreef op maandag 27 december 2004 @ 11:17:
[...]
Is dit ongeveer wat je bedoelt, Alarmnummer:
[afbeelding]

Volgens mij kan dit inderdaad een goeie oplossing zijn aangezien de search engine de mogelijk heeft om de query te optimaliseren. Echter, zoals in Oplossing 3, heeft bij deze oplossing de klassen die verantwoordelijk zijn voor de search nog altijd kennis nodig over security en hoe deze is opgebouwd.

Ik heb 2 oplossingen gegeven: een met de doa die een filter toepast en een met de security op die service. Uit jouw verhaal op te maken wil jij puur een filter.

schets:

code:

ProductDao{
     List search(String productInfo){
           List foundProducts = mooieDatabase.findAllProducten(productInfo);
           ProductFilter filter =  getRoleFromThreadLocal().getProductFilter();
           return filter.doFilter(foundProducts);
     }

      private List apply(List productList, ProductFilter filter){
         List result = new List();
         forearch(Product product in productList){
             if(filter.allows(pruduct)  result.add(product);
         }
         return result;
      }
}

interface ProductFilter{
     boolean allows(Product p);
}

class BlaProductFilter implements ProductFilter{
     boolean allows(Product p){
          return p.getName().contains("bla);
     }
}

interface Role{
     ProductFilter getProductFilter();
}

class BlaRole implements Role{
     ProductFilter getProductFilter(){return new BlaProductFilter());
}

Op deze manier kan je per role een aparte ProductFilter er aan hangen en de dao die past alleen maar de gevonden filter toe, zonder rekening te houden met hoe die filter er aan de binnenkant uit ziet.

Ik weet trouwens niet of dit de meest heldere oplossing is, maar het is er wel een Het voordeel van deze aanpak is dat je alles bij de roles hebt afgevangen en dat hele aspect dus kunt centraliseren ipv dat het versnipperd over je hele systeem ligt.

[ Voor 13% gewijzigd door Alarmnummer op 27-12-2004 11:42 ]

[Antediluvian]

Maar dan moet er per role een implementatie geschreven worden van ProductFilter. Aangezien een user verschillende roles kan vervullen (lid van meerdere usergroeps) en op zichzelf een unieke role vervult is dit niet mogelijk.

[Antediluvian]

Ik kan ook de security engine alle ProductPolicies van een bepaalde user voor alle producten laten ophalen maar aangezien er wellicht meer dan 20 ProductRules zullen zijn en +30k producten kan dit een vrij grote en onwerkbare lijst worden.
Dit onwerkbaar ken ik niet uit ondervinding maar dit geeft mijn gevoel vertelt mij dit, is mijn gevoel juist of niet?

[Stephan Oudmaijer]

als je toch Spring gebruikt dan doe je je security toch "gewoon" met aspects?

[zneek]

Als ik het nu zo terug lees zie ik 1 belangrijke denkfout: je moet je ontwerp niet beginnen met performance in je hoofd. Wat is belangrijker? Dat dat zoekresultaat er binnen 1 seconde staat? Of dat het 100% kloppend is met de rechten die de gebruiker heeft? Performance problemen zijn (meestal) ook op een andere manier op te lossen: meer schijfruimte, snellere proc, meer procs, meer geheugen, clustering.

Ik denk dat je primair moet kijken naar de manier om met een zo correct mogelijk ontwerp de specificaties te implementeren. Dan denk ik dat je op 2 plekken security moet toevoegen: op service niveau en als filter over bijv producten.

Zoals je zelf ook al zegt:

Antediluvian schreef op maandag 27 december 2004 @ 11:55:
Ik kan ook de security engine alle ProductPolicies van een bepaalde user voor alle producten laten ophalen maar aangezien er wellicht meer dan 20 ProductRules zullen zijn en +30k producten kan dit een vrij grote en onwerkbare lijst worden.
Dit onwerkbaar ken ik niet uit ondervinding maar dit geeft mijn gevoel vertelt mij dit, is mijn gevoel juist of niet?

Je weet het niet. Testen en uitproberen geeft je uitsluitsel. Met die testresultaten in je hand kun je altijd nog met de opdrachtgever in overleg om te bepalen wat belangrijker is: snelheid of correctheid.

[PhoneTech]

Ik ben momenteel ook bezig een role based security te implementeren. We volgen hierbij een deel van het RBAC model. Soort gelijke opzet als in de TS beschreven. Per object tabel, worden 2 access tabellen bijgehouden. eentje voor de rollen, en eentje voor de users aangezien users ook indivuele rechten heeft op een object.

Snelheid is geen pre, want dat kan altijd opgelost worden. Het beveiligingsmodel moet ongeveer wel waterdicht zijn.

Ik gebruik een CMP 2.0 voor persistence met 1-n relateis naar de access tabellen. Is het verstandig om via de EJB QL de access te regelen?

[Antediluvian]

zneek, je hebt wellicht volledig gelijk ivm die performance maar wat is volgens jullie de "beste" plaats op security te gebruiken?
1. Een aparte layer tussen BL en DAO om zo security af te dwingen
2. Een Aparte Engine die na DAO security toepast
3. Security verwerken in de DAO
4. Security verwerken in de BL
5. ???

Opmerkingen:
1. security is goed gecentraliseerd maar moet wel weten welke manieren van data access de BL nodig heeft. Dubbel werk dus. Een bepaalde DB request moet dus in de security layer en in de DAO layer aanwezig zijn.

2. security is goed gecentraliseerd maar als er in de BL na het verkrijgen van de data vergeten wordt de security engine zijn werk te laten doen dan is het security aspect volledig omzeild.

3. security is gedecentraliseerd dus moeilijk te onderhouden. Echter heeft de DAO layer alles "kennis" om de security rules goed toe te passen. (DAO heeft kennis van de Data object en van de DB)

4. gedecentraliseerd en makkelijk "vergeten" worden. Dit is volgens mij de slechtste manier.

5. misschien zijn er andere oplossingen waar ik niet aan denk.

[Alarmnummer]

Antediluvian schreef op maandag 27 december 2004 @ 21:40:
zneek, je hebt wellicht volledig gelijk ivm die performance maar wat is volgens jullie de "beste" plaats op security te gebruiken?

Het is gebruikelijk om dit in de service layer op te lossen. De service layer is de bovenste layer van je domein layer. (Dus zit boven je business logic/domein objecten) en in het geval van een applicatie met een webinterface zit het onder de weblayer.

Check verder Patterns of Enterprise Architecture van Martin fowler: Service Layer (je kunt op zijn site wel uitleg over dit pattern krijgen).


Maar nogmaals. ik zou het echt koppelen aan roles. Eventeel alle filters van de roles (als er meerdere toepasbaar zijn) gebruiken. Dus als product a voldoet aan filter van role1 of van filter van role2 of van... dan mag het meegenomen worden in het resultaat.

[ Voor 18% gewijzigd door Alarmnummer op 27-12-2004 22:20 ]

[zneek]

Ik denk dat Alarmnummer helemaal gelijk heeft. Als je niet kijkt naar performance dan is een soort van wrapper die de security doet om je service laag het best. Je hebt nergens in je applicatie "last" van security. Heel simpel gezegd: je DAO heeft in feite niets te schaften met security, die moet zich alleen druk maken om het persisten en vinden van je entity objecten.

Ik twijfel in dit verhaal echter aan 2 dingen:

1. hoe dwing je toegangsrechten af (in de zin van een menu optie niet tonen als iemand geen recht er toe heeft, of bij een product geen verwijder knop als de gebruiker dat niet mag)
2. Hoe ga je om met berekeningen die afhankelijk zijn van de rechten van de gebruiker, zoals bijvoorbeeld een optelling van alle in het systeem aanwezige producten (die bijvoorbeeld wijzigbaar zijn voor de gebruiker )

[Kwistnix]

Is AspectJ hier niet bij uitstek geschikt voor?
Security implementeren a.h.v. AOP lijkt mij een aardige oplossing.

[Antediluvian]

Ik ben niet zo vertrouwd met AOP maar ik zal het zeker komende dagen bekijken.
Heb je eventueel een aantal links met wat mooi leesvoer over dit onderwerp?

[Alarmnummer]

Antediluvian schreef op dinsdag 28 december 2004 @ 02:06:
Ik ben niet zo vertrouwd met AOP maar ik zal het zeker komende dagen bekijken.
Heb je eventueel een aantal links met wat mooi leesvoer over dit onderwerp?

Je moet niet gaan pielen met AspectJ of andere AOP talen die een superset zijn van de Java taal. Het probleem eraan is dat het dus geen normale Java meer is.

Als ik je iets kan aanraden is het Spring. Spring kan oa ook mbv AOP functionaliteit toevoegen, oa security. Spring = lijm, dus je hoeft niet bang te zijn api`s op te geven. Spring maakt het alleen makkelijker om die api`s te gebruiken.,

[edit]
Misschien valt een gedeelte van wat iemand mag zien ook gewoon mee te geven als parameter aan de db query.

select product from product,managerwhere manager.id = javaObjectManager.getId()

[ Voor 14% gewijzigd door Alarmnummer op 28-12-2004 09:02 ]

[Stephan Oudmaijer]

spring heeft een AOP framework, je kan dus gewoon de AOP van spring gebruiken.

[Verwijderd]

Ik kick dit topic even omhoog, ik zit met een identiek soort probleem. Heeft de topicstarter nog een oplossing kunnen vinden voor zijn probleem, en wat was de uitkomst daarvan?

[Antediluvian]

Momenteel ben ik Spring aan het leren. Ik ben nog niet toegekomen aan het AOP gedeelte maar ik hoop een galante oplossing te vinden.

Ik heb ook reeds een blik geworpen op JAAS maar heb nog niet kunnen ingaan op de details hiervan.

acegisecurity (security framework voor spring) ziet er ook intressant uit. Ik ga zo snel mogelijk bekijken wat het allemaal kan.

Vooral deze key feature intresseert mij:

# Keeps your objects free of security code: Many applications need to secure data at the bean level based on any combination of parameters (user, time of day, authorities held, method being invoked, parameter on method being invoked....). This package gives you this flexibility without adding security code to your Spring business objects.

[ Voor 32% gewijzigd door Antediluvian op 01-04-2005 22:03 ]