Bakgrunn

Altinn 2 sitt reportees-API er under utfasing og erstattes i Altinn 3 av Access Management API og endepunktet authorizedparties.

Søknadssystemer bør derfor migrere fra:

/api/reportees

til:

/accessmanagement/api/v1/enduser/authorizedparties

Dokumentasjon:
https://docs.altinn.studio/nb/authorization/guides/system-vendor/access-management/#api-hente-autoriserte-parter

Scope-krav

For å bruke endepunktet må Altinn-tokenet inneholde følgende scope:

altinn:accessmanagement/authorizedparties

Scopet må legges til på Maskinporten-/ID-porten-klienten som brukes for autentisering.

Endepunkt

Testmiljø (TT02)

GET https://platform.tt02.altinn.no/accessmanagement/api/v1/enduser/authorizedparties

Produksjon

GET https://platform.altinn.no/accessmanagement/api/v1/enduser/authorizedparties

Filtrering på applikasjon / ressurs

For å hente kun parter som har tilgang til en bestemt applikasjon brukes query-parameteren:

anyOfResourceIds

Eksempel (TT02):

GET https://platform.tt02.altinn.no/accessmanagement/api/v1/enduser/authorizedparties?anyOfResourceIds=app_dibk_nabovarsel-v5

Eksempel (Produksjon):

GET https://platform.altinn.no/accessmanagement/api/v1/enduser/authorizedparties?anyOfResourceIds=app_dibk_nabovarsel-v5

Dette returnerer kun de partene den innloggede brukeren har tilgang til for den angitte ressursen/applikasjonen.

Filtrering på aktive parter

For å utelate slettede/utgåtte virksomheter brukes query-parameteren: includeInactiveParties=false

Eksempel (TT02):

GET https://platform.tt02.altinn.no/accessmanagement/api/v1/enduser/authorizedparties?anyOfResourceIds=app_dibk_nabovarsel-v5&includeInactiveParties=false

Eksempel (Produksjon):

GET https://platform.altinn.no/accessmanagement/api/v1/enduser/authorizedparties?anyOfResourceIds=app_dibk_nabovarsel-v5&includeInactiveParties=false

Dette sørger for at kun aktive virksomheter returneres, slik at brukeren ikke kan velge en slettet virksomhet som avsender.

Tolkning av respons

Brukeren har tilgang

Hvis responsen inneholder ett eller flere elementer i data-listen:

{
  "data": [
    {
      "partyUuid": "7970f658-9519-4213-94e9-6195779e6097",
      "name": "LEGITIM SERVIETT",
      "organizationNumber": null,
      "personId": "63843700170",
      "partyId": 50514069,
      "type": "Person"
    }
  ]
}

betyr dette at brukeren har tilgang til applikasjonen for den aktuelle parten/virksomheten.

Brukeren har ikke tilgang

Hvis data-listen er tom:

{
  "data": []
}

har brukeren ikke tilgang til ressursen.

Merk at tom data[] er forventet respons ved manglende tilgang, og ikke en teknisk feil.

403 Forbidden returneres normalt kun ved:

ugyldig token
manglende scope
feil miljø
manglende tilgang til API-et

Viktig forskjell i Altinn 3

Det at en bruker kan representere en virksomhet betyr ikke nødvendigvis at brukeren har tilgang til en bestemt innsendingstjeneste.

For å sjekke tilgang til en konkret tjeneste/applikasjon må anyOfResourceIds brukes.

Dette erstatter funksjonaliteten som tidligere lå i:

/api/reportees?app=<appnavn>

Mapping fra Altinn 2 til Altinn 3

Altinn 2	Altinn 3

Altinn 2	Altinn 3
`/api/reportees`	`/authorizedparties`
`/api/reportees?app=x`	`/authorizedparties?anyOfResourceIds=x`
`ReporteeId`	`partyId` / `partyUuid`
`Name`	`name`
`OrganizationNumber`	`organizationNumber`
`Type`	`type`
`OrganizationForm`	`unitType`

Resource ID vs appnavn

anyOfResourceIds forventer resource-id fra Altinn Resource Registry, ikke nødvendigvis appnavnet.

Eksempel på resource-id:

app_dibk_nabovarsel-v5

Denne verdien må være registrert som ressurs i Altinn Resource Registry.

Liste over resource-id for de ulike appene er dokumentert her: https://dibk.atlassian.net/wiki/x/AoCl6g

Brukerroller i Altinn3