Andreas Solberg om API og dataflyt i offentlig sektor

Chief Technical Officer (CTO) i Uninett, Andreas Solberg, deler i dette blogginnlegget sine innspill til arbeidet med API-katalog, infrastruktur for API og dataflyt i offentlig sektor.

Dette er en del av tilbakemelding til Skate – Styring og koordinering av tjenester i e-forvaltning om videre satsning på API-katalog i offentlig sektor. Jeg tenkte jeg kunne dele mine tanker slik at det kan leses og diskuteres også av de som ikke deltar på Skate-møtene.

Her finner du ut Brønnøysundregistrenes datakatalog

Slik API-katalogen fremstår nå, er det fokus på å oppdage og til dels å vurdere:

 

 

I fortsettelsen følger noen refleksjoner rundt hvordan man angriper «få tilgang» og «ta i bruk».

Selv om API-katalogen blir den ene nasjonale katalogen for alle APIer, må man erkjenne at den vil eksistere i et samspill med utallige andre API-kataloger. Disse mer lokale og sektorspesifikke katalogene vil ofte være integrert i en verdikjede som også involverer å få tilgang og å ta i bruk.

Dette kan for eksempel være Feide i kunnskapssektoren, UiOs API-plattform for lokale APIer, Oslo kommunes Origo utviklerplattform, utviklerplattformen Fiks fra KS og fylkeskommunenes API-plattform FINT.

Fordelen med den nasjonale API-katalogen vil være å få en helhetsoversikt på tvers av disse. Videre fokus bør det være å sikre godt samspillet mellom plattformene. Det er interessant å se på muligheter for å trekke ut funksjonalitetet fra alle disse lokale APIene, dersom det kan bidra til å øke evnen til samhandling på tvers av domener, noe som en svært sentral kapabilitet for den ønskede digitaliseringen av offentlig sektor. 

Friksjonsfri samhandling på tvers av plattformer og administrative domener er en forutsetning for verdensledende digitalisering.

Under følger noen ideer:

 

Selvbetjening og register for APIer og klienter

For at APIer og klienter (konsumenter av APIer) skal kunne kommunisere effektivt og sikkert på tvers av plattformer trenger man identifikatorer og credentials som håndteres på nasjonalt nivå. Dette er en naturlig start på en erstatning av virksomhetssertifikater.

Siden Brønnøysundregistrene har registrert fødselsnummer knyttet til alle organisasjoner, kan man lage en selvregistreringsportal for digitale tjenester/entititer (både APIer og klienter) hvor tjenestene knyttes til en organisasjon. Dette kan være en naturlig utvidelse av grensesnittet som finnes i API-katalogen i dag (som jeg ikke har testet).

Noe overordnet metadata vil være felles på tvers av klienter, APIer og annet. Som for eksempel navn, beskrivelse, identifikator, kontaktpunkter, lenke til mer informasjon osv.

API-katalogen har allerede mange API-spesifikke felter som må med. En utvidelse må til for eventuelt å understøtte tilgang basert på personlig samtykke. Da behøves tilstrekkelig informasjon for å kunne representere et korrekt og godt grensesnitt for personlig samtykke.

For klienter behøves informasjon som gjør det mulig for API-eier å ta en beslutning om klienten skal få tilgang eller ikke.

For at dette skal fungere godt må det etableres en beste praksis i offentlig sektor om bruk av (eller i hvert fall støtte for) asymmetriske nøkler for autentisering mot API. client_secret, passord og symmetriske nøkler vil ikke kunne benyttes utenfor det stedet der de blir utstedt og vil dermed ikke kunne brukes sømløst mellom API-plattformer.

For OpenID Connect betyr dette bruk av private_key_jwt. For OAuth 2.0 og API-tilgang så vil det involvere JWT Bearer tokens.

Fordelen med denne type credentials er at den også kan gjenbrukes i andre formater, for eksempel meldingskryptering for APIer med særlig krav til sikkerhet utover TLS, TLS-klientsideautentisering, certificate pinning av APIer eller kryptering av asynkrone meldinger på hendelsesdrevne systemer (Kafka, meldingskø m.m.).

Det vil være en stor fordel for administratoren av både klient og API å ha en enkelt plass å kunne «revokere» sine credentials, og gjennomføre certificate roll-over med mer. En sentral håndtering av dette vil være svært ressursbesparende for klient og API-eier, og kan understøtte en beste praksis for hvordan slike operasjoner skal gjennomføres.

 

Grovkornet autorisasjon for tilgang til APIer på tvers av plattformer

Så snart man har et register for klienter/konsumeter og APIer, samt en sikker kobling mellom de (en organisasjon og en autentisert sluttbruker) kan man understøtte prosessen hvor API-eier tilbyr et sett med grovkornede rettigheter som klienten så kan etterspørre. API-eier kan varsles om forespørselen og få et enkelt grensesnitt for å kunne ta stilling til hvor vidt den aktuelle klienten skal få tilgang eller ikke.

 

Brukeropplevelse

Utvidelsen av API-katalogen beskrevet over vil fungere som følger:

  • en enkeltperson autentiseres på et høyt sikkerhetsnivå med ID-porten
  • registrerer en tjeneste tilknyttet en organisasjon
  • navigerer i en katalog over alle tilgjengelige APIer
  • Med et klikk etterspør man så tilgang fra en aktuell tjeneste og til APIet
  • API-eier får varsel, 
  • API-eier godkjenner forespørselen
  • Tjeneste og API kan deretter kommunisere direkte eller via en vilkårlig API-plattform, dersom autentisering av sluttbruker eller personlig samtykke er nødvendig

Funksjonaliteten i maskinporten er per nå avgrenset til kun system til system integrasjoner. Funksjonaliteten beskrevet over vil kunne brukes i flere sammenhenger, inkludert systemer som involerer sluttbrukerautentisering og personlig samtykke.

 

Generisk tjeneste for personlig samtykke

En god løsning for å innhente personlig samtykke for utlevering av personopplysninger vil naturlig høre hjemme sammen med en ID provider eller API-plattform. Med en nasjonal felles tjeneste og API-register, så vil det bli mulig for en klient og mer sømløst kunne benytte forskjellige API-plattformer med den samme konfigurasjon. APIer kan løsrives fra enkelte API-plattformer og gjøres tilgjengelig i den nasjonale API-katalogen, hvor klienter kan få godkjent sin grovkornede aksess til APIet. Deretter kan klienten benytte forskjellige plattformer for både klient autentisering, sluttbrukerautentisering og brukerens samtykke.

 

Helhetlig arkitektur for samhandling på tvers av plattformer

En slik modell kan fint gradvis innføres ved at API-plattformene fungerer som før, men kjenner igjen IDer på APIer og tjenester som er registrert i den nasjonale API-katalogen, og henter så ut informajson derfra. API-katalogen gjør tilgjengelig metadata om tjeneste og API, et signert statement om grovkornet autoriasasjon og offentlige nøkler.

Funksjonaliteten beskrevet over er relativt enkel og avgrenset, så arkitekturen har den fordelen at man tilrettelegger for mer distribuerte enkle komponenter som bedre spiller sammen enn dagens plattformer som nødvendigvis må bygge inn all nødvendig funksjonalitet for å understøtte tjenestenes behov.