[php] Authentication & Authorization

[Verwijderd]

Ik maak gebruik van het CodeIgnitor Framework en wil nu een authenticatie en authorizatie functies toevoegen.

Ik dacht er aan om een Library te maken voor de authenticatie samen met een model voor interactie met de db en vervolgens een Helper te maken met functies voor authorizatie.

Echter hoe ik die authorizatie moet aanpakken ben ik nog niet helemaal uit...

Enkele mogelijkheden (Als ik mogelijkheden over het hoofd zie meld het mij gerust!)

Database:
Een tabel met de gegevens van de gebruiker en dan een veld met daarin een getal voor de authenticatie.
Vorm van het getal: Keuze 1 -> elke functie 1 bit geven die 0 of 1 kan zijn en zo een reeks bits vb: 100100
Of Keuze 2 -> gebruik maken van 1+2+4+8 dus vb 10 betekent dan toestemming voor de tweede en vierde functie

Ofwel een nieuwe tabel die gekoppeld wordt met de user tabel dmv user_id en dan vervolgens elke functie een veld geven en daar een true or false (bool).

Sessie:
Vervolgens zal bij het inloggen deze rechten ook naar een sessie geplaatst worden.
Hoe doe ik dit het beste?
Een array maken met elk een true or false (bool).
Of de bits houden of ...

Ik vraag jullie dus eigenlijk wat gebruiken jullie? Waarom gebruik je dit en wat zijn de voordelen?

Voor de authenticatie gebruik ik dus een library, voor de interactie met de database een model (zoals het hoort) en dan voor de authorizatie een helper (verzameling van functies die rechtstreeks in de controller/library te gebruiken zijn).

[kluyze]

Verwijderd schreef op dinsdag 27 juli 2010 @ 22:17:

Database:
Een tabel met de gegevens van de gebruiker en dan een veld met daarin een getal voor de authenticatie.
Vorm van het getal: Keuze 1 -> elke functie 1 bit geven die 0 of 1 kan zijn en zo een reeks bits vb: 100100
Of Keuze 2 -> gebruik maken van 1+2+4+8 dus vb 10 betekent dan toestemming voor de tweede en vierde functie

Ofwel een nieuwe tabel die gekoppeld wordt met de user tabel dmv user_id en dan vervolgens elke functie een veld geven en daar een true or false (bool).

Optie 4, een 3de tabel met de userid gekoppeld aan de functieid, zo moet je in die tabel niet voor ELKE user - functie relatie een rij hebben, hetzelfde als jouw optie 3, maar alleen de true in de tabel bewaren.

Tussen optie 1 en 2 zit geen verschil, als je binair 0001 + 0010 doet krijg je 0011 of 1 + 2 = 3. Dan zou ik het zeker niet in binaire vorm in een string steken en zo opslaan, maar gewoon houden op een integer, dat is altijd sneller om te parsen etc.

Over jouw vraag, wat wij gebruiken dan moet je wat verder naar je applicatie kijken. Wil je simpel een 5 tal functies en een user of 3-4 bedienen dan maakt het zoveel niet uit. Ga je echter naar grotere projecten ed. Dan is het misschien handig om je users op te delen in groepen en de groepen bepaalde rechten geven. Zo lijkt me dat de meeste users toch ruwweg dezelfde rechten zullen hebben. En dat er een aantal beperkte users wat meer rechten nodig hebben.

[ Voor 24% gewijzigd door kluyze op 27-07-2010 23:14 ]

[RedHat]

TS verkeerd begrepen.

[ Voor 132% gewijzigd door RedHat op 27-07-2010 23:22 ]

[Cartman!]

Bedenk goed dat je met bitwise-rechten tegen een limiet aankomt van 32 of 64 afhankelijk van je OS. Je kunt er dus t best vanuit gaan dat je dan 32 verschillende rechten maximaal kunt hebben. Misschien voor jou voldoende maar voor genoeg projecten niet.

