Fremtidig løsning for sluttbrukersystemer

[TheTechArch]

Beskrivelse

Dagens Altinn 2 plattform har løsninger for at systemer kan autentisere og autorisere seg for API.

Noen av de tilgjengelige muligheten forsvinner med Altinn 2.

Denne analysen skal beskrive hvordan Altinn sammen med andre felleskomponenter kan tilby autentisering og autorisasjon av systemer og sluttbrukere av systemene hvor dette er aktuellt.

Løsningene søker å støtte både Digdir sine plattformer og andre plattformer hvor tjenester tilbys.

Mål

• Løsning skal kunne brukes i Altinn og utenfor Altinn
• Det skal ikke være nødvendig å dele sertifikat/brukernavn/passord med systemleverandør
• Det skal være enkelt å onboarde nye kunder for systemleverandører
• Løsningen skal dekke maskin-maskin kommunikasjon hvor det er organisasjoner som er involvert. Privatpersoner dekkes av andre løsninger. Disse er også beskrevet i denne issuen.
• Token skal kunne inneholde nok informasjon slik at man kan bruke Altinn Autorisasjon til tilgangskontroll

Begrepsoversikt

I dette dokumentet brukes følgende begreper.

• Tjeneste- En tjeneste i denne sammeheng er digital tjeneste tilbydt av tjenesteeier for innrapportering eller uthenting av data. Eksempler på tjenester kan være Innrapportering MVA, Rapportering av Lakselus, Innsyn Enhetsregister, Søknad om skjenkebevilgning, Barnehagesøknad Drammen kommune Det finnes tusenvis av slike tjenester i Norge og svært mange av dem kan benyttes via API. Tjenestene er laget for næringsliv eller innbyggere eller begge deler.
• Tjenesteeier Er den aktøren som tilbyr tjenesten. Typisk er dette offentlige etater eller kommuner. Som Skattedirektoratet, NAV, Brønnøysund kommune, Utdanningsdirektoratet osv.
• API Tilbyder Tilbyr API tilknyttet en tjeneste. Dette er typisk det samme som tjenesteeier.
• Part - Dette er den som det sendes inn eller hentes ut data for. F.eks Elkjøp er part for MVA rapporteringen for Elkjøp eller Kari Hansen er part for barnehagesøknad.
• Hjelper - Dette er en privatperson eller organisasjon som hjelper part med å gjennomføre tjenester. F.eks et regnskapsbyrå, venn, ektefelle eller revisor. Hjelperen må ha fått tildelt rettigheter for Part slik at hjelper er autorisert.
• Sluttbrukersystem - Programvare som er egenutviklet eller kjøpt inn fra leverandør. Kan være installert på hardware lokalt eller kjøre i sky. Typisk er programvaren laget for å gjøre en eller noen få relaterte oppgaver. F.eks rapportere inn MVA eller rapportere inn lakselus. Forkortes til SBS.
• SBS Tilbyder - Organisasjon som tilbyr SBS programvare til markedet. Enten via skybasert løsning eller som programvare som kan installeres på egen hardware
• SBS Ansvarlig - Organisasjon som er ansvarlig for credentials som brukes for å autentisere SBS. For skybaserte løsninger vil det være det samme som SBS Tilbyder. For lokalt installerte SBS vil det være PART eller HJELPER.
• Systembruker - Identitet opprettet i Altinn som kan tildeles rettigheter for tjenester.
• Systembruker Administrator - Part eller hjelper som har registrert en systembruker i Altinn
  systemet, men også den part som har kjøpt inn system for lokal installasjon.
• SBS register: En oversikt over programvare som brukes som sluttbrukersystem. Inneholder informasjon om hvem som er SBS Ansvarlig hvor dette er relevant.
• OAUTH Klient ID-porten Klientdefinisjon ID porten som SBS ansvarlig må opprette for systemer som skal bruke ID-porten som autentiseringsmekanisme
• SCOPE Grovkornet tilgangsmekanisme som API tilbyder kan bruke for å beskytte et API.
• Maskinporten integrasjon Klientoppsett i maskinporten som definerer nøkkeloppsett for en unik client_id. Klientoppsett er knyttet til organisasjon og kan tildeles scopes som organisasjonen har.

