[Alg] Verhouding Rollen en Groepen in Role Based Security.

Pagina: 1
Acties:
  • 125 views sinds 30-01-2008
  • Reageer

  • gvanh
  • Registratie: April 2003
  • Laatst online: 02-12-2023

gvanh

Webdeveloper

Topicstarter
Inmiddels heb ik ongeveer alle topics over Role Based Security en aanverwante onderwerpen gelezen. Bijzonder interessant en leerzaam! Ik snap al een hoop meer van dergelijke systemen.

Het enige dat ik nog niet doorheb, is de verhouding tussen Rollen en Groepen.

Zijn rollen en groepen ideeën die elkaar aanvullen, of maak je bij het ontwerp van je gebruikers-systeem een keuze tussen een systeem dat gebaseerd is op groepen OF op rollen.

Indien - hetgeen ik zo'n beetje verwacht - de twee ideeën elkaar aanvullen, hoe verhouden groepen en rollen zich dan tot elkaar?

Is het zo, dat je groepen aanmaakt om op eenvoudige wijze gebruikers een aantal basis rechten/permissies te geven. En werken dan rollen zo, dat een rol is opgebouwd uit het lidmaatschap van specifieke groepen, eventueel aangevuld met specifieke rechten/permissies?

Zo ja, hoe is dan de verhouding tussen rollen en groepen geregeld in de (typische) database structuur.


---- Aanvulling ----
Als voorbereiding en concretisering van wat ik tot nu toe heb begrepen en wat ik graag wil bereiken, heb ik een simpele database-structuur opgezet. Die zet ik hieronder even neer ter info.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
TABLE cms_users
cms_userID  INT(11)
user    VARCHAR(50)
pass    VARCHAR(30)
ip  VARCHAR(15)
created BIGINT(22)
last_login  BIGINT(22)

TABLE cms_groups
cms_groupID INT(11)
name    VARCHAR(30)

TABLE cms_operations
cms_operationID INT(11)
name    VARCHAR(30)

TABLE cms_users2groups
csm_userID  INT(11)
cms_groupID INT(11)

TABLE cms_users2rights
cms_userID  INT(11)
cms_operationID INT(11)
permission  INT(4)

TABLE cms_groups2rights
cms_groupID INT(11)
cms_operationID INT(11)
permission  INT(4)


De 'permission' die in de cms_users2rights en cms_groups2rights staat, wil ik in de database gaan opslaan als 'optelling' van de permissies die een gebruiker kan hebben. Zo zal ik in mijn script de basis permissies definiëren:

READ = 1
WRITE = 2
PUBLISH = 4

Daardoor kan ik later simpelweg controleren of een gebruiker een bepaalde permissie heeft door iets als:

code:
1
2
3
if ( $user->rights['news'] & WRITE ) {
  // Blablabla
}


Ik heb in eerdere posts gelezen, dan men veel meer permissies definieert als de drie die ik hierboven heb neergezet, maar ik heb het idee dat wanneer je deze drie rechten maar op het juiste niveau implementeerd, dat deze 3 dan voldoende moet zijn (analoog aan het READ/WRITE/EXECUTE van de meeste besturingssystemen).

Is dat een slimme benadering? Of ga ik mezelf dan keihard tegenkomen.

Wat een vervelend lang verhaal ... ik hoop dat iemand nog zin heeft hierop te reageren. In ieder geval bedankt voor de moeite om helemaal tot hier te lezen! _/-\o_

[ Voor 50% gewijzigd door gvanh op 19-10-2004 21:44 . Reden: Aanvulling met meer concreet gewauwel. ]


Verwijderd

Een groep zie ik als een hierarchische ordening van objecten.
Een rol zie ik als een object dat een gebruiker rechten geeft op een ander object.

In UML:
Afbeeldingslocatie: http://server.ricardis.tudelft.nl/~scholtens/rechten.gif

- Alles erft (via via) van Object. Op Object kunnen rechten gegeven worden. Er kunnen nog meer klasses afgeleid worden.
- De schikking van Role en User kan omgekeerd worden, de getoonde aanpak dwingt af dat alle rechten via roles geregeld worden.
- In dit schema zitten geen expliciete verbanden tussen mogelijke rechten en subklasses van Object. Bv execute rechten op een directory zijn mogelijk ;).

  • ripexx
  • Registratie: Juli 2002
  • Laatst online: 14:21

