[SQL] Gebruikers en Groepen

[Oberon]

Momenteel heb ik drie tabellen voor gebruikers en groepen (tabellen hieronder zijn fictief, maar zijn voldoende als voorbeeld):

tbluser
UserID | Username

tblgroup
GroupID | GroupName

tblusergroup
UserID | GroupID

Alle security baseert zich met het huidige systeem op groepen - users zijn lid van groepen en objecten worden via een tussentabel gelinkt aan groepen. Bijvoorbeeld:

tblarticle
ArticleID | ...

tblarticlesecurity
ArticleID | GroupID

In de toekomst zou het echter ook mogelijk moeten zijn om aparte users rechten te geven op artikels. (Maw users en groepen door elkaar) Hoe los ik dit het best op?

Ik dacht te werken met een nieuwe tabel, bijvoorbeeld:
tblsecurityobject
SecurityObjectID | ObjectType | ObjectID

Waarbij ObjectType een integer zou zijn, wat moet aanduiden of het ObjectID een GroupID is of een UserID. Security op artikelen zou dan gebeuren met SecurityObjects ipv groepen. Ergens vind ik het echter heel fout om de waarde van een kolom af te laten hangen van een andere. Anderzijds vind ik het properder werken dan bijvoorbeeld het volgende:
tblsecurityobject
SecurityObjectID | UserID | GroupID

Waarbij ofwel het één of ander ingevuld wordt...

Zijn hier andere best practices voor?

[Verwijderd]

Het open-source CRM pakket vTiger biedt een zelfde functionaliteit.
In hun geval werkt het met een overkoepelende 'entity' tabel, waar alle common data in staat. Een gedeeld ID, het type van de gegevens (bijv. contact, factuur, account, etc.), laatste wijziging, etc. Deze tabel heeft vervolgens een 1-op-1 relatie met de verschillende andere tabellen. In principe hebben alle entities in dat systeem dus een gedeelde ID, waar vervolgens allerlei rechten aan gehangen kunnen worden.
Nadeel is wel dat je dan op een gegeven moment een stapel joins krijgt in je systeem waar je eng van wordt (of valt dat wel mee? is puur een gevoelskwestie ). Daarbij staat 't natuurlijk vreemd om in een relationeel model zo'n soort van overerving te proberen te bewerkstelligen.

[Gomez12]

Wat ik zou doen, is per user waarvoor dit geldt een aparte groep aanmaken waarin maar 1 user zit.Dan houd je alles instand, je hebt een eenduidig rollenmodel en het scheelt je een extra join ( alhoewel dit met 1.000.000 users in aparte groepen opeens weer performance kan gaan kosten )

Ik denk dat dit vooral afhangt van het aantal users waarvoor dit geldt, zijn dit 1.000 users dan ben je volgens mij beter af met 1 aparte groep per user dus 1 tabel SecurityObjectID | GroupID, zijn dit 1.000.000 users dan ben je beter af met een extra join naar een tabel SecurityObjectID | UserID om te zien of deze specifieke user specifieke rechten heeft.

Gecombineerde tabellen met SecurityObjectID | UserID | GroupID zou ik niet aan beginnen, dan ga je query's bouwen die business logica bevatten en die ook best wel ingewikkeld kunnen zijn ( normaal gesproken gaat UserID boven GroupID behalve als GroupID een super-admin group is en UserID leeg is / niet genoeg rechten heeft behalve als er op UserID een specifieke deny staat voor een user die ook onderdeel is van een super-admin Group )

Of alleen GroupID's of 2 losse tabellen, GroupID's en UserID's.

[Oberon]

Verwijderd schreef op dinsdag 06 mei 2008 @ 19:33:
Het open-source CRM pakket vTiger biedt een zelfde functionaliteit.
In hun geval werkt het met een overkoepelende 'entity' tabel, waar alle common data in staat. Een gedeeld ID, het type van de gegevens (bijv. contact, factuur, account, etc.), laatste wijziging, etc. Deze tabel heeft vervolgens een 1-op-1 relatie met de verschillende andere tabellen. In principe hebben alle entities in dat systeem dus een gedeelde ID, waar vervolgens allerlei rechten aan gehangen kunnen worden.
Nadeel is wel dat je dan op een gegeven moment een stapel joins krijgt in je systeem waar je eng van wordt (of valt dat wel mee? is puur een gevoelskwestie ). Daarbij staat 't natuurlijk vreemd om in een relationeel model zo'n soort van overerving te proberen te bewerkstelligen.

