Spørsmål og svar

Hvilke roller i virksomheten kan signere på bruksvilkår for sluttbrukersystemleverandører?
Svar: I punkt 1.1 i våre bruksvilkår fremgår det at vilkårene må signeres av en bemyndiget person. Dette innebærer at det er virksomheten selv som er ansvarlig for å påse at personen som signerer på vegne av virksomheten, har fått nødvendig fullmakt til dette.

Kan vi ha flere kontaktpersoner i registreringsskjemaet?
Svar: Ja, i punkt tre er det mulig å skrive inn flere navn og epostadresser.

Stemmer det at vi ikke lenger må kjøpe Altinn virksomhetssertifikat fra Commfides eller Buypass?
Svar: Innlogging med virksomhetssertifikat er utgående. Ved bruk av Maskinporten (med eller uten systembruker) og ID-porten er det ikke nødvendig med virksomhetssertifikat.

Vi skal bruke et API fra Skatteetaten, og dette API-et er ikke utviklet enda. Hvor langt i integrasjonsprosessen kan vi komme mens vi venter? Kan vi få gjort unna den delen som omhandler Maskinporten, eller kreves det at API-et vi skal bruke finnes under "Apper i produksjon"?
Svar: Det kommer litt an på hvilket API det gjelder, men dersom Maskinporten-scope allerede er opprettet for tjenesten, kan den delen av prosessen startes.

For en leverandør av et lønnssystem som tar i bruk Maskinporten: Er det kostnader for oss som bygger alle tjenestene selv? Eller gjelder kostnaden kun de som benytter Altinn Studio?
Svar: Egenutviklet løsning med direkte integrasjon mot Maskinporten har ingen kostnader. Ved bruk av Altinn Studio er det kostnader knyttet til transaksjoner, infrastruktur og etablering.

Blir kvitteringen tilgjengelig umiddelbart etter at innsendingen er fullført, eller må en forvente noe forsinkelse?
Svar: Kvitteringen blir generert som en del av siste steg, og blir tilgjengelig umiddelbart.

Når blir klientbiblioteker for autorisasjon tilgjengelig?
Svar: Her er vi helt i planleggingsfasen, og har ikke noe konkret å vise til enda.

For innsending av årsregnskap, kan autorisasjon bli gitt både av Maskinporten og ID-porten?
Altinn-apper kan velge å støtte autentisering med både Maskinporten og ID-porten. Tjenesteeier må svare på hvilke valg de har tatt i den konkrete appen for årsregnskap.

• 1) I dokumentasjonen står det at man må bruke systembruker for å opprette agentsystembruker. Er dette riktig, og hvordan fungerer den prosessen?

Her er det en feil i dokumentasjonen, som vil rettes innen kort tid.

Riktig prosess:
- Ha et registrert system hos Altinn.
- Systemleverandøren sender forespørsel om Systembruker for klientforhold.
- Altinn gir en lenke som leverandøren deler sikkert med sluttbrukeren.
- Sluttbrukeren godkjenner i Altinn.
- Systembruker for klientforhold kan deretter brukes til å representere flere klienter.

• Hva er forskjellen på en systembruker og en agentsystembruker?

Systembruker for eget system:
Brukes når en virksomhet eller person leverer tjenester for seg selv. Den representerer kun én juridisk enhet og kan ikke ha klienter tilknyttet.

Systembruker for klientforhold:
Brukes når en tjenesteleverandør (f.eks. et regnskapsbyrå) leverer på vegne av flere klienter. Denne typen kan ha flere klienter knyttet til seg og krever en godkjenningsprosess via Altinn

• 2) Kan en systembruker være tilknyttet flere systembrukeragenter? Med andre ord – kan ett selskap være knyttet til flere agenter?

Ja, ett selskap være knyttet til flere klienter:

Et selskap kan være kunde hos flere systemleverandører, og hver leverandør kan opprette sin egen Systembruker for klientforhold.

Knytningen skjer mellom det registrerte systemet (hos leverandøren) og organisasjonsnummeret til kunden.

Dermed kan samme selskap være tilknyttet flere agent‑systembrukere, for eksempel én for regnskap og én for HR.

• 3) Hvordan er flyten for at man er identifisert som en systemleverandør for å deretter få denne agentsystembrukeren?

1. Systemleverandør identifiseres ved at de har et registrert system hos Altinn. Nærmere beskrivelse finner du her: https://samarbeid.digdir.no/altinn/kom-i-gang/2868

2. Leverandøren sender en forespørsel om å opprette Systembruker for klientforhold via API eller integrasjon.

3. Altinn returnerer en lenke som leverandøren må dele sikkert med sluttbrukeren.

4. Sluttbrukeren logger inn i Altinn og godkjenner forespørselen.

5. Når godkjenningen er fullført, kan Systembrukeren for klientforhold brukes til å representere flere klienter. (Eksempel: regnskapsbyrå som leverer for mange kunder.)

• 4) I endringsflyt for systembruker som kommer i dag – støtter den også agent?

Endringsflyten for systembruker støtter også Systembruker for klientforholde. Når en endringsforespørsel sendes inn, får man tilbake en respons med en lenke som må deles sikkert med kunden. Hvis flere endringsforespørsler opprettes samtidig, er det den sist aksepterte forespørselen som gjelder. Hver endringsforespørsel må ha en unik korrelasjons-ID. Det er opp til leverandøren hvilken forespørsel som vises til kunden; hvis kunden får flere lenker, mister leverandøren kontroll over hva som godkjennes.

• 5) Hva skjer om man oppretter to aktive endringsforespørsler – er det mulig, og vinner sist aksepterte endringsforespørsel?

Ja, det er mulig, men hver forespørsel må ha en unik korrelasjons-ID. Den sist aksepterte forespørselen vinner, altså den som sluttbrukeren godkjenner sist, blir gjeldende. Det er leverandørens ansvar å styre hvilke forespørsler som vises til kunden. Hvis kunden får flere lenker og godkjenner begge, mister leverandøren kontroll over rekkefølgen.

• 6) Så vidt jeg kan se har vi i dag ikke mulighet til å bruke tilgangspakker med vanlige systembrukere. Stemmer det, og vil det i så fall bli mulig?

Ja, det stemmer at det så langt ikke har vært mulig å bruke tilgangspakker med Systembrukere for eget system, men dette er i ferd med å endres:

Det er allerede en versjon i test som gir støtte for tilgangspakker også for Systembrukere for eget system. Denne er planlagt i produksjon fra 1. desember.

Systembrukere for klientforhold har hatt støtte for tilgangspakker hele tiden.

• 7) Hvordan ser det ut i sluttbrukers Altinn-oversikt når man har lagt til en eller flere systembrukere? Jeg har testet med en systembruker i dag jeg ikke ser i Altinn.

Per dags dato er det ikke synlig i Altinns vanlige oversikt når du har lagt til en eller flere Systembrukere for eget system.

Det finnes ingen innboks eller GUI som viser ventende eller eksisterende systembrukerforespørsler.

Den eneste inngangen er den dype lenken som returneres i responsen når forespørselen opprettes. Denne må systemet ta vare på og gi til brukeren på en trygg måte.

Dette kan bli bedre senere, men per nå er det ikke implementert i Altinn-portalen.

• 8) Jeg trodde systembrukere bare hadde tilgangspakker, og ikke roller – og personbrukere skulle få tilgangspakker etter hvert. Er det forskjell på systembruker og agentsystembruker når det gjelder dette?

Systembrukere har ingen knytning til Altinn-rollene som nå fases ut. Tilgangsstyring her skjer på ressurser (Systembrukere for eget system) eller tilgangspakker (Systembrukere for klientforhold og Systembrukere for eget system). Personbrukere kan fortsatt få tilgang via Altinn-rollene, men også snart via tilgangspakker.

Forskjellen mellom systembruker for eget system og Systembruker for klientforhold er ikke i hvordan tilgang gis, men i bruksområdet:

- Systembruker for eget system: Jobber på vegne av egen virksomhet.
- Systembruker for klientforhold: Brukes av en tredjepart (f.eks. regnskapsfører) for å representere flere klienter.

• 9) Har dere anbefalinger ift. hvordan fordele rettighetene på flere systembrukere?

Ha så få tilganger som mulig per systembruker – dette er den sikreste tilnærmingen.

Samtidig må det tilpasses arbeidsprosessen. Hvis ett system jobber mot flere tjenester (f.eks. NAV og Skatteetaten), kan det være fornuftig å samle disse i én systembruker for det caset.

Unngå å lage én systembruker med «alle rettigheter» hvis det ikke er nødvendig, da dette øker risikoen ved misbruk.

• 10) Dersom man legger til flere rettigheter på en systembruker, og klienter allerede har godkjent med de gamle rettighetene, hvordan håndteres dette?

Når du legger til flere rettigheter (tilgangspakker) på en eksisterende systembruker, og klientene allerede har godkjent tidligere rettigheter, så brukes endringsforespørsel-mekanismen:

Du sender inn en endringsforespørsel for den aktuelle systembrukeren.

Endringsforespørselen kan inneholde én eller flere nye tilgangspakker.

