1 Innledning
Formålet med Dezoom er å automatisk forvalte brukermassen i en institusjons Zoom-instans over tid.
1.1 Kontakt
- Systemeier: Seksjon for nettdrift (NETT) / zoom-core
- Drift: Seksjon for integrasjon og elektroniske identiteter (USITINT)
- Utvikling: Seksjon for integrasjon og elektroniske identiteter (USITINT)
2 Redegjørelse
UiO-brukere blir provisjonert til Zoom ved å logge inn via Feide, og får samtidig automatisk tildelt en fullverdig lisens. Det er derimot ingen innebygde mekanismer som rydder bort ubrukte lisenser og brukerkontoer etterhvert som disse blir sperret i brukeradministrasjonssystemet. Dezoom er ment å løse dette.
2.1 Designvalg
2.4.1 Avhengighet til API-gateway
Kommunikasjon med Zooms API krever normalt en JWT-autentiseringsflyt. Hos UiO er Zooms API gjort tilgjengelig i Gravitee, som tar seg av denne biten. Dezoom trenger kun å autentisere mot Gravitee med en statisk API-nøkkel.
I tillegg sørger Gravitee for at Dezooms API-nøkkel kun gir tilgang til endepunktene og operasjonene som er nødvendig for at tjenesten skal fungere.
2.4.2 Språk og rammeverk
Tjenesten skrives i Python.
Vi gjenbruker biblioteket tofh, som gjør det enkelt å utføre oppgaver på bakgrunn av notifikasjoner som mottas via RabbitMQ. Dette biblioteket brukes også av Kada, Canvas-MS og flere av integrasjonene til BOTT-INT.
3 Detaljbeskrivelse
3.1 Teknisk formål
Dezoom skal:
- endre lisenstypen på allerede provisjonerte Zoom-brukerkontoer på bakgrunn av tilstand i Cerebrum
- slette Zoom-brukerkontoer som er å regne som slettet i Cerebrum
3.2 Høynivådesign
Dezoom lytter på notifikasjoner fra Cerebrum om endringer som har skjedd på brukerkontoer. Logikken for å vedlikeholde brukerkontoer i Zoom hekter seg på eksisterende funksjonalitet for avvikling av brukerkontoer, som omtaler avvikling. En avviklet brukerkonto har utløpsdato i fortiden.
Når en utløpsdato på en brukerkonto i Cerebrum har blitt passert med N dager, blir Zoom-lisensen endret til en basic-lisens og kontoen meldes inn i en dedikert Zoom-gruppe for kontoer i karantene. Dette reverseres om utløpsdatoen på brukerkontoen senere endres.
Når en utløpsdatoen har blitt passert med N+X dager, blir kontoen meldt inn i en dedikert Zoom-gruppe for kontoer som skal slettes. Dette reverseres om utløpsdatoen på brukerkontoen senere endres.
Det kjøres jevnlig en automatisk jobb som sletter Zoom-brukerkontoer som er tagget for sletting. Når en Zoom-konto er slettet kan det ikke reverseres. Kontoen må provisjoneres på nytt ved å logge inn i Zoom via Feide.
3.3 Lavnivådesign
3.3.1 Notifikasjoner og automatiske jobber
Dezoom har ingen database, men utfører oppgavene sine på bakgrunn av notifikasjoner i Cerebrum og ved å jevnlig se på gruppemedlemskap i Zoom.
Hver gang utløpsdatoen til en brukerkonto endres i Cerebrum, vurderer Dezoom om noe må gjøres med den. Lite destruktive operasjoner som å nedgradere/oppgradere lisenser og å melde kontoen inn i grupper (karantene- og slettes-gruppa) utføres umiddelbart. Sletting gjøres kun av en separat prosess.
Det er to jobber som automatisk utføres med jevnlige mellomrom:
- gjennomgang av medlemmene i karantenegruppa
- bruker samme logikk som ville blitt brukt ved endring av utløpsdato
- sørger for å oppgradere brukere som har mistet sin utløpsdato
- sørger for å markere brukere for sletting, om nødvendig
- gjenomgang av medlemmene i slettes-gruppa:
- bruker samme logikk som ville blitt brukt ved endring av utløpsdato, men tillater sletting
3.3.3 Kort om driftsregime
Kildekodeavhengigheter og det virtuelle Python-miljøet til Dezoom styres ved hjelp av verktøyet Poetry. Denne sørger for å låse alle avhengigheter og deres under-avhengigheter til en spesifikk versjon, slik at nye versjoner av pakker kan kvalitetssikres før de rulles ut.
Dezoom bygges som container images og lastes opp til Harbor, UiOs register for container images. Harbor håndhever tilgangskontroll til bildefilene og skanner jevnlig etter sårbarheter.
Hver komponent/prosess kjører i hver sin container. Inn- og utgående kommunikasjon skjer gjennom UiOs API gateway.
Tjenesten konfigureres via konfigurasjonsfiler som er montert opp i containeren. Stien til konfigurasjonsfilen settes i en miljøvariabel.
Konfigurasjonsfiler for applikasjonen og nødvendig oppsett i OpenShift/Kubernetes genereres av Helm. Hemmeligheter er lagret i Hashicorp Vault og dekrypteres midlertidig ved utrulling.
Les mer om sikring av containerbaserte tjenester.
4 Avhengigheter
4.1 Systemet er avhengig av
Tjenesten er avhengig av følgende systemer for å fungere:
- Zoom: tjenestens målsystem
- Cerebrum: leverer informasjon om brukerkontoer
- RabbitMQ: benyttes som intern oppgavekø og for å motta notifikasjoner fra Cerebrum
- Harbor: tjenestens container images er lagret her
- OpenShift: applikasjonsplattformen som containere kjøres i
- Gravitee: benyttes for å kommunisere med Zoom og Cerebrum
5 Relaterte systemer
6 Lenker og referanser
- zoom-deprovisioner-ms: Kildekode for Dezoom
- dezoom-deploy: Deployeringsverktøy (tilgangsbegrenset)