ripexx

bibs

Je wil niet weer extra opties gaan defineren zoals je nu weer gaat doen dus read, write en publish. Dit zijn afzonderlijke rechten en het is dan ook aan te raden om hier een opsplitsing in te maken. Je kan het wel zo doen maar dan is het naar mijn idee weer vragen om problemen zeker als je geheel flexibel wil zijn. Je wil gewoon kunnen defineren wat jij wit.

Waarom maak je groepen om het overzicht te behouden users -> rechten groep -> rechten. Een user kan dan in een of meerdere groepen zitten. Dit is in weze de bases van het verhaal. Daarnaast kan je zaken als overerving en overschijving toe gaan voegen. Maar het is de vraag of dit op weegt tegen de voordelen ;)

Een zeer intressant verhaal is deze. [rml][ php/[ my]sql] inherited rechtensysteem[/rml] Het gaat in dit geval wel over PHP/MySQL maar is net zo goed toepasbaar ain een andere taal.

buit is binnen sukkel


  • TheRebell
  • Registratie: Oktober 2000
  • Laatst online: 20-05 16:00
ik heb Rol Based Access Control (rbac) op de volgende manier toegepast. Mijn systeem bestaat uit modulen en operations. Een combinatie van deze twee vorm een (unieke) privilege (op module-operation)

Een user heeft een rol. Deze rol heeft vervolgens privileges. Om het nu allemaal iets makkelijker te maken zijn er ook groepen.
Een user zit in een groep en erft op deze manier alle privilegs van de groep. Zit een user in meerdere groepen dan krijgt hij/zij op deze manier meer privileges. Doordat je ook direct aan een user privileges kunt koppelen kun je een user op deze manier dus net wat extra's geven. Uiteraard kun je op deze manier ook een bepaalde user juist een privilege ontnemen ;)

Om het zaakje allemaal bij elkaar te houden heb ik twee classen, Authorization en AuthorizationManager. Kort gezegd kletsen andere classes tegen Authorization, deze roept de manager weer aan. Feitelijk zit hier dus alle logica in.
Van een user kun je op deze manier een Actice Role Set (ARS) ophalen waarin al zijn/haar privilegs staan :)

Het kost eeeeeven wat tijd maar je krijgt er op deze manier wel een erg schaalbaar rechtensysteem mee. Misschien voor een hoop dingen te uitgebreid maargoed, voor mij werkt het perfect (en daar gaat het om ;) )

Waar je dus alleen nog mee zit is met tegenstrijdige prvilegs. Naast seperation of duty kunnen sommige privileges tegenstrijdig zijn, dit zul je dus ook nog wel moeten afvangen/oplossen als je zowel groepen- als user-privilegs gaat gebruiken

[ Voor 10% gewijzigd door TheRebell op 20-10-2004 00:36 ]


  • gvanh
  • Registratie: April 2003
  • Laatst online: 02-12-2023

gvanh

Webdeveloper

Topicstarter
Ja, dat laatste topic had ik inderdaad ook al gevonden. Zeker interessant.

Dank ook TheRebell voor je bijdrage. Da's inderdaad heel interessant en sluit aan op wat ik net uitgebreid op de bank heb zitten lezen: http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf. Dat is de officiële definitie van het zogenaamde RBAC (Role Based Access Control). Opnieuw min of meer een eye-opener. Daar staat eigenlijk heel duidelijk beschreven wat precies de eisen zijn van het RBAC model. Daarin staat ook min of meer uitgelegd wat de relaties zijn tussen gebruikersgroepen en rollen.

Een nederlandstalig artikel over het concept van RBAC door een medewerker van KPMG is: http://www.bholdcompany.c..._RBAC_artikel_1.2c_NL.pdf. Voor begrip van het concept - ook in contrast met NIET-rolgebaseerde systemen - is dat wel een duidelijk artikel.

Dat voor zover het concept.

Nu dus inderdaad de vertaalslag maken naar Database-structuur en de definitie van Objecten en 'Operations'. Want - als ik het goed begrepen heb - zin die twee de bouwstenen voor permissies...