Typer sluttbrukersystemer

Skybasert sluttbrukersystem med sluttbrukerpålogging via ID-porten

I dette scenarioet er det en part (avgiver) eller hjelperen til en part (f.eks firma som håndterer lønn) som benytter seg av et skybasert sluttbrukersystem som tilbys fra en SBS Tilbyder.

Eksempler på slike system er

• Fiken
• Visma
• Poweroffice

Hvem autentiseres

I dette tilfellet er det sluttbrukeren selv via en av påloggingsmekanismene i ID-porten. Her kan typisk sluttbruker velge mellom BankID, MinID, Buypass osv. Når påloggingen er gjennomført får sluttbrukersystemet tilgang til et accesstoken som benyttes mot API. Accesstokenet inneholder identiteten til sluttbruker.

Systemet gjør kall mot nødvendige API ved å sende med accesstoken utstedt av ID-porten for sluttbrukeren.

Hvem autoriseres?

Bruken av API blir autorisert basert på rettigheten til sluttbrukeren. Enten via direkte delegeringer til sluttbruker av roller eller rettigheter. Eller så er det indirekte via nøkkelroller eller roller man automatisk har fått for part. Enten via roller i enhetsregisteret eller fordi man selv er personen som er part. Part kan være en organiasjon eller en person.

Hvilken trust er det til systemet?

Slik det er nå så er det systemet som ber om pålogging. Sluttbruker må akseptere at systemet får token fra ID-porten under innlogging. Sluttbruker har i praksis ingen kontroll på hva sluttbrukersystemet faktisk bruker tokenet til. Alt som sluttbruker har lov til kan systemet trigge fra bakgrunnprosesser uten sluttbrukerinvolvering.

I tillegg kan ID-port klienten bli autorisert via SCOPES som ID-port klienten har. Hvis scope krever det, må sluttbruker godkjenne bruken av scope.

Eier av API som krever scope kan definere ved hjelp av parameter requires_user_consent at sluttbruker må akseptere.

Systemet må forhåndsregistreres hos ID-porten for å få en klient-id for å kunne be om en ID-port pålogging. Det er SBS tilbyderen som gjør denne registreringen.

Skjermbildet viser når sluttbruker må godkjenne scopes.

TODO: Hvilken validering er det av system i dag før man får lukkede scopes.

Pro/cons

• Vanskelig å fullautomatisere prosesser da det krever pålogging fra bruker.

Lokal installert sluttbrukersystem med sluttbrukerpålogging via ID-porten

Dette konseptet er likt som over, men SBS ansvarlig er hjelper eller part. Hjelper eller PART må ha registrert en klient hos ID-porten som brukes som konkret i installasjonen av systemet.

Skybasert sluttbrukersystem med maskin til maskinpålogging via maskinporten

I dette scenarioet har part eller hjelper til part gått til anskaffelse av et skybasert sluttbrukersystem som benytter maskinporten til å autentisere systemet.

Eksempel på aktuelle leverandører

• PostNord Strålfors (bruker virksomhetsbrukere i dag)
• 4Human (bruker virksomhetsbrukere i dag)

Hvem autentiseres

Det som autentiseres er en OAUTH klient som er satt opp av SBS-ansvarlig/SBS-tilbyder. Autentiseringen kan skje ved hjelp av virksomhetssertifikat for SBS tilbyder, via Json Web Key (JWK) satt opp for den aktuelle klienten eller et nøkkelpar.

Hvem autoriseres?

I dette tilfellet er det systembrukeren som benyttes. En systembruker kan benyttes av organisasjonen systembrukeren er opprettet av eller av en organisasjon som har fått gitt tilgang til denne systembrukeren ved hjelp av at client_id er knyttet til systembrukeren.

Hvilken trust er det til systemet

