API management Uninett

God datadeling krever gode løsninger for API management

Hvordan bør API management løses i kunnskapssektoren for at vi skal kunne lykkes med god og enhetlig datadeling? Vår teknologidirektør (CTO), Andreas Åkre Solberg, skriver i dette blogginnlegget om hvordan API management best kan håndteres i sektoren.

Datadeling er en svært sentral del av kunnskapssektorens digitaliseringsstrategi. I Units datadelingsprosjekt jobbes det nå med å finne ut hvordan datadeling kan gjøres best mulig og på en lik måte i hele sektoren.

God datadeling i sektoren krever en enhetlig tilnærming til hvordan APIer administreres, ofte omtalt som API management. Det finnes flere ulike initiativer og tjenester som løser dette på ulik måte i vår sektor, og det hele kan oppleves litt kaotisk. Vi har blant annet IntArk, Feide, Maskinporten og ulike skytjenester, og området er under sterk utvikling både når det gjelder teknologi, standarder og programvare.

Uninett blir ofte spurt om hvordan API management best kan håndteres i vår sektor, og vår CTO, Andreas Åkre Solberg, svarer på det i dette blogginnlegget.

Hva er API management?

Når en tjeneste eller datakilde skal gjøre data tilgjengelig, gjøres det gjerne via et maskinlesbart grensesnitt, kalt API. Hvordan man håndterer tilgangskontrollen til APIer kaller vi for API management. API management består av ressurser, prosesser, informasjon og teknologi som gjør det mulig å tilgjengeliggjøre API på en trygg og sikker måte. APIene kan både publiseres internt i en organisasjon eller eksternt, for eksempel på tvers av organisasjoner og virksomheter.

Sentralt i API management står den tekniske infrastrukturen som hjelper til med å styre tilgang og kontrollere hvilke konsumenter som har tilgang til hvilke data.

Hvordan sikrer man API?

Det finnes flere måter å sikre tilgangen til et API. Hvilken mekanisme som passer best er avhengig av hvordan den blir konsumert. Dersom et API bare skal konsumeres av en spesifikk klient kan det være tilstrekkelig å sikre APIet med standard websikringsmekanismer, som f.eks. CORS og cookies. Dersom APIet skal bli konsumert av mange klienter kan det være nyttig å kreve andre mekanismer, som f.eks. tilgangsbilletter, såkalte access tokens, som er utstedt av en kilde som APIet har tillit til. Noen ganger er det tilstrekkelig at en access token utleveres kun basert på en autentisert klient, men andre ganger, og spesielt med personidentifiserbare data, kan det være hensiktsmessig å også autentisere sluttbrukeren.

Andreas Solberg

CTO i Uninett, Andreas Åkre Solberg.

Integrasjonsarkitektur (IntArk)

BOTT-universitetene har i IntArk-prosjektet etablert et felles mønster og et sett prinsipper for hvordan man implementerer integrasjoner/datasynkronisering mellom en kilde og et målsystem. USIT (IT-avdelingen ved UiO) har stått i spissen for dette arbeidet.

Mønsteret for integrasjoner er basert på at data hos kilden gjøres tilgjengelig via et API, og at endringer publiseres i en meldingskø. Dette er en god modell, og Units datadelingsprosjekt ser nå på hvordan denne modellen kan skaleres opp til å gjelde for hele sektoren.

For å realisere integrasjoner i henhold til IntArk-modellen er det behov for infrastruktur som støtter dette – infrastruktur for API management.

Fra én organisasjon til en hel sektor

For å kunne gjøre integrasjoner i henhold til IntArk-modellen har UiO valgt å bruke open source-produktet Gravitee. Dette er ett av mange produkter på markedet for API management. UiO har gode erfaringer, og de andre BOTT-universitetene setter i disse dager opp egne instanser av det samme produktet.

Men hva er API management for en hel sektor? Skal 37 institusjoner få hver sin instans av Gravitee? Må alle benytte samme produkt? Kunne man klart seg med en delt instans? Hva med nasjonale aktører som har tilbyr data på vegne av flere institusjoner, som FS, Cristin, SO, DFØ og NSD skal de ha egne løsninger? Og skal leverandører av fellestjenester forholde seg til 37 ulike portaler for å få tilgang til sektorens data? Og hvordan er rollen til Maskinporten og Feide for API management i sektoren?