Als ik m'n DB-model morgen afrondt zal ik dat nog even plaatsen hier. In de tussentijd ben ik erg benieuwd naar de (concrete) database-modellen van anderen!

@ripexx:
Dat betekent dan dus wel, dat ik voor elke module (elk object?) dat ik in mijn CMS systeem heb (pagina's, nieuwsberichten, afbeeldingen, mappen, etc. etc.) een complete set van rechten moet maken. Dan krijg je dus:

create_page
edit_page
publish_page
delete_page
create_message
edit_message ...
... het systeem is duidelijk :p

En dat terwijl waarschijnlijk de meeste objecten binnen een CMS exact dezelfde basis-rechten te verdelen hebben (create/edit/read/publish/etc.). Is het dan niet overzichtelijker en juist flexibeler om die twee van elkaar te scheiden?

Mocht ik dan na verloop van tijd beseffen dat het toch echt handig is om systeem-breed een nieuw recht te definiëren, bijvoorbeeld het recht om te "printen" (ik noem maar iets onnozels 8)7 ), dan hoef ik alleen maar in de tabel met rechten "printen" toe te voegen, en direct hebben alle CMS-modules/objecten dit recht erbij gekregen.

Of zeg ik nu hele domme dingen? B)

[ Voor 32% gewijzigd door gvanh op 20-10-2004 00:52 . Reden: Reactie aan ripexx toegevoegd. ]


  • TheRebell
  • Registratie: Oktober 2000
  • Laatst online: 20-05 16:00
hey die artikelen ken ik ;) (ook allemaal gelezen)

Ik heb voor de operations, de acties die je kunt uitvoeren dus, een tabelletje gemaakt. Dit zijn dus een aantal standaard dingen zoals:
- add
- edit
- delete
- publish
- view
- list
etc....
Dit koppel je aan een module en dan heb je een privilege/recht. Dat geef je dan aan een groep of een user.

Hmm met dat printen zou ik op een andere manier doen. Zoals jij het even zegt zou iedereen gelijk een nieuw recht hebben. Dat wil je natuurlijk niet, want pietje mag niet printen. Die heeft namelijk ook een andere rol of andere groep.
Wat natuurlijk wel kan als je systeem breed iets wilt hebben is door een recht aan de applicatie zelf toe te kennen (bv net als inloggen) Iedereen heeft dit recht dan. Of je maakt een groep waar feitelijk iedereen in zit (dus ook andere groepen)
Uiteraard moet het dan ook zo zijn dat een module het nieuwe recht implementeerd. Als een module geen print-iets heeft kun je wel doorleuk het recht ervoor hebben maar heb je er nog niets aan.... Door het zaakje juist te koppelen weet je dus ook welke module welke rechten heeft (dus welke acties het aanbied)

Nou genoeg stof tot nadenken :P

  • D4Skunk
  • Registratie: Juni 2003
  • Laatst online: 20-10-2025

D4Skunk

Kind of Blue

Zoals ik het persoonlijk interpreteer en gebruik :
Een rol moet je bekijken als het kleinste gemeen veelvoud van alle database bewerkingen/beveiligingen op een (groep van) tabel(len).
Een groep moet je bekijken als het kleinste gemeen veelvoud van alle users

Een voorbeeld :
op een tabel artikels heb je een admin (die kan alles), een publisher (die kan bv enkel artikels publiek maken of verwijderen) en een writer (kan enkel eigen artikels aanmaken/wijzigen, niet publiek maken of verwijderen), een editor (kan enkel correcties aanbrengen aan artikels) en een reader(read-only access).

Vervolgens heb je een groep. Aan een groep ga je bepaalde rollen gaan toekennen. Aan de groep hoger kader ken je bv publisher en editor toe; aan een groep auteurs bv enkel de rol writer.

Op zich lijkt dit een dom voorbeeld, maar wanneer je dit bv uitbreidt met een tabel die de lonen bevat van de werknemers, dan merk je automatisch dat je voor het hoger kader andere rollen zal moeten toekennen dan voor een auteur, en nog andere rollen voor de groep HRM. De groep HRM zal bv enkel de rol reader toegekend krijgen voor de tabel artikels

