Innhold
1 Bakgrunn
Når en person slutter i sin rolle ved universitetet, vil personens brukerkonti miste noen av sine tilganger, men langt i fra alle. Dette gjelder både personer som ikke lenger er tilsatt, samt personer som bytter rolle (f.eks. en ny stilling).
Noen av disse tilgangene har blitt automatisk tildelt, basert på forretningslogikk i Cerebrum, men de fleste tilganger vil være tildelt manuelt, av IT-personell som har tilgang til å gjøre dette.
2 Cerebrum
Cerebrum har i dag ansvar for å provisjonere mange av universitetets systemer med autorisasjonsdata som benyttes for å håndheve tilgangskontroll.
Internt i Cerebrum representeres tilgang hovedsaklig som tilknytninger og grupper. I tillegg finnes det en egen autorisasjonsmodul, bofhd_auth, som gir mer finmasket tilgangskontroll i grensetnittet mot Cerebrum, bofhd.
Ulike systemer representerer it-tilganger ulikt, og håndhever tilgangskontroll på ulike måter. Dette gjør at denne informasjonen gjerne må tilpasses, berikes eller forenkles i kommunikasjon med systemet.
Her taes gjerne mer informasjon enn tilknytninger og grupper i betraktning. Ulike systemer har egen forretningslogikk som kan se på Cerebrum-data i sin helhet og beregne hvilke autorisasjonsdata som skal eksporteres.
2.1 Tilknytninger
Roller fra autoritative systemer representeres som tilknytninger i Cerebrum. Tilknytningen binder en person til en organisassjonsenhet med en tilknytningstype. Tilknytningstypen er et forenklet rollebegrep som sier noe om personen f.eks. er student, ansatt, eller noe annet ved organisasjonsenheten.
Denne informasjonen er destillert ned fra rik informasjon fra kildesystemer. HR-system gir informasjon om ansettelser, hvor en gitt person kan ha mange ulike stillinger, og mange ulike roller. Resultatet er maks en tilknytning for hvert sted personen er ansatt ved. For studenter er fungerer dette tilsvarende. Sammensetningen av studieretter, studieprogrammer og emner som studenten har et forhold til i studentsystemet reduseres ned til maks en tilknytning per studiested som studieprogram/emne er registrert ved.
Etter at denne informasjonen har blitt importert, mister Cerebrum alt av beslutningsgrunnlag som ikke kan representeres i tilknytninger.
2.2 Grupper
Grupper i Cerebrum er simple greier. Det er en liste med medlemmer, hvor et enkelt medlem enten er en brukerkonto, person-objekt, eller en annen gruppe. En del systemer med et gruppe-begrep støtter kun at brukerkonto er medlem av grupper; i så fall reduseres informasjonen ved eksport.
Noen gruppe-medlemsskap vedlikeholdes automatisk; disse gruppene vil i praksis regelmessig tømmes helt, og re-populeres basert på kildedata fra ett system. Disse vil derfor være oppdatert ihht. kildedata.
En relativt ny type gruppe har også blitt implementert i Cerebrum: Virtuelle tilknytningsgrupper. Disse gruppene kan ikke endres manuelt, og vil alltid være oppdatert i henhold til tilknytninger som er registrert i Cerebrum.
I den vanlige, manuelle gruppen finnes det ingen informasjon som kan fortelle oss hvorfor en bruker har fått medlemsskap. En del automatikk kan melde inn brukere i grupper dersom en rolle indikerer at eieren skal ha en gitt tilgang.
Men automatikk kan ikke lese ut hvorvidt en slik tilgang er basert på kildedata fra et gitt system eller om tilgangen er tildelt manuelt på et annet grunnlag. Cerebrum vet heller ikke nødvendigvis hvilke tilganger en gitt gruppe vil dele ut.
2.3 Annen tilgangsinformasjon
Mens grupper ofte er den eneste muligheten for eksterne systemer å kontrollere tilganger, finnes det flere muligheter internt i Cerebrum. Vi kan se direkte på koblinger mellom data-objekter og håndheve tilgangskontroll basert på dette.
- bofhd
- Bofhd har egne tabeller som lenker sammen brukergrupper og tillatte operasjoner. Denne informasjonen brukes for å regulere tilgang til kommandoer i grensesnittet som bofhd tilbyr, og er ikke nyttig i særlig grad utenfor dette. Unntaksvis brukes enkelte spesielle roller/opsets fra bofhd i Cerebrum.
- karantene
- Karantener benyttes for å midlertidig sperre brukere fra bruk i Cerebrum og eksterne systemer. Dette utgjør en enkel måte å trekke tilbake all autorisasjon, f.eks. for å forhindre misbruk.
- ephorte
- Saksbehandlingssystemet ePhorte har egne datamodeller for å lagre roller og tilganger i Cerebrum. Disse tilgangene er registrert manuelt på person, og har ikke nødvendigvis noe samsvar med hvilke tilknytninger personen har.
- kildedata i eksporter
- Enkelte eksporter (spesielt eksporter knyttet til studentsystemer) leser kildedata direkte fra kildesystem, og benytter disse i forretningslogikk som genererer roller og tilganger i det eksterne systemet. Dette er gjort i de tilfellene der informasjonsgrunnlaget i Cerebrum ikke er rikt nok til å gjøre beslutninger om tilganger i eksterne systemer.
- spreads
- I provisjonering av enkelte eksterne systemer, styres eksport av brukerkonto og gruppe av spreads. I eksporter som støtter dette, eksporteres ingen brukerkonti eller grupper dersom ikke det har blitt merket med tilhørende spread.
3 Fjerne tilganger
En tilknytning kan være avledet av en eller flere ansettelsesroller fra HR-system. Dersom alle disse ikke lenger er tilstede i HR-systemet, så vil Cerebrum registrere en last seen-dato for tilknytningen.
Dette gir rot til et annet konsept i Cerebrum; grace-periode. Når datagrunnlaget fra kildesystem indikerer at en person ikke lenger har en gitt rolle, så markeres tidspunktet. Dersom en tilsvarende rolle ikke dukker opp igjen innen en gitt tid (30 dager pr. dd.), så vil en egen vedlikeholdsjobb plukke opp dette, og registrere en deleted-dato for tilknytningen.
Eksportjobber som baserer tilganger eller attributter på at en person har en gitt tilknytning vil oppføre seg riktig, og sørge for at eksterne systemer er oppdatert med slik informasjon.
Det som imidlertid ikke skjer, er endring av tilgangsinformasjon som er registrert på en person (eller en brukerkonto tilhørende personen). Cerebrum har ikke beslutningsgrunnlag for å si at f.eks. ephorte-tilgangen som er blitt tildelt, eller medlemsskapet i den manuelle gruppen tjeneste-foo, er tildelt på grunnlag av et verv som følger av en gitt ansettelsesrolle.
Mye av dette mitigeres når brukere avvikles. Da fjernes et bredere sett av tilgangsinformasjon, simpelthen fordi en person mister alle sine tilknytninger til universitetet.
4 Tiltak
4.1 Med dagens løsning
- Bruke riktig informasjon
- Cerebrum har allerede tilgangsinformasjon som blir automatisk vedlikeholdt fra kildesystemer, i form av tilknytning. Ved å basere tilganger i eksterne systemer på automatisk vedlikeholdt informasjon, spesielt da virtuelle grupper, vil en sørge for at tilganger alltid er regelmessig oppdaterte.
4.2 Videreutvikling
- Bedre tilknytninger
- Informasjonen som lagres i dagens tilknytning er ikke rik nok. Cerebrum kan f.eks. ikke lagre at en person har to ulike stillinger med ulike roller ved et og samme tilsettelsessted. I tillegg mistes mye informasjon om stillinger ved import, spesielt informasjon som kunne/burde/skulle vært brukt som beslutningsgrunnlag ved vedlikehold av tilganger.
- Bedre opprydding
- Det kan selvsagt lages oppryddingsjobber for f.eks. ephorte-roller, men dette krever at en sammen med systemeier nøye tenker gjennom forretningsreglene som skal finnes i en slik jobb. En er også begrenset til de data som eksisterer i Cerebrum.
- Bedre forretningslogikk
I Cerebrum blir forretningslogikk gruppert i egne vedlikeholdsjobber. Dette gjør at denne logikken aldri kan se på endringer som skjer, men må forholde seg til en statisk tilstand.
Et vedlikeholdsscript som da rydder opp når tilknytninger forsvinner kan mao. aldri ta hensyn til hvilken tilknytning som ble fjernet, men kan kun forholde seg til hvorvidt en bruker har eller ikke har en gitt tilknytning. Denne formen for vedlikehold skaper også problemer i forretningslogikk som ikke omhandler tilgangsstyring.
Et bedre alternativ er å implementere bedre forretningslogikk, hvor vedlikeholdsoppgaver kan abbonere på endringer, og behandle endringer i en kontekst med både gammel tilstand og ny tilstand.
- Eksponere bedre tilgangsinformasjon
I tillegg til å importere mer informasjon i Cerebrum, burde også Cerebrum benytte denne informasjonen bedre til å bygge tilgangsinformasjon.
Ved å standardisere måter man henter ut tilgangsinformasjon, kunne vi bygget enklere, og mer konsistente eksporter til eksterne systemer, samt enklere feilsøkt hvorfor en gitt bruker ikke har fått tilgang i et gitt system.
Dette kunne også bidratt til å eksponere tilgangsinformasjon på andre måter enn ved å eksponere gruppemedlemsskap. Vi kunne f.eks. eksponert tilganger som entitlements i LDAP - eksplisitt tilgangsinformasjon.
- Eksplisitt tilgangsinformasjon
Videreutvikling av tilgangskontroll i Cerebrum, med fokus på automatisk vedlikeholdte data.
Cerebrum burde ha modeller for å lagre, vedlikeholde og presentere tilganger på bedre måter enn gruppemedlemsskap. En tilgangsmodell ville gitt mulighet for å legge kriterier på tilganger, og bygge inn støtte for forretningslogikk i selve tilgangsmodellen.
Slike tilganger må også inkludere beslutningsgrunnlag for å kunne vedlikeholdes automatisk. Et slikt beslutningsgrunnlag kan f.eks. være:
- Tidsbasert
- Tilgang har begrenset levetid. Dette vil kreve scheduling av vedlikehold for å overholdes.
- Knyttet til kildedata
- Tilgang fjernes når kildedata endres. Dette vil kreve en form for intern endringshåndtering for å overholdes.
- Knyttet til bruker
- I praksis manuelt vedlikeholdte data, men med forståelse om at tilgang faktisk fjernes ved avvikling. Enkelte tilgangsdata overlever en deaktivering/reaktivering av brukerkonto i dag.