SAMTYKKEBASERT DELING AV DATA

Transkript

1 SAMTYKKEBASERT DELING AV DATA Dokumentasjon for samtykkeløsningen i Altinn Sluttbrukere kan nå gjennom Altinn samtykke til at data om dem deles mellom datakilder (f.eks skattedirektoratet) og datakonsumenter (offentlige og private enheter). Dette er realisert ved at man i Altinn kan samtykke til at en datakonsument får delegert tilgang til en viss type data definert som en tjeneste i Altinn. Det er fire ulike alternativer for hvordan samtykkedelegeringer kan gjennomføres. I dette dokumentet vil vi først gi en detaljert beskrivelse av hvordan man får tatt i bruk samtykke løsningen i Altinn. Deretter vil vi beskrive alle fire løsningsalternativene. Vi vil i dokumentasjonen ta utgangspunkt i et Lånesøknad case der en bank ønsker tilgang til opplysninger fra skatteetaten for behandling av en lånesøknad for sluttbruker.

2 Innholdsfortegnelse INNLEDNING... 2 Samtykkeside... 2 Samtykketjeneste og kontekst... 3 Samtykketekst... 4 Oversikt over midlertidige innsyn... 4 Fjerning av samtykke... 5 Aktivitetslogg... 5 ALTERNATIV 1: SAMTYKKELØSNING MED DATAFLYT GJENNOM ALTINN... 6 Oppgaver som må gjøres av datakilde... 8 Opprettelse av innsynstjeneste i tjenesteutviklingsløsningen TUL... 8 Opprettelse av proxy Definere samtykketekst Sette rolle på tjenesten Registrere datakonsumenter for samtykketjeneste i tjenesteierstyrt rettighetsregister Enhetsteste med samtykke URL Oppgaver som må gjøres av datakonsument Opprette virksomhetsbruker med virksomhetssertifikat Autentisere seg mot Altinn API Hente ut påloggings-token Videreføre påloggings-token i kall til Altinn API ALTERNATIV 2: DATAFLYT UTENOM ALTINN Oppgaver som må gjøres av datakilde Opprettelse av lenketjeneste i tjenesteutviklingsløsningen TUL Registrere tjeneste i tjenesteierstyrt rettighetsregister Sjekke samtykke (autorisasjonsdata) Oppgaver som må gjøres av datakonsument ALTERNATIV 3: DATAFLYT UTENOM ALTINN MED REFERENCE TOKEN Oppgaver som må gjøres av datakilde Oppgaver som må gjøres av datakonsument ALTERNATIV 4: DATAFLYT UTENOM ALTINN MED SELF CONTAINED TOKEN Authorization code og Self contained Oauth token Oppgaver som må gjøres av datakilde Oppgaver som må gjøres av datakonsument BEGREPSLISTE Side 1

3 samtykkebasert deling av data D O K U M E N T A S J O N F O R S A M T Y K K E L Ø S N I N G E N I A L T I N N INNLEDNING I samtykkeløsningen i Altinn vil brukeren gi samtykke til at en tredjepart får midlertidig innsynsrett på et spesifikt sett med opplysninger om brukeren som tidligere er innhentet. Med brukerens samtykke vil det automatisk bli gitt en tidsbegrenset lese-rettighet for en eller flere definerte Altinn-tjenester. Autorisasjonsmotoren i Altinn støtter tidsbegrensede rettighetsdelegeringer altså tildelinger av rettigheter som har en angitt gyldighetsperiode. Samtykkeside For alle tjenester som benytter seg av Altinn sin samtykkefunksjonalitet vil sluttbrukeren bli presentert for en egen samtykkeside. Tredjepart angir hvilke opplysninger det ønskes midlertidig innsyn i, hvor lenge innsynet skal vare og i hvilken kontekst (altså hvorfor tredjepart vil ha innsyn) opplysningene skal benyttes. Figur 1 viser et eksempel på hvordan en samtykke siden kan se ut for et lånesøknadcase. Side 2

4 FIGUR 1EKSEMPEL PÅ SAMTYKKESIDE FOR EN LÅNESØKNAD Samtykketjeneste og kontekst Tredjepart angir hvilke opplysninger det ønskes midlertidig innsyn i (definert ved en samtykketjeneste i Altinn), hvor lenge innsynet skal vare og i hvilken kontekst (altså hvorfor tredjepart vil ha innsyn) opplysningene skal benyttes. Alle disse opplysningene angir tredjepart som input til samtykke-siden i URL. I Lånesøknad caset er det Banken som er tredjepart. Konteksten som angis av banken i URL kan tilpasses hver enkelt brukstilfelle om det er ønskelig. Men banken har da selv ansvar for å holde oversikt over de forskjellige kontekstene. Konteksten vil også logges i brukerens oversikt over samtykker i Altinn. Konteksten kan være på maks 600 tegn. Side 3

