Samhandlingsmønstre og eoppslag referansearkitektur

Størrelse: px

Begynne med side:

Download "Samhandlingsmønstre og eoppslag referansearkitektur"

Karoline Evensen
5 år siden
Visninger:

1 Samhandlingsmønstre og eoppslag referansearkitektur Håkon Jendal (NAV) Anne Lise Furmyr (Skatteetaten) 6.Februar - Faglig arena for informasjonsforvaltning - API-katalog

2 Innhold Intro - bakgrunn DSOP - Konto 3 referansearkitekturer Metode Samhandlingsmønstre Mapping til Referansearkitekturer eoppslag Mønster Pågående arbeid Sammenheng med API-katalog, Maskinport og Altinn Authorisation Case DSOP uføreforsikring Videre arbeid DSOP

3 Digital Samhandling Offentlig Privat (DSOP) Skatteetaten, Brønnøysundregistrene, NAV, Politiet og finansnæringen samarbeider om digitalisering av viktige prosesser i samfunnet DSOP programmet. Samarbeidet vil skape store verdier og spare tid og penger både for aktørene og ikke minst bidra til den videre digitaliseringen av Norge. Bits representerer finansnæringen i dette samarbeidet. Samarbeidet er basert på en porteføljetankegang der DSOP programmet setter sammen prosjektinitiativer som balanserer innsats og nytte for alle involverte parter. Programmet forutsetter aktiv deltagelse i alle prosjektene, og at partene bidrar aktivt både i de ulike prosjektfasene og til etablering av gode driftsog forvaltningsrutiner.

4 DSOP prosjekter Samtykkebasert lånesøknad (i produksjon) Kontrollinformasjon Skatt, NAV og Politiet (kontoinformasjon) Konkursbehandling Syke- og uføreopplysninger fra NAV til forsikringsselskap Maskinell kontroll av signaturrett og prokura Oppgjør etter dødsfall

5 Bakgrunn DSOP Kontoopplysninger (foranalyse 2017)

6 Mange løsningsmuligheter?? API konsument API kall WS / RestHttp API tilbyder Autentisering Autorisasjon Kryptering

Informasjonstilgang Access to Information «Information

7 Difis Referansearkitekturarbeid (2017) Meldingsutveksling edelivery «Information Push» Informasjonstilgang Access to Information «Information Pull» Hendelses-notifikasjon Event Notification «Publish-Subscribe» Difi jobbet med referansearkitektur for Meldingsutveksling, men pekte samtidig på at det vil være andre referansearkitekturer

8 Usikkerhet rundt videre veivalg Banker ønsket å utnytte investeringer og teknologi fra Peppol Skatteetaten ønsket en "KISS" online oppslagsløsning (API Rest/http) Bankene utfordret "de offentlige" til å komme med en felles anbefaling Difi, Brreg, NAV, Skatteetaten og Politiet dannet en arbeidsgruppe som ila. 1-2 måneder skulle komme med en felles anbefaling Behov for en metode

9 Gå fra behov til valg av teknologi Gjør avklaringer i rett rekkefølge Juridisk samhandlingsevne Organisatorisk samhandlingsevne Semantisk samhandlingsevne Teknisk samhandlingsevne

10 Digital informasjonsutveksling En part avgir informasjon til annen part Dette kan gjøres på forskjellige måter sett fra et forretningsståsted Heretter kalt samhandlingsmønstre Mottaker Informasjon Avgiver Note: Begrepene informasjon, opplysninger og data er i denne metoden likestilt 10

11 Digitale samhandlingsmønstre Digital samhandling mellom virksomheter kan utføres på et begrenset antall måter sett fra et forretningsståsted. Vi kaller dette samhandlingsmønstre. Samhandlingsmønstre sier ikke noe om hvilken teknologi som skal benyttes, men sier noe om hvilken egenskap samhandlingen skal ha. Det er til nå identifisert 7 forskjellige samhandlingsmønstre, men flere vil bli lagt til når det blir behov for det og eksisterende vil bli justert. NOTE: For hvert enkelt samhandlingsmønster finner man referanse til samhandlingsmønstre (patterns) som er definert av andre: UMM Transaction patterns (UN/CEFACT s Modeling Methodology - UMM) Enterprise Integration Patterns (EAI) (Gregor Hohpe og Bobby Woolf)

12 Digitale samhandlingsmønstre og referansearkitekturer 12

13 Fra digital samhandlingsprosess til valg av teknologi i 3 steg 1. Modeller fulldigitalisert forretningsprosess med fokus på digital samhandling tenk digital transformasjon 2. Identifiser samhandlingsmønstre Asynkronitet gir bedre løs-kobling og dermed bedre endringsevne Kan gjøres i parallell med steg 1 3. Identifiser beste tekniske løsning (løsningsarkitektur) som svarer på forretningsmessig behov Bruker samtykkebasert lånesøknad som eksempel Takk til SKD for lån av case