Feide

I 2018 ble Feide utvidet med API management-funksjonalitet da Feide ble slått sammen med tjenesten som den gang ble kalt Dataporten. Dataporten baserte seg på en sentral gateway for tilgangskontroll til APIer. Selv om modellen var enkel for datatilbydere, så er ikke en sentral gateway ønsket målarkitektur. Det har blitt jobbet videre med en mer distribuert modell hvor ikke all API-trafikk går via Feide.

Selv om Feide med Dataporten fokuserte på en use case der sluttbrukeren var involvert og autentisert når API ble kontaktet, så har Feide hele tiden støttet “system til system”-integrasjoner.

Siden den gang Dataporten ble lansert, og siden UiO valgte å ta i bruk Gravitee hos seg, har det skjedd veldig mye både med standarder og utvalget av tilgjengelig programvare.

API management er mer enn én ting

API Management er en samlebetegnelse for mange funksjoner knyttet til hele livssyklusen av datadeling. Helt fra datakonsumenten oppdager et API, til man får tilgang og tar det i bruk.

API management figur 1

Figur fra digitaliseringsdirektoratets datadelingsprosjekt.

 

Vi sorterer funksjonaliteten inn i to hovedbolker:

1. API-portal og autentisering

  • API-portalen tilbyr selvbetjeningsgrensesnitt for tjenesteleverandører og konsumenter av data.
  • Nye tjenesteleverandører må registreres og godkjennes, og utviklere må tildeles roller slik at de kan registrere applikasjoner som kan konsumere data.
  • En applikasjon får tildelte hemmeligheter (nøkkelpar eller passord) som gjør at den kan autentisere seg.
  • Tjenesteleverandøren kan bla i en API-katalog over tilgjengelige APIer og etterspørre tilgang man har behov for.
  • Dataeieren godkjenner og sørger for at riktig applikasjon kan nå riktig API.
  • Videre er det vanlig at applikasjonen bruker sin hemmelighet (nøkkelpar eller passord) for å be om å få en access token for å bruke mot APIet.
  • I tilfeller der det ikke er «system-til-system» vil dette også involvere autentisering av sluttbrukeren og noen ganger samtykke.

2. API gateway

  • For å beskytte tilgangen til et API er det vanlig å sette en API gateway foran som tar seg av tilgangskontrollen for hver enkelt forespørsel. Et API kan motta hundre eller tusenvis av forespørsler per sekund, og denne API gatewayen stopper eller slipper videre forespørselen.
  • Adgangskontrollen som skjer i API gatewayen er grovkornet. Den kan skille mellom noen enkle hovednivåer for tilgang, men kan ikke ta stilling til om en foreleser skal ha tilgang til resultater kun for sine studenter. API gatewayen kan videresende parametre som gjør det enklere for APIet å gjøre finmasket tilgangskontroll.
  • API gatewayen har ofte ekstra funksjonalitet for logging, statistikk, rate-limiting og lastbalansering.
  • Noen ganger kan også API gatewayen ha avanserte funksjoner for å skrive om innholdet i meldingene.

Nasjonal arkitektur

Når vi nå har delt inn API management i to områder kan vi ta stilling til de hver for seg. Det er mange grunner til at det kan være ønskelig med én felles API-portal og autentiseringsløsning for hele sektoren. Onboarding av tjenesteleverandører og utviklere bør skje én gang, og utviklerne bør kun ha ett grensesnitt å forholde seg til.

Men for en API gateway er behovene helt annerledes. API gatewayen kan med fordel plasseres tett på APIet og nær infrastrukturen der APIet kjører. Eksterne parter som har data på vegne av sektoren, som FS og DFØ, bør ha sin egen API gateway på egen infrastruktur.

En API gateway kan gjerne deles av mange APIer. Utvalget av API gateway-produkter er blitt svært godt, og det kan være hensiktsmessig å ikke begrense seg til kun ett produkt. I noen miljøer passer kanskje Tyk, Kong eller NGINX godt inn med øvrig infrastruktur, men andre steder foretrekker man et enterprise produkt. Det foretrukne valget av API gateway kan også avhenge av eksisterende infrastruktur for f.eks. statistikk, logging og lastbalansering.