5 Samtykketekst Samtykketeksten skal forklare nærmere hva brukeren samtykker til. For at samtykke skal være gyldig må det være informert. Det betyr at brukeren får informasjon som gjør at han forstår hva han samtykker til og hvilke konsekvenser det vil få for han. I Lånesøknad case så bør samtykketeksten si hvilke opplysninger banken henter fra selvangivelsen. Om det er informasjon om lønn, gjeld eller andre ting. Samtykke teksten defineres ikke av banken, men av Skatteetaten (SKD) eller datakilden som deler data. Det er derfor nødvendig at datakilden/skd og datakonsumenten/bankene blir enige om en tekst som er fornuftig å bruke. Samtykketeksten kan være på maks 2000 tegn. Oversikt over midlertidige innsyn Sluttbruker kan logge inn i Altinn og gå inn på siden Profil, roller og rettigheter for å få en oversikt over hvem man har gitt midlertidig innsyn til. Figuren under viser hvordan midlertidige innsyn vil presenteres for bruker. FIGUR 2 MIDLERTIDIG INNSYN PÅ PROFIL, ROLLER OG RETTIGHETSSIDEN I ALTINN Side 4

6 Fjerning av samtykke samtykkebasert deling av data Det er også mulig å fjerne et samtykke man har gitt. Etter at samtykke er fjernet vil det ikke lenger være mulig for tredjepart å få tilgang til data som sluttbrukeren opprinnelig samtykket til å dele. For å fjerne samtykke velger man «se og fjern samtykke» under midlertidig innsyn (se figur 2). FIGUR 3 EKSEMPEL PÅ HVORDAN MAN FJERNER ET SAMTYKKE Aktivitetslogg Sluttbruker får tilgang til en aktivitetslogg på sidene for «Profil, Roller og Rettigheter» som viser hvilke samtykker brukeren har gitt, når de har utløpt osv. Denne aktivitetsloggen vil også inneholde normale rolle og rettighets delegeringer (fra dagen loggfunksjonaliteten produksjonsettes) og bidrar til at alle brukere har innsyn i hvilke rettigheter som delegeres på vegne av en virksomhet for eksempel. Side 5

7 ALTERNATIV 1: SAMTYKKELØSNING MED DATAFLYT GJENNOM ALTINN Dette alternativet baserer seg på at Altinn er en proxy for datakilder som ønsker å være tilgjengelige for forskjellige datakonsumenter. Datakilden er eier av informasjonen som skal deles og datakonsumenten er den som ønsker tilgang til denne informasjonen. I dette alternativet delegerer sluttbrukeren rettighet for en gitt innsynstjeneste til en datakonsument. Datakilden har på forhånd opprettet en innsynstjeneste i Altinns tjenesteutviklingsløsning. Sluttbrukeren bekrefter at rettighetsdelegering skal utføres på samtykke siden og datakonsument kaller så Altinn, med parameter som inneholder referanse til Altinn-bruker, i form av personnummer for sluttbruker/organisasjonsnummer for virksomhet sammen med tjenestekoder for å identifisere aktuelle innsyntjenester. Dette kallet til Altinn kan skje ved hjelp av forskjellige protokoller: 1. Som virksomhetsbruker via web service grensesnitt (SOAP 1.2) 2. Som sluttbrukersystem via web service grensesnitt (SOAP 1.0/1.2) 3. Som virksomhetsbruker via REST grensesnitt I Altinn verifiseres det at samtykket er gitt og dermed at datakonsument har nødvendige rettigheter. Hvis det er tilfelle videreføres kallet fra datakonsumenten ved hjelp av en proxy knyttet til innsynstjenesten, som utfører et kall mot en tjeneste(er) hos datakilde. Datakilde kan da stole på at Altinn sikrer at det er kun datakonsumenter som har fått tildelte rettigheter for angitt Altinn-bruker som får tilgang til data. Se begrepsliste for forklaring av alle begreper som er brukt i dokumentet. Figuren under viser hvordan en slik prosess kan skje: Side 6

