[Database] Rechtenstructuur

[Verwijderd]

Goed, ik zit een beetje met een dilemma. Ik wil een datamodel ontwerpen voor een willekeurige bedrijfsapplicatie (denk aan relatiebeheer, e-mails, etc.), maar ik wil op ieder object dat ik heb rechten kunnen toekennen, per afzonderlijke gebruiker. Nu zat ik te denken hoe ik dit zou kunnen aanpakken, en kwam ik op hetvolgende uit:

• één overkoepelende tabel met daarin enkel unique IDs, eventueel met aanmaak datum/wijzig datum;
• aan deze tabel koppel ik de gebruikers met een bepaald recht (lezen en/of schrijven om te beginnen). Dit moet uiteindelijk uitbreidbaar zijn, dus laat ik dit verder open;
• Nu is ieder object in de database uitgerust met een dergelijk ID. Ik kan dan dus van ieder object zien of een gebruiker gerechtigd is om een object te benaderen, en op welke manier. Daarnaast kan ik ook nog eens zien wanneer de boel gewijzigd is en aangemaakt.

Nu is het probleem dat ik in dit geval dus voor alles wat ik opzoek minstens 3 JOINs zal moeten doen (als ik zo even goed tel):

SQL:

-- puur voor completeness van 't voorbeeld
DECLARE @userid int
SET @userid = 1

SELECT relation.*, entity.created, entity.modified, rights.rightid

FROM relation JOIN entity
ON relation.id = entity.id

LEFT JOIN rights
ON relation.id = rights.id

WHERE rights.userid = @userid

Dit is even snel zo neergegooid, dus 't kan misschien niet helemaal correct zijn. Mijn bezwaren tegen deze opzet zijn voornamelijk:

1. De queries worden zo onnoemelijk complex voor de meest simpele dingen;
2. Veel joins... is dit een probleem met veel data?