Viktig: Operasjonen er idempotent add – det betyr at nye pakker legges til uten å fjerne de gamle.

Klienten må godkjenne endringen via en ny lenke (samme prosess som ved opprettelse).

Eksisterende rettigheter forblir aktive til endringen er godkjent.

• 11) Forstod jeg det riktig at på en agentbruker som er knyttet til 1000 klienter, må man inn og endre for én og én?

Ja, i dagens løsning må endringer gjøres per klient i brukergrensesnittet. For å håndtere store volumer mer effektivt anbefales det å bruke API-et, som gjør det mulig å automatisere prosessen (for eksempel med en løkke som legger til alle klientene programmatisk).

• 12) Hvis et selskap mottar en systembrukerforespørsel med flere scopes eller access packages, men bare ønsker å autorisere én av dem – hvordan kan dette gjøres?

Det er ikke mulig å godkjenne bare deler av en forespørsel. Når en systembrukerforespørsel er opprettet, gjelder prinsippet «alt eller ingenting». Hvis kunden kun skal gi tilgang til et utvalg av rettighetene, må systemleverandøren opprette en ny forespørsel som kun inneholder de ønskede tilgangene.

• 13) Jeg har tidligere etterlyst et API for å sjekke om en agentbruker har rettigheter for et gitt organisasjonsnummer. Er dette noe dere ser på?

Per i dag finnes det ikke et eget API for dette. Den eneste kontrollen skjer gjennom Maskinporten, som spør Altinn om rettigheter når et token brukes. Det er foreløpig ikke planlagt å eksponere dette endepunktet for systemleverandører, fordi det mangler underliggende data for å løse det på en god måte. Teamet har ikke landet en løsning ennå.

• 14) Kan dere gå igjennom hvordan en systembruker opprettes?

Følg dokumentasjon for opprettelse av systembruker: https://docs.altinn.studio/nb/authorization/guides/system-vendor/system-user/systemuserrequest/

• 15) Finnes det en oversikt i Altinn Access Management for ventende systembrukerforespørsler, og er det planlagt en GUI-løsning for godkjenning?

Nei, det finnes per i dag ingen innboks eller oversikt i Altinn-portalen for ventende forespørsler. Den eneste inngangen er den dype lenken som returneres i API-responsen ved opprettelse. Det er heller ikke planlagt en GUI-løsning for dette, men status på forespørsler kan hentes via API.

• 16) Typisk case: Bruker av sluttbrukersystem har ikke tilgang til å godkjenne, men må få en annen til å logge inn i Altinn og godkjenne – hvordan håndteres dette?

Det finnes ikke en innboks eller oversikt i Altinn-portalen der slike forespørsler automatisk vises. Den eneste måten å godkjenne forespørselen på er via den dype lenken som systemleverandøren mottar i responsen ved opprettelse. Denne lenken må systemet selv ta vare på og distribuere til riktig person (f.eks. daglig leder) på en trygg måte.

• 17) I tilfeller der man skal signere en innsendelse og bruker Maskinporten-token (f.eks. innsendelse av signert årsregnskap): Sender man da inn med Maskinporten-token og signerer med ID-porten-token? Finnes det scenarier der man benytter både Maskinporten og ID-porten?

Ja, det finnes scenarioer der man benytter både Maskinporten og ID-porten. Man kan sende inn data med Maskinporten-token og deretter signere med ID-porten-token. Dette er spesielt aktuelt ved innsendelse av signert årsregnskap, hvor selve innsendingen skjer via Maskinporten, mens signeringen gjøres med ID-porten for å sikre sporbarhet. Brønnøysundregistrene har åpnet for begge metoder, og det er mulig å bruke samme API med enten Maskinporten-token eller ID-porten-token, avhengig av behov og rollefordeling.

• 18) Det er også mulig å gjøre alt med ID-porten-bruker, både i portal og via API, og aldri bruke systembruker – stemmer det?

Ja, det er mulig. Man kan bruke ID-porten-bruker til å utføre hele prosessen – både innsending og signering – uten å benytte systembruker. Dette gjelder både via Altinn-portalen og via API. Det ble nevnt at Brønnøysundregistrene har åpnet for begge metoder, og at samme API kan benyttes med ID-porten-token for å sikre sporbarhet, som systembruker ikke tilbyr.

• 19) I TT02 får vi feilmeldingen 401 Unauthorized for party (agent-systembruker, tilgangspakke regnskapsfører med full signeringsrettighet, sender inn på vegne av systembrukerens kunder). Vet dere hva som typisk mangler i oppsettet for denne feilen?

For konkret feilsøking trenger vi at dere sender så mye info dere har til servicedesk@altinn.no. Nøyaktig klokkeslett og evt traceid er spesielt nyttig.

• 20) Hvordan kan systemleverandører som ikke har norsk organisasjonsnummer eller norsk ID-/D-nummer registrere sitt system?

Det er ikke mulig å registrere et system uten norsk organisasjonsnummer. Systemet må være registrert i Enhetsregisteret, og det valideres mot dette ved opprettelse. Det holder ikke å ha et personnummer – det må være et organisasjonsnummer. Dersom utviklerne eller eierne av systemet sitter i utlandet, må de ha et norsk søsterselskap med organisasjonsnummer som kan stå som systemeier.

• 21) API-et for «klientdelegering» som kommer – krever det at kunden delegerer full klientadministrator-rettighet til systemet/systemleverandøren?

Ja, API-et for klientdelegering krever at kunden gir klientadministrator-rettighet til systemleverandøren. Dette skjer via ID-porten med riktig scope, og det er en forutsetning for at systemleverandøren skal kunne administrere klienter på vegne av kunden.

• 22) Det blir vanskelig med to systembrukere, der de enten er for seg selv med Ordinær eller om de er for andre med Agent

Å bruke samme systembruker både for eget system og klientforhold vil kreve nyutvikling hos Altinn, og vi har ikke noe tidshorisont som vi kan kommunisere ut for det nå.

• 23) Bruke EIDAS for å logge inn i Maskinporten, for å kunne opprette et system

Det vil i så fall kreve ny utvikling hos Altinn, og vi har ikke noe tidshorisont som vi kan kommunisere ut for det nå.

• 1) Vi skal integrere mot Miljødirektoratets "avfallsdeklarering.no" via en integrasjonsplattform. Hvordan fungerer pålogging med en Altinn systembruker i praksis for en slik maskin-til-maskin-løsning? Vi ønsker en upersonlig pålogging uten brukerinteraksjon (som pop-ups for BankID), gjerne via et token.

Systembruker er designet for akkurat dette. Det gir en upersonlig, langtlevende pålogging på vegne av virksomheten (i dette tilfellet Norsk Gjenvinning).

- Løsningen bruker et langtlevende token som dere benytter mot etatens API. Levetiden på dette tokenet styrer dere selv.

- I motsetning til personlig pålogging via ID-porten, hvor handlinger spores til en enkeltperson, spores handlinger med systembruker tilbake til virksomheten.

- For å sette dette opp, må dere opprette en systembruker. Prosessen for dette er beskrevet på dokumentasjonssidene.

• 2) Er "klientdelegerings-API-et" nå tilgjengelig i produksjon?

Ja, klientdelegerings-API-et ble produksjonssatt i går ettermiddag (14. oktober). Se dokumentasjon av API-et.

• 3) Hvor finner jeg produksjons-URL-er for dette? Dokumentasjonen ser ut til å kun inneholde test-URL-er.

Produksjons-URL-en er den samme som test-URL-en, men uten test-identifikatorer (f.eks. fjern "tt02").

Den generelle adressen er plattform.altinn.no. Vi skal sørge for å tydeliggjøre dette i de delene av dokumentasjonen der det i dag kan være uklart.

• 4) Hvilke roller kreves for å godkjenne opprettelse av en systembruker, og kan denne retten delegeres?

Godkjenning krever Altinn-rollen "Tilgangsstyring". Daglig leder og styreleder har denne rollen implisitt, men den kan delegeres til andre personer i virksomheten som da også kan godkjenne opprettelse av systembrukere.

• 5) Når vi oppretter en systembruker via API-et, får vi tilbake en URL som kunden må bruke for å godkjenne. Er dette den eneste måten å godkjenne på per i dag? Vil det komme en funksjon i Altinn-portalen der kunden kan se og behandle forespørsler som venter på godkjenning?

Per nå er lenken den eneste måten å godkjenne på. Vi har imidlertid identifisert behovet for å kunne se og behandle ventende forespørsler direkte i Altinn-portalen, siden den som oppretter forespørselen ikke alltid er den som skal godkjenne. Dette ligger i vår backlog for å bli implementert.

• 6) Hvordan skal vi som systemleverandør håndtere rettigheter for en systembruker over tid? En kunde kan for eksempel kjøpe en ny modul som krever utvidede rettigheter. Vi har ingen måte å se hvilke rettigheter en systembruker har, spesielt siden kunden selv kan endre disse i Altinn.

Dette er en kjent svakhet per i dag. Dere må foreløpig selv holde kontroll på hvilke rettigheter som er tildelt. Vi venter på underliggende funksjonalitet før vi kan tilby et API for å slå opp hvilke rettigheter en systembruker har. Dette ligger i vår backlog.