8 FIGUR 4 DATFLYT FOR ALTERNATIV 1 Under ser dere en nærmere forklaring av steg 1-9 i figur 4 1. Sluttbruker går inn på ei nettside som bruker samtykkeløsningen i Altinn og en HTTP request blir sendt til datakonsumenten. 2. Datakonsument behandler forespørselen fra bruker. Som en del av prosessen sender datakonsumenten bruker til samtykkesiden og sluttbruker må logge seg inn i Altinn om man ikke allerede er logget. 3. Sluttbrukeren gir samtykke på samtykkesiden som medfører at rettigheter blir tildelt datakonsumenten i Altinn autorisasjon 4. Etter at rettigheter er tildelt blir brukeren sendt tilbake til datakonsument (5) 5. se punkt 4 6. Datakonsumenten spør Altinn Intermediary om å få data for sluttbruker 7. Altinn intermediary sender da en forespørsel til Altinn autorisasjon for å få bekreftet at datakonsumenten skal ha tilgang til sluttbrukers data 8. Dersom datakonsumenten har tilgang (punkt 3 er gjennomført) sender Altinn Intermediary forespørselen til datakilden Side 7

9 9. Datakilden sender data tilbake til Altinn intermediary som videresender en respons til datakonsument 10. Altinn videresender data responsen til datakonsumenten Med alternativ 1 vil Altinn tilby både tjenestegrensesnitt og samtykke-autorisasjon mot alle konsumenter. I dette alternativet trenger derfor datakilden og datakonsumenten bare å forholde seg til kommunikasjon med Altinn. Oppgaver som må gjøres av datakilde I dette kapittelet vil vi beskrive hvilke oppgaver som datakilden må gjøre for å få realisert en samtykkeløsning i Altinn. Vi vil ta utgangspunkt i eksemplet Lånesøknad, der en bank ønsker å lage en samtykkeløsning som gjør at sluttbruker kan samtykke i at banken henter ligningsdata fra skatteetaten i sin behandling av lånesøknaden. Opprettelse av innsynstjeneste i tjenesteutviklingsløsningen TUL I Lånesøknad-caset vil datakilden være skatteetaten. Datakilden må være tjenesteeier i Altinn og ha tilgang til tjenesteutviklingsløsningen TUL. Innsynstjenester er tjenester som brukes til å hente data fra en tjenesteeier til Altinn ved å kalle en eller flere web services og presentere disse dataene for brukeren i Altinn portalen. Forretningslogikk og data ligger hos tjenesteeier, mens presentasjonen av dataene ligger i Altinn. I samtykkeløsningen brukes innsynstjenesten ikke til presentasjon av data i Altinn portalen, men kun til å definere samtykketjenesten, og til å knytte tjenesten til proxyen som gjør det mulig for datakonsumenten å kalle datakilden igjennom Altinn. Innsynstjenestene som brukes i forbindelse med samtykkebasert deling av data vil derfor ikke oppføre seg som en tradisjonell innsynstjeneste i Altinn. Figur 2 viser definisjon av innsynstjenesten i TUL. Side 8

10 DEFINERING AV INNSYNSTJENESTE FIGUR 5 DEFINERING AV INNSYNSTJENESTEN I TUL Utgavenavnet vil vises for sluttbruker på samtykkesiden derfor kan det være hensiktsmessig å velge et navn som også forteller hva slags data eller informasjon denne tjenesten tilbyr. I Lånesøknad har vi valgt å kalle innsynstjenesten for ligningsopplysninger fordi det er ligningsdata som skatteetaten her vil dele med bankene. Det er viktig å markere at tjenesten skal bruke tjenesteierstyrt rettighetsregister. Ved å gjøre dette sikres det at kun registrerte datakonsumenter kan benytte samtykkesiden, og eksempelvis be om å få hentet ut ligningsdata fra skatteetaten. Husk at det ikke er nok å bare markere dette i TUL på innsynstjenesten, listen over gyldige datakonsumenter må også vedlikeholdes i det tjenesteeierstyrte rettighetsregisteret for Side 9

