Iemand toestaan namens een ander taken uit te voeren, kan in een reële zakelijke behoefte voorzien, maar mag niet betekenen dat wachtwoorden worden gedeeld of algemene toegang tot een account wordt verleend. In een PHP-applicatie moet bij een veilige delegatie duidelijk zijn wie handelt, namens wie, op welke resources diegene mag ingrijpen en hoelang. De delegatie moet ook kunnen worden ingetrokken en gecontroleerd.
Het doel is een concrete actie te autoriseren met behoud van de identiteit van beide personen. Dat vereist meer dan een scherm om machtigingen toe te kennen: het heeft gevolgen voor het datamodel, elk autorisatiepunt, asynchrone bewerkingen en tests. Door deze elementen in samenhang te ontwerpen, verklein je het risico dat een geldige delegatie op één scherm via een alternatieve route leidt tot te ruime toegang.
Onderscheid maken tussen delegatie, impersonatie en gedeelde toegang
Bij een delegatie blijft de identiteit van de geauthenticeerde gebruiker de identiteit die de bewerking start. Daarnaast registreert de applicatie dat deze gebruiker namens iemand anders handelt op basis van een beperkte autorisatie. De vertegenwoordigde persoon is niet ingelogd en mag niet als directe uitvoerder van het verzoek worden weergegeven.
Bij impersonatie verandert de effectieve identiteit waarmee het systeem een verzoek behandelt. Zonder specifieke beheersmaatregelen kan daardoor onduidelijk blijven wie de actie heeft uitgevoerd. Gedeelde toegang, bijvoorbeeld door inloggegevens te verstrekken, heft de scheiding tussen gebruikers op en maakt het moeilijker om toegang of bevoegdheden in te trekken en activiteiten aan de juiste persoon toe te schrijven. Voor een reguliere delegatiestroom is geen van deze benaderingen een vervanging voor een expliciete context met een actor en een vertegenwoordigde principal.
Gebruik voor beide rollen duidelijke namen in de code en logs. actor_id identificeert bijvoorbeeld degene die de bewerking uitvoerde en principal_id de persoon namens wie deze werd uitgevoerd. Vermijd ambigue namen zoals user_id in logs waarin die naar een van beide kan verwijzen.
Reikwijdte, resources en geldigheidsduur bepalen vóór de implementatie
Een bruikbare delegatie beschrijft nauwkeurig wat er wordt geautoriseerd. ‘Het account beheren’ is doorgaans te ruim. Je kunt de delegatie daarentegen beperken tot acties zoals taken bekijken, hun status bijwerken of op een verzoek reageren. Als acties verschillende gevolgen hebben, modelleer dan afzonderlijke machtigingen in plaats van lezen, bewerken, goedkeuren en verwijderen onder één algemene bevoegdheid te groeperen.
Bepaal ook de reikwijdte van de resources: een organisatie, project, takeninbox of specifieke set records. De machtiging om taken in één project te bewerken, mag niet ook toegang tot gegevens in een ander project verlenen, alleen omdat dezelfde gedelegeerde gebruiker daar via een andere functie toegang toe heeft.
De geldigheidsduur moet een duidelijk begin- en eindmoment hebben, plus een status waarmee de delegatie vóór het verstrijken kan worden ingetrokken. Bepaal welke tijdzone wordt gebruikt om datums weer te geven en houd interne vergelijkingen consistent. Als het beleid goedkeuring vereist of kettingdelegaties verbiedt, leg dat dan vast als een expliciete, toetsbare regel; laat het geen conventie van de gebruikersinterface zijn.
Autorisatie modelleren en bij elke bewerking controleren
Een relationeel schema kan een delegatie weergeven met velden zoals een identificatie, bevoegde actor, vertegenwoordigde principal, reikwijdte, acties, startdatum, vervaldatum, status, aanmaker en intrekkingsdatum. De precieze structuur hangt af van het domein: acties kunnen in een gerelateerde tabel of in een ander gevalideerd formaat worden opgeslagen, maar moeten zonder dubbelzinnige interpretatie kunnen worden opgevraagd en gecontroleerd.
De autorisatie moet de bevoegdheid van de principal scheiden van de aan de actor gedelegeerde autorisatie. Controleer voor de aangevraagde bewerking of de vertegenwoordigde principal regulier toegang tot de resource zou hebben en of de toepasselijke bedrijfsregels dit toestaan. Controleer vervolgens of de geauthenticeerde actor de ontvanger is van een geldige, niet-ingetrokken delegatie en of die delegatie de betreffende actie op die resource toestaat. De effectieve machtiging wordt begrensd door de toegang van de principal en de reikwijdte van de delegatie: de delegatie mag de actor niet meer acties of resources toekennen dan de principal kan autoriseren, en ook niet meer dan in de delegatie zelf is vastgelegd. Vereis niet dat de actor ook zelfstandig toegang tot de resource heeft; de actor kan juist dankzij de delegatie handelen. Pas wel de beperkingen toe die bij de identiteit van de actor horen, zoals authenticatie, lidmaatschap van de vereiste context of beveiligingscontroles voor de bewerking.
In de praktijk moet de controle het volgende omvatten:
- De actor is geauthenticeerd en de delegatie is aan deze actor verleend.
- De vertegenwoordigde principal is geldig in deze context en heeft regulier toegang tot de aangevraagde resource.
- De delegatie is actief op het moment van de bewerking, is niet ingetrokken en valt binnen de geldigheidsduur.
- De aangevraagde actie en resource vallen binnen de verleende reikwijdte, zonder de bevoegdheid van de principal te overschrijden.
- De bedrijfs- en beveiligingsbeperkingen die voor de actor en de bewerking gelden, worden nageleefd.
Centraliseer deze beslissing in een autorisatieservice of herbruikbaar beleid, in plaats van gedeeltelijke voorwaarden in controllers te herhalen. Roep die beslissing desondanks aan bij elke relevante bewerking: een beveiligde weergave beveiligt niet automatisch een API, download, bulkactie of beheerroute. In PHP kan de controller de geauthenticeerde actor ophalen, de delegatiecontext bepalen en de service vragen de actie op de specifieke resource te autoriseren. Ook de domeinlaag kan kritieke invarianten afdwingen wanneer een bewerking belangrijke gevolgen heeft.
Vertrouw een principal_id die vanuit de browser wordt verzonden niet als bewijs van autorisatie. De server moet de relatie tussen actor, principal, delegatie, resource en actie controleren aan de hand van betrouwbare gegevens. Ga er evenmin van uit dat het verbergen van een knop in de gebruikersinterface rechtstreekse aanroepen van het endpoint voorkomt.
Attributie behouden in auditlogs en asynchrone bewerkingen
Met een bruikbaar logboek kun je reconstrueren wat er is gebeurd zonder identiteiten met elkaar te verwarren. Bewaar voor elke relevante gebeurtenis de actor, vertegenwoordigde principal, actie, type en identificatie van de resource, datum, resultaat en verwijzing naar de toegepaste delegatie. Registreer afhankelijk van het risico ook de reden voor de bewerking of de correlatie-ID. Sla geen geheimen of onnodige persoonsgegevens op in de geschiedenis.
De attributie moet behouden blijven voor queues en achtergrondtaken. Als een gedelegeerd verzoek een taak inplant, moet het bericht een verifieerbare context met de actor, principal en autorisatieverwijzing bevatten, in plaats van afhankelijk te zijn van de websessie die dan niet meer beschikbaar is. Bepaal bij de uitvoering van de taak of opnieuw moet worden gecontroleerd of de delegatie nog actief is. Voor een actie die nog kan worden geannuleerd, voorkomt een controle op het moment van uitvoering doorgaans dat een ingetrokken delegatie een openstaande taak met verouderde machtigingen achterlaat. Als de bewerking al onomkeerbaar is vastgelegd, documenteer dan die grens en registreer het moment van autorisatie.
Bescherm de logs tegen ongeautoriseerde wijzigingen en beperk wie ze kan raadplegen. Auditlogging moet onderzoek en verantwoording ondersteunen, maar mag geen ongefilterde kopie van de operationele gegevens worden.
Verloop en intrekking als onderdeel van de flow ontwerpen
Verloop en intrekking zijn niet slechts statuswijzigingen op een scherm. Een sessie waarin een delegatiecontext is opgeslagen, kan verouderde opties blijven tonen. Daarom moet de serverautorisatie bij elk verzoek de actuele status controleren, ook als de gebruikersinterface eveneens wordt bijgewerkt. Als machtigingen worden gecachet, bepaal dan hoe die caches ongeldig worden gemaakt en welke maximale vertraging acceptabel is voordat een intrekking van kracht wordt.
Registreer bij intrekking wie deze heeft uitgevoerd en wanneer. Beoordeel expliciet de actieve sessies, uitgegeven tokens, taken in de queue en gekoppelde tijdelijke links. Ga er niet van uit dat het beëindigen van een sessie of wijzigen van een databaseveld al deze elementen automatisch ongeldig maakt. De juiste aanpak hangt af van het ontwerp, maar moet vaststaan voordat de flow in productie wordt genomen.
Grenzen en vaak over het hoofd geziene gevallen testen
Tests moeten zowel toegestane als geweigerde acties controleren. Neem minimaal de volgende gevallen op: de delegatie is nog niet geldig, verlopen of ingetrokken; de actor is niet de bevoegde gebruiker; de resource valt buiten de reikwijdte; de actie is niet toegekend; de principal is onjuist of heeft geen reguliere toegang tot de resource; en endpoints worden rechtstreeks aangeroepen terwijl de gebruikersinterface ze niet toont. Neem ook een positief geval op waarin de actor geen eigen toegang tot de resource heeft, maar de principal wel toegang heeft en de delegatie de actie en resource omvat. Zo controleer je dat het systeem de eigen machtigingen van de actor niet verwart met gedelegeerde bevoegdheid.
Voeg tests toe voor tijdsgrenzen, gelijktijdige wijzigingen en indirecte effecten. Controleer bijvoorbeeld wat er gebeurt als een delegatie wordt ingetrokken terwijl een bewerking bezig is of een taak in de wachtrij staat, en of een actie op een taak meldingen, exports of secundaire wijzigingen veroorzaakt. Controleer of deze effecten de juiste attributie behouden en de reikwijdte niet uitbreiden.
Scheid unittests van het autorisatiebeleid van integratietests die routes, persistentie en queues doorlopen. Een test die alleen de beslismethode controleert, bewijst niet dat alle routes deze aanroepen; een UI-test toont evenmin aan dat de server beschermd is.
Checklist vóór publicatie
- Zijn de actor en de vertegenwoordigde principal duidelijk van elkaar te onderscheiden in de code, gebruikersinterface en auditlogs?
- Beperkt elke delegatie de acties, resources en geldigheidsduur, en worden ongeldige combinaties voorkomen?
- Controleert het beleid de toegang van de principal en beperkt het de actor tot de gedelegeerde reikwijdte, zonder eigen toegang tot de resource te vereisen?
- Controleert elke bewerking op de server de identiteit, status, geldigheidsduur, reikwijdte en actie?
- Heeft intrekking gevolgen voor sessies, tokens, caches en openstaande taken volgens een vastgelegd beleid?
- Kunnen acties aan de juiste persoon worden toegeschreven zonder onnodige informatie op te slaan?
- Dekken de tests weigeringen, tijdsgrenzen, geldige delegaties zonder eigen toegang van de actor en indirecte effecten?
Een delegatie is veilig wanneer ze niet wordt verward met toegang tot het account van iemand anders en wanneer elke actie kan worden gerechtvaardigd door de bevoegdheid van de principal en een geldige, beperkte delegatie. Als het team niet precies kan aangeven wie handelde, namens wie, op welke resource en met welke machtiging, moet de flow verder worden ontworpen voordat deze in productie wordt genomen.