• 7) Det nye API-et for å slå opp systembrukere per organisasjonsnummer er veldig bra. Vi ser at man får tilbake informasjon om "tilgangspakker", men ikke om enkelttjenester. Når kan vi forvente å kunne se enkelttjenester?

Det stemmer. Muligheten til å se enkelttjenester avhenger av annen funksjonalitet vi venter på. Dette ligger i vår backlog, og vi håper å ha dette på plass innen utgangen av året.

• 8) Flere av de tematiske tilgangspakkene (f.eks. "Lønn" og "Merverdiavgift") virker å være tomme. Hva er status på disse, og kan vi som systemleverandører gi tilbakemeldinger på innholdet?

Vi har i utgangspunktet ikke invitert SBSL til å komme med innspill på tilgangspakker. Fristen som er gitt nå handler om hvilke tilgangspakker som er nødvendig. Det er tjenesteeier (TE) som velger hvilke(n) tilgangspakke(r) som er relevant for deres tjenester, og SBSL må melde inn evt ønsker til aktuell(e) TE.

• 9) Vi er et regnskapskontor som får tilgang til klienter via rollen "Regnskapsfører" i Enhetsregisteret. Hvordan kan vi få systembrukertilgang for en klient som ikke er en del av denne ordningen? Vi har prøvd å delegere tilgang, men får det ikke til.

For å få tilgang til klienter der det ikke finnes knytning mellom regnskapsfører- eller revisorfirmaet og kunden i Enhetsregisteret kan kunden delegere den tilgangspakken som tjenesten krever (f.eks skattegrunnlag) til regnskapsfører- eller revisorfirmaet (på organisasjonsnummeret). Deretter kan leverandør av sluttbrukersystem sende en forespørsel om å opprette systembruker for klientforhold med den aktuelle tilgangspakken, som klientadministrator på regnskapsfører- eller revisorfirmaet kan godkjenne og knytte til aktuell kunde. Merk at en systembruker som har både tilgangspakke som følge av Enhetsregisterkobling og tilgangspakke delegert fra kunde i de fleste tilfeller ikke vil fungere. Det bør derfor opprettes separate systembrukere. Denne problemstillingen er beskrevet som et av brukerscenariene for systembruker.

• 10) Hva er forskjellen på en vanlig systembruker og en "agent systembruker"? Vi skal hente data (f.eks. påleggstrekk) på vegne av våre kunder, som er kommuner. Hvilken type skal vi bruke?

Systembruker for eget system:
Brukes når en virksomhet eller person leverer tjenester for seg selv. Den representerer kun én juridisk enhet og kan ikke ha klienter tilknyttet.

Systembruker for klientforhold:
Brukes når en tjenesteleverandør (f.eks. et regnskapsbyrå) leverer på vegne av flere klienter. Denne typen kan ha flere klienter knyttet til seg og krever en godkjenningsprosess via Altinn.

I deres tilfelle, der kunden bruker en instans av deres system for å hente egne data, høres det ut som at hver kunde skal ha en systembruker for eget system. De ulike typene systembruker er grundigere beskrevet i dokumentasjonen.

• 11) En bruker med rollen "daglig leder" godkjente en systembruker-forespørsel for en enkelttjeneste uten feilmelding. Da vi kalte API-et, fikk vi "403 Forbidden". Det viste seg at den daglige lederen som godkjente, ikke selv hadde tilgang til enkelttjenesten. Skal ikke systemet validere dette ved godkjenning?

Jo, den som godkjenner må ha tilgang til den aktuelle tjenesten. At forespørselen ble godkjent uten feilmelding høres ut som en feil. Vi ser nærmere på GitHub-isssue som ble delt av spørsmålsstiller.

• 12) Er Altinns support (første-, andre- og tredjelinje) opplært i de nye systembruker-konseptene? Kan vi begynne å sende sluttbrukerne våre dit?

Vi jobber med opplæring av support-apparatet. De bygger kompetanse og eskalerer saker de ikke kan løse. Send oss gjerne typiske spørsmål dere får fra kunder, så kan vi bruke det i opplæringen.

• 13) Finnes det dokumentasjon rettet mot sluttbrukere som vi kan peke dem til?

Ja, det finnes en egen seksjon for sluttbrukere i dokumentasjonen. Denne vil på sikt bli flyttet til altinn.no, slik at det vil være lett å vise til den mot deres brukere. Gi oss gjerne beskjed om det er mangler der. Den midlertidige dokumentasjonen finner dere her: https://docs.altinn.studio/nb/authorization/guides/end-user/system-user/

• 14) Kan det etableres en mekanisme i Slack, f.eks. en emoji, for å flagge tråder der det avdekkes mangler i dokumentasjonen?

Det er en veldig god idé. Vi ser på en løsning for dette. Målet vårt er å svare på spørsmål ved å peke til dokumentasjonen, og hvis den er mangelfull, oppdaterer vi den først.

• 1) Så langt har dere migrert data tilbake til mai. Når ser dere for dere å ha migrert data fra desember (2024) og januar (2025)? Vi spør spesifikt på grunn av Aksjonærregisteroppgaven, som leveres i den perioden. Våre kunder (ofte små bedrifter) leverer gjerne samme oppgave som i fjor, så det er en stor forenkling om vi kan hente fjorårets oppgave direkte via Dialogporten, istedenfor å måtte bruke de gamle Altinn 2-API-ene.

I utgangspunktet har vi konsentrert oss om inneværende år (2025). Målet er å nå 1. januar 2025 i løpet av de neste par ukene, for både arkiverte skjema og meldinger. Vi tar migreringen i biter for å ha kontroll på datamengdene og for å håndtere feil og særegenheter i gamle data underveis. Derfor kan vi ikke love en eksakt dato for når vi når desember/januar. Vi har imidlertid en statusside som er i støpeskjeen og snart publiseres på Docs. Der vil dere fortløpende kunne se hvor langt tilbake i tid migreringen har kommet. Oversikten blir tilgjengelig fra https://docs.altinn.studio/nb/dialogporten/

• 2) I Altinn 2 brukte vi 90-dagers samtykke via ID-porten for å hente meldinger. Finnes det en tilsvarende mekanisme i Altinn 3 / Dialogporten, eller er det kun Maskinporten med virksomhetssertifikat som gjelder nå?

Dialogporten støtter begge deler. Du kan autentisere: 1. En systembruker (via Maskinporten) 2. En person (via ID-porten) på samme måte som i Altinn 2 (90 dagers samtykke). Se mer informasjon på https://docs.altinn.studio/nb/dialogporten/user-guides/authenticating/

• 3) Vil det si at for tjenester som krever Nivå 4, må vi fortsatt bruke ID-porten og hente samtykke fra f.eks. daglig leder?

Det er korrekt. For å oppnå Nivå 4 (som i eIDAS kalles "Høy") kreves det 2-faktor-autentisering. Det får man ikke gjennom Maskinporten. Maskinporten gir tilgang opp til Nivå 3. Se mer informasjon på https://docs.altinn.studio/nb/dialogporten/getting-started/authorization/

• 4) Hva er grunnen til at det kreves systembruker for oppkobling til Dialogporten via Maskinporten? Det fungerer, men det er mer komplekst enn å bare bruke et vanlig access token.

Det er mer komplekst, men det er nødvendig for å fange opp fleksibiliteten i Altinns autorisasjonsmodell, noe et enkelt "scope" i et OAuth2-token ikke kan. Altinn-autorisasjon er veldig finkornet; du kan f.eks. ha tilgang til tre tjenester, men ikke den fjerde, eller signere én, men ikke en annen. Denne kompleksiteten er vanskelig å uttrykke i et standard token. I tillegg må mekanismen håndtere representasjonsforhold (f.eks. en kunde, et regnskapsbyrå og en systemleverandør). Se mer info på https://docs.altinn.studio/nb/authorization/what-do-you-get/systemuser/

• 5) Brukes "on behalf of"-mekanismen (OBO) i Maskinporten i denne sammenhengen?

Den gamle OBO-mekanismen i Maskinporten har ingenting med Altinn-autorisasjon å gjøre, og vi anbefaler generelt at en benytter den nye delegeringsmekanismen i Maskinporten som er basert på Altinn-autorisasjon. Denne brukes f.eks. hvis en kommune (som har API-tilgang) lar en leverandør kalle API-et på sine vegne. Det er viktig å merke seg at dette kun gjelder den grovkornede API-tilgangen (scope). Se info på https://docs.digdir.no/docs/Maskinporten/maskinporten_func_delegering.html

• 6) Vi har en systembruker (via Maskinporten) som vi har gitt tilgang til å hente skattekort. Da vi gjenbrukte denne systembrukeren mot Dialogporten, fikk vi også tilgang der. Må man be om en spesiell tilgang for Dialogporten?

Nei, det er den samme autorisasjonsmodellen som ligger til grunn. Policyen (rettigheten) som regulerer tilgangen til et skjema eller en melding, regulerer også tilgangen til dialogen som representerer den. Se mer informasjon på https://docs.altinn.studio/nb/dialogporten/getting-started/authorization/