Tjenester med data i skyen er også en viktig faktor for arkitektur for API gateway. Det er lite hensiktsmessig å la en tjeneste som kjører i AWS og som skal hente data fra AWS, ta omveien om en on-premise API gateway. API gateway er også en type funksjonalitet som nå inngår som standard hos de fleste skyleverandørene, som AWS API Gateway, Azure API Management eller Google Apigee.

Hybrid API management

Kunnskapssektoren og offentlig sektor er ikke alene om å ha behov for en sentral API-portal i kombinasjon med et mer distribuert og heterogent miljø med infrastrukturnære API gatewayer. Dette er noe Gartner rapporterer som en av de største trendene innenfor API management (April, 2020).

Gartner API management

Figur fra Gartner – API Management – Emerging trends

 

Grensesnitt og standarder

For å kunne kombinere en sentral API-portal med leverandøruavhengige API gatewayer er vi avhengig av et standardisert grensesnitt som gjør at en API gateway kan klare å validere en access token utstedt via en felles API-portal og autentiseringsløsningen.

JWT «Jot» to the rescue

Heldigvis finnes det en standard og beste praksis for kryptografisk signerte tokens som utstedes av en API-portal og autentiseringsløsning og som kan valideres av en API gateway. Standarden heter JSON Web Token (JWT) RFC7519, og en slik token kalles på folkemunne for en «jot».

Det er også standarder for hvordan en applikasjon eller konsument autentiserer seg og får utlevert en token. Dette er OAuth 2.0. OAuth 2.0 har forskjellige flyt definert avhengig om det er en “system-til-system”-integrasjon eller klient med en autentisert sluttbruker. For “system-til-system"-integrasjoner benyttes gjerne OAuth 2.0 Client Credentials flow. Grovkornet aksesskontroll defineres ved hjelp av OAuth scopes.

En JWT er et JSON objekt, med en metadata header og en kryptografisk signatur, satt sammen med «.» og kodet med base64.

 

Slik kan en «jot» se ut:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9
lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

 

Når en applikasjon har benyttet OAuth 2.0 for å få utlevert en «jot» kan den brukes direkte mot APIet for å hente ut data. API gatewayen vil da validere signaturen mot en konfigurert kilde og sjekke innholdet.

Erfaringer og testing av API gateway produkter

For å verifisere at kombinasjonen med forskjellige API gateway fungerer sammen med en sentral API portal og tokenutsteder (Feide), har vi gjort litt research og praktisk testing med et utvalg API gateway-produkter; som NGINX, Kong, Gravitee og Apigee.

Resultatene så langt tilsier at modellen hvor API gateway og API-portal er uavhengig fungerer godt.

Tverrsektorielt samarbeid

Modellen med en sentral API-portal og autentiseringsløsning, med distribuerte API gatewayer, er allerede valgt i offentlig sektor.

Maskinporten er en sentral API-portal og autentiseringsløsning, og de som skal dele data ved bruk av Maskinporten må selv sørge for valg av API gateway eller implementere validering av token inn i selve APIet.

Helsesektoren følger også den samme modellen og er i oppstartsfasen med API management.

Når både offentlig sektor, helse og utdanning bygger API management etter den samme modellen, åpner det seg muligheter for økt interoperabilitet mellom sektorene. En datakilde i kunnskapssektoren kan f.eks. enkelt settes opp til å stole på tokens utstedt både av Feide, HelseID og av Maskinporten.

Helse- og kunnskapssektoren vil nok ha behov for egne grensesnitt for å håndtere den sektorspesifikke organiseringen. Dette kan for eksempel være løsninger for at ansvarlige ved NTNUs studieadministrasjon kan styre hvem som har tilgang til deres data i FS ved at Unit har delegert dette i henhold til dataeierskapet.

Oppsummering

Teknologi, produkter, standarder og grensesnitt gjør det mulig å kombinere en sentral API-portal og autentiseringsløsning med lokale løsninger for API gateway uten å binde seg til kun ett produkt eller én instans. Dette vil være en hensiktsmessig arkitektur for kunnskapssektoren.