Wat ik heb gemaakt en wat tot nu toe voldoende is geweest: tabel users, tabel groepen, tabel rechten. Users kunnen in meerdere groepen en aan groepen hangen bepaalde rechten. Eventueel kun je rechten per user over de groepsrechten heenzetten. In m'n code check ik dan of de gebruiker rechten x en y heeft en als dat zo is returned ie true, en anders false. In de groepen zit nog een conflicthandler die aangeeft wat er met je rechten moet gebeuren als ie het recht al eerder aan of uit gezet heeft.

[RobIII]

Cartman! schreef op woensdag 28 juli 2010 @ 11:44:
Wat ik heb gemaakt en wat tot nu toe voldoende is geweest: tabel users, tabel groepen, tabel rechten. Users kunnen in meerdere groepen en aan groepen hangen bepaalde rechten.

Klassiek (versimpeld) gevalletje RBAC. Ik gebruik 't in veel rechttoe-rechtaan projecten ook.
Tabellen zijn dan: users, roles, permissions, userroles, rolepermissions. De eerste 3 spreken voor zich, de laatste 2 zijn koppeltabellen voor de eerste 3. Roles en permissions hoeven feitelijk niet meer te bevatten dan een pk en naam/omschrijving. En de koppeltabellen hoeven weer niet meer te bevatten dan 2 FK's. Simpeler dan dat krijg je het niet en 100x flexibeler dan werken met bits, vooral omdat je niet beperkt bent in het aantal rechten noch rollen/groepen.

Cartman! schreef op woensdag 28 juli 2010 @ 11:44:
In de groepen zit nog een conflicthandler die aangeeft wat er met je rechten moet gebeuren als ie het recht al eerder aan of uit gezet heeft.

Daarmee maak je zaken complexer (en vaak minder doorzichtig voor beheerders) dan nodig. Gewoon uitgaan van 0 rechten en zodra je een recht érgens verworven hebt omdat je in groep-X of Y zit heb je het recht gewoon. Voila. Ik zie ook meestal af van hiërarchische structuur in groepen e.d. want dat maakt het voor veel beheerders ook al weer een stuk minder overzichtelijk (en nu heb ik het dus even niet over systeembeheerders die vaak wel wat gewend zijn, maar bijv. "CMS beheerders" ofzo).

[ Voor 28% gewijzigd door RobIII op 28-07-2010 11:57 ]

[Cartman!]

Dat is een keuze ja, ik vind het handig om iemand bijv. alle rechten te geven en een 2e persoon ook maar omdat ie soms ineens dingen verwijderd die niet verwijderd moeten worden voeg je gewoon een groep toe die dat verwijder-recht weghaalt. Dat scheelt je het aanmaken van een 2e groep die alle rechten heeft van de eerste behalve dat verwijder-recht. Kwestie van wat je handig vind.

De beheerder kan in het CMS van een gebruiker netjes zijn rechten bekijken en als er een recht later wordt afgenomen wordt dit ook getoond. Een eventuele onduidelijkheid wordt daar snel mee gespot. Maar zoals ik zei, kwestie van smaak hoe je dat wilt aanpakken.

[TheNephilim]

RobIII schreef op woensdag 28 juli 2010 @ 11:52:
Klassiek (versimpeld) gevalletje RBAC. Ik gebruik 't in veel rechttoe-rechtaan projecten ook.
Tabellen zijn dan: users, roles, permissions, userroles, rolepermissions. De eerste 3 spreken voor zich, de laatste 2 zijn koppeltabellen voor de eerste 3. Roles en permissions hoeven feitelijk niet meer te bevatten dan een pk en naam/omschrijving. En de koppeltabellen hoeven weer niet meer te bevatten dan 2 FK's. Simpeler dan dat krijg je het niet en 100x flexibeler dan werken met bits, vooral omdat je niet beperkt bent in het aantal rechten noch rollen/groepen.

Kun je dit misschien eens toelichten met een voorbeeldje, ik snap de permissions, maar de roles kan ik me niet veel bij voorstellen.