• 7) Så hvis en systembruker har fått rettighet til å rapportere Aksjonærregisteroppgaven, får den automatisk tilgang til dialogene som omhandler den oppgaven?

Ja, det er korrekt. Hvis kunden delegerer en tilgangspakke (f.eks. "Revisormedarbeider") til deres systembruker, vil alle tjenester knyttet til den pakken bli tilgjengelige når systembrukeren henter data for den kunden. Dette fungerer likt enten det er en hel tilgangspakke eller enkelttilganger.

• 8) Vi bruker en "agent systembruker" med rettighetspakken "Revisormedarbeider" for våre klienter. Jeg opplever at jeg ikke får opp alle meldinger, spesifikt meldinger knyttet til MVA-innsending i Altinn 3. Jeg ser disse meldingene hvis jeg logger inn manuelt i arbeidsflaten med samme rolle. Skyldes dette "lag" eller er det noe jeg gjør feil?

Det er vanskelig å si uten flere detaljer, men en vanlig feil er at man spør på feil part (f.eks. at man spør på egne vegne og ikke på vegne av kunden). Hvis dere har kjørt dere fast, ber vi om at dere sender inn en supportsak (se spm. 17), så kan vi se nærmere på det. Merk: Agent systembruker omtales i dokumentasjon og løsning som: Systembruker for klientforhold.

• 9) Hva er prosessen for nye data som oppstår i dag (ikke de historiske dere migrerer)?

Det er ulikt for Altinn 2 og Altinn 3:
Altinn 3 Apper: Synkroniseres fortløpende. I løpet av sekunder etter at en instans opprettes i "App", vil den dukke opp som en dialog i Dialogporten.
Altinn 2 Skjema: Vises kun i Altinn 2-innboksen mens de er under utfylling eller signering. Først når skjemaet arkiveres i Altinn 2 (dvs. etter innsending), blir det fanget opp for overføring til Dialogporten. Denne synkroniseringen skjer ca. hvert femte minutt.
Meldinger (Correspondence): Altinn 3-meldinger dukker opp umiddelbart. Altinn 2-meldinger vil dukke opp begge steder, men med en liten forsinkelse i Dialogporten (siden de må synkroniseres over).

• 10) Vi har erfart at brukere ikke finner igjen elementer i arbeidsflaten for vår første Altinn 3-app. Hva skyldes dette?

Dette kan skyldes at bruksmønsteret er litt annerledes enn i Altinn. I Altinn 3-arbeidsflaten vil skjema som brukeren selv har startet og som er under utfylling, legge seg under visningen "Utkast". Det er mulig brukerne ikke ser etter dem der.

• 11) Vi har to problemer med hvordan historiske data håndteres: 1. Historiske skjema og meldinger ser ut til å bli egne ressurser i vårt ressursregister (ISKD). Dette gjør registeret rotete, stort og tregt. 2. Titlene som vises til brukerne er uheldige. For eksempel "Brev fra Skatteetaten (migrert fra Altinn 2)", eller kryptiske skjemanavn. Brukerne forstår ikke dette, og tror kanskje de har tilgang til alle brev, ikke bare de historiske. Har det blitt gjort noen tanker om dette?

Om rot i ressursregisteret: Dette er en kjent utfordring. Siden tjenestene og delegeringene i Altinn 2 ikke er de samme som i Altinn 3, ble det besluttet å ikke migrere/synke delegeringer. Derfor må man ha doble ressurser (én for A2, én for A3). Dette er en kostnad vi må ta i overgangsfasen, og problemet vil forsvinne når Altinn 2 skrus av.
Om treghet i ressursregister-API: Det skal finnes filtreringsmuligheter i API-et for ressursregisteret, slik at man kan velge å inkludere eller ekskludere ressurser basert på Altinn-versjon (A2/A3).
Om titler: Vi kan ikke svare konkret på dette her nå, på hvilke vurderinger som er gjort rundt navngivingen; det ligger hos autorisasjons-teamet. Men vi tar med oss innspillet om at dette er en pedagogisk utfordring for brukerne.

• 12) I arbeidsflaten i Altinn 3 ser jeg mappen "Utkast", men jeg finner ingen knapp eller lenke for å starte et nytt skjema, slik man kunne i Altinn.

Det stemmer, det mangler en lenke til "skjemakatalogen" (som i Altinn 2 tilsvarte "infoportalen"). Vi er enig i at den burde vært der, slik at brukere enkelt kan finne og starte utfylling av skjema. Dette kommer i produksjon 1. desember, og er allerede på plass i testmiljøet TT02.

• 13) Forsendelser (Transmissions) i Dialogporten har en "type" (f.eks. "alert"). Er det en standard for hvordan tjenesteleverandører bruker disse? Jeg ser Skatteetaten bruker "alert" for en innsending som var godkjent, men hvor de bare ville påpeke noe.

Det finnes retningslinjer for hvordan typene skal benyttes , men vi har ingen mulighet til å håndheve at en gitt meldingstype brukes på en spesifikk måte. Det er til syvende og sist opp til tjenesteeieren (som Skatteetaten) å beslutte dette for sin tjeneste. Tjenesteeiere som NAV og Skatt har en direkte integrasjon og definerer dette selv. De fleste andre tjenesteeiere bruker Altinn 3 Apps, som gir en mer standardisert implementasjon. Se også https://docs.altinn.studio/nb/dialogporten/user-guides/service-owners/creating-dialogs/

• 14) Dette er i ferd med å skape et kaos for oss som konsumenter. Det er ikke mulig i dag å se intensjonen med en dialog, eller hva systemet (API-et) forventes å gjøre. Dialogene virker laget for et GUI, men vi skal handle på dem. Spesielt de store aktørene (NAV og Skatt) som integrerer direkte, fomler. Dere bør komme på banen med tydeligere retningslinjer for å gjøre det enklere for oss.

Vi har mekanismer i dialogmodellen, som API actions, som er tiltenkt å guide API-konsumenter om hva de kan foreta seg gitt en tilstand. Vi har nok litt å gå på for å få utnyttet det bedre. Vi antar at de fleste tjenesteeiere vil benytte Altinn 3 Apps, som gir en standardisert integrasjon. Altinn 3 tilbyr mye mer fleksbilitet enn Altinn 2, og det er nok vanskelig å lage én generisk integrasjon som håndterer alle tenkelige forretningsbehov - protokollen som må brukes vil kunne være ulik fra tjeneste til tjeneste. Dette er imidlertid en viktig tilbakemelding til de som integrerer direkte (NAV/Skatt): at de må utnytte mekanismene i datamodellen for å tydeliggjøre intensjonen og tilstanden, samt dokumentere dette grundig. Digdir som plattformleverandør har en veiledningsplikt og jobber med å etablere arenaer for å dele "beste praksis" mellom tjenesteeierne.

• 15) Når dere migrerer data, blir de gamle (migrerte) ressursene inkludert i de eksisterende tilgangspakkene? Eller må vi som systemleverandører legge til masse enkeltressurser på systembrukerne våre for å få en total oversikt i overgangsfasen?

Tilgangspakkene blir ikke satt på de migrerte ressursene, det er kun policy fra A2 som migreres sammen med instansene. Vi har ikke landet helt hvordan tilgang til historiske meldinger skal ivaretas når A2-rollene fjernes, men sannsynligvis vil nøkkelroller i virksomhetene få tilgang, og kan delegere enkelttjenester ved behov. ALternativet er at tjenesteeierne må finne tilgangspakker som gir tilgang til gamle/historiske tjenester. [Spørsmålet ble ikke besvart i møtet, svar er avklart i bakkant]

• 16) Mye av dokumentasjonen er kun på norsk. Vi har mange utenlandske utviklere og må oversette mye selv. Kan dere sørge for at dokumentasjon er tilgjengelig på engelsk?

På Docs og for Dialogporten spesifikt, skal alt være på både norsk og engelsk. Dette oppdateres fortløpende. Hvis dere finner feil eller har innspill på innhold i "Docs"-sidene er det en lenke til GitHub nederst på siden hvor en kan legge inn både issues og pull requests.

• 17) Er det en fast struktur for disse drop-in-møtene? Og er Slack den eneste kanalen for support?

Møter: Dette er første sesjon for Dialogporten. Det er ikke satt opp faste datoer, men vi vil følge opp med flere sesjoner ved behov. Invitasjoner kommer på e-post og publiseres på Samarbeidsportalen her: https://www.digdir.no/digdir/arrangementsoversikt/692.
Support: Slack er en "community"-kanal. Primærkanalen for support er e-post til vår servicedesk (servicedesk@altinn.no) eller skjema som ligger etter innlogging i Samarbeidsportalen. Da sikrer vi at saken logges i mottakssystemet vårt.

• 1) Problemer med oppsett av systembruker: En gjest opplever å få feilmelding om at de ikke er "systembruker" ved kall mot Dialogporten, til tross for forsøk på korrekt oppsett.

