1 Innledning
Gjesteregistreringsløsningen (GREG, Guest REGistation) tilbyr et grensesnitt der institusjoner kan legge inn data om personer som trenger gjestekontoer for å få tilgang til IT-tjenester. Tjenesten kan integrere med institusjonens IAM (Identity and access management) løsning for overføring av data til denne.
Hver institusjon som ønsker å bruke GREG vil ha sin egen instans som bare inneholder data om brukere ved den institusjonen.
Registrering av gjester er en HR-funksjon, så GREG blir en del av institusjonens HR-portefølje. SAPDFØ er per i dag ikke en HR-løsning, men et lønns- og personalsystem, og dekker ikke gjesteregistreringer på en optimal måte.
1.1 Brukerroller
Det er to brukerkategorier i tjenesten:
- Verter: Dette er brukere ved institusjonene som kan invitere gjestebrukere. Tidligere også kalt sponsor, men det er for tvetydig.
- Gjester: Dette er personer lagt inn av vertene og som ønsker tilgang til IT-systemene ved institusjonen. Generelt er alle som ikke er studenter eller ansatte kategorisert som gjester - for eksempel emeritus og gjesteforskere.
1.2 Kontakt
- Systemeier: Per 2022 er ØVA systemeier, men det pågår en prosess for å overføre dette til USIT.
- Drift: Seksjon for integrasjon og elektroniske identiteter (USITINT)
- Utvikling: Seksjon for integrasjon og elektroniske identiteter (USITINT)
2 Redegjørelse
Dagens løsning i DFØ-SAP for å registrere gjestebrukere dekker ikke behovene til UiO og UiB, og det ble avgjort å utvikle en alternativ løsning for å få et system mer i tråd med behovene på plass innen kort tid. Generelt er det to utfordringer:
- Alle gjester må registreres manuelt av sentrale saksbehandlere, så det er arbeidskrevende å bruke DFØ-SAP. Dette blir mer arbeidskrevende for spesielt større institusjoner.
- En person kan enten bare være ansatt, bilagslønnet eller gjest, fordi dette styres av medarbeidergruppen (MG) til personen. En person kan bare være i en MG omgangne. En person kan derfor ikke være gjest og samtidig ha utbetalinger. Dette skaper utfordringer for alle som har flere roller hos institusjonen, og skaper ekstraarbeid.
En utfordring var tidsperspektivet: GREG har primært fokus på håndteringen av gjester og prosessen med å få registrert deres personopplysniger. Dette skopet ble satt på grunna av tidsbegrensningen ved overgang til DFØ-SAP for UiB og UiO. GREG har for eksempel ikke forvaltning av mer granulerte roller for gjester.
2.1 Designvalg
2.1.1 Kjerne
Kjernen er utviklet med Django, et populært webrammeverk i Python som har mange tilleggsmoduler som gjør utviklingen enklere. USIT har kompetanse på Django, og det er allerede brukt i Kada og Mreg.
2.1.2 Selvbetjeningsløsning
Selvbetjeningsløsningen er skrevet i React, et av de mest brukte javascriptrammeverkene. Dette var et naturlig valg da utviklerne allerede hadde erfaring med det fra andre tjenester, som eValg og passordtjenester.
3 Detaljbeskrivelse
Systemet består av to deler, en kjerne og en selvbetjeningsløsning, og kommunikasjon mellom disse skjer gjennom et REST API kjernen gjør tilgjengelig. Ved å splitte funksjonaliteten på denne måten er teknologivalg gjort i selvbetjeningsløsningen, som er frontenden sluttbrukerne ser, uavhengig av kjernen. Så utviklerne kan på hver sine side, frontend og backend, velge teknologier de er komfortable med. Det gjør også at andre løsninger, som UH Sak, kan integrere mot kjernen uavhengig av GREG sitt grensesnitt.
Gjester administreres av verter ved de forskjellige organisasjonsenhetene. Vertene kan gis hierarkisk tilgang som innebærer at de kan administrere gjester ved enheter under sin enhet i organisasjonstreet.
Gjester inviteres av verter per e-post, og autentiserer seg normalt med Feide/Id-porten, men kan også fylle inn passnummer/fødselsnummer manuelt som deretter må godkjennes av verten. Når gjestens identitet er verifisert publiserer tjenesten en melding som plukkes opp av IGA (Cerebrum og Rapid Identity), og det blir så opprettet en brukerkonto, og vanlig løp for ansatte følger (oppretting av passord i Passordtjenesten osv.).
En gjest kan ha roller ved flere enheter. En rolle har en type, start dato, og slutt dato. Dette muliggjør finkornet tilgangsstyring i tjenester som bruker Gjestetjenesten som kilde (per nå Rapid Identity og Cerebrum).
3.1 Teknisk formål
Kjernen har som hovedoppgave å lagre data om gjestene, sende notifikasjoner om relevante endringer via en meldingskø og tilby et REST API for å lagre og hente ut data.
Endringer som det publiseres meldinger for inkluderer opprettelse av nye gjester i kjernen, endring gjort på eksisterende gjester og sletting av gjester.
IGA-systemet ved en institusjon kan lytte på meldingskøen kjernen publiserer til for å bli gjort oppmerksom på endringer for gjester. Informasjonen i meldingene kan brukes til å gjøre oppslag i API'et.
Kjernen vil også periodisk slette persondata for gjester som ikke lenger er aktive.
Adgangskontroll til API'et skjer gjennom Gravitee.
Selvbetjeningsløsningen lar sponsorer opprette gjester og lar gjestene legge inn identitetsinformasjon. Det er selvtjeningsløsningen som har ansvaret for flyten gjennom registreringsforløpet, dvs. den sender for eksempel ut e-poster til gjestene om at de må legge inn informasjon og til sponsorene om at de må godkjenne gjester som har lagt inn informasjon.
Selvbetjeningsløsningen bruker kjernen hovedsaklig for å lagre informasjon.
3.2 Høynivådesign (Overordnet design)
3.3 Lavnivådesign (Design av enkeltkomponenter)
3.3.1 Kjerne
For å tilby et REST API brukes "Django REST framework".
En OpenAPI spesifikasjon av API'et er tilgjengelig (generert ved hjelp av drf-spectacular)
Sending av meldinger til RabbitMQ skjer ved hjelp av pika-context-manager biblioteket.
Tilgangskontroll til API'et skjer via Gravitee. Brukerne av API'et er selvbetjeningsløsningen og institusjonens IAM-system.
En kø for fremtidige hendelser håndteres av Django-q. Dette sikrer at:
- det blir sendt meldinger på startdatoen til roller som starter i fremtiden.
- epost blir sendt i fremtiden dersom e-post serveren har nedetid når man skulle sendt e-post.
- import av enheter fra Orgreg skjer daglig
3.3.2 Selvbetjeningsløsning
Løsningen er skrevet i typescript og benytter api-et til kjernen for å hente informasjon som brukeren har tilgang til. MaterialUI brukes for å få et helhetlig design, React-i18next for å tilby tjenesten på flere språk, samt andre småpakker for mindre formål.
Avhengig av om man er gjest, vert, eller ingen av delene får man tre forskjellige sider etter innlogging. De som ikke har tilgang til noe, får en enkel tekst som informerer om dette. Gjester får se en oversikt over den informasjonen som er lagret om dem. Verter får tilgang til grensesnittet for å invitere nye gjester, samt muligheten til å legge til eller endre roller på eksisterende gjester.
4 Avhengigheter
4.1 Systemet avhenger av
- Harbor: Lagring av container images
- Openshift: Applikasjonsplattform for å kjøre containere
- Gravitee: Tilgang til API styres gjennom Gravitee
- RabbitMQ: Brukes for å sende meldinger til andre systemer
- Dataporten: Muliggjør innlogging med Feide/Id-porten
- OrgReg: Holder informasjon om vertenes organisasjonsenheter oppdatert
4.2 Andre systemer er avhengige av
- IGA (Rapid Identity/Cerebrum): Dersom tjenesten er nede vil ikke data for gjester bli holdt oppdatert, og grunnlaget for IT-tilgang bli utdatert for gjestene.
- Lenel OnGuard: Uten tilgang til informasjon om gjester kan ikke gjestene få tilgang til UiOs bygningsmasse.
5 Relaterte systemer
- Cerebrum: Brukeradministrasjonssystem ved UiO. Henter data fra GREG og oppretter brukerkontoer. Sender data tilbake til Greg om hvilke gjester som har fått brukerkontoer.
- Rapid Identity: Brukeradministrasjonssystem ved UiB. Opererer etter samme mønster som integrasjonen mellom Cerebrum og GREG.
6 Lenker og referanser
- Programkoden (UiBs gitlab)
- Nettsiden ved uio
- Nettsiden ved uib