[Alg] Rechtenbeheer, hoe het datamodel te doen?

[alienfruit]

Als jullie waarschijnlijk al reeds weten ben ik zelf niet zo'n ster in het maken van datamodellen en daarom zou graag jullie meningen willen horen over wat ik tot nu heb bedacht.

Ik wil mijn beveiliging systematiek voor mijn simpele CMS op verschillende niveau willen bepalen, per repository, per folder, maar ook per item en/of gebruiker.

Nu had ik de volgende algemene rechten bedacht:

• Read (lees rechten)
• Write (schrijf/bewerk rechten)
• Localize (vertaal rechten)
• Delete (verwijder rechten)

De rechten wordt onderdeel verdeeld in de volgende delen namelijk:

• Gebruikers
• Groepen
• Rechtsgroepen

Bij het onderdeel gebruikers kunnen er verschillen rechtsgroepen worden bijv. Template Management, Folder Management, Permissions Management, Constraints Management. Elk van deze rechtsgroepen geven bepaalde activiteiten binnen het cms aan bijv. Folder Management wordt bedoeld de rechten voor het aanmaken/bewerken/verwijderen van mappen in de repository e.d.

De rechtsgroepen kunnen dan worden onderverdeeld onder gebruikers en/of groepen gebruikers. Oftewel vergelijkbaar met een role.

Vervolgens kun je dus opgeven of een gebruiker of een gehele gebruikersgroep bepaalde rechten heeft zoals bovengenoemd namelijk read, write, localize en delete.

Hiervoor heb ik het volgende datamodel bedacht:



Wat vinden jullie ervan?

[henkleerssen]

die rechtsgroepen vind ik zelf een beetje onzinnig.. maar hee das een kwestie van smaak.
Localize variabele? snap ik niet.
Verder ziet het er goed uit.

[Infinitive]

Je kan ook de diverse rechten eruit factoriseren: dus dat voor een bepaalde user/group en item een setje met rights kan definieëren.

Voor ideeën zou je eens op zoek kunnen gaan naar informatie omtrengt access control lists.

Administratief kan dat een hel zijn (in dit geval valt dit nog wel mee): dit leent zich aardig voor het facade design pattern: boven op de ACL definieer je een administratief laagje waar je de hoofdzaken/standaard zaken implementeerd wat administratief eenvoudiger is in gebruik.

[ Voor 3% gewijzigd door Infinitive op 14-07-2004 12:56 ]

[alienfruit]

Beheer technische kan het wel een hel zijn, maar dat is niet mijn probleem
Ik ben van plan om in iedergeval wel LDAP te ondersteunen, zodat onze vrienden de systembeheerders deze rechten kunnen instellen op een centraal punt. Denk dat ze dat wel leuk vinden.

Verder betekend het Localize-recht dus dat een gebruiker het recht heeft om een bestaande assets te vertalen, oftewel:

Je hebt verschillende repositories waarin alle assets in worden uitgesorteerd, zo kun je ook subrepositories maken die bijv. voor Nederlands, Engels zijn. Nu kun je zeggen dat Engels de "default" repository is en je kan dan vervolgens een asset overerven van de Engelse repository na de Nederlandse repository en wordt dan een local copy gemaakt van de Engelse asset.

Met rechtgroepen bedoel ik dus eigenlijk bepaalde "vaste" activiteiten in het cms, die kan koppelen aan bepaalde groepen en/of gebruikers. Met de bovenstaande rechten. oftewel of je een bepaalde groep gebruikers toestaat om templates te maken e.d.

[ Voor 15% gewijzigd door alienfruit op 14-07-2004 13:10 ]

[PrisonerOfPain]

Rights_assoc mist een group_id toch?

[alienfruit]

item_id kan een groep en of item zijn :):)

[JaQ]

alienfruit schreef op 14 juli 2004 @ 13:19:
item_id kan een groep en of item zijn :):)

lekkere sleutel krijg je dan... Ik bedoel: is een groep en een item functioneel hetzelfde? Zo nee, waarom delen ze dan dezelfde sequence (id). Of is een item stiekem een subtype van een groep (of andersom).

