Rechten in een SaaS-product: rollen, geen vinkjes

Dit is de derde en laatste van de beslissingen die je in een SaaS-product later bijna niet meer rechttrekt. De eerste ging over hoe je klanten uit elkaar houdt, de tweede over hoe je geld rekent. Deze gaat over wie wat mag, en hij loopt bijna altijd op dezelfde manier vast.

Hoe het begint

De eerste klant vraagt of een medewerker wel facturen mag zien maar geen salarissen. Dat is een redelijk verzoek en er is een redelijke oplossing: een vinkje op het gebruikersprofiel.

De tweede klant wil hetzelfde, maar dan andersom. De derde wil het per afdeling. Bij de tiende staan er veertig vinkjes op een scherm dat niemand meer durft aan te raken, en bij de twintigste is de meest gestelde supportvraag geworden: welke vinkjes moet ik aanzetten om deze persoon te laten doen wat hij gisteren ook al deed?

Dat is het moment waarop het te laat is, en het is te laat om drie redenen tegelijk:

• Het is niet te testen. Veertig onafhankelijke vinkjes zijn meer combinaties dan er atomen in je testsuite passen. Je test er in de praktijk vijf, en de andere combinaties bestaan alleen bij klanten.
• Het is niet uit te leggen. Een klant kan niet meer beschrijven wat “boekhouder” bij hem betekent, want het is geen begrip meer maar een verzameling toevalligheden.
• Het is niet te migreren. Voeg je een functie toe, dan moet je voor elke bestaande gebruiker raden of die het mag. Elk antwoord is fout voor iemand.

Wat er wel werkt

Rechten horen bij een rol, en een gebruiker krijgt een rol. Niet omgekeerd.

Dat betekent concreet:

Er is een vaste, kleine verzameling rechten. Ze zijn benoemd op wat iemand kan doen — factuur.aanmaken, boekhouding.lezen — en niet op welk scherm ze zitten. Schermen verhuizen, handelingen niet.

Rollen zijn samenstellingen van die rechten, en er zijn er weinig. Als er twintig rollen ontstaan, zijn het geen rollen meer maar vinkjes met een andere naam.

Een klant mag een eigen rol samenstellen, maar alleen uit de vaste verzameling. Dat is de flexibiliteit die klanten werkelijk vragen, en het is de enige vorm die je nog kunt testen: het aantal rechten blijft eindig, dus de matrix blijft eindig.

Het verschil met vinkjes lijkt cosmetisch en is het niet. Bij vinkjes is het antwoord op “mag deze persoon dit?” een eigenschap van de persoon. Bij rollen is het een eigenschap van het systeem, en dat is het verschil tussen iets wat je kunt nakijken en iets wat je moet reconstrueren.

Rechten zijn niet hetzelfde als bereik

Dit is de fout die ook mensen maken die het bovenstaande goed doen.

Een recht zegt wat iemand mag. Het zegt niet waarover. Dat tweede is het bereik, en dat hoort bij de klantscheiding — bij de tenant, en soms bij een laag daarboven.

Bij booxx staat er een administratiekantoor tussen: een kantoor ziet zijn eigen klanten, een klant ziet alleen zichzelf. Dat is geen recht maar een grens, en hij staat daarom niet in de rollentabel maar in de database, als beleid op de rij. Zou je het als recht modelleren — mag_klanten_van_kantoor_zien — dan hangt de scheiding tussen twee bedrijven aan een if in de applicatie, en dan is het dezelfde vergissing als een tenantfilter zonder tweede slot.

De vuistregel: rol bepaalt wat, grens bepaalt waar, en die twee mogen elkaar nooit vervangen.

Vier regels die het overeind houden

Weiger standaard. Een handeling zonder expliciet recht is verboden, niet toegestaan. Een nieuw eindpunt dat niemand aan een rol heeft gekoppeld hoort onbereikbaar te zijn — hinderlijk tijdens het bouwen, en de goede kant op fout.

Controleer op de server, altijd. Een knop verbergen is vriendelijkheid, geen beveiliging. De controle hoort op de plek waar de handeling werkelijk gebeurt, en die plek is er precies één per handeling.

Houd bij wie de rol heeft veranderd. Een rolwijziging is de enige gebeurtenis die achteraf verklaart waarom iemand bij iets kon. Zonder dat spoor is elk incidentonderzoek giswerk. Dit is bovendien het goedkoopste om vooraf te doen en het duurste om te reconstrueren, want de geschiedenis die je niet hebt opgeslagen komt niet terug.

Eén plek waar het antwoord vandaan komt. Zodra er twee functies zijn die allebei “mag deze persoon dit” beantwoorden, gaan ze uit elkaar lopen. Meestal binnen een maand, en altijd stil.

De test die ertoe doet

De nuttigste test hier is een matrix: voor elke rol, voor elk eindpunt, mag het of mag het niet. Dat is saai om te schrijven en het is het beste geld dat je in je testsuite steekt.

Er zit één truc in die het verschil maakt. Laat de test de lijst van eindpunten uit de applicatie zelf halen in plaats van hem over te typen. Dan faalt hij automatisch zodra iemand een eindpunt toevoegt zonder erover na te denken. Een matrix die je met de hand bijhoudt, dekt precies de code van vorig jaar.

Het is ook het soort werk dat zich uitstekend leent voor de nachtploeg van agents die bij ons de dekking aanvult: het is volledig af te leiden uit de code, het is repetitief, en het is precies daarom het werk dat mensen blijven uitstellen.

Wat het kost om het later te doen

Vooraf: een tabel met rechten, een tabel met rollen, een koppeling, en één functie die de vraag beantwoordt. Een dag, misschien twee.

Achteraf: je moet voor elke bestaande gebruiker afleiden welke rol hij eigenlijk had. Dat kan alleen door zijn vinkjes te interpreteren, en die zijn in de loop der jaren door verschillende mensen aangezet om verschillende redenen. Elke afleiding die je maakt, geeft iemand meer of minder rechten dan gisteren — en dat merk je pas als het misgaat, want niemand belt de helpdesk om te melden dat hij te veel mag.

Dat was de lijst

Klantscheiding, geld, rechten. Alles daarbuiten mag je later veranderen, en dat is ook precies waarom deze drie de aandacht verdienen die ze zelden krijgen.

Bouwen wij dit voor u in? Dat is wat we doen — en voor een bestaand product is doorontwikkelen meestal het gesprek waar dit begint.