Api som benyttes av SBS krever potensielt scopes gitt til SBS leverandør. API tilbyder/Tjenestetilbyder kan sette krav til å gi scope til SBS tilbyder.

Part eller hjelper som ønsker å benytte seg av systemet må velge å utføre en knytning (onboarding) fra av systembrukeren til SBS leverandøren. Delegering av rettigheter til systembrukeren er i praksis delegering av rettigheter til systemet som har fått en slik tilgang for systembruker.

For en systembrukeren så kan man endre systemdelegering uten å endre rettigheter gitt. F.eks at man går fra et system tilbydt fra Visma til en Maskinporten-integrasjon som er for et egetutviklet system hvor integrasjon er satt opp på egen bedrift i Maskinporten.

Onboarding process

Det er ønskelig å kunne tilby en enkel prosess som tilbydere av systemløsninger kan tilby til sine kunder slik at nødvendige rettigheter.

Målet med prosessen er å kunnne sette opp en systemtilgang for sin kunde samt veildedning i det å kunne gi rettigheter til systemtilgangen slik at løsningen til systemtilbyder kan håndtere data på vegne av sin kunde eller sin kunde kunder

Tekniske flyter

Onboarding med systemleverandør

"Onboarding" eget system

Token pålogging tynt token

• Sluttbrukersystem autentiserer seg mot Maskinporten med ClientInfo + orgnummer til hjelper/part
• Maskinporten finner systemtype fra Client-definisjon i Maskinporten.
• Maskinporten kaller Altinn Authentication for å få ut systembruker for kombinasjonen av hjelper og systemtype
• Altinn returnerer systemUserId
• Maskinporten lager et token som inneholder consumer, supplier, og systemUserId
• Sluttbrukersystem bruker token mot API
• API tilbyder plukker ut informasjon om systemUserID
• API tilbyder kaller Altinn Authorisasjon med informasjon om ressurs, part, action samt systemUserID
• Altinn Autorisasjon sjekker om systemuserID har rettighet til å utføre action for ressurs som tilhører part
• Altinn Autorisasjon returnerer svar
• API tilbyder avviser eller godtar forespørsel mot API basert på svaret.

JWT GRANT

Nedenfor viser hvordan en JWT grant kan se ut i en slik flyt

{
  "aud" : "https://test.maskinporten.no/",
  "scope" : "difitest:test2",
  "iss" : "my_client_id",
  "exp" : 1584693557,
  "iat" : 1584693437,
  "jti" : "eb6ab01e-5834-4ba0-a2a1-457bfd0f0a49",
  "systemuser_org" : "910753614"
}

Tokenet som Maskinporten oppretter hvis API kall mot Altinn viser at man har tilgang til en gitt systembruker kunne sett noe slikt ut hvis organisjonen er tilgang til systembrukeren fdfb80a6-7d54-4c86-8670-7e77307942b5 opprettet av orgnr 910753614

{
  "iss" : "https://ver2.maskinporten.no/",
  "client_amr" : "virksomhetssertifikat",
  "token_type" : "Bearer",
  "aud" : "unspecified",
  "systemuser": "fdfb80a6-7d54-4c86-8670-7e77307942b5"
  "consumer" : {
    "authority" : "iso6523-actorid-upis",
    "ID" : "0192:910753614"
  }
  "scope" : "difitest:test2",
  "exp" : 1578924303,
  "iat" : 1578923303,
  "jti" : "QPdTeNlE-RtrNczkCIZ0yAoSzJSIC3Jo7L6B_PmY2X4",
  ...
}

Tykt token

Nødvendige avklaringer

• Trenger vi et register av godkjente Maskinporten-integrasjoner, eller kan hvem som helst med en slik integrasjon i Maskinporten få gitt systemtilgang til en systembruker?

Lokalt installert sluttbrukersystem med maskin-til-maskinpålogging via Maskinporten

I dette scenarioet har man utviklet et system selv hos part, eller hjelper til part, eller man har kjøpt inn software man installerer på egen hardware. Scenarioet er ellers likt bortsett fra at SBS Ansvarlig og systembruker administrator er den samme.