DE beste manier om dit concept volledig te begrijpen is alle relevante bedrijfsprocessen in kaart te brengen, en dan zal je vanzelf(=mits enige moeite) de rollen en groepen naarbuiten zien komen. Hoe meer ervaring je hierin krijgt, hoe vlotter dit gaat.
Indien je dit interessante materie vindt, verdiep je dan eens in workflow-systemen; ik gebruik dit steeds als eerste stap in de analyse van mijn klanten om te kijken of ik de werking van het bedrijf correct begrijp.

  • gvanh
  • Registratie: April 2003
  • Laatst online: 02-12-2023

gvanh

Webdeveloper

Topicstarter
Ja, da's ook een goeie, ik wil me vandaag inderdaad eens even gaan verdiepen in Workflow ... nog suggesties voor artikelen die ik daarover echt gelezen MOET hebben?

Dan nog even een vraagje over ownership. Hoe wordt dat in dit hele systeem geregeld? Ik neem aan dat (in een publishing omgeving) ieder artikel, nieuwsbericht, etc. een bepaalde eigenaar heeft. Blijft het daarbij? Of wordt er ook nog een groep (of rol?) aangesteld als eigenaar van een item?

Dit zodat als (bijvoorbeeld) een writer een bepaald artikel schrijft, dat alle andere writers dit dan mogen inzien omdat het artikel in eigendom staat van de groep/rol "writers". Of zeg ik nu weer hele rare dingen :P

Pfff ... de vragen blijven maar komen he ... ik vind het overigens wel mooie materie! Eigenlijk de eerste keer dat ik me ZO uitgebreid verdiep in de theorie, voordat ik daadwerkelijk aan het programmeren sla.

offtopic:
Voor alles is een eerste keer ...

[ Voor 18% gewijzigd door gvanh op 20-10-2004 10:01 ]


  • D4Skunk
  • Registratie: Juni 2003
  • Laatst online: 20-10-2025

D4Skunk

Kind of Blue

gvanh schreef op 20 oktober 2004 @ 09:58:
Ja, da's ook een goeie, ik wil me vandaag inderdaad eens even gaan verdiepen in Workflow ... nog suggesties voor artikelen die ik daarover echt gelezen MOET hebben?
offtopic:
Ik weet dat het nogal dom klinkt: verdiep je even in workflow 8)7
Ieder maakt dit natuurlijk voor zichzelf uit; mij heeft het enorm veel geholpen om massa's doctoraatsthesisen te lezen mbt tot analyse-technieken e/d.
Alles hangt imho af van de grootte van het project ; alhoewel je in elke opdracht toch op z'n minst duidelijk de scope en beoogde doelstellingen moet vooropstellen en duidelijk maken aan de klant. Als je dit niet doet, kom je gegarandeerd in de problemen met je budget-bepaling. Naarmate je grotere projecten maakt, zul je merken dat je sowieso niet zonder een bepaalde methodologie kunt...
Dan nog even een vraagje over ownership. Hoe wordt dat in dit hele systeem geregeld? Ik neem aan dat (in een publishing omgeving) ieder artikel, nieuwsbericht, etc. een bepaalde eigenaar heeft. Blijft het daarbij? Of wordt er ook nog een groep (of rol?) aangesteld als eigenaar van een item?

Dit zodat als (bijvoorbeeld) een writer een bepaald artikel schrijft, dat alle andere writers dit dan mogen inzien omdat het artikel in eigendom staat van de groep/rol "writers". Of zeg ik nu weer hele rare dingen :P
Dit is een duidelijk voorbeeld van een worklow : ipv aan het artikel een owner te hangen, werk je beter met een workflow-systeem.
De transaction-log zou er zo uitzien :

code:
1
2
3
4
5
6
7
8
9
ID  Object      OBJ_ID    ACTION      USER   STATUS
------------------------------------------------------
1   ARTICLE     32        WRITE       IKKE   WRITTEN
2   ARTICLE     32        REVIEW      BOSS   ASSIGNED
3   ARTICLE     32        REVIEW      BOSS   REVIEWED
4   ARTICLE     32        PUBLISH     GOD    ASSIGNED
5   ARTICLE     32        PUBLISH     GOD    REFUSED
6   SALARY      54        EDIT        BOSS   EDITED
7   ARTICLE     33        REVIEW      BOSS   PENDING


