Description

Each authentication request must be logged as an authentication event to the audit-log component. Considering the performance, each event will be written to a storage queue and a function app will process the queue and send the event to the audit log component to be stored in the database.

Tasks

• write the authentication event to the storage queue
• Implement feature flag for event logging
• Deploy til at environment with feature flag on for testing
• Identify areas in the authentication component to implement event logging

Acceptance Criteria

• Each authentication request is saved as an authentication event
• Refresh action is registered as an authentication event with specific authentication event type
• Exchanging external token is registered as an authentication event with specific authentication event type
• Authentication of altinn studio token is registered authentication event with specific authentication event type

Description

To get started using Cypress, we are going to port some of our existing Selenium tests. These tests were chosen as a way to learn Cypress and to gain experience using it. When tests are ported, they will be removed from the Selenium test runs to make them run faster, and to avoid testing the same thing twice.

Tests

Your contact information for the enterprise

• Enter valid phone number in ContactSettingsProfessional Details

• Enter invalid phone number in ContactSettingsProfessional Details

• Enter valid email in ContactSettingsProfessional Details

• Enter invalid email in ContactSettingsProfessional Details

• Save a valid phone number

• Save a valid email address

• Change SMS notification settings

• Set SMS notification settings

• Change email notification settings

• Set email notification settings

• Change notification settings for services

• Remove tests from Selenium once they've been ported to Cypress

Others with rights

• Add new person

• Delegate role

• Delete delegation of role

• Enter email if missing

• Delegate single rights

• Remove tests from Selenium once they've been ported to Cypress

Common notification address

• Add element in list in Common Notification Address

• Delete element in list in Common Notification Address

• User who is access manager for an organization has many varslingsadresser in profile, sms and email

• Remove tests from Selenium once they've been ported to Cypress

Overordnet beskrivelse

Samtykke må reetableres på ny plattform som en frittstående komponent med eget brukergrensesnitt.
Løsningen må la eksterne be om et samtykke (samtykkeforespørsel), som inneholder informasjon om hvem som skal gi samtykke (person, organisasjon), hvilken tjenesteressurs det skal gis samtykke til og hvem samtykket skal gis til.

Bruker som skal gi samtykke må få presentert detaljer om hva det ønskes samtykke til samt andre nødvendige detaljer.
Etter at bruker har gitt samtykke blir han sendt tilbake til den som har startet prosessen.

Overordnet beskrivelse av behov

 
Vi må tilby en samtykke komponent som har følgende egenskaper.

• Eksterne kan registrere en samtykkeforespørsel. Den inneholder hvilken aktør det er snakk om (person, organisasjon) hvilke tjenesteressurs som det skal gis tilgang til og implisitt hvem som ønsker tilgang.
• Man skal kunne sende sluttbrukere til en url med en referanse til forespørsel. Sluttbruker skal da bli logget på og fremvist detaljer om hva som det ønskes tilgang til med alle detajler
• Når bruker aksepterer skal man bli redirectet tilbake til den som har startet prosessen med en access_code. Denne kan brukes til å hente ut
   

Hva skal leveres

• Ny frittstående samtykkekomponent etableres
• Ny frittstånde GUI med BFF etableres
• Ny lagring av samtykke
• Benytter seg av Ressursregisteret som definisasjon av tjeneste og delegeringstekst.
• Benytter seg av RRR for å styre hvem som kan sende samtykkeforespørsler

Estimat/Omfang 

Spørsmål

• Burde tnjenesteeier selv tra ansvar for innhold i mal/visning?
• Why smatykke-komponent eller som egen app/ steg i app?
• Scope basert delegering i maskinporten /ID-porten?
• Migrering av delegering og eksisterende samtykkelog?
• Migrering av authrequest og API for å registrere forespørsler?
• Dersom app løsning hvordan skal banken instansiere app/forespørsel
• Finne ut hvordan banker bruker token
• Hvilke API skal tilbys

Description

In some scenarios the ID provider gives Altinn Authenticaiton access to an access token during loggin

This token can be used to call API to get information.

But currently we don't share the access token with the app.

Consideration

Is there special need for protection?

Requirements

• Make the access token available for the app to be used

Description

	In some scenarious

Additional Information

No response

Tasks

No response

Acceptance Criterias

No response

Description

We have some code that need to be improved for readability and functionality

Considerations

Describe input (beyond tasks) on how the user story should be solved can be put here.

Acceptance criteria

Describe criteria here (i.e. What is allowed/not allowed (negative tesing), validations, error messages and warnings etc.)

Specification tasks

• Development tasks are defined

Development tasks

• Extract validation of issuer to separate methods
• Add claims whitelist of allowed claims from studio

Test

Add test cases here as checkboxes that are being tested as part of the changes.

Definition of done

Verify that this issue meets DoD (Only for project members) before closing.

• Documentation is updated (if relevant)
  • Technical documentation (docs.altinn.studio)
  • User documentation (altinn.github.io/docs)
• QA
• Manual test is complete (if relevant)
• Automated test is implemented (if relevant)
• All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

Overordnet beskrivelse

Flytte løsning for OIDC pålogging som skjer via Altinn 2 over på Altinn 3 plattformen.
 

Overordnet beskrivelse av løsning