Mobilapp

Her er scenarioet at man har laget en mobilapp som er tilgjengelig i AppleStore.

Hvordan løser vi det hvis det skal polles mot f.eks Dialogporten?

Person AS eksempler

Ragnar - Frilans IT-konsulent

• Behov for å rapportere inn omsetning via MVA på sitt enkeltmannsforetak:

• Utvikler eget SBS som sender inn data fra en excelfil hvor han har regnskapet.

• Registrerer OAUTH client i maskinporten for sitt enkeltmannsforetak

• Oppretter systembruker for sitt enkeltmannsforetak.

• Delegerer rettigheter til systembruker for innsending av MVA

Kari - Økonomiansvarlig for Storkjøkken AS

20 ansatte. Har behov for å rapportere på forskjellige skjema tilknyttet bedriften:

• Kjøper tilgang på skyløsningen dinbedrift.net
• Oppretter systembruker og gir nødvendige rettigheter til denne
• Delegerer systemtilgang til SBS ansvarlig.

Punkt 2 og 3 bør kunne startes fra SBS ansvarlig mot en samtykkelignende side som oppretter systembruker og gir nødvendige tilganger.

Det vil være mulighet å endre rettighetene fra Storkjøkken AS sin profil eller via en lenket forespørsel om flere rettigheter initiert av dinbedrift.net

Trine - Kundeansvarlig Revisor AS

100 ansatte. Har behov for at sine ansatte har effektive verktøy for å håndtere alle 1200 kundene de har.

• Køper tilgang til RevisorKontrolCloud
• Oppretter systembruker og refeerer til systemet tilbudet fra SBS Ansvarlig (se skjermbilde lenger ned)
• Delgerer rettigheter for alle kunder som skal behandles i systemet til systembrukeren.

Truls - Nerd med vaskehjelp

Truls er nerd og har ukentlig besøk av vaskehjelp. Dette må ha rapportere inn hver måned med "Melding om lønnet arbeid i hjemmet". Det er han møkka lei av. Så han har laget seg et system for automatisk innrapportering basert på scanning av faktura han får.

• Koder system
• Oppretter Maskinporten integasjon og systembruker
• Delegerer rettighet til skjema "Melding om lønnet arbeid" til systembrukeren

Hvordan løse dette med varig tilgang til system uten at Truls må logge inn med jevne mellomrom?

Oppsummert system scenarioer

• Egenutviklet system som kjører på egne servere installert
• Innkjøpt system som kjører på egne server med installerte credentials
• SAS system kjører i sky med installerte credentials

Avklaringer

Behov for "data-entitet" hos sluttbruker/hjelper for beskrive system og samle tilganger

Vi må lande at vi trenger en entitet som administreres av sluttbruker eller hjelper som

• Navngir og beskriver entiteten ("Økonomsystem", "Knyttet mot Visma")
• Gir muliget å delegere rettigheter for egen organisasjon eller kunder til denne "data-entiteten"
• Gir muliget til å bytte systemleverandør uten å måtte delegere på nytt

En slik "data-entitet" vil administreres fra Altinns profil.

• Ja, det må etableres en slik entitet
• Nei, dette er ikke nødvendig.

Navngi "data-entitet"

For øyeblikket kalles entitet "integrasjonsmappe". Dette gir neppe mening for sluttbrukere å delegere til "integrasjonsmappe".

Vi må lande hva vi kaller dette sluttbrukere og hva vi kaller det internt

• Integrasjonsmappe
• System Identitet
• Systembruker
• Sluttbrukersystem
• Virksomhetsystem
• Annet

Er det behov for et register for system & system-leverandører

Vi må avklarere om vi trenger et register over system & system-leverandører.

Dette registeret vil innholde minimum en liste over system med

• Navn på system
• Beskrivelse
• Informasjon om system-leverandør (Visma f.eks)

Skal systemregisteret innholde informasjon om rettigheter systemet krever/trenger for å utføre alt.