Hiernaast heb je natuurlijk een tabel nodig die aanduidt welke action/status kan volgen op welke voorgaande action/status, en welke role deze status mag aanpassen.

code:
1
2
3
4
5
6
7
8
9
OBJECT    CURRENT   CURRENT   NEXT      NEXT      ALLOWED
          ACTION    STATUS    ACTION    STATUS    ROLE
-------------------------------------------------------------
ARTICLE   REVIEW    ASSIGNED  REVIEW    PENDING   EDITOR
ARTICLE   REVIEW    PENDING   REVIEW    REVIEWED  EDITOR
ARTICLE   REVIEW    PENDING   REVIEW    REFUSED   EDITOR
ARTICLE   REVIEW    REVIEWED  PUBLISH   ASSIGNED  PUBLISHER
ARTICLE   PUBLISH   ASSIGNED  PUBLISH   PUBLISHED PUBLISHER
ARTICLE   PUBLISH   ASSIGNED  PUBLISH   REFUSED   PUBLISHER


Dit is natuurlijk een zeer eenvoudig systeem, maar blijkt in praktijk zeker werkbaar, en relatief duidelijk voor de klant.
Pfff ... de vragen blijven maar komen he ... ik vind het overigens wel mooie materie! Eigenlijk de eerste keer dat ik me ZO uitgebreid verdiep in de theorie, voordat ik daadwerkelijk aan het programmeren sla.
Vanaf het moment dat je met iets grotere projecten bezig bent, loont het wel degelijk je eerst te verdiepen in de materie alvorens aan de slag te gaan.. veel succes !!!!!

  • gvanh
  • Registratie: April 2003
  • Laatst online: 02-12-2023

gvanh

Webdeveloper

Topicstarter
Dit geeft weer een hoop stof tot nadenken ... slim systeem. Daarmee wordt het hele workflow systeem dus een integraal onderdeel van het gebruikers/rechten/rollen systeem. Da's mooi ... dan hoef ik maar één systeem uit te denken :+ .

Dan ga ik nu maar weer 'ns m'n database "modelletje" wat uitbreiden ... kijken hoever ik kom!

Ik zal hem straks weer even posten hier.

Dank tot zover voor alle hulp!

TOEVOEGING
Da's waar ook ... ik bedenk me nog iets ... een veel concretere vraag eigenlijk. Ik ben dus nu bezig met het opzetten van een heel RBAC en Work-flow systeem voor mijn CMS.

Nu ben ik momenteel al met een site bezig, die met mijn CMS werkt. Op die site komt straks een apart 'inloggedeelte' voor geregistreerde gebruikers (het zou bijvoorbeeld een forum kunnen zijn). Deze geregistreerde gebruikers moeten natuurlijk niet in het CMS terecht komen, daar hebben ze helemaal niets te zoeken.

Moet ik nou twee compleet aparte gebruikers-databases aanhouden voor CMS-gebruikers en geregistreerde website-gebruikers? Of moet ik hetzelfde systeem aanhouden, maar gewoon in een duidelijke rollen-verdeling?

[ Voor 52% gewijzigd door gvanh op 20-10-2004 11:16 ]


  • D4Skunk
  • Registratie: Juni 2003
  • Laatst online: 20-10-2025

D4Skunk

Kind of Blue

Moet ik nou twee compleet aparte gebruikers-databases aanhouden voor CMS-gebruikers en geregistreerde website-gebruikers? Of moet ik hetzelfde systeem aanhouden, maar gewoon in een duidelijke rollen-verdeling?
Ik zou voor optie 2 kiezen : één systeem = minder werk, meer uniformiteit

  • TheRebell
  • Registratie: Oktober 2000
  • Laatst online: 20-05 16:00
Voor een website had ik ook zoiets, daarbij kon je op de front-end inloggen en ook op de back-end. Omdat er eg veel gebruikers zijn (die niet allemaal toegang moeten hebben) heb ik een gebruikerslijst eraan gehangen. Dan kun je een rol (of groep) kiezen en daar gebruikers aan koppelen. Niet helemaal een ideaal systeem op deze manier maargoed. Eigenlijk wil je deze gebruikers van elkaar scheiden. Een lijst met gebruikers welke toegang hebben tot de back-end. De geregistreerde gebruikers (aan de front-end) kun je dan bv als een module integreren.
Het kan dus in 1 lijst (tabel) maar het mooiest/best is deze van elkaar te scheiden.