Løsningen må støtte single signon og signout
Løsningen gjør det mulig for brukere å logge seg inn på Altinn via ID-porten.

Estimat/Omfang

• Det meste av koden her er allerede utviklet i forbindelse overgang fra YAML til OIDC i Altinn2
• Forutsetter at dette kun er OIDC pålogging

Spørsmål

Overordnet beskrivelse

Altinn pålogging er en autentiseringsløsning som stammer fra før ID-porten. Denne løsningen har overlappende funksjonalitet med MinID og ønskes derfor fjernet. Ettersom denne autentiseringsmetoden også blir brukt mot SOAP-tjenestene, vil vi i første omgang fjerne muligheten for å logge seg på fra portalen, for å senere ta bort hele løsningen når SOAP API-ene er fjernet. Ettersom løsningen også brukes under automatisk testing må det legges til rette for ny autentiseringsmetode som kan brukes for dette formålet
 

Overordnet beskrivelse av løsning

I første omgang skal vi fjerne pålogging fra portalen og potensielt kun gjøre det tilgjengelig for test.

I første omgang vil linken fra ID-porten til alternativ innlogging endres til å gå mot Selvidentifisert bruker, som er brukeren vi vil videreføre frem til vi har en alternativ nasjonal løsning for dette.

Dagens Altinn Pin pålogging brukes i stor grad av forskjellig typer testing og frem til at vi har et like brukervennelig alternativ må vi fortsette med å ha det tilgjengelig.
Påloggingsmetoden som fjernes er

• Altinn kodebrev
• SMS Kode
• Kun passord

For SOAP grensesnitt er antakelsenat vi må støtte dette til Altinn 2 slås av. Hypotesen er også at vi ikke trenger å tilby integrasjon med SOAP for arkiverte Altinn 2 elementer i fremtiden. Disse data må evnentuelt lastes ned i portal.
 

