Wie mag wat doen in jouw applicatie? Het klinkt als een bijzaak, iets wat je later wel uitwerkt. In de praktijk is het een van de zwaarste ontwerpvraagstukken in een maatwerk webapplicatie, en als je er te laat over nadenkt, betaal je er dubbel voor. Rollen en rechten zitten overal doorheen: in de navigatie, in de databasestructuur, in de API-endpoints, in de formulieren. Verander er later iets fundamenteels aan, dan raak je bijna alles aan.
Wat rollen en rechten precies inhouden
Elke webapplicatie heeft gebruikers, en die gebruikers doen niet allemaal hetzelfde. Een medewerker mag orders inzien maar niet verwijderen. Een manager ziet rapportages die een gewone medewerker niet te zien krijgt. Een klant logt in op een portaal en ziet alleen zijn eigen dossier, niet dat van de buurman. Dat onderscheid heet autorisatie: je bepaalt niet alleen wie er mag inloggen, maar ook wat iemand vervolgens mag doen.
Autorisatie is iets anders dan authenticatie. Authenticatie controleert of je bent wie je zegt dat je bent, doorgaans via een wachtwoord of een koppeling met een extern systeem. Autorisatie regelt wat je daarna kunt. Die twee worden in gesprekken over "een loginpagina" regelmatig door elkaar gehaald, maar ze vragen om heel andere technische oplossingen. Een aanmeldformulier bouwen duurt een dag. Een doorgedacht rechtensysteem dat past bij jouw bedrijfsprocessen kan weken kosten.
In Laravel werk ik doorgaans met een combinatie van gates en policies voor eenvoudige toewijzingen, en een apart pakket zoals Spatie Laravel Permission voor projecten waar rollen dynamisch beheerd moeten worden. Dat dynamische beheer is meteen een extra laag: wil je zelf rollen kunnen aanmaken en aanpassen zonder dat er een developer aan te pas komt? Dan heeft de applicatie een beheerscherm nodig, en dat beheerscherm heeft op zijn beurt ook weer rechten nodig.
De meest gemaakte inschattingsfout bij de offerte
Stel dat je een portaal laat bouwen voor medewerkers en klanten. Je geeft aan dat er twee typen gebruikers zijn. De developer rekent twee rollen in, bouwt twee weergaven en levert op. Drie maanden later blijkt dat accountmanagers wél facturen mogen zien maar niet mogen aanmaken, dat leidinggevenden de gegevens van hun eigen team mogen exporteren maar niet die van andere teams, en dat externe partners een aparte beperkte toegang nodig hebben. Dat zijn geen twee rollen, dat zijn er vijf of zes, met elk hun eigen uitzonderingslogica.
Dit is geen verzonnen scenario. Bedrijfsprocessen zijn zelden zo overzichtelijk als ze op papier lijken. Rechten volgen de hiërarchie van een organisatie, en die hiërarchie heeft altijd uitzonderingen. De fout zit niet bij de ondernemer die dit niet vooraf weet, de fout zit in projecten waar er niet expliciet naar gevraagd wordt. Een goede developer stelt die vraag wel degelijk: werk je met afdelingen, vestigingen, teams? Wie beheert de gebruikers? Wie mag gebruikers aanmaken of deactiveren? Zijn er tijdelijke toegangen nodig, zoals voor een stagiaire of een extern bureau?
Die vragen voelen in een eerste gesprek soms overdreven gedetailleerd, maar ze voorkomen meerwerk. Meerwerk dat bij dit soort wijzigingen niet alleen de module met rollen raakt, maar ook de database, de API-laag, de testscenario's en in veel gevallen de navigatiestructuur.
Hoe je dit in een projectscope verankert
Voordat er ook maar één scherm ontworpen wordt, is het verstandig om een rechtenmatrix op te stellen. Dat is geen technisch document, maar gewoon een tabel: welke rollen bestaan er, en welke acties mag elke rol uitvoeren op welk onderdeel van de applicatie? Denk aan het aanmaken, lezen, bewerken en verwijderen van gegevens, maar ook aan het exporteren van rapporten, het beheren van andere gebruikers, het bekijken van dashboards of het goedkeuren van aanvragen.
Zo'n matrix schrijf je idealiter samen op, jij als opdrachtgever en de developer als sparringpartner. Je hoeft de technische werking niet te kennen, maar jij kent de organisatie. Wie geef je nu toegang tot gevoelige informatie? Wie mag definitieve beslissingen nemen in het systeem? Dat zijn vragen die jij beantwoordt, en de developer vertaalt die antwoorden naar code. Als die vertaalslag vroeg in het project plaatsvindt, kost het een paar uur overleg. Als het halverwege de bouw gebeurt, kost het veel meer.
Een aandachtspunt dat ik hierbij altijd meeneem: datascheiding. Zeker bij portalen waar meerdere bedrijven of klanten inloggen, moet je nadenken over welke gebruiker welke rijen in de database mag opvragen. Dit heet multi-tenancy, en het vraagt om een bewuste keuze in de architectuur. Zet je alles in één database en filter je op een klantveld, of geef je elke klant een afgeschermde eigen dataset? Die keuze beïnvloedt niet alleen de veiligheid, maar ook de prestaties op langere termijn.
Onderhoud en beheer na oplevering
Na de livegang begint de praktijk. Medewerkers vertrekken, nieuwe collega's starten, rollen verschuiven. Als het rechtensysteem goed is gebouwd, beheer je dat zelf via een adminpanel zonder dat je steeds een developer nodig hebt. Als het halvegare constructies zijn, of rollen die hardcoded in de code zitten, dan is elk wijzigingsverzoek betaald werk.
Vraag bij een offerte altijd expliciet: kan ik zelf gebruikers aanmaken, rollen toewijzen en accounts deactiveren? Wie beheert de rollen zelf als er een nieuwe laag bijkomt? Wat kost het om een nieuwe rol toe te voegen? Die vragen klinken misschien alsof je mistrouwig bent, maar ze zijn volkomen normaal. Een systeem dat na oplevering volledig afhankelijk blijft van de developer voor basisbeheer is duurder dan het er bij de bouw uitziet.
Beveiliging speelt hier ook mee. Een slecht gebouwd rechtensysteem is een aanvalsvector. Als een gewone gebruiker door een fout in de autorisatielaag toch bij administratieve functies kan, heb je een datalek in handen. Dit soort kwetsbaarheden komt niet altijd voort uit slechte bedoelingen, maar gewoon uit overhaaste bouw of onvoldoende testen. Ik test rechten altijd expliciet met losse testaccounts per rol, juist om te controleren of de grenzen ook echt dicht zijn.
Tenslotte: vergeet logging niet. Een applicatie met gevoelige bedrijfsdata heeft er baat bij om bij te houden wie wat heeft gewijzigd. Heeft een medewerker een klantdossier aangepast, een prijs gewijzigd of een export gedraaid? Met een auditlog kun je dat terugvinden. Het is geen verplichting voor elk project, maar zodra privacy of compliance een rol speelt, zoals bij persoonsgegevens onder de AVG, is het iets om al in de ontwerpfase mee te nemen in plaats van achteraf toe te voegen.
Rollen en rechten zijn uiteindelijk een spiegel van hoe jouw organisatie werkt. De techniek volgt de structuur van je bedrijf, niet andersom. Als je die structuur helder hebt uitgedacht voordat de bouw begint, voorkom je de verrassingen die achteraf het meest kosten. En als je er niet zeker van bent hoe je dat in kaart brengt: een goede developer helpt je daarbij, dat is onderdeel van het werk.
Wil je een webapplicatie laten bouwen waar rollen, rechten en datascheiding van meet af aan goed zitten? Kijk dan op https://pimvdmolen.nl/diensten/webapplicaties voor wat ik op dat vlak doe, of neem direct contact op via https://pimvdmolen.nl/contact. Ik denk graag mee in de opzet, ook als je nog niet precies weet hoe jouw rechtenstructuur eruit moet zien.