Ved å forhåndsregistrere rettighetsbehov for et system så kan Altinn Tilgangstyring automatisk foreslå delegering av rettigheter til systemet ved bruk av "Onboarding prosess"

Hvem skal kunne registrere system i registeret?

Skal det være en prosess for å kunne registrere et slik system i listen?

• Alle organisasjoner som har fått scope for API kan opprette og oppdatere system
• Det må lages en prosess hvor noen manuelt godkjenner systemet slik at det kan legges til en liste.

Skal tjenesteeiere godkjenne hvilke rettigheter et system kan forespørre

Skal det være en godkjenningsprosess for et system. Slik at f.eks SKD må godkjenne at systemet ber om rettigheter for en gitt ressurs.

Hva hvis det er tjenesteeiere som ikke ønsker denne begrensningen? Hvordan sier man at en tjeneste krever forhåndsgodkjenning?

Hvordan skal en slik godkjenningsprosess fungere? Hva med organisasjoner som utvikler sine egne system?

Vil det ikke kunne være nok at tjenesteier med API setter scope krav på API? Så kan gjerne systemleverandør forespørre om rettigheter den ikke har praktisk tilgang til å gjennomføre.

Må sluttbrukersystem selv holde styr på system-identitet som man har fått delegert tilgang til?

Når man i en onboarding prosess ber om å få opprettet en system-identitet så er en mulig flyt at man får i retur "system-identitet" referanse og man må bruke denne mot Maskinporten.

Alternativt kan system-leverandør be om liste over hvilke system-identiteter som er man har fått delegert kontroll over.

Det siste er en nødvendighet når system-identiteten er knyttet til en system basert på en prosess initiert av sluttbruker

Skal man kunne delegere flere systembrukere til samme aktør?

Vil det være mulig å delegere flere systembrukere til samme aktør?

• Nei
• Ja, det er naturlig for f.eks Visma tilbyr flere løsninger hvor man ønsker å separere rettigheter. Dette forutsette delegeringer til forskjellige systemer. Det er ikke mulig å knytte flere systembrukere til samme systemtype.

Hvilke parametere kreves ved autentisering mot Maskinporten

Når den som har fått delegert tilgang til en systembruker skal logge inn må den oppgi noe slik at Maskinporten vet hvilken systembruker som skal inn i Maskinporten token

• Systembrukerid
• SystembrukerID + orgnummer til den som eier systembrukeren
• Orgnummer til den som eier systembrukeren

Data entiteter og definisjoner

Figuren nedenfor viser en forenklet model av de dataentiteter som må etableres gitt hypoteser om løsning

Registrering av system i systemregisteret

Systemet registreres. Det blir et nytt innslag av typen SystemType. Denne har navn og beskrivelse og referanse til hvem som er leverandør av systemet. F.eks Navn «TurboSkatt» som er levert av «Visma AS» Eier refereres direkte eller indirekte via orgnr.

Det er ikke avklart om leverandører kan selvregistrere dette til systemregisteret, eller om det må gjennom en godkjenningsprosess. Hvis det blir godkjenningsprosess, hvem er det som gjør det?

Registrering av systembruker

Hvis part eller hjelper ønsker å sende inn data via API må det opprettes en systembruker. Denne systembrukeren får et navn og beskrivelse i tillegg til at det KAN knyttes mot en systemtype i systemregisteret. Hvis det knyttes til et system i systemregisteret vil leverandør av systemet kunne autentisere seg som systembrukeren.

Et system registrert i systemregisteret kan få veldig mange systembrukere knyttet til seg.
Maskinporten vil måtte sjekke mot datagrunnlag via API, om et system har rett til å benytte en gitt systembruker i sammenheng med autentisering.

Det kan kun knyttes en systembruker pr systemtype

Fullmaktsgrupper (roller) til systembruker

En part eller hjelper som har opprettet en systembruker kan velge å delegere en fullmaktsgruppe til systembrukeren. Fullmaktsgruppen gir rettigheter til de ressurser som har en policy hvor den aktuelle fullmaktsgruppen har fått rettighet. Hvis nye ressurser knyttes til fullmaktsgruppen får systembrukeren automatisk tilgang til dette.

