altinn-studio
altinn-studio copied to clipboard
Altinn
Tjenesteeier kan angi hvem som er innlogget bruker i øvrige tjenesteeiers brukerflater
Description
Skatteetaten ønsker å kunne angi hvem som er innlogget bruker i Skatteetatens brukerflate i operasjoner som gjøres mot Altinn3-appen.
Skatteetaten har laget en brukerflate som behandler data som er lagret i en Altinn3-app. Denne brukerflaten identifiserer brukeren med ID-porten (med SAML, per dags dato). Men kommunikasjonen mellom Skatteetatens servere og Altinn3- appen skjer med Skatteetatens Maskinporten-nøkkel. Som tjenesteeier av Altinn3-appen så ønsker Skatteetaten å angi hvem den innloggede brukeren er.
Additional Information
Det er godt nok for oss å kunne angi hvem som utførte steget. Jeg har lagt ved et forslag til løsning (se PDF), med nytt next-API. Kan kanskje også løses med utvidelser i eksisterende API-er…
2022-09-21 Forslag til løsning i Altinn3 for å la tjenesteeier angi identitet til bruker.pdf
Her må vi avklare det med sikkerhet før implementasjon. Ideelt sett så burde nok token som identifiserer bruker flyte til APIet i app, at brukerflaten hos Skatteetaten oppfører seg som andre klienter. Antar at dette ikke er mulig med SAML (som er på vei ut).
@knut-olav-hoven-ske Har dere vurdert å benytte OIDC mot ID-porten?
//cc: @TheTechArch @elsand
Å bruke brukerens OIDC-token for denne flyten har vært diskutert i Skatteetaten i flere runder.
Vi bruker faktisk dette mønsteret allerede i web-løsningen "Skatt Delegering", hvor innlogget bruker kan velge å representere en annen person. Altinn Autorisasjon-API-ene vi kaller på trenger brukerens egen tilgangsnøkkel. Denne løsningen har noen svakheter som av og til gir en litt dårlig brukeropplevelse.
Enn så lenge er bruk av Maskinporten-nøkkel vår foretrukne løsning for kommunikasjon mellom Skatteetatens serverpark og Skatteetatens tjenester/apper på Altinn.
Kan sikkerhetsproblemet løses ved at det lagres i databasen/sporingsloggen at det var tjenesteeier - og ikke ID-porten - som var kilden for identifisering av brukeren?
Vi bruker faktisk dette mønsteret allerede i web-løsningen "Skatt Delegering"
Dette er vel via nettleser, og ikke server-til-server som foreslås her?
Kan sikkerhetsproblemet løses ved at det lagres i databasen/sporingsloggen at det var tjenesteeier - og ikke ID-porten - som var kilden for identifisering av brukeren?
Utfordringen er vel at brukere og andre orgs med rettigheter til next-api'et da også vil kunne gjøre det samme.
-
Initiert via nettleser ja, men det er vår server (backend-for-frontend) som henter access-tokenet fra ID-porten. Noen hos dere (Altinn) har frarådet oss å holde tokenet i nettleseren. Det ser også ut til å være ID-porten sin anbefaling, ref https://docs.digdir.no/docs/idporten/oidc/oidc_auth_spa
-
Muligheten for å angi brukeren må begrenses til kun tjenesteeieren. Er ikke next-API-ene per Altinn3-app? URL-en vi kaller på er bygd opp slik i tt02:
https://skd.apps.tt02.altinn.no/skd/formueinntekt-skattemelding-v2/instances/<partyId-og-instansId>/process/nextNår vi med Skatteetatens Maskinporten-token kaller på API-ene for å styre prosessen, så vises dette i processHistory med "performedBy=skd".
-
Noen grunn til at dere ikke kan gjøre det samme mot appen, altså gjøre kall mot next-APIet med access-token, slik at det er den faktiske brukeren som logges?
-
Ja, next-API eksponeres per app, men er del av standard apiene for alle apps med prosessflyt. Når dere kaller apiet med maskinporten-token så er det et eksempel på standardfunksjonaliteten, at token viser hvem som benytter APIet, noe som gjenspeiles i historikken.
Mulig vi kompliserer prosessen noe ved at Altinn 3 Apps krever et token utsted av Authentication i Altinn 3, men jeg er enig med Eirik her. Hvis det er bruker trigget logikk så kan API kallet mot Altinn 3 med fordel være med brukerens token. Det er ikke noe anderledes enn om en bruker sitter på fiken.no eller i en windows applikasjon laget av Visma.
Jeg kan vinkle behovet vårt litt annerledes. Dette vil også gi oss det vi trenger i løsningen: Skatteetaten trenger å kunne lagre data/filer til Altinn3-instansen som kun Skatteetaten har tilgang til å lese ut igjen.
Det å kunne sette autorisjonsregler på et gitt dataelement virker ikke å være en uoverkommelig oppgave. Dog litt usikker hvor mange API som det gjelder. Men dere ønsker altså å laste opp hemmelig.pdf i et steg i prosessen og brukeren skal ikke se hemmelig.pdf i kvitteringen. For regelen skal være slik at den ikke vises for andre enn skd
Havnet nå to helt forskjellige diskusjoner og behov i samme issue ved en feiltagelse?
Vi gjør et forsøk på å lage en løsning med brukerens ID-porten-token, tilsvarende som vi har for Skatt Delegering. Hvis vi får det til så forsvinner behovet, både det som er beskrevet i opprinnelig bestilling og i plan-B-forslaget om "hemmelig" vedlegg.
Jeg oppdaterer med status når jeg vet mer.
@knut-olav-hoven-ske Noen ny status? Har dere fått til å bruke brukerens ID-porten token mot appen?
Vi har enttopp laget og utført en ende-til-ende-test med bruk av ID-porten-OIDC.
Denne saken kan avlyses.
Denne saken kan avlyses.
Veldig bra! 👍 Da lukker jeg denne. cc: @FinnurO