localize vind ik trouwens een beetje een raar "recht". Is localizeren niet een apparte functie waar je lees/schrijf etc. rechten op dient te hebben om dat te mogen?

Buiten deze 2 zaken om zie ik verder geen rare dingen. Wel weet ik dat je met de search een heleboel verschillende oplossingen kan vinden voor het gebruiker, rechten & groepen verhaal (om het maar eens zo te noemen). Misschien leuk om er daar eens wat van te bekijken en nog meer ideeën op te doen?

[alienfruit]

Localize recht heeft in het beginsel in mijn opinie dus lees/schrijf rechten al nodig, om zelf iets te kunnen vertalen en daarom heeft dit recht geen eigen lees/schrijf optie nodig. Ik heb natuurlijk al reeds de search geraadpleegd en zodoende kwam ik dus onder meer met het bovenstaande idee.

[ Voor 24% gewijzigd door alienfruit op 14-07-2004 14:49 ]

[Verwijderd]

Ben toevallig net een week begonnen met eenzelfde project, hele rechtensysteem omgooien, en het is een hel als je rekening moet houden met een interface

Maar ik heb het onderverdeeld in de volgende tables:

departments
roles
policies
policyconfig
users
permissions

Aan elke department hangen 1 of meerdere roles. Deze roles kun je dus hergebruiken. Aan een role hangt een policy, (een verzameling van permissions), die dus ook hebruikbaar is. Aan een role kan een of meerdere users hangen. En deze kunnen overrided permissions krijgen door een eigen policyconfig.

[PrisonerOfPain]

alienfruit schreef op 14 juli 2004 @ 14:48:
Localize recht heeft in het beginsel in mijn opinie dus lees/schrijf rechten al nodig, om zelf iets te kunnen vertalen en daarom heeft dit recht geen eigen lees/schrijf optie nodig. Ik heb natuurlijk al reeds de search geraadpleegd en zodoende kwam ik dus onder meer met het bovenstaande idee.

Dan moet je toch iemand (de juiste) rechten geven voor de localize module?

[alienfruit]

Ja.... Volg je effe niet hoor.

Gordijnstok, aha. Ik volg je "departments" niet helemaal, is dat vergelijkbaar met een module ofzo? Dus heb je bijv. een module templatesbeheer, gebruikersbeheer en je koppelt vervolgens er rechten aan.

[ Voor 76% gewijzigd door alienfruit op 14-07-2004 15:55 ]

[PrisonerOfPain]

alienfruit schreef op 14 juli 2004 @ 15:37:
Ja.... Volg je effe niet hoor.

Je geeft de vertaal groep lees en schrijf rechten op de 'vertaal-module'

[BurningSheep]

Jouw datamodel is hetzelfde als waar ik op uit kwam. Wat me niet duidelijk wordt uit het model is hoe de rights gekoppeld worden aan de objecten waarvoor deze gelden.

Enige waar ik eigenlijk commentaar op heb is de naamgeving, over het algemeen zijn tabelnamen in enkelvoud. Dus group en user ipv groups en users, voor groups_users_assoc zou ik iets nemen als membership. Rights_assoc is in feite de entiteit waarop een bepaald recht geld, dus dat zou ik entity noemen, maar dat is persoonlijke smaak. Verder zou ik het rights eerder permission noemen, maar dat is helemaal persoonlijk waarschijnlijk =]

Het nut van localize is me niet helemaal duidelijk, maar waarschijnlijk komt dat omdat er een deel van het datamodel mist? In feite is localize een combinatie van read en write, maar dan alleen voor bepaalde objecten.

[Verwijderd]

alienfruit schreef op 14 juli 2004 @ 15:37:
Ja.... Volg je effe niet hoor.

Gordijnstok, aha. Ik volg je "departments" niet helemaal, is dat vergelijkbaar met een module ofzo? Dus heb je bijv. een module templatesbeheer, gebruikersbeheer en je koppelt vervolgens er rechten aan.

Nee het is voor een CMS/DMS systeem bedoeld. Een department is een business unit van een bedrijf, dus bijvoorbeeld Marketing, Development etc.

Dus even een lijst van voorbeelden:

Departments:
Marketing, Development

