Styringsregler for brukerkontoprovisjonering (utkast v0.5)

Tjenester trenger ofte informasjon om brukere som skal benytte tjenesten. Noe av denne informasjonen er for brukeropplevelse – som for eksempel en persons fulle navn – mens annen informasjon brukes for å avgjøre om en person skal ha tilgang til å benytte tjenesten.

Dette dokumentet inkluderer styringsregler, "best practices" og informasjon rundt det å provisjonere brukerkonti.

 

Styringsregel

En tjeneste som har behov for å hente informasjon om brukere utover det som innhentes gjennom innloggingen vil måtte provisjonere disse dataene. Gjeldende praksis for dette er å benytte API-er for å hente denne informasjonen, som skissert i UiO:IntArk. En tjeneste som kun trenger informasjon om brukeren ved innlogging kan heller implementere "Just In Time"-provisjonering – JIT-provisjonering. Eldre former for provisjonering, som LDAP- eller AD-integrasjoner, databaseintegrasjoner eller filbasert informasjonsutveksling er generelt ikke tillatt, men gitt begrensninger i en applikasjon så kan man vurdere å unntakshåndtere integrasjonen.

Hvordan velge

Hendelsesdrevet provisjonering er den generelt anbefalte metoden å provisjonere brukerkontodata. I noen tilfeller kan JIT være mer formålstjenlig og er også en godkjent provisjoneringsform, med forbehold om at ulempene med f.eks. deprovisjonering adresseres. 

Kopiering fra LDAP/AD, hente data fra databaser eller basere seg på filer med denne informasjonen er ikke godkjente provisjoneringsformer. I spesielle tilfeller, som f.eks. gamle tjenester som har eksisterende integrasjoner og tjenesten har en satt End of Life, så kan krav om provisjoneringsform fravikes. I de aller fleste tilfeller av anskaffelser så unntakshåndteres det ikke.

Bakgrunn: Hva er brukerkontoprovisjonering?

Brukerkontoprovisjonering er det velklingende begrepet som benyttes om det å fôre en tjeneste med informasjon om brukere. Det å provisjonere er å sende over informasjon, gjerne i forkant, slik at tjenesten har nødvendig informasjon. Brukerkonto er den elektroniske identiteten, med tilhørende informasjon, som personer ved UiO får utstedt for å kunne bruke IT-tjenester ved universitetet.

Tradisjonelt foregår slik provisjonering ved at tjenesten mottar en fil med all relevant informasjon. Denne filen blir generert i et av UiOs sentrale systemer, ofte Cerebrum, i løpet av natten og sendes så til tjenesten.  Tjenesten går gjennom filen og setter opp sine egne datastrukturer basert på informasjonen i filen. Påfølgende natt vil tjenesten måtte gå gjennom en ny fil og finne differansen fra det tidligere importerte.

Det å flytte på store filer medfører ulemper. I senere år er det kommet alternative provisjoneringsmetoder, som just-in-time provisjonering og hendelsesdreven provisjonering. 

"Just in time"-provisjonering

"Just in time"-provisjonering, ofte forkortet JIT-provisjonering, er en markant annerledes måte å tenke provisjonering på. Hensikten med JIT er å ikke provisjonere data før behovet oppstår. Idet en bruker logger inn så vil tjenesten enten få data via autentiseringen eller hente informasjonen under innloggingen – derav begrepet "just in time". Dette er veldig attraktivt mtp. lovkrav om å begrense det å spre personopplysninger. 

Fordeler Ulemper
Kun provisjonere data om de brukere som aktivt oppsøker tjenesten. Ikke veldig utbredt for programvare UiO kjøper. Lite sannsynlig at dette er støttet i "hyllevare".
Brukeren setter selv igang provisjoneringen og det er dermed helt ferske data. Ganske kompleks prosess. Setter krav til både tjenesten og infrastruktur.
Brukere kan spørres om samtykke som en del av første innlogging. Ingen deprovisjonering. Egne prosesser må slette gamle data.
  Data blir kun oppdatert ved innlogging. Usikker tilstand på tidligere provisjonerte data.
  Begrenset mengde data tilgjengelig under provisjonering. Vanskeliggjør komplekse spørringer.

Flere av ulempene med JIT kan adresseres. Eksempelvis kan dette med manglende deprovisjonering løses ved at informasjon om brukere som ikke har logget inn i tjenesten på seks måneder slettes. 