Via klientdelegering vil hjelper kunne delegere fullmaktsgrupper

Rettigheter gitt til systembruker

En part kan delegere rettigheter til systembruker via tilgangstyring i Altinn på samme måte som man kan gi sluttbrukere rettigheter. Rettighetene gis ved å lage regler som gir et system rett til å utføre operasjoner på gitte ressurser.

En part kan også delegere via en ny samtykke dialog hvor system-leverandør ber om å få opprettet en systembruker med visse rettigheter som de kan bruke.

Det antas at en hjelper også kan delegere rettigheter via klientdelegering til en systembruker. Dette er ikke tilgjengelig i dag.

###Autorisasjon av token
Altinn Autorisasjon vil ved hjelp av systembrukerID, informasjon om ressurs og informasjon om hvem som er part for ressursen, kunne autorisere om systembrukeren har tilgang.

Skjermbilder Altinn

Nedenfor vises noen konseptuelle skjermbilder fra hvordan man muligens kan realisere håndtering av systembrukere

Samtykke basert registrering av systembruker

Manuell opprettelse og administrasjon av systembrukere fra Altinn Profil

Utviklingsoppgaver

Nedenfor sees utviklingsoppgaver tilknyttet det å utvikle en løsning for å administrere systembrukere i Altinn
#331

[joergenb]

Eg oppfattar "Sluttbrukersystem" som i hovudsak eit Skatteetaten-begrep. Blir det brukt av andre? I til dømes helsesektoren virkar det som omgrepa "fagsystem" eller "integrasjonsløsning" i større grad vert nytta: https://www.ehelse.no/standardisering/standarder/malarkitektur-for-datadeling-i-helse-og-omsorgssektoren/_/attachment/inline/a5a908cd-5054-4d21-8eaf-8b795dcb25ea:761793d5dd6b6a1f2b9dd334a44e3a754d5b88e6/M%C3%A5larkitektur%20for%20datadeling%20i%20helse-%20og%20omsorgssektoren%20(HITR%201231_2021).pdf

Spørsmålet mitt er om "sluttbrukersystem" er det samme som "fagsystem", eller om ein legge noko anna i begrepet?

[hjendal]

Ref: Enkel systemdelegering til SBS tilbyder
Hvis relasjonen er på plass utstedes et token som inneholder systembruker ID som "consumer" og SBS tilbyder som "supplier"

Er det ikke egentlig part som er consumer?

[TheTechArch]

Hvordan knytte en integrasjon mot en gitt systembruker?
Skal vi begrense integrasjon og systembrukere?

[hilmersen]

Eg oppfattar "Sluttbrukersystem" som i hovudsak eit Skatteetaten-begrep. Blir det brukt av andre? I til dømes helsesektoren virkar det som omgrepa "fagsystem" eller "integrasjonsløsning" i større grad vert nytta: https://www.ehelse.no/standardisering/standarder/malarkitektur-for-datadeling-i-helse-og-omsorgssektoren/_/attachment/inline/a5a908cd-5054-4d21-8eaf-8b795dcb25ea:761793d5dd6b6a1f2b9dd334a44e3a754d5b88e6/M%C3%A5larkitektur%20for%20datadeling%20i%20helse-%20og%20omsorgssektoren%20(HITR%201231_2021).pdf

Spørsmålet mitt er om "sluttbrukersystem" er det samme som "fagsystem", eller om ein legge noko anna i begrepet?

Skatteetaten benytter også begrepet fagsystem, men typisk om egne interne skattefagligeapplikasjoner, Man kan diskutere hvorvidt et regnskapssystem er et fagsystem eller et støttesystem, som er et begrep som hyppig benyttes for øknonomisystem m.m. Integrasjonsløsning ser jeg på som noe annet, men jeg kan se at noen kan velge å ha integresjonsløsninger mellom f.eks. egne regnskapssystem og det som for dem er eksterne tjenester.