11 den aktuelle innsynstjenesten. Registrering i tjenesteeierstyrt rettighetsregister gjøres med webservicekall til Altinn som sier hvilke organisasjoner eller personer som skal registreres i rettighetsregisteret for akkurat denne utgaven. Les mer om dette under. Opprettelse av proxy Kall til alle eksterne web services fra InfoPath i Altinn skal gå gjennom en proxy, eller såkalt mapper. Dette er en intern webservice som kaller en ekstern web service, og som returnerer resultatet fra denne. Hovedgrunnen til at en slik proxy må benyttes er at adressen som legges inn i InfoPath skal være lik, uavhengig av hvor selve web servicen som returnerer data befinner seg. En mapper kan inneholde en eller flere operasjoner. Vi henviser til dokumentasjonen som ligger her for hvordan man utvikler en mapper i Altinn: %20Brukerdokumentasjon%20for%20tjenesteutvikling/Mapper_Utvikling_0_9.pdf Når mapperen er ferdig utviklet og installert på Altinn sitt mappershare, må navnet på mapperen registreres på utgaveparametersiden til innsynstjenesten.. Se figur 3 under. FIGUR 6 NAVNET PÅ MAPPER MÅ LEGGES INN UNDER MAPPERNAVN Side 10

12 Definere samtykketekst Hvis man skal lage en innsynstjeneste som skal benyttes som en samtykke tjeneste må man gå inn på Samtykke-fanen i TUL og huke av for å tillate at utgaven skal tillate samtykkebasert deling av data. Da vil det bli obligatorisk å fylle ut en samtykketekst som vil vises for sluttbruker under samtykkesiden. Samtykketeksten skal forklare nærmere hva brukeren samtykker til. For at samtykke skal være gyldig må det være informert. Det betyr at brukerne får informasjon som gjør at de forstår hva de samtykker til og hvilke konsekvenser det vil få for dem. I vårt Lånecase så bør samtykketeksten si hvilke opplysninger banken henter fra selvangivelsen. Om det er informasjon om lønn, gjeld eller andre forhold. Samtykketeksten defineres ikke av banken, men av skatteetaten eller datakilden som deler de faktiske dataene. Det er derfor nødvendig at datakilden/skd og datakonsumenten/banken blir enige om en tekst som er fornuftig å bruke. FIGUR 7 VISER HVORDAN MAN DEFINERER Å BRUKE SAMTYKKEBASERT DELING AV DATA I TUL Sette rolle på tjenesten Før man migrerer tjenesten over til testmiljø og produksjon må man sette en rolle på tjenesten. Rollen man velger trenger ikke å være delegerbar, men enkeltrettigheter på tjenesten må være delegerbare. I vårt eksempel har vi valgt å sette ALLEA rollen, men det bør vurderes hvilken rolle som er best egnet. Side 11

13 FIGUR 8 VISER HVILKE RETTIGHETER SOM ER SATT PÅ INNSYNSTJENESTEN I TUL Registrere datakonsumenter for samtykketjeneste i tjenesteierstyrt rettighetsregister Figur 4 viser et eksempel på hvordan en request for å registrere en datakonsument i tjenesteierstyrt rettighetsregister ser ut. ServiceCode er tjenestekoden og ServiceEditionCoden er tjensteutgavekoden for aktuell innsynstjeneste og hentes fra TUL. Reportee angir datakonsumenten som skal kunne benytte samtykkesiden og hente ut data gjennom denne innsynstjenesten. I Lånesøknadcasen må man legge inn organisasjonsnummeret til alle bankene som skal få lov å hente ligningsdata fra Skatteetaten. Det må også registreres hvilket domene sluttbruker skal sendes til etter at sluttbruker har godtatt samtykke eller ikke. Dette legges inn etter AllowedRedirectDomain. Husk at det kun er mulig å legge inn ett domene per datakonsument (organisasjonsnummer). Side 12

14 FIGUR 9 EKSEMPEL REQUEST FOR Å REGISTRERE EN TJENESTE I TJENESTEEIERSTYRT RETTIGHETSREGISTER Enhetsteste med samtykke URL Når man har opprettet en tjenesteutgave i Altinn sin tjenesteutviklingsløsning og konfigurert den til å være en «samtykketjeneste» og migrert den over til Altinn sitt testmiljø (AT08 eller TT02) kan man definere en URL som gjøre at man får testa ut samtykke siden. Eksempel på en URL kan være: turl= er eksempel på en samtykke kontekst tekst..responsetype=code Forklaring på hva de ulike begrepene som benyttes i URL en finner dere i kapitlet Begrepsliste. Oppgaver som må gjøres av datakonsument For at datakonsumenten skal få tak i data fra datakilden via Altinn kan man bruke 2 forskjellige metoder: 1. Web service grensesenitt med virksomhetsbruker og virksomhetssertifikat 2. REST grensesnitt med virksomhetsbruker og virksomhetssertifikat I vår Lånesøknad har vi valgt å kommunisere med Altinn via REST grensesnitt (2) og her vil vi beskrive hva som da må gjøres av datakonsument. Side 13