Roles:
Author, Publisher, Approver

Policies:
Policy for Author, Policy for Approver

PolicyConfig: koppeltabel policies+permissions

User:
Jan, Kees, Miep, Toos

Permissions:
View,Add,Delete,Publish


Door deze rechtenstructuur kan ik elke department of role of user zijn eigen stuk binnen het cms geven om te beheren. Dus Marketing kan de marketing pagina beheren maar meer ook niet bijv.

[alienfruit]

Aha, bij kan dat in principe dus ook, omdat dus verschillende mappen of constraints hebt. Waarop je dus bijv. alleen specieke assets in kan maken, dus als de marketing afdeling alleen maar marketing relateerde dingen mag maken bijv. Marketing Release Page etc. Naja, dit is het idee iig. Dit is ook bedoeld voor een CMS van een klant en voor mijn eigen website en natuurlijk deels zelfstudie (WebDAV, LDAP e.d.)

Het idee wat ik heb is om alles dmv. SOAP, WebDAV, XML, XSD, XSLT e.d. af te handelen. Alleen jammer dat het in PHP moet, en niet magen in ASP.NET/C# (of Mono)

[ Voor 18% gewijzigd door alienfruit op 14-07-2004 16:28 ]

[Verwijderd]

Als je webDAV gebruikt, waar wil je XML/XSLT dan voor gebruiken? Voor zover ik weet stuurd MsOffice geen XML streams via webDAV

[alienfruit]

Voor het template gebeuren natuurlijk
Na langdurig intern overleg (met mijn persoonlijkheden ) ben uiteindelijk toch voor de combinatie XML/XSLT gegaan, het gemak en de standardisatie stonden toch wat hoger dan het gebruiken van een Template Engine. Die je in principe toch zelf weer moet bouwen en bedenken.

[Verwijderd]

Aangezie je het in PHP bouwt zou Smarty een hele goede kandidaat zijn

[MisterData]

XML/XSLT gebruik ik ook, het werkt erg relaxed en is sneller dan in PHP zelf geschreven template parsers (tenminste, dat is mijn ervaring)

[alienfruit]

Ja, maar ik ben ook van plan om een versie .NET/C# te maken. Omdat dat eigenlijk nog meer functionaliteit standaard heeft dan PHP en natuurlijk is C# veel leuker

[Verwijderd]

alienfruit schreef op 14 juli 2004 @ 22:01:
Ja, maar ik ben ook van plan om een versie .NET/C# te maken. Omdat dat eigenlijk nog meer functionaliteit standaard heeft dan PHP en natuurlijk is C# veel leuker

Als je je kunt redden met C# zou ik zeker voor C# kiezen. Applicaties als een CMS zijn zo mooi te onderhouden op OO niveau

[alienfruit]

Daarom gebruik ik dus C# ook liever dan PHP, gezien de betere OO ondersteuning Misschien anders nog Delphi.NET kunnen we er een Delphi.NET example/demo van maken

[TheRebell]

