Designdokument for Zapip

Zapip (Zoom-API-proxy) er en tjeneste som lar datasystemer opprette Zoom-møter for alle brukere i organisasjonen, men kun lese, redigere og slette møter som er opprettet av samme datasystem.

1 Innledning

Formålet med Zapip er å tilby mer fingranulert tilgangskontroll i Zoom sitt API enn det som støttes ut av boksen.

1.1 Kontakt

2 Redegjørelse

Timeplanleggingssystemet TP, og muligens andre systemer, har behov for å hel- og halvautomatisk opprette Zoom-møter på vegne av brukere, og senere vedlikeholde disse møtene. Det finnes ingen god mekanisme i Zoom for å gi rettigheter som er finkornet nok for dette formålet.

Løsningen er å etablere en liten proxy-tjeneste som står mellom Zoom sitt API og systemet som trenger å opprette møter. Proxy-tjenesten holder styr på hvilke applikasjoner som har opprettet hvilke møter, og gir kun tilgang til disse.

2.1 Designvalg

2.4.1 Avhengighet til API-gateway

For å ikke finne opp hjulet på nytt, er det er ønskelig å la API-gatewayen Gravitee holde styr på hvilke applikasjoner som har tilgang til proxyen og hvilke API-nøkler som er gyldige for bruk.

2.4.2 Språk og rammeverk

Tjenesten skrives i Python med webrammeverket Django, da dette er kjente teknologier for USIT-INT.

Hos USIT brukes Django også av kalendersystemet Kada og DNS-administrasjonsverktøyet Mreg.

3 Detaljbeskrivelse

3.1 Teknisk formål

Zapip skal:

  • la applikasjoner som har fått tilgang opprette Zoom-møter for brukere ved UiO
  • la applikasjoner få lese, redigere og slette Zoom-møter som applikasjonen selv har opprettet

3.2 Høynivådesign

Zapip speiler endepunktene i Zooms API som omhandler oppretting og vedlikehold av møter. HTTP-forespørsler og -svar videreformidles mellom applikasjonen og Zoom sitt API som de er.

Ved opprettelse av et nytt møte lagrer Zapip møte-ID-en og kobler den til applikasjonen. Ved lesing, endring eller sletting av møter sjekker Zapip om møte-ID-en er opprettet av applikasjonen.

3.3 Lavnivådesign

3.3.1 Autentisering og autorisasjon

For alle innkommende forespørsler, leter Zapip etter headeren X-Zapip-Api-Key som må inneholde en API-nøkkel. Denne headeren legges automatisk på av API-gatewayen og gir i praksis tilgang til proxy-mekanismen i tjenesten.

API-gatewayen legger også på headerne X-Api (identifiserer Zapip som API), X-Api-Application (identifiserer applikasjonen i gateway) og X-Api-Subscription (identifiserer applikasjonens tilgang til API-et). Alle disse må være tilstede i forventet format for at en forespørsel skal slippe gjennom. Verdiene satt i disse logges.

3.3.2 Proxy

Zapip støtter å være proxy for utvalgte metoder mot to endepunkter:

  • POST /v2/users/foo@example.com/meetings
  • GET/PATCH/DELETE /v2/meetings/1234567890

I alle tilfeller videresendes innholdet i forespørselen (body/payload) som det er. Den eneste headeren som bestemmes av applikasjonen og sendes videre til Zoom er Content-Type. 

Ved kall mot /v2/users/foo@example.com/meetings som resulterer i en 201 Created, lagrer Zapip brukernavnet og møte-ID-en i databasen. Ved andre typer svar videreformidles svaret som det er.

Ved kall mot /v2/meetings/1234567890 sjekker Zapip om møte-ID-en er lagret i databasen og koblet mot samme applikasjon som opprettet den, før forespørselen videresendes til Zoom.

Om Zapip videreformidler et svar fra Zoom, settes headeren X-Zapip-Response-From til zoom. Om en forespørsel avvises av Zapip, settes samme header til zapip.

3.3.3 Kort om driftsregime

Kildekodeavhengigheter og det virtuelle Python-miljøet til Zapip 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.

Zapip 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

Mikrotjenestene er avhengig av en rekke andre systemer for innhenting og oppdatering av data:

  • Zoom: Tjenesten videreformidler alle forespørsler til Zoom sitt API.
  • Postgres: Tjenesten bruker Postgres som databaselager.
  • Harbor: Tjenestene startes fra container images som er lagret i tjenesten Harbor.
  • OpenShift: Tjenesten kjører i OpenShift.
  • Gravitee: Tjenesten gjøres tilgjengelig i API-gatewayen Gravitee og benytter samme gateway for å få kontakt med Zoom sitt API

5 Relaterte systemer

Timeplanlegging (TP)
TP er systemet for timeplanlegging og eksamensplanlegging ved UiO. Les mer om TP ved UiO.

6 Lenker og referanser

Publisert 9. mars 2021 07:54 - Sist endret 13. jan. 2023 12:56
Del på e-post