15 Opprette virksomhetsbruker med virksomhetssertifikat Det er to aspekter ved bruken av sertifikater i forbindelse med samtykke. Det ene er kommunikasjon med datakilden, men det er også behov for det når banker skal autentisere seg mot Altinn. Når banken skal bruke samtykket brukeren har gitt, så vil en spørring mot Altinns REST-api eller webservicer medføre at banken må autentisere seg med virksomhetssertifikatfor en en ren maskin-til-maskin-integrasjon. Etter at man har installert sertifikat fra utsteder, må man registrere sertifikatet i Altinn og opprette en virksomhetsbruker. Dette er beskrevet her ( En virksomhetsbruker har i utgangspunktet ingen rettigheter til å benytte tjenester i Altinn på vegne av virksomheten den er knyttet til. For at en datakonsument skal kunne utnytte virksomhetsbrukeren må den derfor først tildeles nødvendige rettigheter. Daglig leder eller andre hos datakonsumenten med rettigheter i Altinn (Rollen tilgangsstyring og rettigheter til aktuell samtykketjeneste) må derfor logge inn i Altinnportalen og tildele virksomhetsbrukeren nødvendige rettigheter for å benytte samtykketjenesten. Autentisere seg mot Altinn API Send følgende POST-request mot APIet med brukernavn/passord for virksomhetsbruker du har opprettet. POST HTTP/1.1 Host: Content-Type: application/hal+json ApiKey: mykey { "UserName": "MyUsername", "UserPassword": "MyPassword" } Hente ut påloggings-token Etter vellykket pålogging oppretter Altinn et sett med tokens i form av HTTP cookies i Set-Cookie header. Når Altinn har opprettet disse tokenene burde din applikasjon hente de ut, siden disse må legges ved i fremtidige kall for å identifisere innlogget bruker. Side 14

16 Videreføre påloggings-token i kall til Altinn API Tokenet du hentet ut legges i HTTP header som «Cookie" i videre på kall til Altinn API: Cookie:.ASPXAUTH=2AF7F API nøkkelen må også legges ved i HTTP header slik: ApiKey: mykey API nøkkel får du etter registrering av din applikasjon. Hente ut altinnid for de som har samtykket: Send følgende GET-request mot for å finne Altinnidn for brukeren GET eq <SluttbrukersPersonnummer> HTTP/1.1 Host: Content-Type: application/hal+json ApiKey: mykey Apiet vil returnere et array med Reportees slik: { "_links": { "find": { "href": " "istemplated": true }, "self": { "href": " } }, "_embedded": { "reportees": [ { "ReporteeId": "r ", "Name": "ANNELI SKOMEDAL", "Type": "Person", "SocialSecurityNumber": " ", Side 15

17 } ] } "_links": { "self": { "href": " }, "messages": { "href": " } } } "ReporteeId" må benyttes i påfølgende kall til APIet for å hente sluttbrukers data. Dersom «reportees» arrayet er tomt vil det si at aktuell sluttbruker ikke har gyldig samtykke. Hente data for sluttbruker: Send følgende GET-request mot for å finne hente data for sluttbrukeren: GET alue1&value2 returnerer dataene man har samtykket til å dele HTTP/1.1 Host: Content-Type: application/hal+json ApiKey: mykey Side 16

18 ALTERNATIV 2: DATAFLYT UTENOM ALTINN samtykkebasert deling av data I dette alternativet går dataflyten utenom Altinn. Datakilden vil i dette alternativet bruke Altinn sin autorisasjonskomponent til å sjekke om datakonsumenten har nødvendige rettigheter. Kallet mot Altinn skjer gjennom webservice-operasjonen AuthorizeAccess som bruker XACML-formatet. Her vil datakilden oppgi identifikator på sluttbruker (personummer), datakonsument (organisasjonsnummer), tjeneste (servicecode /edition code) og operasjon. (read, write). I dette alternativet står datakonsumenten og datakilden helt fritt til å velge kommunikasjonsform. Det kan for eksempel være via webservice, REST eller FTP. Datakilden må være registrert med etatssystem som tjenesteeier for kunne bruke Altinns autorisasjonskomponent. Figur under viser hvordan flyten for alternativ 2 kan se ut: FIGUR 10 SAMTYKKE PROSESS MED DATAFLYT UTENOM ALTINN I Alternativ 2 og 3 vil Altinn håndheve samtykke-autorisasjon, mens datakilde må tilby tjenestegrensesnitt mot alle konsumenter. Oppgaver som må gjøres av datakilde I dette kapittelet vil vi beskrive hvilke oppgaver som datakilden må gjøre for å få realisert en samtykkeløsning i Altinn hvis man velger å benytte alternativ 2, der dataflyten går utenom Altinn. Vi vil ta utgangspunkt i eksemplet Lånesøknad, der en bank ønsker å lage en samtykkeløsning som gjør at sluttbruker kan samtykke i at banken henter ligningsdata fra skatteetaten i sin behandling av lånesøknaden. Side 17