Det er komplekst å få alle trinnene i opprettelse og tilgangsstyring for systembrukere riktig. For å feilsøke spesifikke request/response-meldinger, anbefales det å sende e-post til servicedesk@altinn.no. Dette sikrer at saken rutes til riktig team, for eksempel autorisasjonsteamet først, og deretter Dialogporten ved behov. Man kan også stille spørsmål på Slack-kanalen for produktet.

• 2) Bruk av samme systembruker for både egen virksomhet og klienter: Når vil det være mulig å benytte samme systembruker til begge formål?

Dette ligger under produktområdet for autorisasjon, og Dialogporten-teamet har per nå ikke detaljert informasjon om status for denne funksjonaliteten. Merk at det arrangeres et eget drop-in-møte om tilgangsstyring og autorisasjon onsdag 21. januar. [Red.anm. Dette ligger for tiden ikke inne i planene på denne siden av sommeren]

• 3) Problemer med registrering av e-postdomene for systembruker: En leverandør som leverer data for mange banker opplever at maildomenet allerede er opptatt ved registrering av systembruker på et spesifikt organisasjonsnummer.

Utfordringen er ikke egnet å besvare i møtet. Det anbefales å sende en detaljert henvendelse til servicedesk@altinn.no slik at saken kan undersøkes av rette vedkommende.

• 4) Hvordan feilsøke manglende tilgang til en dialog: Hvordan kan man som systemleverandør selv nøste i hvorfor man ikke får opp en dialog via API-et, selv om man tror man har riktig rolle eller tilgangspakke?

All informasjon om krav og "policy" for en tjeneste ligger i ressursregisteret, som har et åpent API. Her kan man se hvilke roller eller tilgangspakker som kreves. I tillegg finnes API-er for tilgangsstyring som viser hvilke delegeringer som faktisk er gjort for en gitt bruker. Tips: Enhver tilgang til en ressurs (uavhengig av om det er lese- eller skriverettighet) skal være tilstrekkelig for å få opp selve dialogen i søk. Teamet erkjenner at dokumentasjonen på hvordan man feilsøker dette kan forbedres. Vi skal vurdere å gjøre det mulig å se detaljer om en dialog i Arbeidsflate som i dag ikke er synlig i grensesnittet, i stedet for å måtte bruke nettleserens utviklerverktøy.

• 5) Tilgang via tilgangspakker: En gjest erfarte at dialoger ikke ble synlige selv om tilgang var gitt via en tilgangspakke.

Tilgangspakker skal fungere i Dialogporten. Den eneste mekanismen som per i dag ikke støttes fullt ut, er instansdelegering (tilgang til én spesifikk forekomst av et skjema). Hvis vanlige tilgangspakker ikke fungerer, er det trolig noe som er satt opp feil - ta kontakt med servicedesk for bistand.

• 6) Ønske om changelog og varsling ved feilretting: Det etterspørres en bedre måte å følge med på når feil er rettet, slik at man slipper å sjekke manuelt.

For Dialogporten spesifikt finnes det en fil som heter CHANGELOG.md i rotmappen på GitHub-repositoryet som oppdateres fortløpende. Digdir jobber også med å få på plass en felles, aggregert release-logg for alle produkter på tvers.

• 7) Skal Dialogporten være eneste kanal for elektronisk kommunikasjon? Noen tjenesteeiere planlegger å bruke Dialogporten som eneste kanal, mens andre bruker egne API-er i kombinasjon med Dialogporten. Finnes det retningslinjer for dette?

Dialogporten er ment å være det samlende punktet hvor man finner henvisninger til innhold i andre systemer. Selve innholdet i en melding eller innsending av skjemadata skjer fremdeles i de underliggende systemene (som Altinn 3-apper eller egne API-er hos NAV/Skatt). Ambisjon: Målet er at Dialogporten skal fungere som et felles "oppdagelsespunkt" for all kommunikasjon med det offentlige, uavhengig av hvilken plattform tjenesten er bygget på. Per nå er modellen fleksibel nok til å dekke de fleste saksganger mellom én offentlig part og én privat part.

• 8) Hva er vanlige feiltrinn hos systemleverandører?

Systembrukere og tilgangsstyring mot Maskinporten er det mest komplekse området hvor mange kjører seg fast. I tillegg er konseptet med at Dialogporten er et "abstrakt samlepunkt" (som peker til data andre steder) noe som krever modning både hos leverandører og tjenesteeiere. Teamet ser behovet for flere referanse-implementasjoner for å vise "god praksis"

• 1) Hvor finner man en oversikt over eksisterende tilgangspakker og hvilke funksjoner de dekker?

Navn og beskrivelse på tilgangspakker ligger på Altinn Docs. For å se hvilke spesifikke tjenester som er inkludert i en pakke, kan man bruke et åpent metadata-API.
Metadata-API (åpent) for alle A3 ressurser og apper: https://platform.altinn.no/resourceregistry/api/v1/resource/search
Metadata-API for å finne tilgangsregler på en gitt ressurs/app: https://platform.tt02.altinn.no/resourceregistry/api/v1/resource/ske-skattekort-til-arbeidsgiver/policy/subjects [bytt ut ske-skattekort.... med den ressursen man vi sjekke]

• 2) Finnes det rettigheter i tilgangspakker som ikke er tilgjengelige som enkeltrettigheter?

Nei, alle ressurser og tjenester er i utgangspunktet enkeltrettigheter. Tilgangspakker er kun samlinger av disse enkeltrettighetene for å gjøre det enklere for brukere. Dersom man bare trenger tilgang til deler av en tjeneste, kan man velge enkeltrettigheter fremfor en hel pakke. Det ble bekreftet at det skal være mulig å få opp alt i Dialogporten ved bruk av kun enkeltrettigheter.

• 3) Hva er forskjellen på en "agent-systembruker" og en vanlig systembruker?

Systembruker for eget system: Brukes når din virksomhet skal utføre oppgaver på vegne av seg selv (f.eks. levere eget regnskap). Denne kan bruke både enkeltrettigheter og tilgangspakker.
Agent-systembruker (nå kalt systembruker for klientsystem): Brukes når et firma (f.eks. et regnskapsbyrå) skal utføre oppgaver på vegne av sine klienter. Denne kan per nå kun bruke tilgangspakker. Se også veiledning til systembruker.

• 4) Oppdateres tilganger automatisk for en systembruker hvis en tilgangspakke endres?

Ja, hvis nye tjenester legges til i en tilgangspakke, vil systembrukeren arve disse automatisk uten at man må gjøre endringer på selve brukeren.
Merk: Dersom man skal legge til en ny pakke eller fjerne rettigheter:
- For eget system kan systemleverandør gjøre endringer via endringsforespørsel (endringen må godkjennes av virksomheten som eier systembrukeren).
- For klientsystem må systemtilgangen slettes og opprettes på nytt for kunden.

• 5) Må registrering av system skje via API, eller kommer det et brukergrensesnitt (UI)?

Per nå må registrering gjøres via API. Det er ikke planlagt UI løsning for dette

• 6) Hvordan kan vi hjelpe kunder (regnskapsførere) med å verifisere at delegeringer er korrekt satt opp? Finnes det en liste over delegeringer?

Det finnes per i dag ingen eksterne API-er for å hente ut lister over delegeringer, delvis på grunn av juridiske vurderinger rundt personvern. Systemleverandører styrer oppsettet, men kunden må godkjenne fullmaktene i Altinn.

• 7) For en revisor med tusenvis av kunder, finnes det en mer effektiv måte å delegere på enn manuelt arbeid i portalen?

Ja, det finnes et API for å legge til kunder slik at man kan lage en integrasjon for dette. For Systembruker kommer det en funksjon i portalen (i test nå, så i produksjon) der man kan legge til alle kunder som ikke allerede er lagt til, med ett trykk.

• 8) Hvis en kunde har 300 klienter, må kunden klikke "godkjenn" 300 ganger?

Dersom kundeforholdet (f.eks. regnskapsfører-klient) allerede er opprettet i Altinn, kan systemleverandøren legge til alle disse på systembrukeren samtidig via API uten at kunden må godkjenne hver enkelt på nytt. Kundeforholdet og fullmakten er allerede gitt via Samordnet registermelding og innhentes av Altinn fra Enhetsregisteret.

• 9) Hvorfor får jeg ikke tilgang til migrerte meldinger fra Altinn 2 med en Altinn 3-systembruker?

Dette skyldes sannsynligvis at migrerte ressurser fra Altinn 2 ble tatt over med de originale tilgangsreglene og Altinn 2-rollene. Systembrukere er et Altinn 3-konsept som ikke støtter Altinn 2-roller direkte.Løsning: Man må enten ha enkeltrettigheter til de migrerte ressursene, eller så må tjenesteeier oppdatere ressursen med en tilgangspakke. Teamet erkjenner at dokumentasjonen på hvordan man finner rett ressurs-ID for feilsøking bør forbedres.

• 10) Hvor finner man full API-dokumentasjon (Swagger)?

En Swagger-oversikt finnes, men den er under kontinuerlig arbeid ettersom nye API-er utvikles. Den er tilgjengelig via Altinn Docs. API-spesifikasjon for autorisasjon