Hoewel dat niet echt m'n vraag was (m'n vraag ging over hoe ik zowel gebruikers als groepen aan objecten/entities - zoals artikelen - te koppelen), is dit ook wel een issue die ik moet zien op te lossen. Zoals je in m'n voorbeeld ziet los ik dit probleem voorlopig op met securitytabellen zoals tblarticlesecurity. Ik moet echter voor elk type object/entiteit zo'n tabel aanmaken. Het idee van een entity-tabel met type is dan plots zo gek niet. Anderzijds gaat deze tabel wel snel gigantisch groot worden, terwijl dit nu geen probleem is (echter heb ik dan weer veel security-tabellen). Ook hier weet ik dus niet wat de best practice is...

Gomez12 schreef op dinsdag 06 mei 2008 @ 23:40:
Wat ik zou doen, is per user waarvoor dit geldt een aparte groep aanmaken waarin maar 1 user zit.Dan houd je alles instand, je hebt een eenduidig rollenmodel en het scheelt je een extra join ( alhoewel dit met 1.000.000 users in aparte groepen opeens weer performance kan gaan kosten )

Ik denk dat dit vooral afhangt van het aantal users waarvoor dit geldt, zijn dit 1.000 users dan ben je volgens mij beter af met 1 aparte groep per user dus 1 tabel SecurityObjectID | GroupID, zijn dit 1.000.000 users dan ben je beter af met een extra join naar een tabel SecurityObjectID | UserID om te zien of deze specifieke user specifieke rechten heeft.

Gecombineerde tabellen met SecurityObjectID | UserID | GroupID zou ik niet aan beginnen, dan ga je query's bouwen die business logica bevatten en die ook best wel ingewikkeld kunnen zijn ( normaal gesproken gaat UserID boven GroupID behalve als GroupID een super-admin group is en UserID leeg is / niet genoeg rechten heeft behalve als er op UserID een specifieke deny staat voor een user die ook onderdeel is van een super-admin Group )

Of alleen GroupID's of 2 losse tabellen, GroupID's en UserID's.

In dat geval kan ik evengoed de SecurityObject-tabel volledig vergeten en tevens alle gebruikers in tblgroup plaatsen. Functioneel lost dat inderdaad mijn probleem op, maar logischerwijs vind ik het een beetje wringen. Het maakt het overzicht van mijn groepen er ook niet bepaald makkelijker op. Tot nu toe is dit echter de beste oplossing.

[RobIII]

Hang een security desciptor (gewoon een GUID ofzo) aan iedere entity en maak dan 1 centrale tabel met ACL's met daarin de security descriptors.