Week 43 (

Deploy @

• Authentication Production (Tuesday)
• Authorization Production (Tuesday)
• Deploy APIM to prod (Tuesday)
• Authentication TT02 (Wednesday)
• Authorization TT02 (Wednesday)
  • Deploy APIM to TT02 (Wednesday)
• Test (All automated tests green)

Patching

Includes patching of project dependencies (.NET, Maven), containers, and Github Actions

• Authentication
• Authorization
• Access Managment
• Resource Registry

Week 44

Deploy @jonkjetiloye

• Authentication Production (Tuesday)
• Authorization Production (Tuesday)
• Deploy APIM to prod (Tuesday)
• Authentication TT02 (Wednesday)
• Authorization TT02 (Wednesday)
  • Deploy APIM to TT02 (Wednesday)
• Test (All automated tests green)

Patching

Includes patching of project dependencies (.NET, Maven), containers, and Github Actions

• Authentication
• Authorization
• Access Managment
• Resource Registry

Week 34

Deploy @acn-dgopa

• Authentication Production (Tuesday)

  • Deploy APIM to prod (Tuesday) (NA for this week)

• Authorization Production (Tuesday)

  • Deploy APIM to prod (Tuesday) (NA for this week)

• Delegation Events to prod(Tuesday) (nothing to deploy since 5. May)

• Resource Registry Production (Tuesday)

  • Deploy APIM to prod (Tuesday) (NA for this week)

• Authentication TT02 (Wednesday)

  • Deploy APIM to TT02 (wednesday) (NA for this week)

• Authorization TT02 (Wednesday)

  • Deploy APIM to TT02 (Wednesday) (NA for this week)

• Delegation Events to TT02 (Wednesday)

• Test (All automated tests green)

Deploy AccessManagement (TT02 - Wednesday, Prod - Tuesday)

The access management has to de deployed in the following order

• Deploy access management platform component Production
• Deploy access management platform component TT02 (NA for this week)
• Deploy access managment to api managment if relevant Production (NA for this week)
• Deploy access managment to api managment if relevant TT02 (NA for this week)
• Deploy access managment ui application Production (NA for this week)
• Deploy access managment ui application TT02

Patching (Thursday) @acn-dgopa

Includes patching of project dependencies (.NET, Maven), containers (Dockerfile, Will be opened by dependabot/renovate), and Github Actions

• Authentication (NA for this week)
• Authorization
• Access Managment
• Resource Registry
• Access Management Frontend (Frontend patches were created by renovate. Assigned the frontend team to review it as some of the frontend tests failed)

Week 35

Deploy @lovoll

• Authentication Production (Tuesday)

  • Deploy APIM to prod (Tuesday)

• Authorization Production (Tuesday)

  • Deploy APIM to prod (Tuesday)

• Delegation Events to prod(Tuesday) Do not update the altinnaccesstokenclient and moq packages

• Resource Registry Production (Tuesday)

  • Deploy APIM to prod (Tuesday)

• Authentication TT02 (Wednesday)

  • Deploy APIM to TT02 (wednesday)

• Authorization TT02 (Wednesday)

  • Deploy APIM to TT02 (Wednesday)

• Delegation Events to TT02 (Wednesday) Do not update the altinnaccesstokenclient and moq packages

• Test (All automated tests green)

Deploy AccessManagement (TT02 - Wednesday, Prod - Tuesday)

The access management has to de deployed in the following order

• Deploy access management platform component
• Deploy access managment to api managment if relevant
• Deploy access managment ui application

Patching (Thursday) @lovoll

Includes patching of project dependencies (.NET, Maven), containers (Dockerfile, Will be opened by dependabot/renovate), and Github Actions

• Authentication (no patching pull requests)
• Authorization
• Access Managment
• Resource Registry (no patching pull requests)
• Access Management Frontend

Task in the 2.0 board: https://dev.azure.com/digdir/Altinn/_boards/board/t/Team%20Commodore/Stories/?workitem=63605

OIDC Altinn 2

Legge opp til å kunne kjøre i paralell.

La en liten andel ta over

Sign out

OIDC Altinn 3

Ses i sammenheng med flytting av meldingsboks

Er det naturlig å ha meldingsboks i tillegg til dialogporten

Oppdatere redirect/påloggingsekvens til Altinn 2 til å redirecte til Altinn 3 med redirect url.

Hvordan løse sesjons i Altinn 3.

Virksomhetsbrukere

Kan sertifikat fjernes før EC grensesnittene er fjernet
Sannsynligvis ikke ønskelig å fjerne EC grensesnitt før tjeneste er flyttet ut av

Må støtte oppdatering av sertifikat

Hva med BigIp og oppdatering. Hva med ny infrstruktur

Utvide maskinporten for å få klientID. Er det helt utelukket?
Det ville kunne gjøre at man slipper brukernavn/passord

Avikle Altinn pålogging

SMS PIN

Altinn Kodebrev

Hva med testbrukere

Kan sperre sidene for andre enn test. Hemmelig parameter eller annen måte for å sikre ytelsestest

På API så må man

Kan man spare penger på å kutte ut kodebrev

Selvidentifserte brukere

To måter å videreføre

• Knytte ny ID til gammel konto
• Overføre data fra gammel til ny
• Kan vi ikke bare gjøre data utilgjengelig.

Skaffe statistikk

Periode hvor man
Ikke mulig å instansiere

Hvis må videreføre må vi bygge ny GUI

Logging

Altinn 2 sluttbruker APIet støtter i dag ID-Porten tokens for scope-basert autentisering og autorisasjon for tilgang til endepunkter på vegne av brukeren.

ID-Porten er i ferd med overgang fra gammel til ny platform og i en overgangsfase vil vi da måtte støtte både tokens utstedt av gammel og ny issuer.

For virksomhetstoken er dette allerede implementert gjennom støtte for maskinporten tokens som har fått egen dobbel config (MaskinportenWellKnownEndpoint & MaskinportenAlternativeWellKnownEndpoint).

Vi må ha lignende oppsett for sluttbruker tokens fra IDPorten i overgangsfasen for å støtte en "Alternate" issuer for dagens altinn.config verdi: IDPortenWellKnownEndpoint.

Test:
gammel platform: https://oidc-ver2.difi.no/idporten-oidc-provider/.well-known/openid-configuration
ny platform: https://test.idporten.no/.well-known/openid-configuration

Prod:
gammel platform: https://oidc.difi.no/idporten-oidc-provider/.well-known/openid-configuration
ny platform: https://idporten.no/.well-known/openid-configuration

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update nuget non-major dependencies (Altinn.Common.AccessToken, Azure.Storage.Queues, Microsoft.AspNetCore.Mvc.Testing, Microsoft.IdentityModel.Protocols.OpenIdConnect, Swashbuckle.AspNetCore)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Description

In some applications, there is no need to support both cookies and or bearertoken.

To reduce exposure we should add the option to configure JWTCookie to only support one of the methods.

Additional Information

No response

Tasks

• Add configuration to limit support in JWTCookie handler for both

Acceptance Criterias

No response

Week 42 (kopi fra Platform - endres til Autorisasjon)

Deploy @ivartryti

• Platform Production (Tuesday)
• Deploy APIM to prod (Tuesday)
• Platform TT02 (Wednesday)
  • Deploy APIM to TT02 (Wednesday)
• Test (All automated tests green)

Patching

Includes patching of project dependencies (.NET, Maven), containers, and Github Actions

• Register
• Events
• Profile
• Storage
• Receipt
• Notifications
• PDF
• Altinn-cli
• Altinn-application-owner-system
• eFormidling
  • prod
  • tt02
• Test

Overordnet beskrivelse

Det er behov for en bedre funksjonalitet for brukere uten fødselsnummer og d-nummer. For disse er det behov for en løsning som fungerer på tvers av offentlig sektor og ikke kun internt i Altinn.

Hva denne løsningen er, eller hvem som skal realisere den er enda ikke avklart, men når den er på plass må vi koble eksiterende brukere mot den nye løsningen slik at disse kan fortsette å bruke Altinn uten å miste viktige data.

Mer detaljert om behovet

Det er behov for en bedre løsning for brukere uten Dnr/Fnr. Ønsker ikke at dette skal være en Altinn intern bruker, men en bruker som kan brukes på tvers av offentlig sektor.
Det må være mulig å delegere til og fra en selvidentifisert bruker

Løsningen må sikre at dagens SI-brukere kan beholde tilgangen til de meldinger osv. de har i Altinn fra før
 

Overordnet beskrivelse av løsning

Forutsetningen er at det etableres en ny løsning for dette i MinId
Da må det lages en løsning som lar overføre bruker til ny identitet.

Dette kan potensielt gjøres ved at man får beskjed om å logge seg inn dobbelt og at man overfører identitet til ny kilde.

Alternativ er overføring av data til ny brukerId. Det krever mer.

Delegering er i praksis bare en begrensning i dagens løsning som er bestemt. Det kan endres relativt lett.

Estimat/Omfang 

Spørsmål

Hvordan kobler vi dagnes SI brukere til ny nasjonal løsning (ID-porten utland el)

Overordnet beskrivelse

Brukere som i dag finnes i Altinn 2 må migreres over til Altinn 3
 

Overordnet beskrivelse av løsning

Estimat/Omfang

Spørsmål

Description

When ID-porten changes infrastructure there will be a new maskinporten and ID-porten endpoints where tokens will be generated from.

Both new and old environments will be used at the same time. Altinn Authentication needs to be updated to support this.

Additional Information

No response

Tasks

No response

Acceptance Criterias

• Authentication needs to support multiple ID-porten environments
• Authentication needs to support multiple maskinporten environments

Description

Add notification to the logon page for Altinn-koder that the authentication method is depricated and will be removed from the portal when we move to the new Id-porten environment at [date]

Text ui/Authentication

Bokmål
Fra oktober 2023 er det ikke lenger mulig å logge inn med Altinn kodebrev, SMS kode eller Kun passord . Les mer om andre måter du kan logge inn på her.

Nynorsk
Frå oktober 2023 er det ikkje lengre mogeleg å logge inn med Altinn kodebrev, SMS kode eller Kun passord. Les meir om andre måtar du kan logg inn på her.

Engelsk
From October 2023, it will no longer be possible to log in with Altinn code lette,r SMS or passwords. Read more about other ways you can log in here.

Text Alternativ innlogging i Altinn

Bokmål
Fra oktober 2023 er det ikke lenger mulig å logge inn med sms, passord, virksomhetssertifikat eller koder fra kodebrev. Vi anbefaler at du bruker MinID eller annen innloggingsmetode på ID-porten.
 
Dette gjelder ikke maskin til maskin-kommunikasjon. Der vil det fortsatt være mulig å logge inn med virksomhetssertifikat. Det vil også være mulig å logge inn med sms, passord og koder fra kodebrev frem til de forskjellige Altinn 2 programmeringsgrensesnittene fases ut.

For test anbefaler vi å bruke testbrukere fra Tenor

Nynorsk
Frå oktober 2023 er det ikkje lengre mogeleg å logge inn med sms, passord, virksomheitsertifikat eller koder frå kodebrev. Vi anbefalar at du bruker MinID eller annan innloggingsmetode på ID-porten.

Dette gjeld ikkje maskin til maskin-kommunikasjon. Der vil det framleis vere mogeleg å logge inn med virksomheitssertifikat. Det vil også vere mogeleg å logge inn med sms, passord og koder frå kodebrev fram til dei ulike Altinn 2 programmeringsgrensesnitta vert fasa ut.

For test anbefaller me å bruke testbrukarar frå Tenor

Engelsk
From October 2023, it will no longer be possible to log in with SMS, password, business certificate or codes from code letters. We recommend that you use MinID or another login method through ID-porten.

This does not apply to machine-to-machine communication where it will still be possible to log in with a business certificate. It will also be possible to log in with SMS, passwords and codes from code letters until the various Altinn 2 APIs are phased out.

For testing, we recommend using test users from Tenor

Description

We need to create release notes for jwtcookie package

Additional Information

Learn from app-lib-dotnet

Tasks

No response

Acceptance Criterias

No response

Description

Currently, our OIDC implementation does not support PKCE

This will be required from ID-porten
https://docs.digdir.no/oidc_func_pkce.html

Considerations

Ops requirements

Acceptance criteria

• For each OIDC provider we need to be able to enable PKCE and validate the requeste

Specification tasks

• Development tasks are defined

Development tasks

Test

Definition of done

• Documentation (docs.altinn.studio) is updated (if relevant)
  • Technical documentation
  • User documentation
• QA
• Manual test is complete (if relevant)
• Automated test is implemented (if relevant)
• All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

Beskrivelse

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

Noen av de tilgjengelige muligheten forsvinner med Altinn 2.

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

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

Mål

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

Begrepsoversikt

I dette dokumentet brukes følgende begreper.

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

Typer sluttbrukersystemer

Skybasert sluttbrukersystem med sluttbrukerpålogging via ID-porten

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

Eksempler på slike system er

• Fiken
• Visma
• Poweroffice

Hvem autentiseres

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

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

Hvem autoriseres?

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

Hvilken trust er det til systemet?

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

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

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

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

Skjermbildet viser når sluttbruker må godkjenne scopes.

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

Pro/cons

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

Lokal installert sluttbrukersystem med sluttbrukerpålogging via ID-porten

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

Skybasert sluttbrukersystem med maskin til maskinpålogging via maskinporten

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

Eksempel på aktuelle leverandører

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

Hvem autentiseres

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

Hvem autoriseres?

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

Hvilken trust er det til systemet

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

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

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

Onboarding process

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

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

Tekniske flyter

Onboarding med systemleverandør

"Onboarding" eget system

Token pålogging tynt token

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

JWT GRANT

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

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

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

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

Tykt token

Nødvendige avklaringer

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

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

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

Mobilapp

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

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

Person AS eksempler

Ragnar - Frilans IT-konsulent

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

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

• Registrerer OAUTH client i maskinporten for sitt enkeltmannsforetak

• Oppretter systembruker for sitt enkeltmannsforetak.

• Delegerer rettigheter til systembruker for innsending av MVA

Kari - Økonomiansvarlig for Storkjøkken AS

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

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

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

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

Trine - Kundeansvarlig Revisor AS

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

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

Truls - Nerd med vaskehjelp

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

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

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

Oppsummert system scenarioer

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

Avklaringer

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

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

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

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

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

Navngi "data-entitet"

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

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

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

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

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

Dette registeret vil innholde minimum en liste over system med

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

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

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

Hvem skal kunne registrere system i registeret?

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

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

Skal tjenesteeiere godkjenne hvilke rettigheter et system kan forespørre

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

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

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

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

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

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

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

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

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

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

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

Hvilke parametere kreves ved autentisering mot Maskinporten

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

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

Data entiteter og definisjoner

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

Registrering av system i systemregisteret

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

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

Registrering av systembruker

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

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

Det kan kun knyttes en systembruker pr systemtype

Fullmaktsgrupper (roller) til systembruker

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

Via klientdelegering vil hjelper kunne delegere fullmaktsgrupper

Rettigheter gitt til systembruker

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

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

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

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

Skjermbilder Altinn

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

Samtykke basert registrering av systembruker

Manuell opprettelse og administrasjon av systembrukere fra Altinn Profil

Utviklingsoppgaver

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

Description

We would like to be able to pre populate the username for uidp-login. From what we understand there is supposed to be a parameter part of the oidc specification (login_hint?) where we can provide the username. Uidp will on their side use this value to auto-fill the username.

Additional Information

No response

Description

We want to move to a model where Altinn 2 works as an OIDC provider for Altinn 3. This will ensure a standard way to log in to the user. Today we have a custom integration between Altinn 2 and Altinn 3 with the use of an asp.net authentication cookie

This is a showstopper for easy use of the platform and causes issues for the test environment since cookies need to be shared across Altinn 2 and Altinn 3.

Considerations

This implementation should try to use current authentication integration and just make a new endpoint in MVC portal that handles the OIDC functionality. See flows below

Sequence flow user access app without being authenticated

Sequence flow when the user is already logged in to Altinn 2 when accessing Altinn 3 app

The authorization code should be a JWT token containing all information needed to create a id_token. It needs to be created in a way so it cant be used as a token for other.

Acceptance criteria

• Altinn 2 OIDC provider needs to follow OIDC protocol
• Altinn 2 performs client validation so only configured Altinn 3 can use it.
• Redirect UI is validated
• Well known endpoint is exposed
• Code can not be used as token in Altinn 3
• id_token from Altinn 2 contains all needed claims like userid, partyid, authenticaitonmethod, authenticationlevel
• Single logout supported
• Single login across Altinn 2 and Altinn 3.

Specification tasks

• Development tasks are defined

Development tasks

• Create authorization endpoint in Altinn 2 for OIDC
• Create well known endpoint
• Create token endpoint where clientID, client secret is validation

Test

Add test cases here as checkboxes that are being tested as part of the changes.

Definition of done

Verify that this issue meets DoD (Only for project members) before closing.

• Documentation is updated (if relevant)
  • Technical documentation (docs.altinn.studio)
  • User documentation (altinn.github.io/docs)
• QA
• Manual test is complete (if relevant)
• Automated test is implemented (if relevant)
• All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

Description

App owners testing i TT02 report of 401 response when exchanging ID-porten tokens using endpoint https://platform.tt02.altinn.no/authentication/api/v1/exchange/id-porten.

Exchange failed 26.04, team picked up issue and re-tested 28.04 exchange was then successful.

Test users in question 01045002485, 01045100061

To Reproduce

After first manual login in portal through browser, exchange starts working.
Might be a question of lacking documentation explaning that this is a requirement for new test users.

Expected behavior

Behavior should be consistent
If fault does not lie in Altinn, root cause should be determined.

Cause / Resolution

• Should be tested if the user being locked from login in Altinn is a cause of 401 response.

Assumption: token exchange for user is locked until first login in portal.

Additional information

Operation ID for failed request 45d25bb57b0a18068cd36c557c22d1e9

Description

Today we uses a cookie to share identity between Altinn 2.0 og Altinn 3.0.

This is not a standardized option and not reusable for others that want to use the Altinn 3 platform.

We should change so that Altinn 2 works as a ID-provider using OIDC and change Altinn 3 authentication to only support OIDC providers, not using ASPXAuth cookies to share identity between platforms.

It would also make it possible to use ID-porten directly without Altinn 2.

Considerations

This change would require changes in Altinn 2 to work as an OIDC ID provider.

This ID provider needs to work as any other ID provider following the standard when it comes to exchanging information with the clients (EG Authentication component in Altinn 3).

The default implementation strategy should be that we implement what is required from ID-porten for the Altinn 2 side and have full OIDCS support on the client-side.

Note ID porten will do changes in 2022. We need to implement those now.

• Changes needed in Altinn 2
• Single logout.

Acceptance criteria

• Altinn 3 uses OIDC to authenticate the user from Altinn 2 with code flow should be used
• Both Altinn 3 and Altinn 2 implements OIDC as the standard defines
• It should be possible to define which client environments are supported by an Altinn 2 environment
• Altinn 2 uses it own certificate
• The mode should be configurable. (OIDCS or FormsAuthentication)

Specification tasks

• Define all parameters required by the authentication service

• Define and analyze what parameters that need to be supported for ID-porten on the client-side in addition.

• Test design / decide test need

Development tasks

• Update authentication component to request ID token from Altinn 2
• Create OIDC server endpoint in Altinn 2
• Create test server to be used for testing and reference implementation
• Create tokenEndpoint on bridge

Definition of done

Verify that this issue meets DoD (Only for project members) before closing.

• Documentation is updated (if relevant)
  • Technical documentation (docs.altinn.studio)
  • User documentation (altinn.github.io/docs)
• QA
• Manual test is complete (if relevant)
• Automated test is implemented (if relevant)
• All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

Description

From October we will disable the ability to authenticate in the Altinn Portal with Virskomhetssertifikat user.
The authentication method will still work for APIs.

Varslingstekst

Bokmål
Fra oktober 2023 er det ikke lenger mulig å logge inn med virksomhetssertifikat i portalen. Les mer om andre måter du kan logge inn på her.

Nynorsk
Frå oktober 2023 er det ikkje lengre mogeleg å logge virksomhetssertifikat i portalen. Les meir om andre måtar du kan logg inn på her.

Engelsk
From October 2023, it will no longer be possible to log in with a business certificate in the portal. Read more about other ways you can log in here.

Overordnet beskrivelse

Virksomhetsbruker er en løsning vi fremover ønsker å videreutvikle og rendyrke for maskin-til-maskin kommunikasjon.

Virksomhetsbrukerens formål er å gjøre det mulig for en virksomhet med flere integrasjoner å styre rettigheter for det enkelte system og leverandør. Dette bidrar til at personer og virksomheter slipper å dele f.eks. brukernavn/passord med systemleverandører og gjør det lettere å fjerne rettigheter. Videre vil løsningen også gjøre det lettere for tjenestetilbyder å ettergå hvem en tjenesteleverandør opptrer på vegne av

Overordnet beskrivelse av løsning

Behov for en løsning som gjør det mulig å opprette en "bruker" som gjør det mulig å delegere rettigheter fra en virksomhet til en annen.
Brukeren skal rendyrkes for bruk mot API (Maskin-maskin) og skal ikke være mulig å logge på med via portal.

Denne er noe uklar foreløpig da det ikke er 100% avklart hvor ting skal løse.

Det etableres en mulighet å definere systembrukere i Altinn som er knyttet mot en spesifikk OIDC integrasjon i Maskinporten.
Hvordan dette i praksis skal skje er usikkert, men Maskinporten må ha oversikten, eller kalle Altinn for å få ID på systembrukeren.

Systembrukeren kan delegeres til andre organisasjoner slik at de med en valgt OIDC integrasjon kan kalle som maskinport brukeren.

I Altinn trenger vi ny GUI med oversikt over maskinporten baserte systembrukere.
Vi trenger å kunne autorisere at systembrukere får tilgang til ressurser i og utenfor Altinn.

Status

Analyse er startet gjennom dialogporten og opp mot maskinporten, men fremdeles ikke landet hva/hvordan virksomhetsbruker skal være

Estimat/Omfang

Spørsmål

Fremdels mye uklart i forhold til hva denne b"brukeren" skal være. Mye av behovene hentes inn i arbeidet med Dialogporten og API i økosystem

Description

We need to build an API to support the administration of system users for organizations. The concept was analyzed in #200 and defined in #331

Organizations can choose to create, update, and soft delete system users.
In the future, this might be expanded to citizens.

These issues cover the API in Altinn Authentication to support this feature. The Persistence layer and the physical database is covered in #361

#329 covers the system register. System_Type is a foreign key to System

The BFF will consume this API from Altinn/altinn-authentication-frontend#23

Tasks

We need an API that can do CRUD operations on system identities.

• Create new controller

• Finalize system user model (attributes!!!!)

• Create API to create SystemUser

• Create API to update SystemUser

• Create API to delete SystemUser (soft delete)

• Create API to list systems users for party

• Define Persistance Interface

• Implement Persistance Mock

• Create needed mock data for tests

• Create unit tests covering the API methods. Needs to cover authorization. (PDP Mock can be copied from Access management)

• Configure authentication & authorization for API

• Update APIM with API (products?)

• #369

• #445

• Documenation updated: https://docs.altinn.studio/authorization/architecture/authorizationbff.drawio.svg
  SystemUserObject stored in database

• #595

• #607

{
"id" : "37ce1792-3b35-4d50-a07d-636017aa7dbd",
"title": "Nytt regnskapsystem",
"description": "Systemet som vi har kjøpt hos Visma. Kai og Guri vet alt om dette systemet.",
"systemType": "visma_tax",
"ownedByParty": 234654,
"created": "2023-01-01",
"isDeleted": false
}

Acceptance criteria

• An organization can only have one systemuser connected to a specific systemType
• Only systems admin for org is allowed to perform CRUD operations
• Deleted system users are not listed in list

Dette behovet er en del av satningsforslaget "Bevilgningsbehov representasjon og fullmakter" levert for 2024.
Behovet er også knyttet til FUFINN - "Fullmaktsløsning for innbyggere"

Se også #218

Description

ACR values is changed

We need to identify if we support this. This is new values for requesting a specific authentication level

1. In Altinn implementation

https://docs.digdir.no/docs/idporten/oidc/oidc_guide_english

2. In Altinn 3 Implementation

Additional Information

Tasks

No response

Acceptance Criterias

No response

Description of the bug

Looking at the logs it seems like every single call to the exchange endpoint also produce a request to the well-known endpoint for the given provider. Any caching built into ConfigurationManager is circumvented by instantiating a new configuration manager for every request.

Steps To Reproduce

1. Open Application Insights for platform in production.
2. Open the Server Requests / Performance graphs
3. Filter operations by entering "exchange" in the search box.
4. Select "GET Authentication/ExchangeExternalSystemToken [tokenProvider]"
5. Click the "Drill into" Samples button.
6. Use the window to navigate between different requests and observe that all of them also include the configuration lookup.

Additional Information

The default refresh internval is only 5 minutes, but I've seen requests closer in time than 5 minutes still produce new configuration requests.

I'm not worried about this issue as such. The respons time on the exchange endpoint is still very good as far as I can see.

I have not observed the same issue with JWTCookieAuthentication. The number of requests against our own .well-known endpoint in Authentication is significantly lower. In one hour in production there is 160 calls for the JWKS. The code producing the call to the provider configuration is almost identical so I'm not sure where the difference lies. Maybe the log data is tricking me.

I've been tricked!! We have the same issue in JWTCookieAuthentication if using an external provider. Only our own default use of ConfigurationManager is doing it correctly. In the original implementation we use the ConfigurationManager stored on the Options object. This is what enables caching of our own provider settings in all apps using default provider coded in by the app template.

Description

Today it is not possible to exchange id-porten tokens if user does not have a profile.

Additional Information

Tasks

• Consider if we can legally create a user
• Add auto creation

Acceptance Criterias

No response

• Gjør accordions på Page S3 hvite som de er i på S2
• Hvorfor står ikke bedriftsnavn-string under API-navn-string i accordion på side s2
• Hvorfor er avbryt-knappen en link?
• Filtrer-knapp må byttes ut med multiselect (i første omgang).
• Fjerne Mottatte API fra arbeidsflyten.

Overordnet beskrivelse

 Delta I konseptarbeidet for Dialogporten for å påse at autentisering passer inn i konseptene som kommer opp
 

Overordnet beskrivelse av løsning

Det er ikke helt fastsatt hvilken løsning man skal gå for her.

I den ene løsningen vil Maskinporten spørre Altinn om rettighetene på en gitt ressurs slik at resultatet kan bakes inn i token.

Dagens API kan potensielt brukes til dette, men må analyseres videre

Estimat/Omfang 

Spørsmål

Description

This is the part where we change the cookie name in Altinn Authentication

Altinn/altinn-studio#5725 was first part

Considerations

All apps needs to be updated to check for new cookie name

Acceptance criteria

Describe criteria here (i.e. What is allowed/not allowed (negative tesing), validations, error messages and warnings etc.)

Specification tasks

• Development tasks are defined

Development tasks

• Verify that all apps are updated
• Change code in Altinn.Platform when all apps are updated to generate .ALTINNTOKEN cookie

Test

Add test cases here as checkboxes that are being tested as part of the changes.

Definition of done

Verify that this issue meets DoD (Only for project members) before closing.

• Documentation is updated (if relevant)
  • Technical documentation (docs.altinn.studio)
  • User documentation (altinn.github.io/docs)
• QA
• Manual test is complete (if relevant)
• Automated test is implemented (if relevant)
• All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

Description

Move source code from altinn-studio repository

https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository

Must merge directly into main to keep history, pr with squash all commits

Acceptance criteria

Source code is deleted from Altinn-studio repository

Development tasks

• Move source code to new repository
  • Follow the instructions here: https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository

$ git filter-repo --path src/altinn-platform/altinn-authentication

• REMBER TO CHANGE from MASTER to MAIN on new clone before pushing
  - Move code to root
  - Work on a branch that is not main in order to create a PR with the changes.
  - Do NOT merge the PR, once approved, rather merge directly into main to keep commit history
• Restructure repository
• Set up new SonarCloud project
• Move relevant pipelines to GitHub actions
  • CodeQL (Replaces LGTM)
  • Test & analysis for internal
  • Test & analysis for fork PR
• QA
• Update all remaining pipelines in AzDo to go towards the new repository
  • Disable and delete profile-pull-request pipeline
  • Disable and delete analysis pipeline
  • Change repository for authentication-master pipeline. Update path for dockerfile and build context.
  • Update release pipeline, trigger of K6 test should not use same source branch. For all task (environments)
• Set up README.md for new repository
• Delete source code from altinn-studio repository.
• Delete outdated sonarcloud project

Test

• Regression test build/deploy/analysis of compontent

Overordnet beskrivelse

Dagens ID-porten pålogging på Altinn II- plattformen skjer via SAML støtten i ID-porten. Dette er en gammel standard som skal fjernes fra ID-porten. Altinn2 må derfor migreres til å benytte OIDC, som er standarden som støttes videre i ID-porten

Overordnet beskrivelse av løsning

Gå over fra SAML passert autentisering til OIDC for Altinn2.
Må gjennomføres før SAML skrues av i gammelt importen miljø 26. september

Etablere OIDC endepunkt i Altinn 2 for å fungere som OIDC Klient.
Krever integrasjon med dagenssesjonsdatabase
Støtte for global utlogging

Status

Løsningen ble prodsatt 19.04. Gjenstår noe etterarbeid etter prodsetting

Estimat/Omfang

Spørsmål

Week 45

Deploy @lovoll

• Authentication Production (Tuesday)
• Authorization Production (Tuesday)
• Deploy APIM to prod (Tuesday)
• Authentication TT02 (Wednesday)
• Authorization TT02 (Wednesday)
  • Deploy APIM to TT02 (Wednesday)
• Test (All automated tests green)

Patching

Includes patching of project dependencies (.NET, Maven), containers, and Github Actions

• Authentication
• Authorization
• Access Managment
• Resource Registry

Week 46

Deploy @ivartryti

• Authentication Production (Tuesday)
• Authorization Production (Tuesday)
• Deploy APIM to prod (Tuesday)
• Authentication TT02 (Wednesday)
• Authorization TT02 (Wednesday)
  • Deploy APIM to TT02 (Wednesday)
• Test (All automated tests green)

Patching

Includes patching of project dependencies (.NET, Maven), containers, and Github Actions

• Authentication
• Authorization
• Access Managment
• Resource Registry

Week 27

Deploy @acn-dgopa

• Authentication Production (Tuesday) (nothing to deploy since 25. June)

  • Deploy APIM to prod (Tuesday) (nothing to deploy since 25. June)

• Authorization Production (Tuesday)

  • Deploy APIM to prod (Tuesday) (nothing to deploy)

• Delegation Events to prod(Tuesday) (nothing to deploy since 5. May)

• Resource Registry Production (Tuesday)

  • Deploy APIM to prod (Tuesday)

• Authentication TT02 (Wednesday) (nothing to deploy)

  • Deploy APIM to TT02 (wednesday) (nothing to deploy)

• Authorization TT02 (Wednesday)

  • Deploy APIM to TT02 (Wednesday) (nothing to deploy)

• Delegation Events to TT02 (Wednesday) (nothing to deploy)

• Test (All automated tests green)

Deploy AccessManagement (TT02 - Wednesday, Prod - Tuesday)

The access management has to de deployed in the following order

• Deploy access management platform component
• Deploy access managment to api managment if relevant (nothing to deploy)
• Deploy access managment ui application

Patching (Thursday) @acn-dgopa

Includes patching of project dependencies (.NET, Maven), containers (Dockerfile, Will be opened by dependabot/renovate), and Github Actions

• Authentication
• Authorization
• Access Managment
• Resource Registry
• Access Management Frontend (Frontend patches were created by renovate. Assigned the frontend team to review it as some of the frontend tests failed)

Week 29

Deploy Cancelled

• Authentication Production (Tuesday)

  • Deploy APIM to prod (Tuesday)

• Authorization Production (Tuesday)

  • Deploy APIM to prod (Tuesday)

• Delegation Events to prod(Tuesday)

• Resource Registry Production (Tuesday)

  • Deploy APIM to prod (Tuesday)

• Authentication TT02 (Wednesday)

  • Deploy APIM to TT02 (wednesday)

• Authorization TT02 (Wednesday)

  • Deploy APIM to TT02 (Wednesday)

• Delegation Events to TT02 (Wednesday)

• Test (All automated tests green)

Deploy AccessManagement (TT02 - Wednesday, Prod - Tuesday)

The access management has to de deployed in the following order

• Deploy access management platform component
• Deploy access managment to api managment if relevant
• Deploy access managment ui application

Patching (Thursday) Cancelled

Includes patching of project dependencies (.NET, Maven), containers (Dockerfile, Will be opened by dependabot/renovate), and Github Actions

• Authentication (no patching pull requests)
• Authorization
• Access Managment
• Resource Registry (no patching pull requests)
• Access Management Frontend

Overordnet beskrivelse

Bruk av SystemID slik det gjøres i dag skal avvikles siden det har lav sikkerhet og dårlig tilgangskontroll
 

Overordnet beskrivelse av løsning

Et datasystem (SystemID + passord) er en form for systembruker med vide fullmakter for innsending. Systembruker forholder seg ikke til sikkerhetsnivå på tjenester eller delegeringer. I praksis får SystemID automatisk "alle rapporteringsrettigheter for alle mine angivere" når den opprettes
Brukes bare i SOAP

Estimat/Omfang  

Spørsmål

Det må lages en plan for hvordan SOAP skal fases ut (ev bytte ut systemID pålogging) for det fases ut

See TFS for more information https://dev.azure.com/digdir/Altinn/Altinn/_workitems/edit/48656