19 Opprettelse av lenketjeneste i tjenesteutviklingsløsningen TUL I lånecaset vil datakilden være skatteetaten. Selv om dataflyten i Alternativ 2 skal gå utenom Altinn må datakilden allikevel definere en tjeneste i TUL. For alternativ 2, 3 og 4 benytter man Altinn sin lenketjeneste for å definere og konfigurere tjenesten som skal benyttes i samtykke tjenesten. En lenketjeneste vil i disse tilfellene benyttes for å definere den eksterne datakilden og til å legge inn samtykketeksten som skal vises for sluttbruker når man åpner samtykkesiden. DEFINERING AV LENKETJENESTE Utgavenavnet vil vises for sluttbruker på samtykkesiden derfor kan det være hensiktsmessig å velge et navn som også forteller hva slags data eller informasjon denne tjenesten tilbyr. I Lånesøknad har vi valgt å kalle lenketjenesten for ligningsdata fra skatteetaten fordi det er ligningsdata som skatteetaten her vil dele med bankene. Husk å huke av at tjenesten skal bruke tjenesteierstyrt rettighetsregister. Ved å huke av her vil man sikre at ikke hvem som helst kan kunne be om å få hentet ut ligningsdata fra skatteetaten. Husk at det ikke er nok å bare huke av her, man må etterpå gjøre et webservicekall til Altinn som sier hvilke organisasjoner eller personer som skal registreres i rettighetsregisteret for akkurat denne utgaven og dermed får anledning til å be brukere samtykke i å dele sine data. Side 18

20 DEFINERE SAMTYKKETEKST Hvis man skal lage en lenketjeneste som skal benyttes i en samtykke tjeneste må man gå inn på Samtykkefanen i TUL og huke av for å tillate at utgaven skal tillate samtykkebasert deling av data. Da vil det bli obligatorisk å fylle ut en samtykketekst som vil vises for sluttbruker under samtykkesiden. Samtykketeksten skal forklare nærmere hva brukeren samtykker til. For at samtykke skal være gyldig må det være informert. Det betyr at brukerne får informasjon som gjør at de forstår hva de samtykker til og hvilke konsekvenser det vil få for dem. I vårt Lånecase så bør samtykketeksten si hvilke opplysninger banken henter fra selvangivelsen. Om det er informasjon om lønn, gjeld eller andre forhold. Samtykketeksten defineres ikke av banken, men av skatteetaten eller datakilden som deler de faktiske dataene. Det er derfor nødvendig at datakilden/skd og datakonsumenten/banken blir enige om en tekst som er fornuftig å bruke. Side 19

21 SETTE ROLLE PÅ TJENESTEN Før man migrerer tjenesten over til testmiljø og produksjon må man sette en rolle på tjenesten. Rollen man velger trenger ikke å være delegerbar, men enkeltrettigheter på tjenesten må være delegerbare. I vårt eksempel har vi valgt å sette ALLEA rollen. Registrere tjeneste i tjenesteierstyrt rettighetsregister Figur 6 viser et eksempel på hvordan et request for å registrere en tjenesteutgave og en organisasjon i tjenesteierstyrt rettighetsregister ser ut. ServiceCode er tjenestekoden og ServiceEditionCoden er tjensteutgavekoden og hentes fra TUL. Reportee angir hvilken organisasjon som skal få lov å hente ut data gjennom denne innsynstjenesten. I Lånesøknadcasen må man legge inn organisasjonsnummeret til alle bankene som skal få lov å hente ligningsdata fra Skatteetaten. Man må også legge inn hvilket domene man skal sendes til etter at sluttbruker har godtatt samtykke eller ikke. Dette legges inn etter AllowedRedirectDomain. Husk at det kun er mulig å legge inn ett domenen per organisasjonsnummer. Side 20