En merknad om support

For spesifikke tekniske feil eller saksnummer som har ligget lenge, oppfordres det til å sende e-post til servicedesk@altinn.no

• 1) Som systemleverandør, er det mulig å slette systembrukeren som en kunde har tildelt oss, eller må det gjøres av kunden?

Systembrukeren eies av virksomheten som oppretter den. Derfor må sletting gjøres av kunden selv. Det planlegges et API hvor systemleverandører kan sende en forespørsel om sletting, tilsvarende som ved endring av rettigheter. Dette forventes først rundt sommer eller høst.

• 2) Jeg har hatt litt utfordringer og mistenker at system- eller tjenesteleverandøren vi leverer til ikke har satt opp systembruker riktig. Er systembruker noe alle må bruke fremover, eller er det fortsatt mulig å bruke andre mekanismer?

  Finnes det en policy om at alle tjenester skal støtte systembruker?

Systembruker er den nye mekanismen som skal brukes fremover.

Det er imidlertid viktig å være klar over at systembruker ikke erstatter Maskinporten. Maskinporten vil fortsatt eksistere og brukes i scenarier hvor man bare trenger tilgang på virksomhetsnivå.

For eksempel finnes det API-er hvor man kun trenger organisasjonsnummeret til virksomheten. Da trenger man ikke å vite hvilket system som gjør kallet, og man trenger heller ikke tilgangsstyring på systemnivå. I slike tilfeller brukes Maskinporten.

I andre scenarier trenger man derimot å vite hvilket system som utfører handlingen, og at dette systemet har riktige rettigheter. I slike tilfeller brukes systembruker.

Se også veiledning til systembruker.

• 3) Når jeg prøver å opprette en instans får jeg en 403-feil, uten detaljer. Servicedesk eller tjenesteeier har ikke klart å forklare hva det skyldes, selv om jeg har dobbeltsjekket scopes. Jeg fant også i ressursregisteret at enterpriseUserEnabled var satt til false. Jeg trodde først dette var årsaken, men det ser ikke ut til å stemme. (Oppfølging til spm 2)

Flagget enterpriseUserEnabled betyr egentlig ikke noe i denne sammenhengen. Det brukes bare som metadata og påvirker ikke autorisasjonen direkte.

En mulig årsak kan være at tjenesten ikke er utviklet med støtte for systembruker. Hvis det er en eldre applikasjon, kan det hende utviklerne ikke har tatt høyde for systembruker da den ble laget.

For eksempel kan det være at applikasjonen forventer informasjon om avsenderen i selve skjemadataene. I slike tilfeller kan instansiering feile når man bruker systembruker. Det er derfor i stor grad opp til tjenesteeieren om systembruker er støttet eller ikke. Jeg vil anbefale å kontakte Luftfartstilsynet direkte gjennom servicedesk eller tjenesteeier. Servicedesk hos oss har ikke nødvendigvis innsikt i hvordan deres applikasjon er implementert. Det er tjenesteeieren selv som vet hvordan løsningen deres er satt opp.

Det kan også være at tjenesten krever en bestemt tilgangspakke eller delegert rettighet. Hvis det er en eldre tjeneste, kan den i stedet være basert på roller.

• 4) Planlegger dere et API for å finne hvilken agent-bruker en klient tilhører?

Ja, dette er ønsket funksjonalitet, men det er ikke planlagt på kort sikt. Arbeidet vil vurderes etter sommeren når roadmap for høsten planlegges.

• 5) Finnes det planer om et API-endepunkt for å slå opp hvilke tilgangspakker og tjenester som er delegert til en systembruker?

I systembruker-modellen godkjenner sluttbruker enten hele forespørselen eller ingenting. Det betyr at systemleverandøren allerede vet hvilke rettigheter som er godkjent, siden disse ble definert i forespørselen.

For å se hvilke rettigheter en systembruker faktisk har kan man bruke Authorize Party-endepunktet, som returnerer hvilke klienter og tilgangspakker systembrukeren har.

• 6) Hva skjer dersom en klient tidligere har akseptert en systembrukerforespørsel, men systemet senere endrer hvilke rettigheter eller tilgangspakker som kreves? Hvordan kan man vite om klienten har akseptert den nye eller den gamle versjonen?

Hvis rettighetene endres, vil dette normalt håndteres gjennom en ny endringsforespørsel. Systemleverandøren vil da kunne se status på om forespørselen er akseptert eller ikke. Dersom det har vært flere endringsforespørsler over tid, kan det likevel være vanskelig å holde oversikt over hva som til enhver tid er godkjent.

Den gjeldende statusen for en systembruker kan kontrolleres via AuthorizeParty-endepunktet, som returnerer hvilke kunder en agent-systembruker har tilgang til og hvilke tilgangspakker eller rettigheter som er delegert til den brukeren på nåværende tidspunkt.

Dette gjelder også for vanlige brukere, men der vil listen normalt bare inneholde én aktør.

Det er også grunnen til at man ikke kan gjøre endringer direkte på klient-systembrukere. Hvis man kunne endre rettighetene direkte, kunne man risikere å endre dem slik at kunden ikke lenger oppfyller kravene for tilgangen.

• 7) Angående tidligere spørsmål om å bruke systembrukere til å administrere klienter for andre systembrukere. Når endringer eller nyheter som dette kommer ut, hvilken kanal publiseres det i som vi kan følge med på?

Informasjon om nye funksjoner og endringer publiseres primært gjennom følgende kanaler:

• Nyhetssaker på samarbeid.digdir.no. Her publiseres artikler om nye funksjoner, endringer og andre oppdateringer i Altinn.
• Nyhetsbrev. Prosjektet sender ut et månedlig nyhetsbrev med oppdateringer om Altinn og relaterte tjenester.
• Slack kan brukes for diskusjoner med produktteamet og community support.

Når det gjelder release notes, er målet å samle dette mer systematisk på ett sted. Dette er imidlertid ikke fullt etablert ennå, og det jobbes med å forbedre oversikten over endringer fremover.

• 8) Vi er et revisjonsselskap som har et agentsystem med systemtilgang for kundene våre, og vi bruker Maskinporten i produksjon. Det finnes et API for å delegere kunder til systemet, men slik vi forstår det fungerer dette kun via ID-porten.

  Stemmer det at dette ikke kan gjøres via Maskinporten-token, og at man derfor må bruke ID-porten?

  Vi har mange kunder, og det er krevende å legge dem inn manuelt i Altinn. Derfor er vi avhengige av å kunne gjøre dette gjennom et maskinelt grensesnitt. Finnes det planer om å støtte dette, eller må vi basere oss på en mer manuell løsning fremover?

Per i dag er det ID-porten-token som brukes for denne typen operasjoner. Rene Maskinporten-token kan ikke brukes alene, fordi en virksomhet i Altinn ikke har rettigheter i seg selv, rettigheter er alltid knyttet til en bruker.

For klientdelegering som nylig ble lansert via API, støttes det imidlertid å bruke en systembruker basert på Maskinporten. Da kan man sette opp en systembruker som fungerer som klientadministrator, og bruke denne til å administrere kunder og ansatte i systemet. Det betyr at man kan automatisere håndtering av et stort antall kunder og brukere, for eksempel ved å legge til eller fjerne klienter maskinelt.

Når det gjelder administrasjon av systembrukere, vurderes det videre hvordan dette kan støttes bedre. På sikt kan det bli mulig at en systembruker også kan administrere andre systembrukere, på samme måte som en systembruker i dag kan administrere personer i Altinn.

En mulig løsning i dag er å bruke ID-porten-token med 90 dagers varighet. Da må en bruker logge inn og fornye token omtrent fire ganger i året. Dette kan brukes i automatiserte prosesser.

For å delegere klienter via systembruker må systembrukeren ha riktig rolle, for eksempel Klientadministrator. Denne rollen gir systembrukeren rett til å administrere klienter for virksomheten.

Det er likevel viktig å merke seg at daglig leder eller en annen med riktige rettigheter må godkjenne delegasjonen første gang.

• 9) Er dere ferdig med å definere tilgangspakkene? f.eks. https://tjenesteoversikten.no/package/fb0aa257-e7dc-4b7b-9528-77dfb749461c ser litt tynn ut f.eks. sammenlignet med Regnskapsbyrå Lønn pakken?

Tjenestene som knyttes til tilgangspakkene er det tjenesteeierne som velger, så her er nok årsaken til at ikke alle tjenesteeiere har knyttet tilgangspakker ennå.

• 10) Har dere en dato for når arbeidet med tilgangspakkene vil være på plass før tidsfristen?

  Slik jeg forstår det må manuell delegering mellom selskaper (altså delegering som ikke er basert på roller fra Brønnøysundregistrene) gjøres ved hjelp av tilgangspakker. Stemmer det?

Ja, det stemmer at virksomheter må delegere tilgangspakker som skal erstatte dagens roller ved manuell delegering.

Tjenesteeiere må derfor ta i bruk tilgangspakker før Altinn II stenges 19. juni. Samtidig vil det i en overgangsperiode etter dette fortsatt være mulig å autorisere basert på roller. Dette er for å gi virksomheter litt ekstra tid til å få delegert de nye tilgangspakkene.