Ik werk op dit moment met een user -> user_group -> group -> group_permissions model. Voor de laatste tabel bijv. 1 (group_id), 'change_user' (permissie). Hier komt volgens jou dus nog 1 koppel tabel bij van group_permissie naar permissie. Nogmaals, wat doe je met de roles?

[MueR]

Als je het woord "group" in je model vervangt door "role", wordt het dan duidelijker? Feitelijk zijn rollen niets anders dan groepen van rechten.

Stel ik heb onderstaande rechten (tokens) beschikbaar:
- admincp-access
- page-list
- page-create
- page-update
- page-delete
- stats-list
- user-list
- user-create
- user-update
- user-delete

Mijn rollen zijn dan bijvoorbeeld (toegespitst op een afgesloten admin panel):
- Administrator: (krijgt automatisch alle tokens die het systeem kent)
- Editor: admincp-access, stats-list, page-list, page-create, page-update, page-delete
- Crew: admincp-access, stats-list

Zo kan je gemakkelijk rollen aanmaken die op specifieke taken ingericht zijn. Iemand kan bijvoorbeeld een rol "page editor" hebben, waarmee alle pagina beheer functies tot zijn beschikking staan, naast een rol "finance", waarmee bepaalde financiele overzichten beschikbaar zijn. Zo kan je per user dus een systeem inrichten, waarmee je dus alleen functionaliteit ontsluit die mensen echt nodig hebben.

[TheNephilim]

Ah, oké ... dan doe ik feitelijk niet veel anders dus. Bedankt voor de uitleg, ik ga eens even bekijken of ik dit nog aan kan passen

[RobIII]

MueR schreef op woensdag 28 juli 2010 @ 12:43:
<snip>

Precies. Het maakt zaken ook duidelijk(er) als je in rollen denkt. Je hebt verkopers, inkopers, typistes, boekhouding, directie, asemblagemedewerkers en ga zo maar door. Als je gewoon algemene rollen ("verkoper") maakt en de juiste rechten aan die rollen hangt kun je mensen makkelijk dmv koppelen aan de juiste rol(len) rechten toekennen zonder je te hoeven verdiepen in alle, bij wijze van, 151 rechten die er zijn. Mensen die uitzonderingen zijn kun je dan nog eventueel specialistische rollen toekennen. En mocht er in het systeem een bepaalde functie bij komen dan ken je de bijbehorende rechten aan de juiste rollen en iedereen profiteert er meteen van mee. Dat is vele malen makkelijker dan op gebruikersniveau allerlei bitjes gaan bijhouden.

[SeatRider]

RobIII schreef op woensdag 28 juli 2010 @ 13:31:
[...]

Precies. Het maakt zaken ook duidelijk(er) als je in rollen denkt. Je hebt verkopers, inkopers, typistes, boekhouding, directie, asemblagemedewerkers en ga zo maar door. Als je gewoon algemene rollen ("verkoper") maakt en de juiste rechten aan die rollen hangt kun je mensen makkelijk dmv koppelen aan de juiste rol(len) rechten toekennen zonder je te hoeven verdiepen in alle, bij wijze van, 151 rechten die er zijn. Mensen die uitzonderingen zijn kun je dan nog eventueel specialistische rollen toekennen. En mocht er in het systeem een bepaalde functie bij komen dan ken je de bijbehorende rechten aan de juiste rollen en iedereen profiteert er meteen van mee. Dat is vele malen makkelijker dan op gebruikersniveau allerlei bitjes gaan bijhouden.

Wat is dat bitje wat je per gebruiker bijhoudt anders dan een rol? Zeker als TS hetzelfde bitje hergebruikt voor meerdere functies/knoppen

[RobIII]

SeatRider schreef op woensdag 28 juli 2010 @ 13:33:
[...]

Wat is dat bitje wat je per gebruiker bijhoudt anders dan een rol? Zeker als TS hetzelfde bitje hergebruikt voor meerdere functies/knoppen

Dan ga jij z'n project maar onderhouden

[Cartman!]

SeatRider schreef op woensdag 28 juli 2010 @ 13:33:
[...]