22 Sjekke samtykke (autorisasjonsdata) Når datakilden har mottatt et request fra datakonsumenten i spørringen etter data om sluttbrukeren, må den verifisere at datakonsumenten har fått samtykke fra sluttbrukeren. Dette gjør datakilden ved å kalle AuthorizationDecisionPointExternal.AuthorizeAccessExternal med XACML request med datakonsument, sluttbruker og aktuell samtykketjeneste (servicecode/serviceeditioncode) og aktuell operasjon (READ) som input. Dette er et standard XACML kall. Oppgaver som må gjøres av datakonsument Når brukeren har gitt samtykke for en angitt tjeneste skal datakonsumenten sende en request til datakilden for å hente data for sluttbrukeren. Den requesten må da inneholde id til sluttbrukeren og informasjon om hvilken tjeneste samtykket gjelder, angitt med ServiceCode og ServiceEditionCode. Formatet på hvordan denne informasjonen overføres i requesten må avtales mellom datakilde og datakonsument, og styres ikke av Altinn. ALTERNATIV 3: DATAFLYT UTENOM ALTINN MED REFERENCE TOKEN I Alternativ 3 for samtykkekonsumenten henter datakonsumenten data direkte fra datakilden og Altinn kun benyttes til å la brukeren få gi samtykke. Det vil si at datakilden selv må sjekke om datakonsumenten har fått samtykke fra sluttbrukeren. Side 21

23 I dette alternativet går også dataflyten utenom Altinn men under selve samtykket får datakonsumenten et Oauth2 token som skal benyttes for autorisasjon. Når sluttbruker delegerer rettigheter til en datakonsument gjøres det ved hjelp av at man oppretter et Oauth token i Altinns autorisasjonsdatabase som man knytter rettigheter til. I det øyeblikket delegering er utført blir tokenet overført til datakonsument. Når datakonsument kaller datakilde direkte sendes token med request og datakilden må da verfisere at token faktisk gir tilgang til de ressursene. Dette gjøres ved å kalle Altinns autorisasjonskomponent som er utvidet for å støtte verifisering av Oauth token. Figuren under viser hvordan en slik prosess vil se ut. FIGUR 11 SAMTYKKE PROSESS VED BRUK AV OAUTH TOKEN I Alternativ 2 og 3 vil Altinn håndheve samtykke-autorisasjon, mens datakilde må tilby tjenestegrensesnitt mot alle konsumenter. Oppgaver som må gjøres av datakilde På samme måte som i Alternativ 2 og 4 så må datakilden også under alternativ 3 definere en lenketjeneste i TUL, definere samtykketekst for utgaven, registrere tjenesteutgaven i tjenesteeierstyrt rettighetsregister og sette rolle på tjenesten. Når datakilden har mottatt tokene fra datakonsumenten sammen med spørringen etter data om sluttbrukeren, må den verifisere at datakonsumenten har fått samtykke fra sluttbrukeren. Dette gjør data kilden ved å kalle AuthorizationDecisionPointExterna.AuthorizeAccessExternal med XACML request med tokenet som input. Dersom Altinn svarer at tokenet er gyldig skal datakonsumenten få tilgang til data. Side 22

24 Oppgaver som må gjøres av datakonsument Datakonsumenten må ha registrert virksomhetsbruker for å hente ut token. Datakonsumenten må sende sluttbrukeren til samtykkesiden med en parameter som sier at den ønsker en authorizationcode tilbake etter at samtykket er gitt. Når brukeren har gitt samtykke for en angitt tjeneste skal datakonsumenten benytte autorizationcode til å hente et token. Dette tokene er ikke signert av Altinn. Når datakonsumenten kaller datakilden for å be om data om sluttbrukeren, skal dette tokenet legges ved som bevis. ALTERNATIV 4: DATAFLYT UTENOM ALTINN MED SELF CONTAINED TOKEN Dette alternativet baserer seg som alternativ 3 på et token, men i dette tilfellet er tokenet «selfcontained» som betyr at tokenet i seg selv inneholder all informasjon om rettigheten(e) som er blitt delegert. Når brukeren gjør delegeringen sendes tokenet til datakonsument og datakonsument sender dette videre til datakilde ved uthenting av data. Tokenet vil da bli verifisert direkte hos datakilde for å sjekke at innhold stemmer med ønsket utført operasjon. Dette krever at tokenet blir signert med Altinn sertifikat slik at datakilden kan stole på at innholdet er korrekt. Figuren under viser hvordan en slik prosess kan skje: FIGUR 12 SAMTYKKE PROSESS MED SELF CONTAINED TOKEN I alternativ 4 må datakilden både autorisere samtykke og tilby tjenestegrensesnitt mot alle konsumenter. Side 23