• 11) Er det mulig å ta ut samtlige nye meldinger i Dialogporten per dag? Tenker da på kun avsender og subjekt. Eller må en ha alle tilgangspakker slik at alle meldinger blir dekt?

En vil kunne hente ut en liste med alle dialoger med f.eks. /dialogs/?Party=...&Party=...&contentUpdatedAfter=2026-03-10&contentUpdatedBefore=2026-03-11 for å hente alle dialoger som har innholdsendringer på én spesifikk dag.

Men det vil være behov for at den autentiserte brukeren da har tilgangene som trengs; da typisk gjennom tilgangspakker.

• 12) Det ble nevnt at det planlegges en løsning hvor systemleverandører kan sende en sletteforespørsel for en systembruker, som deretter må godkjennes av noen med rettigheter i virksomheten som eier systembrukeren.

  Har dere vurdert en løsning hvor manglende respons fører til automatisk sletting?

  For eksempel at dersom mottaker av sletteforespørselen ikke gjør noe innen et visst antall dager, blir systembrukeren slettet automatisk. Dette kunne bidra til å unngå situasjoner der sluttbrukersystemer blir sittende med tilganger de ikke ønsker, men heller ikke får fjernet.

Denne typen løsning har ikke blitt vurdert så langt. Spesifikasjonen for sletting av systembruker er fortsatt under arbeid. Innspillet om automatisk sletting ved passivitet er imidlertid relevant, og tas med videre i diskusjonen.

Målet er uansett å unngå situasjoner der systemleverandører eller virksomheter sitter med rettigheter de ikke trenger. Siden vi anser systemleverandører som profesjonelle aktører, er ønskelig at de i størst mulig grad kan ta ansvar for å håndtere tilganger/hjelpe kunden til håndtering.

• 13) Hva er grunnen til at systembruker agent ikke kan ha isVisble: true og bruke tilgangspakker. I dag må jeg legge til enkelt ressurser

Årsaken henger sammen med hvordan rettigheter fungerer i agent-scenarioer. Når man bruker en systembruker-agent, er det ikke rettighetene til regnskapsførerfirmaet som er relevante, men rettighetene til kundene deres.

Hvis isVisible: true hadde vært brukt i dette scenariet, ville det innebære at en bruker i regnskapsførerfirmaet kunne delegert tilgangspakker til systembrukeren via brukergrensesnittet. Problemet er at regnskapsførerfirmaet normalt ikke selv har disse tilgangspakkene, fordi de tilhører kundene.

Dermed ville det ikke vært teknisk mulig å delegere disse pakkene fra regnskapsførerfirmaet til systembrukeren. Begrensningen handler derfor om hvem som faktisk har rett til å delegere rettighetene.

• 14) Hvis en kunde delegerer enkeltrettigheter til oss, skal det fungere på samme måte som når vi ber om en tilgangspakke?

  Vi opplever at dersom kunden delegerer enkeltrettigheter som også finnes i en tilgangspakke, ser det ikke ut til å fungere. Det virker som om vi må be om hele tilgangspakken. Stemmer dette, eller har vi misforstått?

Forskjellen mellom tilgangspakker og enkeltrettigheter i dag er at enkeltrettigheter foreløpig ikke kan videredelegeres. Det betyr at hvis virksomhet A gir en enkeltrettighet til virksomhet B, kan ikke virksomhet B gi denne rettigheten videre til sine ansatte eller til en systembruker.

Tilgangspakker fungerer annerledes. Hvis virksomhet B får delegert en tilgangspakke, kan denne videre brukes i virksomheten, for eksempel ved at den tilordnes en systembruker dersom det matcher behovet til systemet. Denne begrensningen har også eksistert tidligere i Altinn i forbindelse med klientdelegering, hvor delegering har vært håndtert på rollenivå og ikke på mer granular nivå.

Det er kjent at dette kan være en begrensning, og det er noe som vurderes videre. Det er imidlertid ikke planlagt noen endring før sommeren, og det er foreløpig usikkert om dette kommer senere i år.

• 15) Når jeg henter dialoger fra Dialogporten, hvordan kan jeg identifisere hvilken type dialogmelding jeg får tilbake?

  For eksempel: Hvis en dialog opprettes ved innsending av en A-melding, hvordan kan jeg da identifisere at en melding som kommer tilbake er en tilbakemelding til denne dialogen?

Per i dag er det opp til tjenesteeieren hvordan tilbakemeldinger på en dialog implementeres.

Anbefalingen er at en tilbakemelding legges inn som en forsendelse på den eksisterende dialogen, slik at hele kommunikasjonen, fra innsending til svar, kan håndteres innenfor samme dialog gjennom hele livsløpet. I praksis er det foreløpig få tjenester som gjør dette fullt ut. I mange tilfeller vil tilbakemeldinger derfor komme som egne meldinger, brev eller annen korrespondanse knyttet til dialogen. Et eksempel er Brønnøysundregistrene, som i enkelte tilfeller legger svar eller tilbakemeldinger direkte inn i dialogen som en forsendelse. Dette gjør det mulig å følge hele prosessen i én og samme dialog.

Det finnes derfor ikke ett generelt svar på hvordan en tilbakemelding identifiseres. For å håndtere dette må man ha kjennskap til:

• den aktuelle tjenesten
• hvordan tjenesteeieren har valgt å modellere kommunikasjonen

Et godt sted å starte er å se på ressursen som dialogen er knyttet til, siden den gir informasjon om hvilken tjeneste dialogen gjelder. For eksempel, hvis dialogen gjelder A-melding, vil ressursen som dialogen er knyttet til indikere at dialogen gjelder denne tjenesten.

For A-melding fungerer tilbakemeldinger slik:

• Når en A-melding sendes inn opprettes en dialog.
• Når tilbakemeldingen kommer, publiseres det et webhook-event på samme dialogId.
• Selve tilbakemeldingen ligger på en egen forsendelsesId, men fortsatt på samme dialogId.
• Tilbakemeldingen inneholder også en referanse til innsendingens forsendelsesId.

Dette gjør det mulig å koble tilbakemeldingen direkte til riktig innsending.

• 16) Vi opplever at ulike tjenesteeiere tilbyr paging i API-er på forskjellige måter.

  Når man henter mange elementer, varierer det hvordan tjenestene indikerer at det finnes flere sider med data. Dette gjør det vanskeligere å jobbe på tvers av tjenester, fordi implementasjonen ikke er lik.

  Innspillet er derfor om det kunne vært mulig å etablere en anbefalt standard eller mal for paging, slik at implementasjonen blir mer lik på tvers av tjenester.

Det finnes i dag ikke en felles standard for paging på tvers av alle tjenester. Tjenesteeiere har i stor grad selv ansvar for hvordan API-ene deres implementeres, og det finnes derfor variasjoner både mellom ulike tjenesteeiere og også innenfor enkelte Altinn-komponenter.

Det kan i beste fall gis anbefalinger eller veiledning, men det er ikke nødvendigvis mulig å styre hvordan alle tjenester implementerer paging.

Innspillet er likevel nyttig, og vi noterer det ned og tar det med videre i arbeidet.

• 17) Stemmer det at vi som leverandør kun registrerer systemet i Systemregisteret for å generere en system_id, og at vi ikke definerer rettigheter eller tilgangspakker i selve registreringsprosessen?

Det er både riktig og ikke helt riktig.

Når et system registreres i Systemregisteret genereres det en system_id, men i registreringen definerer man også hvilke tilgangspakker systemet maksimalt kan be om. Dette fungerer som en avgrensning: systemet kan ikke be om andre tilgangspakker enn de som er registrert der.

Samtidig betyr ikke dette at alle kundene må bruke de samme tilgangspakkene. Et system kan for eksempel støtte flere moduler eller funksjoner, og ulike kunder kan ha behov for ulike tilgangspakker. En kunde kan for eksempel be om tilgangspakke A, mens en annen kunde ber om tilgangspakke B, så lenge disse pakkene er definert som mulige for systemet i Systemregisteret.

Dette gjør det mulig for en systemleverandør å ha ett system som støtter flere moduler eller produkter, hvor ulike kunder får tilgang basert på hvilke funksjoner de faktisk bruker.

I tillegg knyttes systemet til Maskinporten-klienten i Systemregisteret, slik at systemet kan autentisere seg gjennom Maskinporten.

• 18) Er det korrekt at det er kunden (banken/klienten) som oppretter en Systembruker knyttet til vår system_id, og at det er i dette steget kunden tildeler relevante Tilgangspakker (f.eks. fra Skatteetaten)?

En systembruker opprettes i kundens virksomhet, og det er også kunden som til slutt godkjenner opprettelsen og delegasjonen av rettigheter.

I praksis kan imidlertid systemleverandøren initiere forespørselen om å opprette en systembruker. Systemleverandøren sender da en forespørsel som beskriver hvordan systembrukeren skal settes opp, for eksempel hvilke tilgangspakker eller rettigheter som ønskes.

