Brugerroller og rettigheder i SaaS: sådan designer du dem fra start

Brugerroller i en SaaS designer du bedst ved at holde tre ting adskilt fra første dag: hvem brugeren er, hvilken kundekonto brugeren hører til, og hvad brugeren må gøre i den konto. Start med tre eller fire faste roller som ejer, administrator og medlem, men lad koden tjekke konkrete rettigheder som "må eksportere fakturaer" i stedet for "er admin". Så kan du senere tilføje nye roller, eller lade kunderne lave deres egne, uden at skrive halvdelen af systemet om.

Rettigheder er usynlige for kunden indtil de går galt. Så er det enten et sikkerhedshul eller en kunde der ikke kan bruge produktet, fordi den rolle de har brug for, ikke findes.

Den korte version

Rettigheder kan bygges på tre niveauer. Du behøver ikke det øverste fra start, men det du bygger først, skal kunne vokse derop.

Min anbefaling til næsten alle nye produkter er niveau 2. Brugeren ser kun faste roller, men under motorhjelmen tjekker koden rettigheder. Det koster næsten det samme at bygge som niveau 1, og det er det eneste af de to første niveauer der kan vokse til niveau 3 uden en ombygning.

Roller er ét af de fundamenter der er billige at lægge rigtigt og dyre at rette bagefter. De andre gennemgår jeg i guiden til at bygge en SaaS fra idé til betalende kunder.

Fire begreber du skal holde adskilt

Det meste rod i rettigheder opstår fordi fire forskellige ting bliver blandet sammen i én kolonne på brugertabellen.

• Login (autentificering) svarer på hvem du er: e-mail og adgangskode, et link sendt på mail eller SSO (log ind via virksomhedens eget login-system).
• Konto er den kunde der betaler, typisk en virksomhed. I fagsprog kaldes den ofte en tenant.
• Medlemskab er forbindelsen mellem en bruger og en konto. Det er her rollen hører til.
• Rettighed (autorisation) svarer på hvad du må i den konto, fx se fakturaer, invitere brugere eller ændre abonnementet.

Pointen med medlemskabet er at den samme person kan have forskellige roller forskellige steder. En revisor kan være ejer af sit eget firmas konto og have læseadgang hos ti klienter. En ekstern konsulent kan være medlem hos to kunder på én gang. Gemmer du rollen direkte på brugeren, kan systemet ikke udtrykke det.

Konto og medlemskab hænger tæt sammen med hvordan kundernes data holdes adskilt. Roller styrer hvad brugere i samme virksomhed må. Adskillelsen mellem virksomheder er en anden mekanisme, og den har jeg beskrevet i indlægget om multi-tenant-arkitektur og dataadskillelse.

Hold også dine egne medarbejdere ude af kundernes rollemodel. Din supportmedarbejder er ikke "administrator" hos kunden. Det er en anden slags adgang med egne regler, og den vender jeg tilbage til i trin 6.

Hvorfor det bliver dyrt at hardcode "admin" fra dag ét

Den hurtigste måde at bygge rettigheder på er en kolonne is_admin på brugeren og et tjek i koden hver gang noget skal beskyttes. Det virker indtil produktet møder rigtige kunder.

Tjekket ender med at ligge overalt

Den første kunde der beder om en bogholder som må se fakturaer, men ikke ændre brugere, sender dig på jagt i hele kodebasen. Hvert eneste admin-tjek skal vurderes: skal bogholderen have lov her eller ej? Glemmer du ét sted, har du enten en fejl eller et sikkerhedshul.

Forskellen ser lille ud i koden:

if ($user->is_admin) {
    // vis knappen og tillad handlingen
}

if ($user->can('export', Invoice::class)) {
    // vis knappen og tillad handlingen
}

Det første spørger om en rolle. Det andet spørger om en rettighed, og hvilke roller der har den, står ét sted. I Laravel hedder de steder gates og policies, og de er indbygget i frameworket.

Rollen ligger på brugeren og ikke på medlemskabet

Så snart en bruger skal være med i to konti, skal datamodellen laves om, og eksisterende data skal flyttes. Det er typisk en af de ombygninger der trækker længst ud, fordi den rammer login, invitationer, e-mails og alle de steder hvor systemet slår "den aktuelle konto" op.

Din egen superadmin deler flag med kundens admin

Bruger dit eget supportteam og kundens administrator det samme flag, er der kun én fejl mellem en kunde og alle andre kunders data. Den konstruktion anbefaler jeg altid at rette, før der bygges nye funktioner ovenpå.

Tjekket sker kun i brugerfladen

At skjule en knap beskytter ingenting. Kan en bruger kalde API'et direkte, eller ændre et id i adressen fra faktura 1041 til 1042, skal serveren afvise det. Den type fejl er udbredt. Sikkerhedsorganisationen OWASP placerer brudt adgangskontrol som nummer ét på sin Top 10-liste fra 2025 over de mest kritiske risici i webapplikationer, og samtlige testede applikationer i datagrundlaget bag listen havde en eller anden form for brudt adgangskontrol. Flere af de typiske huller finder du i min tjekliste til sikkerhed i webapplikationer.

