Sammendrag
Brukerkontoprovisjonering skal etterstrebe å følge rettningslinjer og styringsregler fra UiO:IntArk. Dette dokumentet illustrerer tre anbefalte metoder for brukerkontoprovisjonering – eller alternativer som oppnår samme eller bedre resultat:
Hendelsesdrevet provisjonering
Bakgrunn
Behovet for provisjonering eller andre former for integrasjon kommer av at tjenester og applikasjoner ikke er separate øyer løsrevet fra resten av IT-landskapet og virksomheten. En tjeneste trenger gjerne å vite noe om virksomheten for å unngå kaos eller dobbeltregistrering. Å vite noe om virksomhetens brukere er et typisk eksempel på dette; tjenester eksisterer som regel for mennesker og følgelig må tjenestene vite noe om menneskene de skal servere.
Provisjonering har historisk vært gjort ved å generere filer med datastrukturer i systemet som er kilde for data, kopiere filen til tjenesten som trenger å vite disse dataene og importere disse filene i tjenesten. Ved import lages en lokal kopi av datasettet i tjenesten. Slike filer genereres typisk noen ganger i døgnet, uken, måneden eller året. Vanlig er at slikt skjer hver natt.
Provisjonering vs. direkte integrasjon
Provisjonering er det å fôre en tjeneste med nødvendig informasjon. Begrepet provisjonering benyttes som oftest når data kopieres til et sted, de kopierte dataene skal fortsatt oppdateres fra kilden og kopien skal ikke overta som kilde. Provisjonering er en utbrakt måte å integrere på. Det sikrer robusthet og autonomi mellom tjenester på bekostning av kompleksitet – data er kopier som kan være forskjellige fra kilden. Kopiene av data kan få avhengigheter som vanskeliggjør oppdateringer.
Det finnes flere måter å gjøre provisjonering.
Med nyere integrasjonsplatformer, som UiO:IntArk, så kan man oppnå effekten av det å provisjonere ved å integrere tjenester direkte med datakilder. Isteden for å gå til en kilde for å kopiere data så spør man kilden direkte når man trenger dataene. Man lagrer ikke en kopi av dataene i egen database, men benytter datakilden som en ekstern database. Dette reduserer kompleksitet i data – alltid de korrekte dataene, men introduserer mer direkte avhengighet til datakilden på bekostning av autonomi.
Direkte integrasjon
Direkte integrasjon er den anbefalte måten å dekke behovet for informasjon på – gitt at forholdene ligger til rette for denne typen integrasjon. Det er en rekke forhold som må ligge til rette for denne typen integrasjon, og som kan være umulige eller urealistiske å tilfredsstille.
| Fordeler | Ulemper |
|---|---|
| Redusert datakompleksitet – ingen "skyggekopier" av data | Ikke veldig utbredt for programvare UiO kjøper. Lite sannsynlig at dette er støttet i "hyllevare". |
| Økt sannsynlighet for at endringer spres i organisasjonen ved at det ikke eksisterer kopier av data. | Ganske kompleks prosess. Setter krav til både tjenesten og kildesystem. |
| Endringer på data blir automatisk "samlet inn" i kilden igjen ved at det ikke eksisterer en lokal kopi som kan endres – endringer gjøres mot kilden. |
Stiller langt større krav til datakilden mtp. oppetid og kapasitet |
|
Krever samarbeid mellom applikasjonsforvalter og kildeforvalter i langt større grad enn ved provisjonering. |
I tillegg så er det en forskjell på integrasjonsstrategien Direkte integrasjon realisert med en lokal cache og Provisjonering ved at førstnevnte benytter et temporært, lokalt lager for å gjøre integrasjonen mer robust, mens integrasjonsstrategien Provisjonering er basert på dette lokale lageret.
Provisjoneringsmetoder
"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.
| 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
Om man har muligheten til å integrere direkte med en datakilde og unngå provisjonering så er dette å foretrekke. Direkte integrasjon understøtter gjeldende føringer fra Difi, digitaliseringsrundskrivet og UiOs arkitekturprinsipper best – men fordrer at tjenesten og kilden har mulighet for dette. De prefererte provisjoneringsmetodene er hendelsesdrevet og JIT-provisjonering. Disse to følger også 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
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.
Direkte integrasjon og 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.