25 Authorization code og Self contained Oauth token Self contained Oauth token er en nøkkel som datakonsumententen benytter for å få tilgang til data som ligger hos datakilden. Dere kan lese om JSON webtokens her: Etter at sluttbruker har åpnet samtykkesiden og trykket på «gi samtykke» vil sluttbrukeren sendes tilbake til siden som er angitt i redirecturl. I URL sluttbruker sendes tilbake til vil det sendes med en autorisasjonskode og en status som forteller om det gikk ok eller ikke. Her ser dere et eksempel på hvordan en slik URL vil se ut om status er ok: 9e4960d5a8b4&Status=OK Autorisasjonskoden brukes av datakonsumenten til å få tak i Oauth token. Her ser dere et eksempel på hvordan et dekodet token ser ut: HEADER: Algorithm & token type { } "typ": "JWT", "alg": "RS256", "x5t": "KaPli0RTuUTr_rQrVJhsBCWA-2k" PAYLOAD: Data { } "ServiceCodes": "v5265,1", "OfferedBy": " ", "CoveredBy": " ", "ValidToDate": " :30:00", "iss": "altinn.no", "exp": , "nbf": ServiceCodes er den unike id en til lenketjenesten man har opprettet for samtykke i tjensteutviklingsløsningen TUL. OfferedBy er personnummeret til den personen som har bedt om samtykke. CoveredBy er organisasjonsnummeret til datakonsumenten. Side 24

26 ValidToDate er gyldighetsdatoen for når samtykket går ut. Oppgaver som må gjøres av datakilde Datakilde må ha Altinns public sertifikat for å sikre at token er gyldig og autorisert. Token har 30 sekunders gyldighet som også må verifiseres av datakilden. På samme måte som i Alternativ 2 og 3 så må datakilden også under alternativ 4 definere en lenketjeneste i TUL, definere samtykketekst for utgaven, registrere tjenesteutgaven i tjenesteeierstyrt rettighetsregister og sette rolle på tjenesten. Oppgaver som må gjøres av datakonsument Datakonsumenten må be om nytt token når det har gått ut (benytt autorization code). For å få tak i token må datakonsumenten bruke Authorization Token External WCF tjenesten og opersjonene den tilbyr. Token tjeneste kontrollerer acess token i Altinn autorisasjon komponent, som brukes for å godkjenne tilgang til data som deles gjennom samtykke delegering av rettigheter. Side 25

27 BEGREPSLISTE Begrep Forklaring Datakonsument Part som ønsker tilgang til data Ansvaret for å sende sluttbruker til Altinn for delegering av rettigheter til tjenestene Ansvarlig for å be om data fra datakilde I lånesøkandscaset er dette bankene Altinn autorisering Verifisere at man har lov til å be om samtykke på en gitt tjeneste Opprette og vedlikeholde nødvendige autorisasjonstilganger Videresende sluttbruker til datakonsument Svare på autorisasjonsforespørsler Altinn intermediary Komponent i Altinn som verifiserer autorisasjon og kaller videre til innsynstjeneste hos datakilde Datakilde Enhet som teknisk har data for bruker eller organisasjon Verifisere mot autorisasjon om datakonsument har nødvendige tilganger I lånesøknadscaset vil dette være SKD Sluttbruker Delegere rettigheter Person som gir samtykke til sine eller andres data CoveredBy Mottaker av samtykket Dersom dette er en person kreves også etternavn på person. (CoveredByName) OfferedBy Hvem som gir samtykket Resources ValidToDate RedirectUrl DelegationContext Angir hvilke utgave av tjenester det gis samtykke til (kan være flere tjenester) Gyldighetsperiode for samtykket Hvor bruker blir sendt når delegering er gjennomført Beskrivelse fra datakonsument Side 26

28 Mapper Tjenesteierstyrt rettighetsregister Tjenesteeier/datakilde kan kreve at tjenesten skal benytte Tjenestestyrt register: Benyttes for å kontrollere Hvem som kan spør om tilgang til data gjennom Samtykke Om bruker skal forbli innlogget i Altinn etter delegering Hvilke domene sluttbruker skal kunne bli sendt videre til Authorization code Oauth token Kode som brukes av datakonsumenten til å få tak i Oauth token OAuth er en åpen standard for autorisasjon, ofte brukt som en måte for Internett-brukere å logge på tredjeparts nettsteder ved hjelp av sine Microsoft, Google, Facebook eller Twitterkontoer uten å oppgi passordet sitt. Side 27