En rollemodel der kan vokse

Her er den model jeg typisk anbefaler som udgangspunkt til en B2B-SaaS: fire roller pr. konto, bygget af et lille sæt rettigheder.

Tabellen er et eksempel, ikke en skabelon. Et par detaljer gør dog modellen holdbar uanset produkt:

• Ejeren er særlig. Der skal altid være mindst én ejer, og det er ejeren der kan ændre betaling og slette kontoen. Byg en måde at overdrage ejerskab på, for den person der oprettede kontoen, er ikke altid den der bliver i virksomheden.
• Rettigheder navngives efter handlinger, fx invoices.export eller users.invite. Navnene står i koden, så de kan versioneres og testes som alt andet.
• Ejerskab af data er en regel for sig. "Må redigere fakturaer" betyder kun fakturaer i brugerens egen konto, og for et medlem måske kun dem vedkommende selv har oprettet. OWASP formulerer det som at adgangskontrollen skal håndhæve ejerskab af den enkelte post i stedet for at give adgang til alle poster af en type.
• Abonnementet styrer funktioner, og rollen styrer personer. Er eksport kun med i den dyre pakke, er det noget abonnementet giver kontoen, ikke noget der står i rollen. Holder du de to ting adskilt, kræver en ny prismodel ikke ændringer i rollerne.

Når modellen skal vokse, sker det i små skridt. Først flere faste roller, fx en bogholder med adgang til fakturaer. Så adgang pr. projekt eller afdeling, hvis kunderne organiserer sig sådan. Til sidst roller som kunden selv sammensætter. Sælger du gennem partnere, kommer der også et lag over kunderne med roller som partneradministrator og partnersupport, og det har jeg skrevet om i indlægget om white-label SaaS.

Sådan designer du brugerroller og rettigheder: 7 trin

1. Skriv handlingerne ned, ikke personerne. Gå produktet igennem skærm for skærm og notér hvert udsagnsord: se, oprette, redigere, slette, eksportere, invitere, betale. Det er din liste af rettigheder. Hold den kort, og lav ikke rettigheder til noget kunderne ikke kan gøre endnu.
2. Saml rettighederne i 3-4 roller ud fra dine første kunder. Spørg hvem i deres virksomhed der skal bruge systemet, og hvem der absolut ikke må kunne slette noget. Svarene er mere værd end en rollemodel lånt fra et andet produkt.
3. Læg rollen på medlemskabet. Det er én tabel der forbinder bruger, konto og rolle, og den skal være der fra start, også selvom ingen bruger i dag er med i mere end én konto.
4. Lad koden tjekke rettigheder, aldrig rollenavne. Rollerne er pakker af rettigheder, og pakkerne er defineret ét sted. Spatie, der står bag en udbredt Laravel-pakke til roller, giver samme råd i deres dokumentation: tjek rettigheder frem for roller.
5. Tjek på serveren, centralt og med afvisning som standard. Hver forespørgsel skal gennem det samme tjek, typisk en policy eller en middleware (et lag der kører før selve handlingen). Findes der ingen regel der giver adgang, er svaret nej. OWASP's vejledning om autorisation bygger på de samme principper: mindst mulige rettigheder, afvisning som standard og tjek ved hver eneste forespørgsel.
6. Giv dit eget team en separat adgang. Support skal kunne hjælpe kunder, men gennem et særskilt administratorpanel eller en "log ind som kunden"-funktion som kun få personer kan bruge, og hvor hver brug bliver logget. Kunderne vil spørge til det, og det hører med til de tekniske GDPR-krav til en SaaS.
7. Test rettighederne automatisk. Lav tests der tjekker at et medlem ikke kan invitere brugere, at en læser ikke kan redigere, og at en bruger fra konto A aldrig kan se konto B's data. Testene skal køre ved hver ændring, så en ny funktion ikke stille og roligt åbner et hul.

Log desuden ændringer af roller og invitationer: hvem gjorde hvem til administrator, og hvornår. Det er noget større kunder ofte spørger efter i deres sikkerhedsspørgeskemaer, og det er uvurderligt den dag noget er blevet slettet, og ingen ved af hvem.

Hvornår kunderne skal kunne lave deres egne roller

Kundedefinerede roller ser godt ud på en kravliste, men de er sjældent det første kunderne mangler. Avanceret rollestyring står da også på min liste over funktioner din SaaS ikke har brug for ved lancering.

Det er tid til at bygge dem når du ser et eller flere af disse tegn:

