Innlogging og tilgang til data handler som regel om to ting: autentisering (gjenkjenning) og autorisasjon (tilgangsstyring). Autentisering, dvs. det å bekrefte ens identitet har med årene blitt standardisert og vi møter ofte enten Feide eller ID-porten, inkl. BankID, når vi skal logge inn og få tilgang til en tjeneste eller en database. De to mest brukte protokollene eller formatene for å kunne utveksle nødvendig informasjon om identitet er SAML(2.0) og OpenID/Oauth (man kan lese mer om disse protokollene på Internett).
Autorisasjon (tilgangsstyring) handler om noe annet og, ofte, om mer enn autentisering. En autorisasjon gir deg rett til utføre visse oppgaver og/eller få tilgang til visse data i en database eller i et system, en tjeneste. En slik autorisasjon kalles ofte rollestyring, fordi man etter å ha bekreftet sin identitet gis visse rettigheter gjennom de rollene autorisasjonssystemet gir deg.
Et mye brukt rollestyringsverktøy er Keycloak (https://www.keycloak.org/). I vår seksjon benytter vi i dag Keycloak i to store utviklingsprosjekt: UniMus og NutriFoodCalc, og som et ekstra lag foran en skytjeneste med autentisering bygd på SAML.
UniMus og NutriFoodCalc er infrastrukturer bygd på klassisk tre-lags-arkitektur med (i) et webgrensesnitt, (ii) et såkalt mellomlag som oversetter brukerens valg og tastetrykk i grensesnittet til instruksjoner/ operasjoner som kan uttrykkes i SQL-spørringer mot en relasjonsdatabase, og (iii) selve databasen. Hvilke operasjoner en spesifikk bruker har lov til å gjøre i databasen styres av rettigheter brukeren er gitt i Keycloak, ofte uttrykt som lese-, skrive eller administrasjonsrettigheter.
En ekstra kompleksitet i forbindelse med dette å gi rettigheter til en bruker, dvs. bestemme hvilke roller vedkommende har, er at rollene satt i Keycloak må «følge» brukeren når hen, gjennom brukergrensesnittet, får utført operasjoner på dataene i databasen eller får tilgang til visse deler av et system. Hver database/hvert system har ofte egne måter å gjøre dette på (dessverre), slik at man ikke slipper helt unna skreddersydd tilgangsstyring på det laveste nivået i databasen/systemet (f.eks. “grant select/delete/insert to <user> on <table>” i en Oracle-database).
En begrensning på SAML-protokollen er at den liker å forholde seg til kun én identitetsleverandør («identity provider»), f.eks. Feide, noe som skaper utfordringer hvis man har et system som kun benytter SAML, mens man samtidig ønsker å kunne la brukeren velge måte å autentisere seg på. For å komme rundt dette kan man benytte Keycloak, som vi gjør når man vil logge seg på sky-tjenesten eLabJournal. «Foran» dette systemet har vi satt opp Keycloak, slik at man kan velge enten Feide eller Educloud som identitetsleverandør, og så «oversetter» Keycloak mellom OpenID/Oauth, som tillater flere identitetsleverandører, og SAML, som så gir tilgang til systemet.
