Innhold
1 Bakgrunn
I samanheng med behovet for bedring av rutinene rundt oppretting av brukarar og avvikling av tilgangar og rettigheter for tilsette, er det behov for å sjå på automatisert sperring og avvikling av brukarkontoar i Cerebrum.
Det er i dag opp til lokal-IT å avvikle brukarane til personar som slutter ved UiO. Dette vert som oftast følgd opp, men sidan det er ei manuell rutine glipper det tidvis og brukarar vert liggande att utan å bli nedsperra, og vil i verste fall også forbli innmeldt i grupper som kan gje ekstra privilegier. Dette er det ønskeleg å unngå med automatikk.
Det har tidlegare vore gjort forsøk på å få opp ei generell automatisert sperring og avvikling av brukarar, men dette stoppa opp då vi ikkje fekk løyst behovet for å sperre alle brukargruppene som treng å bli sperra i samme omgang. Det var då heller ønskeleg å utsette arbeidet til vi har ei løysing for alle brukargruppene, som det kan sjå ut til at vi begynner å få, til dømes for alumni.
Status for studentbrukarar er at det vert gjort ei halvautomatisk sperring som køyrast ein gang i semesteret og baserer seg på korleis studenten er registrert i FS. Dei siste semestera har ikkje denne sperringa blitt utført.
2 Løysinga
Løysinga delast opp i separate rutiner:
- Automatisk sperring av brukarar utan person-tilknyttingar.
- Automatisk avvikling av brukarar som har vore sperra i ein viss periode.
- Automatisk utmelding av grupper for brukarar utan person-tilknyttingar.
2.1 Sperring av brukarar
Det finnast allereie automatikk for sperring av brukarar utan person-tilknyttingar i Cerebrum, så det trengs ikkje så mykje utvikling. Denne jobben tek for seg alle aktive brukarar der personen er utan noko tilknytting, varsler brukaren på e-post og set ei karantene fram i tid. Sperrerutina kan settast opp til å også inkludere visse typar person-tilknyttingar for sperring, til dømes visse manuelle tilknyttingar.
Det finnast allereie ei liste over alle brukarar utan person-tilknyttingar som er publisert for lokal IT. Denne lista inkluderer også brukarar som allereie er i karantene, men utan å vere avvikla, så korrekt tal er noko lågare. Lista gir i dag 12000 brukarar, og eit utplukk av desse vil bli varsla første gang jobben vert køyrd.
2.1.1 Diskusjonspunkt
Vi bør sjå på om vi har ei løysing for registrering av alle personar som er manuelt registrerte i dag, i eit kildesystem. Nokre dømer er alumni-brukarar, emeritus og gjestar. Dersom det er nokre brukargrupper vi ikkje får løyst det for, må vi ta hensyn til desse vidare i prosessen.
I samanheng med bedring av rutinene rundt avvikling av IT-tilgangar er det eit punkt å fjerne muligheten for registrering av manuelle tilknyttingar for alle andre enn lokal IT på USIT. Dersom vi ikkje har ei løysing for å få registrert alle brukargrupper er det usikkert om vi kan både fjerne muligheten for å sette manuelle tilknyttingar for lokal IT og samtidig innføre automatisk sperring. Vi må difor sjå dette i samanheng. Bør vi til dømes vente til ny alumniordning er på plass før vi begynner?
Merk at studentbrukarar også vert påvirka av denne rutina dersom dei ikkje lenger er aktive. Dette krever at vi høyrer med STA om det er ok at vi endrer måten vi sperrer studentbrukarar på, hvis ikkje må vi unngå å sperre desse på noko vis. Dei vil framleis få beholde IT-tilgangen i 180 etter avslutta studier, då vi ikkje fjerner affiliations før eit halvt år etterpå. Det er eit generelt ønske frå Cerebrum å ha samme rutiner både for studentar og ansatte, då det er mindre komplisert og meir oversiktleg funksjonalitet.
2.1.2 Forberedingar
Før vi kan starte med sperringa:
Vi bør vere sikre på alle brukargrupper vil kunne bli registrert i SAP eller FS.
Vi treng ei godkjenning på at dette kan utførast frå ledelsen. Dette skaper ei endring i rutinene for IT for heile UiO.
Vi treng å teste løysinga, til dømes ved å gå gjennom lista over kven som ville blitt varsla og sperra og passe på at vi ikkje sperrer fleire brukarar enn det vi skal.
Ei utfordring som vi må sjå på, er kva som skjer i SAP-fila når personar endrer ei tilsetting. Det som har skjedd tidlegare har vore at personen er utan ei tilknytting den dagen tilsettinga er blitt endra. Dersom vi køyrer ei sperring den dagen vil personen bli påvirka av dette.
Sperrerutina må ha støtte for å fjerne karantena når personen får ei gyldig tilknytting att.
2.1.3 Framgangsmåte
Prosessen for å starte med sperrerutina:
Lokal IT og andre må varslast om kva som vil skje, med tidspunkt og lenke til lista over kven som vil bli påvirka av sperringa. Lokal IT har gjerne også tilbakemeldingar om brukargrupper som dei er bekymra for at skal miste tilgangen, så vi bør oppfordre til tilbakemeldingar. Lokal IT vert også bedt om å få registrert alle som ikkje skal bli sperra.
Dette kan ta noko tid å få gjort, så vi bør gjerne gje dei nokre veker.
Cerebrum set i gang jobben. Ein god del brukarar vil bli varsla og få ei karantene satt fram i tid.
Cerebrum informerer lokal IT og andre om kor mange som vart varsla, og legg ved ei liste over kva brukarar som vart påvirka. Lista kan med fordel sorterast på diskar for å gjere det enklare for lokal IT.
Sperrejobben vert satt opp til å køyre regelmessig, til dømes ein gang i veka eller oftare.
I neste runde bør ein utvide sperringa til å også gjelde personar med visse manuelle tilknyttingar.
2.1.4 Konsekvensar
- Alle personar som skal ha IT-tilgang må ha ein affiliation. Personar som er i permisjon må til dømes ha ein eller anna variant av ei tilknytting for å unngå å bli avvikla.
- Feilregistreringar i kjeldesystem vil føre til at brukarar mister IT-tilgangen sin. Dette kan også få uheldige konsekvensar om det til dømes oppstår ein feil i Cerebrum i importen frå kjeldesystema som fjerne alle tilknyttingar.
2.2 Avvikling av brukarar
Vi har ein jobb i Cerebrum som kan avvikling alle brukarar som har vore i ei gitt karantene i over eit gitt antal dagar. Med avvikling meinast her arkivering av heimeområde og IMAP-konto, gruppeutmeldingar og fjerning av brukaren frå andre IT-system, dvs. fjerning av spread. Det gjerast ingen varslingar her, då brukaren skal ha fått varsel frå sperringa, og skal uansett ikkje ha tilgang til innboksen sin.
Avviklingsrutina kan settast i samanheng med sperrerutina, slik at alle som har blitt automatisk sperra vil etterkvart også bli avvikla.
Prosessen for ein person som har slutta vert då:
- Brukaren får eit e-postvarsel om sperring.
- Etter eit gitt antal dagar, til dømes 7, vert brukaren sperra. Karantena kan opphevast midlertidig av lokal IT dersom det er behov for midlertidige tilgangar til å til dømes rydde og hente ut data frå heimeområde sitt.
- Etter eit gitt antal dagar, til dømes 30, vert brukaren avvikla.
Denne jobben vil berre påvirke den typen karantene som settast ved automatisk sperring, så dette skal ikkje påvirke andre brukarar. Rutina påvirker også studentbrukarar, som vi i per i dag har ei rutine for å ikkje avvikle heimeområdet for før etter at eit semester er passert. Vi bør høyre med STA om denne endringa er greit før vi innfører det. Det vil vere mykje enklare å sleppe å ha unntak i avviklingsrutina, og avviklinga av studentbrukarar gjerast i dag manuelt.
Dersom det ikkje trengs å ha unntak og ekstra hensyn, trengs det ikkje så veldig mykje utviklingsarbeid. Jobben køyrer allereie for andre instansar, men vi treng å legge til alt som er ekstra på UiO, til dømes arkivering av heimeområde og IMAP-konto. Dette heng saman med API-et, og løysinga må diskuterast internt hos utviklarane. Anslått til å kreve to dagsverk med utvikling og dokumentering.
2.2.1 Framgangsmåte
- Sperrerutina må først ha køyrd i meir enn det antalet dagar som det skal settast opp med, til dømes 60 dagar.
- Avviklingsrutina køyrer i dryrun, og vi går gjennom listene av brukarar.
- Avviklingsrutina settast opp til å køyre regelmessig.
2.2.2 Konsekvensar
Det er dei samme konsekvensene som for sperrerutina, men i tillegg har du også utfordringa med at det vil ta lenger tid å få gjenoppretta brukaren ved feilregistrering, sidan det må hentast frå backup. Dette kan ikkje lokal IT utføre i dag, men må gjerast av USIT, så det vil gjerne ta ein dag før nokon får sett på ei innmeldt sak om slikt. Datoen for avvikling bør uansett settast så langt fram i tid at dei fleste har hatt mulighet til å få rydda opp.
2.3 Utmelding frå grupper
Det som har blitt ønska:
- Automatisk utmelding frå grupper når ein slutter.
- Automatisk utmelding frå grupper når ein går ut i permisjon utan lønn.
- Automatisk utmelding frå grupper når ein slutter.
- Automatisk utmelding og innmelding i grupper når ein bytter til ei ny stilling på UiO.
Det er ønskeleg at vedlikehold av grupper vert automatisert meir, for gruppeutmeldingar og -innmeldingar.
2.3.1 Automatiske grupper
Vi har i dag ansatt-gruppene, til dømes ansatt-35100, som vert automatisk vedlikeholdt basert på tilknyttingar frå SAPUiO. Desse gruppene kan i større grad brukast ved å legge dei til som medlem av andre grupper, som gjer at brukarane vil bli meldt inn og ut basert på person-tilknyttingar. Dette vil berre vere brukbart for store grupper som kan ha inn heile stedkodar med brukarar. Det løyser ikkje problemet for grupper som treng eit mindre utplukk av brukarar.
I tillegg står det på planen å få inn grupper som baserer seg på studieinformasjon, til dømes studieprogram, undervisings- og vurderingsmeldingar. Desse gruppene vil også kunne bli lagt inn som medlem av andre grupper, og kan då brukast for å delegere tilgangar meir automatisk enn i dag.
Ved å gå ut og anbefale bruken av desse automatisk styrde gruppene i større grad vil vi løyse utfordringa for større grupper.
2.3.2 Generell gruppeautomatikk
Cerebrum har ikkje noko løysing for automatisk inn- og utmelding av generelle grupper, og vi mangler også datagrunnlaget for å kunne automatisere det. Vi har ikkje data om kven som skal få vere med i ei gruppe eller ikkje. Vi veit heller ikkje kva som er kontaktpunktet for ei gruppe, eller til dømes kva stedkode ei gruppe høyrer til. Kan vi då melde brukarar ut av grupper, når vi ikkje har automatikk for å melde dei inn att?
Når ein brukar vert avvikla ved at nokon køyrer user delete gjennom bofh vil brukaren bli meldt ut av alle grupper med unntak av den som står som standard filgruppe (primærgruppa). Aktive brukarar mister ikkje gruppetilgangane sine per i dag.
Nokre forslag:
- Utvide grupper med informasjon som kontaktpunkt og kva person-tilknyttingar som bør krevast. Vi kan då begynne å sende ut rapportar til kontaktpunkta om kven som ikkje burde vere med i gruppa. Å gjere dette riktig er ein større defineringsjobb. Eventuelt kan vi melde brukarane ut med ein gang dei har mista riktig tilknytting, men det kan gjerne skape problem for lokal IT. Vi løyser heller ikkje innmeldingar med dette.
- Utvide gruppemedlemskap med sluttdatoar for når brukaren skal bli automatisk utmeldt, og kreve at brukarar kan meldast inn for maksimalt eit år om gangen. Ved å kreve vedlikehold av grupper, ved at brukarar må regelmessig leggast inn att vil vi ha bedre opprydding, men vi påfører også lokal IT med ein del arbeid.