Mbt artikels heb ik het iets anders gedaan. Aan een artikel kun je een user hangen. Op deze manier kun je puur 1 user rechten geven op een pagina, andere editors kunnen dan bv alleen maar lezen maar niet het artikel bewerken of verwijderen.

Wel interessant dat workflow mngt, ook eens wat meer over gaan lezen, ziet er erg bruikbaar uit namelijk :)

Verwijderd

Ik heb in principe een domain, met daaronder departments, en daaronder department roles, en daaronder users. Verder nog een policy, en die koppel ik aan een of meerdere department roles.

Een department kan een afdeling zijn, marketing, development, sales, finances, etc.
Een role kan zijn, auteur, redacteur, hoofdredacteur
Een user kan zijn, hans, piet, klaas , etc..

Een user kan bij mij in meerdere departments een rol verrichten, maar hij kan maximaal één rol per department vervullen. De rechten die zo'n user heeft zijn indirect bepaald door zijn rol. Aan die rol hangt een policy, wat een set van rechten is. Een policy kan ik aan meerdere rollen hangen, en hergebruiken.

Een user kan dus in department "marketing" de rol auteur uitvoeren, en kan in department "development" een redacteur zijn. Hij kan ook in beide departments eenzelfde rol uitvoeren, dat maakt niet uit, zolang hij maar maximaal één rol kan vervullen.

  • gvanh
  • Registratie: April 2003
  • Laatst online: 02-12-2023

gvanh

Webdeveloper

Topicstarter
@GordijnStok:
En waarom heb je er dan voor gekozen om maximaal één rol per department aan een gebruiker te kunnen koppelen? Is dat om af te dwingen dat de rollen goed worden gedefinieerd?

Is jouw CMS overigens ergens de bekijken/testen of zijn er iets van screenshots te bewonderen? (Site met product-info?) Na alle input van jou kant op de verschillende topics ben ik inmiddels erg benieuwd naar wat jij voor systeem hebt ...

[ Voor 40% gewijzigd door gvanh op 20-10-2004 11:48 ]


Verwijderd

Wat ik wilde was een systeem waarbij ik een centrale boomstructuur kon opdelen in losse brokken. Marketing beheert dan de pagina marketing incl. alles daaronder, Development idem, etc.

Wat ik niet wilde was dat gebruiker A, in een department zowel author als editor zou worden. Als je dat gaat doen, neem je de stap op na te denken over processen om content toe te voegen, te bewerken en te reviewen weg. Bovendien, als gebruiker A meer rechten nodig heeft, dan plaats je deze in een andere role van die department, of override je de role en geef je de gebruiker meer rechten op user niveau ipv role niveau.

Ik ben overigens nog steeds met het systeem bezig, er gaat veel werk inzitten, en je bent veel tijd kwijt met refactoren als je zoals ik, lui bent en iets niet eerst de moeite neemt om iets uitgebreid technisch op papier te zetten. Ondanks dat dit project hobby is had ik dat wel moeten doen. Ik had overigens ook niet het idee van dit, dit en dit wordt het en basta. Ik heb van tevoren geen enkele grenzen gesteld aan tijd en functionaliteit. De vorige versies draaien al productie maar ik heb daar geen screens meer van online staan.

In het kort bestaat het rechten systeem uit

code:
1
2
3
4
5
- domein
--- department
------ role
--------- user
--- policy


Policies kunnen dus eenmalig gedefinieerd worden (is dus een set van permissies die als configurate voor een role dienen).

In de praktijk ziet dat het er bijv zo uit

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
-  www.domein.nl
--- marketing
------ auteur
--------- gebruiker a
--------- gebruiker b
------ redacteur
--------- gebruiker a
--------- gebruiker b
--- sales
------ auteur
--------- gebruiker a
--------- gebruiker b
------ redacteur
--------- gebruiker a
--------- gebruiker b
--- policies
------- policy voor auteurs
------- policy voor redacteuren

[ Voor 36% gewijzigd door Verwijderd op 20-10-2004 21:54 ]

Pagina: 1