Wat is dat bitje wat je per gebruiker bijhoudt anders dan een rol? Zeker als TS hetzelfde bitje hergebruikt voor meerdere functies/knoppen

De beperkingen die dus van toepassing zijn op de bitjes. Als jij een 33e recht wilt hebben kan het niet dus

offtopic:
tenzij je zeker weet dat je alleen op 64bit systemen werkt maar dan heb je hetzelfde probleem als je een 65e recht wilt toevoegen

Overigens heeft dit topic verder niks te maken authentication tot nu toe

[MueR]

RobIII schreef op woensdag 28 juli 2010 @ 13:31:
Mensen die uitzonderingen zijn kun je dan nog eventueel specialistische rollen toekennen.

Of losse tokens Ik maak meestal wel een mogelijkheid om tokens aan individuele gebruikers toe te wijzen, zonder daar specifiek een rol voor aan te hoeven maken.

[Cartman!]

Daar heb ik dus een koppeltabel voor tussen gebruikers en rechten, om per user rechten toe te voegen of weg te nemen. Heb je ook geen losse rol nodig voor die ene user.

[TheNephilim]

Cartman! schreef op woensdag 28 juli 2010 @ 16:50:
Daar heb ik dus een koppeltabel voor tussen gebruikers en rechten, om per user rechten toe te voegen of weg te nemen. Heb je ook geen losse rol nodig voor die ene user.

Dat is in mijn applicatie niet nodig. Je hebt de standaard gebruikers en een aantal types moderators en beheer. Alle rechten die er meer/extra zijn, zijn voor moderators etc. Al moet ik nog wel even vinden hoe ik het systeem voor de applicatie zelf koppel aan die van het forum.

Want de rechten van een forum kunnen gekoppeld zijn aan 1 board of categorie. Terwijl die bij de applicatie-permissies gewoon globaal zijn.

[Cartman!]

Ik heb daar nooit mee te maken gehad nog, ik ben wel benieuwd wat RobIII en Muer daar over te melden hebben. Krijg je dan 'gewoon' rechten per categorie of kan dat slimmer?

[MueR]

Je kan het natuurlijk uitbreiden met een nullable kolom ForumId. Indien ForumId NULL is bij een rol, is het een globale rol, anders gelden de rechten alleen op dat forum. Idem voor losse tokens. Het is de meest simpele variant om dit op een aantal niveaus te schalen.

[Cartman!]

En als je iemand rechten wilt geven voor 6 fora? Voeg je dan 6 keer dat recht toe met een ander forumId of maak je dan al een extra tabel aan?

[MueR]

Enkele van de rechtensets op mijn account hier:

Moderator Webdesign
Moderator Graphics
Moderator Programmeren
Moderator SE&A

Dat is per forum dus een rol/groep met rechten. Het is zeker in het begin even klotewerk om alles aan te maken, al kan je dat vast automatiseren, en toe te wijzen aan de juiste mensen. Daarna is het eigenlijk maar weinig werk.

[Cartman!]

Duidelijk, dan komt wat in m'n hoofd zat overeen met wat je beschrijft Thanks.

[TheNephilim]

Bedankt voor de tips!

Inderdaad is per modgedeelte een groep nog niet zo gek. Ik heb nog geen ondersteuning ingebouwd voor het lid zijn van meerdere groepen, maar dat is zo moeilijk niet.

Dit ga ik eens even fijntjes uitwerken!

[MueR]

Daar heb je geen extra ondersteuning voor nodig hoor? Je haalt gewoon alle tokens op van alle groepen waar user lid van is. Of dat nu uit 1 groep of uit 30 groepen komt boeit niet. Het enige waar je wel vast over na moet denken is hoe je rollen wil opzetten die bepaalde functionaliteit expliciet uitzetten.

[Cartman!]

En daar komt conflicthandling dus om de hoek kijken

[TheNephilim]

Nou dat klopt, maar moest nog wel het 1 en ander ombouwen om alle tokens op te halen ipv alleen van 1 groep. Daarnaast enkele aanpassingen in de scripts... maar dat is het dan ook.

Werkt perfect!