Hopp til hovedinnhold

Tilgangsstyring

You shall not pass!

Tilgangskontroll består av to hoveddeler. Først må man finne ut hvem brukeren er (autentisering), deretter må man ta avgjørelser om tilgang basert på hvilke egenskaper denne brukeren har (autorisering). På engelsk omtales dette ofte som «AuthNZ» (AutheNtication og AuthoriZation).

I NAV har vi valgt å ta i bruk OAuth 2.0 og OpenID Connect (OIDC) for dette formålet. En introduksjon til disse samt tilhørende begrep og uttrykk finner du her. Dette er veletablerte standarder med god industristøtte.

Standardene muliggjør bruken av eksterne tilbydere som kan abstrahere vekk og konsolidere funksjonalitet som man tradisjonelt sett har måttet håndtere selv. Vi benytter eksterne tilbydere i form av ID-porten og Microsoft Azure AD for henholdsvis publikum og egne ansatte.

I tråd med prinsippene om Zero Trust, har vi også valgt å ta i bruk OAuth 2.0 Token Exchange spesifikasjonen. Måten vi bruker denne spesifikasjonen på innebærer at vi ønsker smalt scopede tokens. Det vil si at et access token kun har én tiltenkt mottaker, og at tokenet altså ikke er gyldig mot noen andre applikasjoner enn denne. I tillegg må de involverte appene på forhånd godkjenne at de kan snakke med hverandre for å kunne få utstedt korrekt token fra identitetstilbyderen. Smalt scopede tokens minsker også skadepotensialet betraktelig hvis de skulle komme på avveie.

Token exchange muliggjør også propagering av subjektet i tokenet. I praksis betyr det at informasjonen om sluttbrukeren som startet kallkjeden er bevart hele veien gjennom dersom man bruker token exchange mellom hvert ledd. Til sammenligning så har man tradisjonelt sett brukt systembrukere mellom de ulike leddene som i praksis fjerner informasjon om sluttbrukeren (eller påtvinger krav om å inkludere den på andre måter). Azure AD støtter token exchange via sin «on behalf of»-flyt, mens for ID-porten har vi laget et tilsvarende opplegg som vi har kalt TokenX. Mer info finnes på NAIS-bloggen.

Eksempler og implementasjon

I eksempel-repoet til NAIS finnes det eksempler på apper som tar i bruk disse tingene i flere språk og rammeverk.

NAIS har også laget en «auth-as-a-service»-løsning i form av en Kubernetes-sidecar kalt Wonderwall for henholdsvis ID-porten og Azure AD.

Validering av tokens

Når man skal validere tokens, kan man benytte et tredjepartsbibliotek, eller vårt egenproduserte token-support som kan plugges rett inn i Spring og Ktor.

Se også tokenvalidering for utdypende info.

Testing

For å gjøre testing av «AuthNZ» enklere og minske behovet for dedikerte testmiljøer, kan man benytte mock-oauth2-server. Denne kan enkelt spinnes opp i f.eks. JUnit-tester eller som en Docker-container. Den kan også konfigureres til å støtte ting som custom «claims» og HTTPS med egne sertifikater.

Grupper i Azure AD og on-premise AD i tilgangskontroll

For å gjøre tilgangskontroll i applikasjoner med interne brukere benyttes primært gruppemedlemskap i Azure Active Directory. For legacyapplikasjoner benyttes gruppemedlemskap i on-premise Active Directory. Ved veldig spesielle behov benyttes Axsys og evnt andre løsninger.

For noen utvalgte tilgangstyper er det felles grupper som skal benyttes for alle nye applikasjoner. De er dokumentert her: https://confluence.adeo.no/display/IDM/Tilgangskontroll+for+spesielle+brukergrupper

Ellers bør ikke grupper i AD/AAD gjenbrukes i nye applikasjoner med mindre teamet selv er eiere av gruppene og har full kontroll på eierskapet, innsikt i bruken og hvordan medlemskap tildeles. Hva grupper representerer, hvilke brukerkontoer som er medlem, hvem som eier grupper og om grupper er i bruk eller avvikles kan endre seg over tid. Det er dermed anbefalt å opprette nye grupper for nye applikasjoner eller å gjenbruke grupper som teamet selv kontrollerer. Nye grupper bestilles av Team Azure og tilgangsstyring bestilles av Team IDM (#identrutina).

Gode ressurser

Savner du noe?

Legg det inn selv på GitHub, si ifra i #security-champion, eller kontakt redaksjonen. Takk! 💖