het model van de topicstarter en van Gordijnstok heeft wel wat weg van RBAC. Daar ben ik (toevalig?) ook een zeer uitgebreid CMS mee aan het maken (wat moet iedereen met die cms'en )

Ik heb de verdeling gemaakt:
• user
• role
• module
• operation
• privilege

[Verwijderd]

Ik heb eigenlijk gewoon wat uitgedacht waarvan ik wilde dat het flexibel zou zijn, en waarbij het mogelijk was om objecten en de rechten te specificeren op meerdere niveaus.

Aan de ene kant is het wel een verdomd slecht model uit usability oogpunt, want maak je klanten die er gebruik van gaan maken maar eens bewust van de structuur. Je moet er als gebruiker wel een keer mee werken om het door te krijgen maar dat is de prijs voor dergelijke mogelijkheden.

Wat iedereen toch met CMS'en heeft? Tja, het is nu mijn, 4de CMS systeem, en elke keer probeer je nieuwe zaken toe te voegen of dingen te verbeteren waarbij je niet tevreden was in de vorige versie. Het huidige project is nogal ambitieus vergeleken met de vorige versies, alhoewel het vordert zie ik het voorlopig nog niet afkomen, daarvoor gaat er teveel in aan functionaliteit

Ik loop ook tegen een hoop complexe zaken aan met de interface. Zoals treeviews, icm meerdere departments. Bij mij kan een user maximaal 1 rol vervullen in een department, maar de user kan wel in meerdere departments onderverdeeld zijn. Ik moet dus tijdens de login procedure de gebruiker een domain en een department laten kiezen, daar een department een eigen startpunt kan krijgen in een treeview. Als ik 2 departments heb waar de user toegang in heeft krijg je dus conflicten in de treeview, want wat wordt nu de start node? Dat soort zaken zijn dus oorzaak en gevolg van dergelijke rechtenstructuren.

Dan hebben we het nog niet eens over versiebeheer+rechten, content stores+rechten, templates+rechten, placeholders+rechten, workflow+rechten, etc.

Een uitgebreid rechten systeem is denk ik het meest complexe wat je kunt hebben in een applicatie. Oppervlakkig lijkt het altijd maar een setje van permissies, maar diep in het systeem wordt het verweven, en in je achterhoofd moet je ook een presentatielaag onthouden die daarop kan inspringen.

[ Voor 42% gewijzigd door Verwijderd op 14-07-2004 23:30 ]

[TheRebell]

Verwijderd schreef op 14 juli 2004 @ 23:05:
Aan de ene kant is het wel een verdomd slecht model uit usability oogpunt, want maak je klanten die er gebruik van gaan maken maar eens bewust van de structuur. Je moet er als gebruiker wel een keer mee werken om het door te krijgen maar dat is de prijs voor dergelijke mogelijkheden.

je kunt je klant toch vertellen dan ie in een (of meerdere) departementen zit waarin hij/zij een rol (= functie) vervult. Op zon manier snappen ze het denk ik wel (hier dan tenminste wel)

Wat iedereen toch met CMS'en heeft? Tja, het is nu mijn, 4de CMS systeem, en elke keer probeer je nieuwe zaken toe te voegen of dingen te verbeteren waarbij je niet tevreden was in de vorige versie. Het huidige project is nogal ambitieus vergeleken met de vorige versies, alhoewel het vordert zie ik het voorlopig nog niet afkomen, daarvoor gaat er teveel in aan functionaliteit

hey dat ken ik

Ik loop ook tegen een hoop complexe zaken aan met de interface. Zoals treeviews, icm meerdere departments. Bij mij kan een user maximaal 1 rol vervullen in een department, maar de user kan wel in meerdere departments onderverdeeld zijn. Ik moet dus tijdens de login procedure de gebruiker een domain en een department laten kiezen, daar een department een eigen startpunt kan krijgen in een treeview. Als ik 2 departments heb waar de user toegang in heeft krijg je dus conflicten in de treeview, want wat wordt nu de start node? Dat soort zaken zijn dus oorzaak en gevolg van dergelijke rechtenstructuren.

Waarom maak je het niet zo dat een user een rol heeft. Binnen een departement kan hij dat max 1 rol aannemen. Je kunt dan op basis van de rollen (uit bv 2 departementen) ervoor zorgen dat de permissies niet conflicteren. Qua startnode maakt het niet zo heel veel uit toch? (ken verder je app niet natuurlijk dus..)
Misschien kun je twee nodes als beginpunt nemen of een algemene startnode weer deze twee nodes onder vallen?

Een uitgebreid rechten systeem is denk ik het meest complexe wat je kunt hebben in een applicatie. Oppervlakkig lijkt het altijd maar een setje van permissies, maar diep in het systeem wordt het verweven, en in je achterhoofd moet je ook een presentatielaag onthouden die daarop kan inspringen.

true, true. Je moet erg goed nadenken over de architectuur. Daarom probeer ik meestal wat bestaande modellen te gebruiken. Je presentatielaag kun je misschien onderverdelen in permissies, users, rollen en departementen. Dan kun je daar best iets duidelijks en overzichtelijks me doen lijkt mij

[alienfruit]

Ja, zelf is dit ook mijn derde CMS, alleen nu wilde de klant iets vergelijkbaars qua functionaliteit als je ziet in de ECMS. Als eerste wordt ik daar niet echt vrolijk van Ten tweede is het verschrikkelijk vele werk, waarom nemen ze niet een Interwoven of Vignette, maar ja als men geld heeft I won't say no Altijd leuk die multinationals

Ik heb momenteel eerlijk gezegd nog niet gekeken naar de interfaces, maar een treeview lijkt me wel handig. Hoorde alleen dat daar wel wat problemen mee zijn in Firefox en IE. Iemand? Naja, ik ga morgen nog eventjes verder met me ideen op papier zetten. Als iemand interesse heeft om er eens na te kijken, dan hoor ik het wel (mailadres staat in me profiel).

[TheRebell]

[slightly-offtopic]
Wat voor soort treeview had je in gedachten dan? Heb zelf ook zoiets en er geen problemen mee
[/]

ben wel benieuwd naar je ideen eigenlijk. Altijd interessant om de vreemde hersenkronkels van een ander te zien

[Verwijderd]

Ik gebruik gewoon mijn eigen treeview, en die werkt crossbrowser (lees browsers die xmlHttp ondersteunen) en is opgebouwd met xhtml+css

http://www.mschopman.demon.nl/treeview/treeview.html

Dit is nog de basis versie, de verdere versie zit al in het cms.

[Verwijderd]

TheRebell schreef op 15 juli 2004 @ 00:28:
je kunt je klant toch vertellen dan ie in een (of meerdere) departementen zit waarin hij/zij een rol (= functie) vervult. Op zon manier snappen ze het denk ik wel (hier dan tenminste wel)

Vertellen kan altijd, maar de vorige versies van het CMS waren zo gebruiksvriendelijke dat het aantal support telefoontjes echt heel minimaal waren. Dat wil ik graag een beetje zo houden

Het gaat er vaak het ene oor in en het andere oor uit.

Waarom maak je het niet zo dat een user een rol heeft. Binnen een departement kan hij dat max 1 rol aannemen. Je kunt dan op basis van de rollen (uit bv 2 departementen) ervoor zorgen dat de permissies niet conflicteren. Qua startnode maakt het niet zo heel veel uit toch? (ken verder je app niet natuurlijk dus..)
Misschien kun je twee nodes als beginpunt nemen of een algemene startnode weer deze twee nodes onder vallen?

Helaas wel, als ik op department A op niveau 1 rechten geef, en department B op niveau 2 onder het niveau van A rechten geef, dan krijgt department B alsnog department A rechten te zien terwijl je dat niet wil hebben.

Zelfde met approval, want wie zijn nu de approvers van een content element? Approvers binnen department A? Of department B? Of allebei? .. dat is niet echt handig

true, true. Je moet erg goed nadenken over de architectuur. Daarom probeer ik meestal wat bestaande modellen te gebruiken. Je presentatielaag kun je misschien onderverdelen in permissies, users, rollen en departementen. Dan kun je daar best iets duidelijks en overzichtelijks me doen lijkt mij

De complexiteit ligt hem niet in de rechten, maar vooral in het toepassen van die rechten in de onderdelen van je applicaties, en het alsnog begrijpelijk te houden voor de gebruikers, want je krijgt ongetwijfeld vragen als "waarom kan ik zus niet" "waarom kan ik zo niet" "waar is mijn artikel gebleven" etc.

Het eerste wat ze doen is niet de bijgeleverde handleiding openvouwen, maar direct naar customer support bellen. Ik denk dat ik een gedeelte al kan afvangen door de applicatie samen te laten werken met de handleiding

[ Voor 4% gewijzigd door Verwijderd op 15-07-2004 09:40 ]

[TheRebell]

heb je al een mooi modelletje Alienfruit?

Gordijnstok, kun je niet een soort rule-engine ofzo gaan gebruiken waarin je exliciet rekening houdt met het geval dat iemand in 2 departementen zit en op die manier conflicten gaat krijgen in zn rechten?

Stomme vragen waarom de een wel iets kan en zij zelf niet krijg je altijd. Daar valt gewoon niets aan te doen, door hun zelf trouwens ook niet (tenzij ze even snel opslag scoren ofzo )

[Verwijderd]

TheRebell schreef op 15 juli 2004 @ 21:42:
heb je al een mooi modelletje Alienfruit?

Gordijnstok, kun je niet een soort rule-engine ofzo gaan gebruiken waarin je exliciet rekening houdt met het geval dat iemand in 2 departementen zit en op die manier conflicten gaat krijgen in zn rechten?

Stomme vragen waarom de een wel iets kan en zij zelf niet krijg je altijd. Daar valt gewoon niets aan te doen, door hun zelf trouwens ook niet (tenzij ze even snel opslag scoren ofzo )

Conflicten kun je inderdaad opzoeken. Ik zou recursive de boomstructuur kunnen aflopen * relaties (ik heb een systeem met many to many relaties), maar dat zou je telkens moeten gaan doen bij het zetten van rechten en daar wordt je niet vrolijk van. De klant nog minder als hij telkens de melding krijgt " nee dat mag je niet ". Dan is de meest gebruiksvriendelijke manier denk ik om de klant een selectie te geven in department.

Ik heb het rechtengedeelte in de basis al geheel werkend op deze manier, en al geimplementeerd incl beheer schermen etc. dus nu ga ik daarop verder borduren, en kan het evt. op een later moment altijd nog aanpassen Je moet wel omdat anders de rest van je werk stil blijft liggen omdat je te lang gaat peinzen over dit soort zaken. Dan kom je in een spiraal terecht.

[ Voor 21% gewijzigd door Verwijderd op 15-07-2004 21:59 ]

[alienfruit]

Hoe bedoel je een mooi model, ik heb in de start topic toch al een suggestie gegeven? Verder is het niet zo spannend: (tot nu toe)

objects
object_id [int]
object_data [blob]

items
item_id [int]
created_by [int/nvarchar] (<-- of zou ik dit als string opslaan en dan username, scheelt weer een query)
creation_date [datetime]
modification_date [datetime]
process_state [int]

[djluc]

created_by [int/nvarchar] (<-- of zou ik dit als string opslaan en dan username, scheelt

Sowieso de id en eventueel de username in een ander veldje. Dan kan je nog altijd je cache updaten. Verder heb je hier geen extra query maar een join voor nodig.

[alienfruit]

Uuuh.

[TheRebell]

[b]Verwijderd schreef op 15 juli 2004 @ 21:53
Conflicten kun je inderdaad opzoeken. Ik zou recursive de boomstructuur kunnen aflopen * relaties (ik heb een systeem met many to many relaties), maar dat zou je telkens moeten gaan doen bij het zetten van rechten en daar wordt je niet vrolijk van. De klant nog minder als hij telkens de melding krijgt " nee dat mag je niet ". Dan is de meest gebruiksvriendelijke manier denk ik om de klant een selectie te geven in department.

hmmm nee die meldingen maken een gebruiker ook niet blij
Kun je het niet zo doen dat een gebruiker gewoon alleen zijn opties ziet en verder alles wat hij/zij niet kan gewoon niet kan zien? (en dus ook niet op kan klikken ed)

Ik heb het rechtengedeelte in de basis al geheel werkend op deze manier, en al geimplementeerd incl beheer schermen etc. dus nu ga ik daarop verder borduren, en kan het evt. op een later moment altijd nog aanpassen Je moet wel omdat anders de rest van je werk stil blijft liggen omdat je te lang gaat peinzen over dit soort zaken. Dan kom je in een spiraal terecht.

Je moet wel ergens een streep trekken ja anders komt het nooit af. Perfectionisme is goed maar _te_ is ook niets...
Pas een beetje op met aanpassen he, anders kun je straks weer overnieuw beginnen

[TheRebell]

[b]alienfruit schreef op 15 juli 2004 @ 23:22
objects
object_id [int]
object_data [blob]

items
item_id [int]
created_by [int/nvarchar] (<-- of zou ik dit als string opslaan en dan username, scheelt weer een query)
creation_date [datetime]
modification_date [datetime]
process_state [int]

zoals djluc zegt. Het ID is het belangrijkste. Ahv het ID kun je dan namelijk altijd de rest weer opzoeken. Uiteraard is het meeste wel je join'en als ik zo kijk