14 Steg 1 - Modeller fulldigitalisert forretningsprosess med fokus på samhandling

15 Steg 2 - Identifisere samhandlingsmønstre

16 Steg 3 - Identifisere løsning

17 eoppslag - Referansearkitektur

18 eoppslag første utkast på skisse * *) Ikke endelig / uttømmende!! Hent tekniske endepunkter Runtime teknisk Adresseringstjeneste SMP "ServiceMetaDataPublisher" API KONSUMENT Direkte API-kall (HTTP/Rest) Request med Autentiseringstoken Response: Data (evt kryptert) API TILBYDER Hent Autentiseringstoken Sikkerhetstjenester Autentisering Maskinporten Autorisasjon Sikkerhets Altinn Authorisation Sertifikat-tjeneste Kryptering BCP "BusinessCertificate Publisher" Hent Krypteringssertifikat Rettigheter, "på vegne av"

19 API-katalog og eoppslag

23 Generisk modell for delegering Pågående arbeid Difi (Brreg og eoppslags-gruppen) Konsument (C) Delegering Leverandør (L) Tilgangsstyring API-tilbyder (A) Klient Tjeneste Utfører delegering hos ber om token for C kan kreve en viss D Delegeringskilde (D) T kontrollerer Tokentjeneste (T) API-tilbyder kan definere at et gitt API kun aksepterer delegeringer utført hos en gitt delegeringskilde (D) Leverandøren må oppgi hvilken konsument han opptrer på vegne av, kan evt. peke på hvilken delegeringskilde som er autorativ for delegeringsforholdet Tokentjenesten sjekker delegeringskilden ved tokenutstedelse

26 DSOP uføreforsikring som eksempel Forsikringsselskap har behov for personopplysninger fra NAV for ytelsene sykepenger, AAP og uføre

27 NAV tilgjengeliggjør API til Forsikringsselskap API-katalog høster API fra NAV API-Gateway API-katalog API-Gateway Maskinporten Virksomhet Publiserer API til NAV API-Gateway Samtykke løsning Tjenestetilbyder Setter scope for API NAV gir tilgang fortløpende til konsumenter Konfigurere samtykke Skal det være en kobling mellom API-katalog og maskinporten? 27

28 Bruker samtykker til utlevering av personopplysninger fra NAV til forsikringsselskap 3. Logge på ID-porten nivå 4 Personbruker ID-porten Personbruker 1. Pålogging forsikringsselskapets nettside 2. Forespørsel forsikring 4. Bekreft samtykke Altinn Samtykkeløsning 5. Bekreftelse samtykke Forsikringsselskap 28

Forsikringsselskap henter opplysninger fra NAV Personbruker Ditt NAV Støtte innsyn bruker 3. Sett opp enveis TLS forbindelse mellom Forsikringsselskap og NAV 4.

29 Forsikringsselskap henter opplysninger fra NAV Personbruker Ditt NAV Støtte innsyn bruker 3. Sett opp enveis TLS forbindelse mellom Forsikringsselskap og NAV 4. Autentiser forsikringsselskap Utleveringslogg Forsikringsselskap API-Gateway Tjenestetilbyder (NAIS) Arena 1. Autentiser forsikringsselskap Maskinporten Virksomhet Altinn Samtykkeløsning 2. Hent samtykke token fra Altinn 5. Tilgangskontroll forsikringsselskap 6. Sjekk om gyldig samtykke token 7. Hent data fra fagsystem 8. Spor utlevering 29

30 Personopplysninger tankekart metadata

31 Behandlingsgrunnlag for innhenting av personopplysninger også et katalog behov? Formål Behandlingsgrunnlag Personopplysningstype Rettsregel Et behandlingsgrunnlag er en tillatelse iht. en rettsregel til å bruke en gitt personopplysningstype til et gitt formål Lovhenvisning (Hjemmel) Avtale Berettiget interesse Samtykke

32 Videre arbeid Ledes av Difis (under "Referansearkitektur") Søker balanse mellom Lettvekts "Best practice" og generisk Referansearkitektur Top-down og Bottom-up Involverer bla. Difi, Brreg, Nav, Skatteetaten (pluss flere )

Like dokumenter

Velkommen til spor 2 Samhandlingsarkitektur i praksis. Informasjonsutveksling og hvordan vi binder mange løsninger sammen

Velkommen til spor 2 Samhandlingsarkitektur i praksis. Informasjonsutveksling og hvordan vi binder mange løsninger sammen 5. September Lillehammer 09.00-11.45 Plan for dagen Kl Tema 09.05 Difi presenterer