Het belangrijkste is dus nummertje 2, de performance. Ik ben zelf geen database goeroe (ik weet hoe ik tabellen moet maken, en informatie daar uit kan krijgen. Voor de rest weet ik niet 't fijne van performance tuning ofzo), dus weet ik niet precies wat voor impact een join heeft. Is er toevallig iemand die hier al een keer over heeft nagedacht en/of tips heeft voor me? Ik heb al een behoorlijke tijd op google gezocht, maar het grote probleem is dat ik niet precies weet waar ik op zou moeten zoeken. Dus voor deze keer: nuttige google zoektermen is ook niet erg

In ieder geval bedankt, want ik zit hier echt een beetje klem.

[alienfruit]

Als je gebruik maakt van joins en je queries op de juiste manier opbouwt hoeft het geen probleem te zijn, oftewel maak de joins in zo'n volgorde dat er snel het aantal te doorzoeken records daalt.

[Tomatoman]

Veel 'echte' databases hebben al een ingebouwd rechtenmanagement, kwestie van de documentatie lezen om uit te vinden hoe het werkt. Waarom het wiel opnieuw uitvinden?

[ Voor 10% gewijzigd door Tomatoman op 23-07-2005 23:49 . Reden: typfoutje ]

[Verwijderd]

Volgens mij kan je met een rechtenstructuur die in bijv. mssql zit geen rechten afdwingen op individuele records, of heb ik het nu verkeerd? Dat is namelijk wat ik wil doen: mensen die inloggen op de applicatie rechten toekennen op record niveau.

Is de complexiteit niet af te vangen met een trigger vraag ik me nu af? Ik heb zelf nog niet zo heel veel met triggers gedaan, maar je kan dus je update, delete, insert en select statements vervangen of aanvullen... Dan kan ik dus met normale queries werken (zonder de toegevoegde rechten), en de rechten in de triggers stoppen. Ik ga dit iig nog even nazoeken.

Ben overigens een week op vakantie nu, dus ik zal niet snel reageren.

[ripexx]

tomatoman schreef op zaterdag 23 juli 2005 @ 23:49:
Veel 'echte' databases hebben al een ingebouwd rechtenmanagement, kwestie van de documentatie lezen om uit te vinden hoe het werkt. Waarom het wiel opnieuw uitvinden?

Ik zie niet direct in hoe jij in Oracle of SQL server rechten gaat afdwingen op record niveau?

Voor de TS. De twee punten die je aangeeft:
- Complexiteit van je SQL statements is toch niet relevant. Als het goed opgezet is, is dat toch geen probleem.

- Prefromance met een paar joins is echt net zo'n probleem maar optimaliseer alles goed. Zowel SQL server als Oracle kunnen je snel laten zien wat er gebeurt. De query analyser van SQL server geeft het zelfs in een soort flow chart weer.

[JaQ]

ripexx schreef op maandag 25 juli 2005 @ 00:09:
[...]

Ik zie niet direct in hoe jij in Oracle of SQL server rechten gaat afdwingen op record niveau?

dan moet je bij Oracle eens naar de Virtual Private Database optie kijken. Deze dwingt op record niveau de rechten af. (Het komt er op neer dat er automagisch een regel aan de query conditie wordt toegevoegd). Moet je uiteraard wel een enterprise editie gebruiken (en die is duur )

Anyway, je kan het min of meer faken door bij iedere tabel een organisatie id (oid) toe te voegen en deze standaard mee te nemen in je query. Vervolgens houd je in een tabelletje bij welke user bij welke organisatie (afdeling, etc) hoort. Iets minder veiig dan VPD, maar het werk wel.

[Tomatoman]

ripexx schreef op maandag 25 juli 2005 @ 00:09:
[...]

Ik zie niet direct in hoe jij in Oracle of SQL server rechten gaat afdwingen op record niveau?

Ik ook niet , maar wie zegt dat het op recordniveau moet? In veel situaties kun je je datamodel zodanig opbouwen dat een gebruiker sommige tabellen wel mag zien en andere niet. Je kent de rechten dan op tabel-/ queryniveau toe.

Stel dat standaardgebruikers alleen klantgegevens mogen inzien en verkopers en binnendienstmedewerkers ook klantgegevens mogen toevoegen en wijzigen. Dan heb je een paar tabellen met klantgegevens, die read-only zijn voor standaardgebruikers, terwijl verkopers en binnendienstmedewerkers ook schrijftoegang hebben. Alle overige groepen gebruikers hebben geen toegang tot de tabellen. De groepen gebruikers leg je in de active directory aan, de gebruikers voeg je toe aan de groepen (de groepen worden speciaal aangelegd voor databasetoegang). Via de beheerstools van de betreffende database koppel je vervolgens de gebruikersrechten van de tabellen aan de zojuist aangelegde groepen. In veel databases is dit standaardfunctionaliteit en hoef je aan de tabellen geen extra velden toe te voegen met rechteninformatie.

[Wacky]

tomatoman schreef op maandag 25 juli 2005 @ 13:00:
[...]
Ik ook niet , maar wie zegt dat het op recordniveau moet? In veel situaties kun je je datamodel zodanig opbouwen dat een gebruiker sommige tabellen wel mag zien en andere niet. Je kent de rechten dan op tabel-/ queryniveau toe.

Maar stel nou dat bijvoorbeeld bij een CRM werknemers alleen zelf toegevoegde relaties mogen beheren? Dan zit je al meteen op record niveau

[jochemd]

Wacky schreef op maandag 25 juli 2005 @ 13:57:

Maar stel nou dat bijvoorbeeld bij een CRM werknemers alleen zelf toegevoegde relaties mogen beheren? Dan zit je al meteen op record niveau

In SQL is dat heel simpel op te lossen. Maak de juiste updateable view aan en geef de medewerkers insert, update en delete permissies op de view:

SQL:

CREATE VIEW myrelations AS
SELECT *
FROM relations
WHERE addedby = CURRENT_USER
WITH CHECK OPTION

Als je database geen volledige implementatie van de SQL standaard heeft moet je misschien even de handleiding er op naslaan wat de equivalente syntax en functionaliteit is.

[Swa-baldie]

In Oracle kun je policies gebruiken voor autorisatie.

[gvanh]

Zelf heb ik (CMS) ook een - zoals Tedkees beschreef - centrale tabel voor "objecten". In de CMS omgeving is eigenlijk alles een object. In de objecten tabel staan properties voor de objecten, die alle objecten gemeen hebben (ownership, maar ook structuur, dus parent - child verhoudingen). In een losse tabel staan operations (lezen, schrijven, ...). Een koppeltabel zorgt voor de koppeling OBJECT - OPERATION - ROLE (iedere user heeft een Role).

Ieder type object heeft vervolgens een eigen tabel met object-specifieke info (bijvoorbeeld een tabel voor pagina's, met daarin 'title', 'content', etc.

Doordat alle objecten via de centrale objecten-tabel één structuur vormen (een pagina is onderdeel van een map, die op zijn beurt onderdeel is van een website), is het toekennen van permissies makkelijk te over-erven. Zo heeft een gebruiker automatisch schrijf-rechten op een pagina, als hij schrijfrechten heeft gekregen op de hele website, TENZIJ voor de map of de pagina is ingesteld dat hij géén schrijfrechten heeft.

Om te voorkomen dat de queries onnodig ingewikkeld worden, gebruik ik - zoveel mogelijk - één centrale functie voor het binnenhalen van objecten binnen het systeem. Dit is mede mogelijk door een systeem van overerving van objecten in PHP. Tot nog toe lijkt het systeem goed te werken en zijn de queries - ook bij een enkele duizenden objecten (maximale belasting tot nu toe) - nog erg snel.

[StevenK]

Voor rechten op objecten zou ik aan elk object een ACL hangen en ja, je krijgt dan meerdere joins, daar ontkom je niet aan, zeker als je ook nog eens met groepslidmaatschap enzo wil werken.

[alienfruit]

"Dit is mede mogelijk door een systeem van overerving van objecten in PHP"

[gvanh]

Ja, terminologie is weer erg brak, ik weet het.

Ik bedoel:

PHP:

class ObjectCommon {
  
  var $dbObjCommonTable = 'objects';

  var $dbObjSpecTable = '';

  function getFromDB($arg1, arg2, etc) {
    $sql = "SELECT * FROM {$dbObjCommonTable}, {$dbObjSpecTable} WHERE ....";
    return $this->getObjsFromDB($sql);
  }
}

class Page extends ObjectCommon {

  var $dbObjSpecTable = 'pages';

}

Dat is een beetje het idee.

[alienfruit]

Aha Ik dacht dat je wat engs ging doen met Reflection etc.

[ Voor 83% gewijzigd door alienfruit op 27-07-2005 11:59 ]

[gvanh]

Louter self-reflection, maar dan wel met behulp van een spiegel!

[ Voor 4% gewijzigd door gvanh op 27-07-2005 12:57 ]

[Verwijderd]

Ik ga 't toch proberen met een entity tabel (alle IDs, geldigheidsduur, eventueel andere generieke informatie), waaraan rechten gekoppeld zijn die ook in een tabel staan.
mbv. views wil ik proberen om het grootste gedeelte van deze koppelingen af te vangen, zodat m'n procedures dit niet constant zelf moeten doen. Ook hou ik op die manier dat stukje script goed onderhoudbaar, omdat het in die view maar 1x terugkomt.

Verdere details heb ik nu nog even niet, omdat ik 't nu allemaal moet gaan ontwerpen