ACL of toch wat anders?

[Standeman]

Ik ben bezig met de architectuur voor webapplicatie en focus me op dit moment op autorisaties. Als je wat gaat googlen kom je uit op ACL, maar ik heb er een beetje mijn twijfels bij.

Ik zal even schetsen wat de situatie gaat worden.

We hebben een lijst met in -en uitkloktijden (en een zooi andere data zoals locatie). Het aantal records loopt in de miljoenen. Deze records zullen door verschillende users (rond de 10.000) bekeken worden. Het is uiteraard niet de bedoeling dat iedereen zomaar alles mag zien, aangezien de gegevens sowieso privacygevoelig zijn.

Er zijn een aantal rollen gedefinieerd die iemand kan zijn. Naar gelang je daalt in de hiërarchie zal de persoon minder van deze kloktijden kunnen inzien.

code:

Admin --> Manager --> Regional Manager --> Supervisor --> Employee

De Admin kan alles zien en de Employee alleen zijn eigen tijden. Een Manager kan alleen de kloktijden van zijn eigen Regional Managers zien. Het zijn dus allemaal 1:N relaties


Wanneer ik dan naar ACL kijk lijkt het de bedoeling dat ik voor elke rol / user moet gaan vastleggen welke rechten op wel object instanties ze hebben.

Met andere woorden wordt de tabel acl_object_identity en vooral acl_entry (zie link) echt enorm! De laatste kan zomaar tien -tot honderd miljoen records gaan bevatten. Overzichtelijk wordt het in ieder geval niet. Tevens vraag ik me ook af wat de impact gaat worden wanneer de ACL lists ingeladen worden voor een Admin qua memory usage e.d. Ik verwacht zo'n duizend concurrent users.

Ik zat me dus een beetje af te vragen of dit de beste oplossing is. Ik heb onderbuikgevoel dat ik met een volledige ACL list meer problemen op de hals ga halen (performance, memory, usabillity) dan ik daadwerkelijk wil.

Dit alles speelt zich overigens af in het J2EE domein.

[kwaakvaak_v2]

Ik zou ook wat onderzoek doen naar ABAC, op basis van attributen bepalen wie wat mag zien. Op die manier kun je op het laagste niveau bijv. een bitwise attribute toevoegen aan je record, en met een rules systeem bepalen of iemand dat record mag zien. Dat scheelt je in ieder geval de mega acl_entry tabel. Vereist wel dat je van te voren goed nadenkt over je attribute systeem.

zie bijv. http://www.axiomatics.com...ers/abac-beyond-rbac.html

[ValHallASW]

Als de rechten direct uit het record volgen (dwz: record van * ValHallASW kan door * ValHallASW , supervisor, RM, M en A gelezen worden) dan is het toch niet nodig om los die rechten bij te houden? Ik zou zeggen dat een

SQL:

select * from tijden
where uid in (lijst van uids die ingezien mogen worden)

in feite al je hele probleem oplost. Je kunt die lijst van uids dan ofwel in je code opbouwen (a la Formatting a multi-level menu using only one query), ofwel door gebruik te maken van een slimme boomstructuur (Wikipedia: Nested set model).

[kwaakvaak_v2]

ValHallASW schreef op woensdag 21 oktober 2015 @ 13:21:
Als de rechten direct uit het record volgen (dwz: record van * ValHallASW kan door * ValHallASW , supervisor, RM, M en A gelezen worden) dan is het toch niet nodig om los die rechten bij te houden? Ik zou zeggen dat een

SQL:

select * from tijden
where uid in (lijst van uids die ingezien mogen worden)

in feite al je hele probleem oplost. Je kunt die lijst van uids dan ofwel in je code opbouwen (a la Formatting a multi-level menu using only one query), ofwel door gebruik te maken van een slimme boomstructuur (Wikipedia: Nested set model).

Persoonlijk denk ik dat een IN query niet echt performed als je daar zeg 50.000 ID's in stopt. En nested set heeft als nadeel dat het verplaatsen van data in de nested set een relatief prijzige operatie is.

[CurlyMo]

Hier hebben we ooit deze implementatie bedacht:

code:

.                         |      Groepen    |  Gebruikers |
                          | Manager | Admin | Henk | Piet |
- Alle medewerkers zien        1        0       0     -1

De admin groep erft alle permissies van de managers groep. De admin groep heeft dus al permissie bij AMZ 1 oftewel toegestaan.

Henk is de hoofdontwikkelaar. Zijn permissie voor AMZ staat op 0 dus hij krijg 1 oftewel toegestaan. Piet is ook ontwikkelaar, maar zijn rechten voor AMZ staan op 0 oftewel ingetrokken.

Op deze manier kan je met overerving, default permissies en specifieke permissies werken. De vaststelling is simpel:
(Groep + Gebruiker >= 1) = Toegestaan
(Groep + Gebruiker <= 0) = Niet toegestaan

Daarbij geldt ook:
(Groep + Groep >= 1) = 1
(Groep + Groep == 0) = 0
(Groep + Groep < 0) = -1

Je kunt hiermee groepen permissies laten overerven van andere groepen, permissies van andere permissies, gebruikers van andere gebruikers en elke andere mix.

Dus mocht de manager groep nu een -1 hebben en de admin groep een 1, dan was het toch 0 gebleven.
Een per groep ingetrokken permissie (-1) kan dan nooit overruled worden. Een per groep neutrale permissie (0) kan wel overruled worden.

[Cartman!]

Ik werk zelf altijd met RBAC omdat je dan niet per user alle objecten hoeft af te gaan. Elke user heeft 0, 1 of meerdere rollen, daarop evt 0,1 of meerdere uitzonderingen (bijv. iemand moet alles kunnen maar vanwege historische reden wordt enkel los een delete recht ingetrokken). Rollen kunnen elkaar ook overerven daarnaast.