En avart av JIT er svært populær blant moderne nettsider og netttjenester i dag: Innlogging med sosiale nettverk. Her er det ikke egne integrasjoner for å hente data, men dataene blir muliggjort av integrasjonen med f.eks. Twitter, Facebook og Google. 

Hendelsesdrevet provisjonering

Ideen bak hendelsesdrevet provisjonering er at tjenesten selv skal hente informasjonen tjenesten trenger, basert på hendelser i virksomheten. Det er to komponenter tjenesten trenger for dette: MQ og API-er. I det en hendelse skjer, som affekterer data tjenesten er avhengig av, så sendes det en melding via MQ om at data er endret. Tjenesten kommuniserer med API-er for å undersøke om dette er en relevant endring. Er det det så provisjoneres endringen.

Fordeler Ulemper
Provisjonerer alle relevante endringer når de skjer – ferske data konsekvent. Kompleksitet og kompetanse blir skjøvet over på tjenesteutviklere isteden for fikset sentralt
Deprovisjonerer som en del av mengden hendelser. Mange meldinger og API-er. Krever oversikt og innsikt.
Støtter det å ha flere kilder til data og hendelser. Hendelsesdrevet provisjonering tilbyr ingen initiell provisjonering.
Generiske meldinger og API-er betyr at tjenesten har kort TTM. Trenger ikke vente på sentralt genererte filer.  
Provisjonering skjer i "bakgrunnen". Feil utenfor tjenesten påvirker kun ny endringer, ikke tilgjengeligheten på tjenesten.  

Kildesystemeiere har et større ansvar for å dokumentere sine API-er og meldinger og slik tilrettelegge for denne typen provisjonering. Manglende initiell provisjonering kan løses ved å benytte de samme API-ene som benyttes for hendelsene. 

Filbasert fulldump

Klassisk provisjonering. Et kildesystem regner ut hvilke brukere som skal benytte en gitt tjeneste, og lagrer data tjenesten skal ha i en stor fil. Filen sendes til tjenesten. Tjenesten importerer dataene ved å se på hva den har i sin egen database.

Fordeler Ulemper
Utbredt teknologi. "Alle" skjønner og støtter dette. Treg og ressurskrevende måte å utveksle data på.
God kontroll på dataflyt.  Lite brukervennlig, gjerne bare nattlige oppdateringer.
Sentral kompetanse, "dumme" mottagere Kompleksistetsproblem når en tjeneste trenger data fra flere kilder.
Provisjonering skjer i "bakgrunnen". Feil utenfor tjenesten påvirker kun ny endringer, ikke tilgjengeligheten på tjenesten. Mottagere må ofte lage eller støtte en del logikk for få store datasett med små endringer i. 
  Undergraver en vedtatt arkitektur på UiO, med de følger det medfører.

Det finnes grep for å redusere de negative aspektene ved fildump, f.eks. det å sende endringer som flere mindre filer. Dette tilfører mer kompleksitet og undergraver fordelene.

Konklusjon

De prefererte provisjoneringsmetodene er hendelsesdrevet og JIT-provisjonering. Dette er fordi disse to følger gjeldende føringer fra Difi, digitaliseringsrundskrivet og UiOs arkitekturprinsipper. Filbasert provisjonering er absolutt mest utbredt på UiO, men det er å anse som teknisk gjeld. En dypere analyse av problemene rundt filbasert provisjonering og hvorfor hendelsesdrevet provisjonering kan man finne i bakgrunnsdokumentasjonen for UiO:IntArk.

Følge gjeldene regler for sikkerhet og arkitektur

Dette dokumentet tar kun for seg den overordnede prosessen med å provisjonere data, men det er flere regler og føringer som sier noe om hvordan man skal integrere. Det finnes mer informasjon rundt dette her:

IT-sikkerhet og retningslinjer

Styringsregler for autentisering

Integrasjonsarkitektur

JIT er en enkel måte å få integrert kjapt på, men man må være obs på begrensningene. Trenger man kun informasjon om brukeren som logger inn så fungerer JIT fint; trenger man f.eks. informasjon om grupper, organisasjonsenheter eller annet ikke-brukerrelatert så fungerer JIT dårlig. 

Hendelsesdrevet provisjonering er dokumentert i UiO:IntArk. Derunder en del teknisk informasjon for de som skal tilby og hente data. JIT provisjonering er ikke spesielt dokumentert på UiO; ønsker man å undersøke dette nærmere så bør man se på hva autentiseringstjenesten Weblogin tilbyr av data. 

Av Mathias Meisfjordskar
Publisert 9. jan. 2018 11:54 - Sist endret 9. jan. 2018 11:55