[Alg] Rechtensysteem voor extranet *

[oZy]

Hoi, heb de search al uitgepluist maar het probleem is dat ik (bijna) alleen maar forum situtaties tegenkom, deze zijn niet van toepassing op mijn systeem.

Het betreft een extranet. We hebben gebruikers, groepen, en 'items' (zijnde pagina's, producten, nieuwsberichten, bestanden etc.)

Ik heb het systeem nu draaiende, maar, users kunnen maar tot 1 group behoren:

code:

| USERS   |                      | ACL      |
-----------     | GROUPS   |     -----------|
| ID      |     ------------     | ID       |
| GroupID | <-> | ID       | <-> | GroupID  |
| Naam etc|     | Naam etc |     | ItemType |
-----------     ------------     | ItemID   |
                                 ------------

verder heb ik vanzelfsprekend een ItemTypes tabel met type id en type naam, en voor ieder itemtype een tabel met daarin de items zelf.

Wat ik nu dus kan doen is groepen toegang geven op verschillende niveau's. Voorbeeld: we hebben een [pagina] met een [product]enoverzicht. Aan deze [producten] zijn [bestanden] gekoppeld (prijslijst.xls, handleiding.pdf, firmware.zip etc).

Nu kan ik dus group 1 geen toegang geven tot [pagina], wat als gevolg heeft dat de users in deze group de rest ook niet te zien krijgen. Group 2 heeft wel toegang, en ziet het productenoverzicht, maar alleen de producten waar group 2 rechten op heeft, onder andere [product 3].

Group 3 heeft ook toegang tot aan [product 3], en ook toegang tot [betand 4]. Dit bestand is gekoppeld aan product 3, dus wordt zichtbaar op de product pagina. Group 2 heeft geen toegang tot [bestand 4] maar wel tot [bestand 7], en uiteraard zien de users van group 2 bestand 4 niet, maar 7 wel.

Dit systeem werkt prima omdat het ook zo is ingericht dat groepen standaard nergeens toegang toe hebben, tenzij dat ingesteld wordt, je kunt dus tot op 3 niveaus diep user afhankelijke content maken.

Je moet de groepen dus helemaal uit 'normaliseren', bijvoorbeeld group 2 heet "LeverancierJanssenTechnischCommercieel", dit houdt in dat group 2 dus alle pagina's kan zien die voor alle leveranciers van toepassing zijn, met bestanden voor firma Janssen, aangezien het technische mensen zijn krijgen ze de mogelijkheid firmwares te downloaden en ze zijn ook commercieel dus kunnen ze ook de prijslijst voor firma janssen downloaden.

Tot zover nog geen probleem.. maar denk er nu even 5000 gebruikers bij. Je kunt, door de groepnormalisatie geen grote groepen maken, dus heb je ongeveer 1000 groepen. Als je nu een nieuw bestand upload, en je wilt de rechten gaan instellen moet je dus alle 1000 groepen doorspitten om deze toegangsrechten in te stellen.

Wat makkelijker zou zijn:
Group: Janssen
GroupKenmerk: Leverancier
User: Piet
UserKenmerk: Technisch
UserKenmerk: Commercieel

Je krijgt dan extra tabellen: [Groepen], [GroepKenmerken], [KruisGroepenGroepkenmerken], [Users], [Userkenmerken], [KruisUsersUserkenmerken].

Maar het probleem bij dit systeem is....... HOE moet ik de rechten nu instellen / ophalen?

Ik kan bijvoorbeeld toegang geven aan [group = janssen], [userkenmerk = technisch], [userkenmerk = commercieel], maar dan zouden ook de commerciele mensen van firma Pietersen toegang hebben. Ik moet dus een soort van access rules gaan maken met verschillende combinaties..:

rule 1: WHERE group = janssen AND groupkenmerk = technisch AND groupkenmerk = commercieel
rule 2: WHERE groupkenmerk = dealers AND groupkenmerk = commercieel
rule 3: WHERE groupkenmerk = administrators

Als een gebruiker dan voldoet aan 1 van de rules voor een item, dan krijgt hij toegang..

Poeh.. ik ben al een stuk verder door deze post alleen maar te maken maar hoe ga ik het maken van die rules nou oplossen in het CMS.. standaard heeft niemand toegang tot een item, geef je aan dat groupkenmerk 'leverancier' wel toegang heeft, dan kunnen alle gebruikers die dat kenmerk hebben het item zien. BEHALVE als je óók aangeeft dat ook userkenmerk 'technisch' nodig is.

Nou wat is eigenlijk mijn vraag.. hoe zou jij dit oplossen in een CMS qua GUI, en dan moet ik nog maar eens kijken of ik die 'getuserrights' query inelkaar kan flansen. Wellicht een veel beter idee voor een rechtensysteem in een situatie als deze? Bedankt voor je aandacht in ieder geval

[EfBe]

Een heel verhaal maar je begrijpt het niet.

Rechtensystemen zijn bedoeld om een USER rechten te geven op een RESOURCE. Welnu, je doet dat door normaliter een tabel AccessRight te definieren (ACL in jouw geval) en een tabel User voor de users. Die hebben dan geen relatie met elkaar, die loopt VIA een resource. Dus de relatie User-AccessRight-Resource is een nieuwe relatie, die moet je dus vastleggen in een tabel. Dit zou dan opleveren UserAccessRightResource met 3 velden: UserID, AccessRightID en ResourceID (noem maar iets).

Dit wordt vrij vervelend bij veel resources en veel users, immers voor 20 users met ieder 4 rechten op 20 resources ben je 20x5x20 rows aan het aanmaken.

Wat heeft men toen bedacht? Men kan de rechten voor een user op een resource bepalen door te kijken of een GROUP (of Role, zelfde idee) access rights heeft op die resources en of de user in die group zit, m.a.w.: de rechten van een USER hangen af van de rechten gedefinieerd op de GROUPS waar de user in zit.

Men introduceert dus de relatie: Group-AccessRight-Resource
Daarnaast de relatie: User - Group.

Users kunnen in meerdere groups zitten, verder gedraagt 'Group' zich zoals ik beschreven heb hierboven in User-AccessRight-Resource

Om nu te checken of User Piet leesrechten heeft op Resource Katja, kijk je of de Groups waar Piet in zit (SoapSterren, DrinkersAnonymous en BNers) accessrechten hebben op Katja. Zo ja dan heeft Piet dat ook want hij zit in die groups.

Indien je hier geen moer van snapt, volgende halte: Role based security zoeken bij google.

[ATS]

Je eerste opzet is, zoals je zelf al concludeerde, niet voldoende. Het is gewoon niet flexibel genoeg. Ik denk dat je het beste kan gaan denken over een systeem hierarchische groepen. Dat wil zeggen: gebruikers kunnen lid zijn van een groep, en groepen kunnen ook lid zijn van een andere groep. Bovendien kunnen gebruikers en groepen lid zijn van méér dan één groep. De accessrights voor je Items zou ik ook many-to-many maken, zodat groepen toegang kunnen hebben tot meerdere items, en meerdere groepen tot een item.

Het is complex om in één keer te achterhalen of een gebruiker rechten heeft in een dergelijk systeem (vooral door de groepen die lid kunnen zijn van groepen, dat kan je eventueel weglaten). Ik denk niet dat je dat met een enkele query lukt. De vraag is of dat nodig is. Je geeft niet aan in welke omgeving je werkt, maar php aannemende kan je een aardig eind komen door gewoon een handige class te bouwen met de de functionaliteit om een gebruiker voor een pagina te autoriseren.

Met bovenstaand systeem van groepen kan je situaties als die je beschreef vermijden. Bijvoorbeeld: je maakt een groep aan voor commercieel en een voor technisch personeel van de firma Janssen, en dat doe je ook voor de firma Pietersen. Nu maak je vier meta-groepen aan: een voor elk bedrijf, en een voor elke 'groep'. De commerciele groep van Janssen wordt nu lid van de groep voor geheel Janssen en van de groep van alle commercielen. Voor je pagina's kan je nu eenvoudig aangeven wie er toegang toe heeft:
-Personeel van Pietersen? -> groep Pietersen toegang geven
-commercieel personeel van elke firma? -> groep Commercieel toegang geven
-technisch personeel van Janssen en Pietersen, maar niet van Geerdsen? -> alleen toegang geven aan die specifieke firma's
etc.

Je kan het ook anders oplossen:
-zorg dat gebruikers lid kunnen zijn van meer dan één groep, en maak groepen aan voor personeels-soorten en voor firma's.
-in plaats van een eenvoudige koppeling tussen groepen en items, maak je criteria die meer dan één groep kunnen bevatten. Gebruikers moeten dan lid zijn van al deze groepen om bij het item te mogen, waarbij er natuurlijk meer dan één criterium per item kan zijn. Binnen een criterium heb je dus een AND voorwaarde, tussen criteria een OR voorwaarde.
In feite verschuif je de complexiteit van de hierarchische groepen naar de toegangsregels. Het is maar net wat je handiger vindt...

[curry684]

_{Topictitel even enorm ontschreeuwd...}

[oZy]

EfBe: Sorry maar wat jij nu beweert is eigenlijk precies hetzelfde als wat ik zei:

code:

Wat ik had:   Users < - > Groups < - > ACL          < - > Items
Wat jij zegt: Users < - > Groups < - > AccessRights < - > Resources

Alleen de benaming is wat anders.

Het probleem is:

Om nu te checken of User Piet leesrechten heeft op Resource Katja, kijk je of de Groups waar Piet in zit (SoapSterren, DrinkersAnonymous en BNers) accessrechten hebben op Katja. Zo ja dan heeft Piet dat ook want hij zit in die groups

Hoe wil je nu onderscheid maken tussen een resource Katja waar je in 1 van de 3 genoemde groepen moet zitten, en tussen een resource Katja waar je in alle 3 de genoemde groepen moet zitten, wil je er toegang tot krijgen? Dat lukt niet in deze oplossing.

ATS: De hierarchische oplossing die jij aankaart spreekt me zeker aan, die ga ik nu even uitwerken en testen. Hier kom ik nog op terug dus, bedankt!

curry684: sorry, was niet schreeuwerig bedoeld

[EfBe]

Nee het is helemaal niet hetzelfde als wat jij zei. Jij hebt een 1:n relatie met groups maar dat is een m:n relatie en de relatie group - AccessRights is er ook niet, die is Group-AccessRight-Resource, dat is OOK wat anders.

IEDER rechtensysteem is bedoeld voor de toetsing of een individueel object (bv een user) rechten heeft op een ander object (bv page). Dat er groepen/roles in welke hoedanigheid dan ook worden gebruikt is leuk, maar dat is alleen bedoeld voor beheer.

Hoe wil je nu onderscheid maken tussen een resource Katja waar je in 1 van de 3 genoemde groepen moet zitten, en tussen een resource Katja waar je in alle 3 de genoemde groepen moet zitten, wil je er toegang tot krijgen? Dat lukt niet in deze oplossing.

Zoals ik al zei, je snapt er niks van, sorry. Zo moet je niet met je rechten omgaan. Je moet rechten definieren als "Lezen", "Schrijven", "Verwijderen" etc. Welnu, het is totaal tegen de filosofie van role based security om dingen te willen als "je moet in alle 3 de groepen zitten". Dan snap je niet waar die groepen voor zijn. Wil je dat? Maak een nieuwe groep aan, KatjaUsers en geeft die groep "Lezen" en "Schrijven". Voeg de users toe die DIE rechten moeten hebben op Katja aan DIE groep toe.

Zo gebruik je role based security en de groups/roles die daarin worden gedefinieerd. Niet ook nog eens limieten op groups, want dan hebben die accessrights geen zin.

[djluc]

Egbe heeft gelijk met zijn tabelopzet, althans dat vind ik... Waar je rekening mee moet houden bij het plaatsen in meerdere groepen is de manier waarop je met de rechten om gaat, is het voldoende als 1 van de 2 groepen waar de gebruiker lid van is het recht heeft, of moeten ze dit beiden hebben? Waar je misschien eens naar zou moeten kijken is de mogelijkheid om + en - rechten te geven. Dus dingen die wel of net niet mogen. Dan kan je een user dus in een groep hangen die het recht heeft om te bewerken, maar kun je di individuele persoon toch dat recht ontnemen.

[oZy]

EfBe: Wat jij zegt schiet het doel compleet voorbij. Lezen? Schrijven? Verwijderen? Ik ben een 'virtuele catalogus' aan het maken, geen forum. Deze rechten hebben ook totaal geen toepassing in het CMS, dat heeft zijn eigen rechtensysteem. Het is heel simpel, en ik zal het even in jouw termen verwoorden:

Je hebt 2000 resources, en 5000 users. Een user kan, afhankelijk van zijn situatie, een resource [WEL / NIET] bekijken.

Waar gebruik ik mijn groups/roles voor? Om deze situaties zo overzichtelijk mogelijk in kaart te brengen, zodat je niet voor een resource 3000 gebruikers hoeft te selecteren om deze toegang te geven tot de betreffende resource.

Ik ben er al vrij zeker van dat ik de groepen hierarchisch in ga delen zoals ATS eerder opperde, dit werkt voor mij prima omdat je dan alles van [GroepMetAlleUsers] tot [GroepMetMaarEenUser] kunt uitspecificeren.

Het voordeel is dat het betrekkelijk simpel te programmeren is in het bestaande systeem, en dat het erg makkelijk is om rechten toe te kennen aan een resource (selecteer alle groepen uit een lijst die wel toegang hebben).

Nadeel is dat je nog steeds veel groepen overhoudt als je hele specifieke rechten aan iets wilt toekennen, maar dit zal niet vaak gebeuren. Dat heb je overigens zelf, als user, in de hand.

Het is trouwens een beetje flauw om steeds te roepen dat ik er niets van snap. Jij snapt niet wat ik bedoel. Dat wil niet gelijk zeggen dat ik niets van rechtensystemen weet.

[EfBe]

oZy schreef op 11 december 2003 @ 15:55:
EfBe: Wat jij zegt schiet het doel compleet voorbij. Lezen? Schrijven? Verwijderen? Ik ben een 'virtuele catalogus' aan het maken, geen forum. Deze rechten hebben ook totaal geen toepassing in het CMS, dat heeft zijn eigen rechtensysteem. Het is heel simpel, en ik zal het even in jouw termen verwoorden:

Role based security is uniform, het heeft niets te maken met de toepassing. User heeft recht X op resource R, gedefinieerd via de relaties user-group en group-right-resource. Of die resource een forum, een page, een file op disk of een auto buiten is, dat boeit niets.

Je hebt 2000 resources, en 5000 users. Een user kan, afhankelijk van zijn situatie, een resource [WEL / NIET] bekijken.

Waar gebruik ik mijn groups/roles voor? Om deze situaties zo overzichtelijk mogelijk in kaart te brengen, zodat je niet voor een resource 3000 gebruikers hoeft te selecteren om deze toegang te geven tot de betreffende resource.

Mja, ik heb dat al 3 keer gezegd geloof ik.

Ik ben er al vrij zeker van dat ik de groepen hierarchisch in ga delen zoals ATS eerder opperde, dit werkt voor mij prima omdat je dan alles van [GroepMetAlleUsers] tot [GroepMetMaarEenUser] kunt uitspecificeren.

Dat moet je dan maar doen, maar groepen in een hierarchische vorm gieten is alleen maar meer complexiteit toevoegen. Groepen zijn geen doel op zich, het zijn middelen om users met DEZELFDE rechten op (!) DEZELFDE resources te groeperen. Alleen DAN kun je spreken over een groep. Dit is niet te inheriten, want je kunt wel willen dat een groepje daarbinnen extra rechten heeft op dezelfde resource maar users BUITEN die initele groep kunnen dan ook weer in die groep plaatsnemen, wat resulteert in venndiagram nightmares. En dat terwijl het zo simpel is als koek. Een hierarchische groepenstructuur voor rechtenverdelingen is onnodige complexiteit.

Het voordeel is dat het betrekkelijk simpel te programmeren is in het bestaande systeem, en dat het erg makkelijk is om rechten toe te kennen aan een resource (selecteer alle groepen uit een lijst die wel toegang hebben).

Jij hebt maar 1 accessright? Of begrijp ik het verkeerd?

Nadeel is dat je nog steeds veel groepen overhoudt als je hele specifieke rechten aan iets wilt toekennen, maar dit zal niet vaak gebeuren. Dat heb je overigens zelf, als user, in de hand.

Ja en cycles in je hierarchie en horizontale inheritence. Veel plezier.

Het is trouwens een beetje flauw om steeds te roepen dat ik er niets van snap. Jij snapt niet wat ik bedoel. Dat wil niet gelijk zeggen dat ik niets van rechtensystemen weet.

Je snapt het ook niet, dat is niet erg, het wordt alleen een beetje vervelend als degene die het niet snapt dat niet wil horen en denkt dat ik het niet snap. Vind ik prima hoor, hou ik nou op met blaten en kun jij aan je overbodige hierarchie van groepen werken om er later achter te komen dat iedere andere role based security model dat niet heeft en met een reden: het klopt niet.

Group A heeft rechten 1 en 2 op resource R
Subgroup A' van A met 50% van de leden heeft dus rechten 1 en 2 en recht 3 op R.
A' is dus een nieuwe group. Piet wordt in A' geplaatst. Moet Piet ook in A zitten? (J/N)

Dit soort onzinnige toestanden krijg je nu voor je kiezen. En dat terwijl het onnodig is want je kunt A' ook als B definieren.

User U wil iets doen. U heeft een sessie. U's sessie bevat de groups van U. Je kijkt middels een centrale functie of U met zn groups recht X heeft op resource R. Die centrale functie zegt "J" of "N". Indien "J", ga je door, indien "N" dan ga je niet door.

Omdat alles in de database zit kun je gewoon dit querien. Ik wil jouw queries met je hierarchien wel eens zien.

Maar zoals gezegd, het is heel simpel, het is al 10.000 keer gedaan, zoek gewoon op Role based security (volgens mij heb ik het hier ook al 10 keer uitgelegd op dit forum) op google.

Edit: je zit ook vast in je hierarchische pagina handel. Dat zijn verschillende resources. Je rechten/groepenstructuur hoeft daar totaal niet mee overeen te komen, immers de hierarchie is in de resources, niet in de rechten. Op XP of Linux kun je ook geen subdir lezen als je de parentdir's inhoud niet kunt lezen. Hetis dus al onnodig om rekening te houden met "Japie mag de page niet zien maar wel bestandje 2 diep in de krochten van die page die hij niet mag zien. Hij mag de page niet zien, dus ook de content niet.

Ergens rechten op willen definieren vereist een interpretatieslag van die rechten. Omdat je page renderer daar gebruik van moet maken kun je (moet je zelfs) je rechtensysteem daarin aanroepen, top down.

Vergeet overigens niet dat een resource R op page 1 niet te zien hoeft te zijn, maar op page 2 weer wel (kan). Een resource' rechten dan laten afhangn van de page waar deze inzit lijkt me niet zo wenselijk.

[ Voor 12% gewijzigd door EfBe op 11-12-2003 16:53 ]

[oZy]

EfBe: Nogmaals, miscommunicatie. Ik snap wat role based security inhoud, maar ik kan maar geen voorbeeld vinden waarom een RBS model hier uitkomst zal bieden.

In principe is mijn huidige model ook al een RBS model, ik noemde het alleen niet zo. Laten we even als uitgangspunt dit voorbeeld nemen. In mijn geval zal ik dus de tabellen enigzins anders in moeten delen:

code:

| users |          | profiles |          | groups |        
---------          |----------|          |--------|        
| ID    |  n -> 1  | ID       |  1 -> n  | ID     | -\     
| Naam  |          | Naam     |   \      | Naam   |   \    
| Etc.  |          | Etc.     |    \     ----------    \   
---------          ------------     \                   \  
                                     \      | roles |    \ 
                                      \     ---------     \
                                       -> n | pID   |     /
                                            | gID   | n <- 
                                            ---------

De profiles tabel is dus puur om de users die dezelfde rechten hebben te kunnen groeperen, onder een leesbare naam, in plaats van een lijst rechten combinaties. Ik kan me alleen niet voorstellen hoe ik dit gebruikersvriendelijk kan verwerken in de GUI. Bijkomend probleem (volgens mij) is dat de in dit systeem benoemde 'groups', algemene functies bevatten. read, modify, write, delete,.. ik heb geen rechten op acties, maar op items. Als je read rechten hebt zou je dus alles mogen zien? Hoe wou je aangeven dat je alleen op bestand xyz.zip die rechten hebt? Dat is mij niet geheel duidelijk.

Met het hierarchische model lukt dat me echter wel. Dat ziet er als volgt uit:

code:

| users |           | profiles |          | ACL    |      
---------           |----------|          |--------|      
| ID    |     /-> 1 | ID       |  n -> n  | PrfID  |      
| PrfID | n -/      | ParentID |          | ItemID | n <-\
| Etc.  |           | Etc.     |          ----------     |
---------           ------------                        / 
                                     | items |         /  
                                     ---------        /   
                                     | ID    | n ----/    
                                     | Etc.  |            
                                     ---------

Ik sta nog steeds open voor suggesties, en call me stupid, maar het laatste model vind ik nog steeds veel beter bij mijn situatie passen omdat het goed beheersbaar is, makkelijk op te lossen qua GUI en overzichtelijk voor gebruiker.