Kunden må deretter godkjenne forespørselen. Når kunden godkjenner, opprettes systembrukeren i virksomheten, og de aktuelle tilgangspakkene eller rettighetene blir delegert til systembrukeren. Samtidig opprettes det en kobling mellom systembrukeren og systemet, slik at systemleverandøren kan opptre på vegne av denne systembrukeren når det gjøres API-kall.

Det er viktig å merke seg at systembrukeren tilhører kundens virksomhet. Det betyr at det er kunden som eier systembrukeren og som kan administrere den videre, for eksempel ved å endre rettigheter eller slette systembrukeren. Systemleverandøren kan ikke gjøre dette uten at kunden godkjenner det.

• 19) Vi planlegger å hente tokens fra Maskinporten. Kan dere bekrefte at når kunden har delegert en tilgangspakke til vår Systembruker, vil vi motta et Maskinporten-token som inneholder et systemuser-claim (eller tilsvarende), som gir oss de nødvendige rettighetene i Altinn 3.0 API-er?

Ja, forutsatt at forespørselen som sendes før systembrukeren opprettes inneholder de nødvendige rettighetene for å kalle det aktuelle API-et, for eksempel for en app eller et API man skal rapportere til.

Når systembrukeren opprettes, får den en egen systembruker-ID, og denne systembrukeren har et sett med rettigheter lagret hos oss.

Når en tjenesteeier mottar en forespørsel fra systemet, kan de bruke systembruker-ID-en til å sjekke om systembrukeren har riktig tilgang. For eksempel kan Skatteetatens API spørre om systembrukeren har lesetilgang til MVA-pakken. Vi sjekker da i våre data om denne tilgangen er delegert til systembrukeren.

Hvis rettighetene er på plass, bekrefter vi dette, og API-et kan behandle forespørselen og returnere svar.

• 20) Tidligere i Altinn 2 måtte vi gjøre ett kall per organisasjon i Oslo kommune for å hente ut alle brukere som har roller eller rettigheter i hele organisasjonshierarkiet.

  Vil det være mulig å gjøre ett kall mot hovedorganisasjonsnummeret for å hente ut alle brukere som har roller eller rettigheter i hele organisasjonen?

Vi har publisert dokumentasjon for det nye Connections API-et, som ble lansert nylig. Dette er et tilgangsstyrings-API som i praksis gjør det samme som man kan se i brukergrensesnittet i Altinn, nemlig å få oversikt over hvem i en virksomhet som har tilgang.

For eksempel kan man gjøre et kall for Oslo kommune, og få en oversikt over hvem som har rettigheter der. Samtidig må man være oppmerksom på at rettigheter kan være delegert til underenheter. Hvis en person for eksempel har fått rettigheter til en bestemt barnehage som ligger under Oslo kommune, vil ikke dette nødvendigvis vises i et kall mot hovedorganisasjonsnummeret.

For å få full oversikt må man derfor gjøre separate kall for de aktuelle enhetene. Man kan for eksempel gjøre ett kall for hovedorganisasjonen, og deretter et eget kall for en underenhet, som en barnehage, for å se hvem som har rettigheter der.

Dette betyr at man fortsatt kan måtte gjøre flere kall for å få en komplett oversikt over rettigheter i hele organisasjonsstrukturen.

• 21) Hvilke retningslinjer har dere for hvordan tjenesteeiere skal implementere og bruke Dialogporten?

  Vi opplever at mange av funksjonene i Dialogporten ikke tas i bruk, selv om de kunne gitt bedre løsninger. Det gjelder for eksempel bruk av metadata og strukturer som gjør maskin-til-maskin-kommunikasjon enklere. Kunne Digdir i større grad lagt føringer eller oppfordret tjenesteeiere til å bruke disse funksjonene mer konsekvent, slik at løsningene blir bedre fra start?

Dette er et tema Digdir er klar over og har på agendaen, selv om arbeidet ikke har kommet så langt som ønsket.

Blant annet arbeides det med nye bruksvilkår for offentlige virksomheter som tar i bruk fellesløsninger som Dialogporten. Her vil det bli tydeligere forventninger til hvordan løsningene brukes, for eksempel når det gjelder å holde dialoger oppdatert og bruke statusfelter slik at løsningene blir mer brukervennlige.

Det er også et mål at tjenesteeiere i større grad tar i bruk tilgjengelige datafelter i Dialogporten for å legge bedre til rette for maskin-til-maskin-kommunikasjon.

Samtidig er Digdirs rolle først og fremst å tilby fellesløsningen, gi veiledning og anbefalinger og legge til rette for god bruk. Hvordan løsningene faktisk implementeres vil i stor grad avhenge av tjenesteeierne. Innspill fra leverandører er derfor viktige. Leverandører som jobber tett på løsningene kan bidra med konkrete eksempler på hvor ting ikke fungerer optimalt, slik at dette kan tas videre i dialogen med tjenesteeiere.

Det er også et ønske å kunne stramme inn enkelte krav i fremtidige versjoner av API-er, for eksempel ved å gjøre enkelte felter obligatoriske. Dette er noe som vurderes videre.

• 22) Kan dere si noe om hvilke tilgangspakker som må brukes for tjenester knyttet til lønn, A-melding og skattekort?

For å bruke slike tjenester må systemet ha en systemtilgang som dekker de aktuelle tjenestene, enten direkte eller gjennom tilgangspakkene som tjenestene inngår i.

Det er tjenesteeierne som bestemmer hvilke tilgangspakker som brukes for de ulike tjenestene.

Det viktigste er derfor å kartlegge hvilke tjenester systemet skal bruke, og deretter finne ut hvilke tilgangspakker disse tjenestene ligger i, slik at systemtilgangen kan settes opp med riktige rettigheter.

• 23) Vi er relativt tidlig i prosessen og sliter litt med å finne alle meldingene vi skal hente fra Dialogporten, siden de kommer fra flere ulike etater.

  Jeg er også usikker på:

• hvor vi finner oversikt over hvilke tilgangspakker og ressurser som kreves
• om man må legge inn scopes fra ulike etater når man lager tokens for å hente dialoger

• og om alle meldinger faktisk er representert i Dialogporten

  Finnes det en felles oversikt over dette?

Det finnes foreløpig ikke en komplett og offisiell tjenestekatalog som gir en full oversikt over alle tilgangspakker, ressurser og tjenester på tvers av etater.

Det finnes imidlertid en foreløpig oversikt på tjenesteoversikt.no, hvor man kan se en liste over tjenester, tilgangspakker og tilhørende ressurser. Denne kan brukes for å navigere i landskapet og finne ut hvilke tilganger som trengs for ulike tjenester.

Når det gjelder scopes, trenger man i utgangspunktet bare ett scope for å kunne snakke med Dialogporten-API-et. For å få tilgang til dialogene må brukeren eller systembrukeren man autentiserer seg med ha de nødvendige rettighetene, typisk gjennom tilgangspakker delegert til virksomheten for de aktuelle tjenestene.

Meldinger som sendes gjennom Altinns meldingstjeneste vil være representert som dialoger i Dialogporten, og dialogene følger de samme autorisasjonskravene som selve meldingene. Samtidig inneholder ikke Dialogporten selve meldingsinnholdet. Dialogen inneholder i stedet lenker til hvor innholdet ligger, ofte i API-er hos den aktuelle etaten. For eksempel kan meldingsinnhold for tjenester fra Skatteetaten ligge i deres egne API-er.

For å hente meldingsinnhold fra Altinn Melding og Altinn Apps, er det egne scopes for dette i tillegg til det ene scopes man trenger for å snakke med Dialogporten API-et.

Et praktisk tips dersom man prøver å finne riktig tilgang eller ressurs, er å ta utgangspunkt i en dialog man allerede ser i Arbeidsflaten. Ved å inspisere nettverkstrafikken i nettleseren kan man se på payloaden fra backend-API-et. I denne payloaden ligger blant annet ressurs-ID for dialogen. Denne ressurs-ID-en kan deretter brukes mot for eksempel tjenesteoversikt.no for å finne hvilke tilgangspakker og ressurser som er knyttet til dialogen.

• 24) Hvor oppdatert er Altinn TT02 når det gjelder grensesnitt for oversikt over systembrukere og deres tilganger?

  Jeg finner ikke hvor jeg kan se godkjente systembrukere eller tilhørende roller/tilganger for en organisasjon.

I TT02 finnes det funksjonalitet for dette dersom du har riktig rolle.

Hvis du har rollen Tilgangsstyrer, vil du i menyen finne et valg for systembrukere (i den delen av løsningen som fortsatt bruker den gamle brukerflaten). Der kan du se hvilke systembrukere som er opprettet og akseptert for virksomheten.

Når du åpner en systembruker, kan du også se hvilke tilgangspakker og rettigheter som er delegert til den.

Hvis du i tillegg har rollen Klientadministrator, vil du også kunne se agent-systembrukere og hvilke kunder de er knyttet til. Det er per nå ikke planlagt større ny funksjonalitet på kort sikt for dette området i TT02.

En merknad om support

For spesifikke tekniske feil eller saksnummer som har ligget lenge, oppfordres det til å sende e-post til servicedesk@altinn.no