Op het moment dat je ergens een entity maakt maak je dus eerst een securitydescriptor en die sla je op bij de entity. Vervolgens hang je rechten (ACL's ofzo) aan de securitydescriptors et voila. Of je die security descriptor laat maken door de DB of zelf genereerd moet je zelf weten; als je de hele handel binnen een transactie opslaat (dus eerst nieuwe sid, dan nieuwe entity opslaan) kan er weinig mis

[ Voor 40% gewijzigd door RobIII op 07-05-2008 15:44 ]

[Gomez12]

Oberon schreef op woensdag 07 mei 2008 @ 15:27:
[...]
In dat geval kan ik evengoed de SecurityObject-tabel volledig vergeten en tevens alle gebruikers in tblgroup plaatsen. Functioneel lost dat inderdaad mijn probleem op, maar logischerwijs vind ik het een beetje wringen. Het maakt het overzicht van mijn groepen er ook niet bepaald makkelijker op. Tot nu toe is dit echter de beste oplossing.

Je kan inderdaad alle gebruikers in je tblgroup plaatsen, maar ik neem aan dat er in tbluser iets meer staat als alleen een username, naw gegevens / wachtwoord etc.
Dit hoef je allemaal niet in tblgroup te hebben zitten.

En waarom zou dit model wringen? Ik vind het altijd goed werken, users hebben geen losse rechten behalve in extreme uitzonderingsgevallen. Gebruiker x moet wel bij bestand y kunnen maar niet bij bestand z, er is geen groep die hieraan voldoet, dan mag er eerst overlegd gaan worden waarom deze situatie onstaat, want als je dit gaat invoeren dan weet je na een tijdje niet meer wie nou wel bij bestand x mag en wie nou bij bestand z mag.

1 ding wat al heel vroeg geleerd heb over file/article security. KISS, anders krijg je een onwerkbare brij waarin het gaat voorkomen dat iemand wel het recht heeft article x te lezen, maar hier niet bijkomt omdat hij categorie x niet mag lezen...

Dus houd het gewoon bij een zo beperkt mogelijk aantal groepen. Deel alleen rechten uit aan groepen en categorieen, niet aan artikelen.

[RobIII]

Gomez12 schreef op woensdag 07 mei 2008 @ 15:43:
Dus houd het gewoon bij een zo beperkt mogelijk aantal groepen. Deel alleen rechten uit aan groepen en categorieen, niet aan artikelen.

Dan kun je beter eens kijken naar RBAC. Dan hang je (1 of meer) rechten aan (1 of meer) rollen en (1 of meer) rollen hang je aan (1 of meer) groepen of (1 of meer) users.

Dan krijg je zoiets:

Permission
id, name, description, ...

Role
id, name, description, ...

User
id, name, ...

RolePermission
[roleid, permissionid] (compound key)

UserRole
[userid, roleid] (compound key)

En groepen voeg je net zo easy toe:

Group
id, name, <parentid>, ...

GroupRole
[groupid, roleid] (compound key)

UserGroup
[userid, groupid] (compound key)

Voor het bewerken van articles kijk je dan of de permission "editarticle" in 1 van de roles van de user/group zit et voila.

[ Voor 52% gewijzigd door RobIII op 07-05-2008 15:54 ]

[Oberon]

RobIII schreef op woensdag 07 mei 2008 @ 15:45:
[...]

Dan kun je beter eens kijken naar RBAC. Dan hang je (1 of meer) rechten aan (1 of meer) rollen en (1 of meer) rollen hang je aan (1 of meer) groepen of (1 of meer) users.

Dan krijg je zoiets:

[...]


En groepen voeg je net zo easy toe:


[...]


Voor het bewerken van articles kijk je dan of de permission "editarticle" in 1 van de roles van de user/group zit et voila.

Ik zit enkel met het volgende probleem:
1) Er zijn artikelen die iedereen kan bekijken, maar er zijn er ook die enkel maar door bepaalde mensen/abonnees kunnen bekeken worden
2) Een gebruiker met een abonnement kan alle artikels bekijken, vervalt zijn abonnement dan kan hij geen artikels meer bekijken waarvoor je abonnee voor moet zijn
3) Een gebruiker kan ook een artikel kopen (zonder een abonnement te hebben) waardoor hij "levenslang" toegang heeft tot dat bepaalde artikel

Moest 3) er niet zijn was het idd zo simpel als je het voorstelt; gebruikers (of groepen) met de viewarticle permission konden dan alle artikelen zien.

Ik vrees dus dat ik roles dus niet kan verbinden met permissions, maar dat ik permissions op mijn objecten moet zetten. Users en Groepen kunnen dan bepaalde permissions hebben op een object (roles ernaast is dan niet meer nodig).

Probleem dan weer is dat ik niet eenvoudig kan checken (in de zin van User.IsInRole("administrator")) of een gebruiker permissies heeft, maar ik dus telkens eerst het object moet queryen (heeft een bepaalde user rechten op dat object, zoja, welke?).

Hoever ga je dan in objecten definiëren? Is een Artikel een object? Is een advertisement in een artikel een object? Is een "Edit Article" knop op een pagina een object? In dat geval ga ik ook elk type object in een object-tabel moeten gieten om daar mijn ACL's aan te hangen. (zie post van Tedkees)

Ik vrees alleen dat dit het nodeloos(?) complex gaat maken.