:strip_exif()/u/82924/avatar.gif?f=community){kind=avatar}
Hallo!
Voor mij vraag wil ik eigenlijk beginnen met een briljante uitleg van EfBe over het Role Based Access Control ofwel Role Based Security model.
Voor een praktische toepassing van mijn verhaal het volgende. Binnen m'n CMS kan ik keurig per "role" aangeven welke permissies ze hebben op welke resources. Zo mag rol A misschien pagina's toevoegen maar niet verwijderen, terwijl rol B dat wellicht wel mag. Het probleem komt nu als ik onderscheid wil gaan maken in het resource-type pagina's. Ik wil namelijk dat iemand met rol A wel zijn eigen gemaakte pagina's mag verwijderen, maar niet degene die zijn gemaakt door een gebruiker met rol B. Maar hoe zit dat dan op het moment dat er een gebruiker komt met rol C, waarbij rol C = superbeheer. Die is dan niet de eigenaar van de pagina, maar moet hem wel weer kunnen verwijderen. Dan moet je dus hierarchie in je rollen gaan maken, en dat is nou juist niet de bedoeling.
Dan zou je nog kunnen zeggen dat de "superbeheerder" gewoon alle mogelijke rollen toebedeeld moet krijgen en daarmee denken het probleem op te lossen ... dat zou inderdaad werken, ware het niet dat het mij dan compleet onduidelijk is welke rol de eigenaar wordt van een item dat door de superbeheerder is gemaakt.
Wie laat mij het licht zien?
Alvast veel dank!
Voor mij vraag wil ik eigenlijk beginnen met een briljante uitleg van EfBe over het Role Based Access Control ofwel Role Based Security model.
Nu snap ik dit verhaal gelukkig heel erg goed. Wat ik alleen nog niet snap, is hoe dit model toegepast moet worden voor wat betreft de eigendom van een bepaalde resource. Want stel dat een gebruiker lid is van een aantal "groepen" of "rollen". Welke groep of rol wordt dan de eigenaar van een item dat deze gebruiker heeft aangemaakt?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.
Voor een praktische toepassing van mijn verhaal het volgende. Binnen m'n CMS kan ik keurig per "role" aangeven welke permissies ze hebben op welke resources. Zo mag rol A misschien pagina's toevoegen maar niet verwijderen, terwijl rol B dat wellicht wel mag. Het probleem komt nu als ik onderscheid wil gaan maken in het resource-type pagina's. Ik wil namelijk dat iemand met rol A wel zijn eigen gemaakte pagina's mag verwijderen, maar niet degene die zijn gemaakt door een gebruiker met rol B. Maar hoe zit dat dan op het moment dat er een gebruiker komt met rol C, waarbij rol C = superbeheer. Die is dan niet de eigenaar van de pagina, maar moet hem wel weer kunnen verwijderen. Dan moet je dus hierarchie in je rollen gaan maken, en dat is nou juist niet de bedoeling.
Dan zou je nog kunnen zeggen dat de "superbeheerder" gewoon alle mogelijke rollen toebedeeld moet krijgen en daarmee denken het probleem op te lossen ... dat zou inderdaad werken, ware het niet dat het mij dan compleet onduidelijk is welke rol de eigenaar wordt van een item dat door de superbeheerder is gemaakt.
Wie laat mij het licht zien?
Alvast veel dank!