• Flere kunder beder om den samme mellemrolle, men med små variationer, så faste roller ikke længere slår til.
• Kunderne har mange brugere pr. konto, fordelt på afdelinger eller lokationer med forskellige behov.
• Større kunder stiller krav om rollestyring i udbud eller sikkerhedsspørgeskemaer.
• Din support bruger tid på manuelt at give enkelte brugere særlige rettigheder.

Det er derimod for tidligt hvis du stadig har få kunder, hvis kun én kunde har bedt om det, eller hvis kunderne har en håndfuld brugere hver. Én kundes ønske løser du bedre med en ny fast rolle som andre kunder måske også kan bruge.

Kundedefinerede roller kræver mere end en ny tabel. Kundens administrator skal have en brugerflade hvor det er tydeligt hvad hver rettighed betyder. Systemet skal sikre at ingen kan give andre flere rettigheder end de selv har, og at ejeren ikke kan låse sig selv ude. Og din support skal kunne forklare hvorfor en bestemt bruger ikke kan se en bestemt side. Byg derfor niveau 2 ordentligt først. Så bliver niveau 3 en udvidelse og ikke en omskrivning.

Når roller ikke er hele svaret

Sælger du til større virksomheder, vil de ofte styre adgangen fra deres eget login-system, fx Microsoft Entra ID, så en medarbejder automatisk mister adgang den dag vedkommende stopper. Det er endnu en grund til at holde login og roller adskilt.

Nogle produkter vokser også ud af roller som model. Afhænger adgangen af relationer, fx at du kun må se de projekter du er tilknyttet, skal rollerne suppleres med regler på selve dataene. Det klarer Laravels policies fint. Skal de samme adgangsregler deles på tværs af mange systemer og teams, er en dedikeret autorisationstjeneste værd at overveje. Så er det typisk en opgave for en organisation med et platformsteam, ikke for en enkelt freelanceudvikler som mig.

Næste skridt

Planlægger du en SaaS, så tag rollerne med i forprojektet sammen med datamodellen og adskillelsen af kundernes data. Skriv handlingerne ned, vælg 3-4 roller, og aftal med udvikleren at koden tjekker rettigheder fra første dag. Det er en beslutning der koster timer nu og kan spare uger senere.

Styrer is_admin allerede det meste i dit produkt, kan det rettes trinvist: saml rettighederne ét sted, flyt tjekkene over ét modul ad gangen, og lås det fast med tests.

Vil du se hvordan jeg arbejder med SaaS-produkter, fra et forprojekt til fast pris til videreudvikling efter lancering, så læs om min udvikling af SaaS-produkter.

Ofte stillede spørgsmål

Hvad er forskellen på RBAC og ABAC?+

RBAC (rollebaseret adgangskontrol) giver adgang ud fra brugerens rolle, fx administrator. ABAC (attributbaseret adgangskontrol) giver adgang ud fra egenskaber ved brugeren, dataene eller situationen, fx afdeling, lokation eller tidspunkt. RBAC er nemmest at forstå og passer til de fleste SaaS-produkter i starten. I praksis ender mange produkter med en blanding: roller til det grove og regler på dataene til det fine.

Skal jeg bruge en færdig pakke eller bygge rettigheder selv?+

Brug det dit framework har, og design kun selve rollemodellen selv. I Laravel er gates og policies indbygget, og til faste roller defineret i koden er det ofte nok. Skal roller kunne gemmes og ændres i databasen, eventuelt pr. konto, er spatie/laravel-permission et udbredt valg med understøttelse af teams. Login og sessioner skal du aldrig bygge fra bunden.

Kræver GDPR at min SaaS har brugerroller?+

GDPR nævner ikke brugerroller direkte. Men artikel 32 kræver passende sikkerhed, og artikel 25 kræver at adgangen til persondata som standard begrænses til det nødvendige. Din kunde er typisk dataansvarlig og du databehandler, så kunden har brug for at dit produkt gør det muligt at begrænse adgangen. Roller er den mest almindelige måde. Det her er ikke juridisk rådgivning, så tal med en jurist hvis du er i tvivl.

Hvad gør jeg når én kunde vil have en rolle der kun passer til dem?+

Byg den som en ny fast rolle med et generelt navn, hvis andre kunder sandsynligvis kan bruge den. Undgå særregler i koden for én bestemt kunde, for de bliver hængende og gør hver fremtidig ændring dyrere. Begynder flere kunder at ønske hver deres variant, er det signalet til at bygge roller som kunderne selv kan sammensætte.

Hvad sker der med data når en bruger fjernes fra en konto?+

Fjern medlemskabet, ikke dataene. Data tilhører kontoen og ikke den enkelte bruger, så fakturaer, opgaver og noter skal blive liggende, og brugerens navn skal stadig fremgå af historikken. Til gengæld skal adgangen lukke med det samme, også aktive sessioner og API-nøgler. Er brugeren kun med i den ene konto, kan selve brugeren deaktiveres eller slettes efter jeres regler for opbevaring.