Publiserte eventer blir tilsynelatende ikke tilgjengeliggjort via HTTP GET

[MagnusSandgren]

Description of the bug

Når jeg publiserer et event via POST https://platform.tt02.altinn.no/events/api/v1/events for ressursen urn:altinn:resource:super-simple-service forventer jeg å finne tilbake til det via GET https://platform.tt02.altinn.no/events/api/v1/events?after=2025&resource=urn:altinn:resource:super-simple-service. Jeg forventer også å få det via registrert webhook subscription.

Subscription er livløs og responsen fra GET kallet er tomt.

Steps To Reproduce

1. Opprett subscription via POST https://platform.tt02.altinn.no/events/api/v1/subscriptions med følgende body:

{
  "endpoint": "{{WEBHOOK_URL_HERE}}",
  "resourceFilter": "urn:altinn:resource:super-simple-service"
}

2. Send POST https://platform.tt02.altinn.no/events/api/v1/events med følgende body (får 200 ok tilbake):

{
  "id": "8bc189c1-210a-49f9-9107-2e6497dc30a8",
  "source": "https://dialogporten.no/api/v1/dialogs/1e038d0f-7738-4a51-b9f8-b44b2fca94ee",
  "specversion": "1.0",
  "type": "dialogporten.dialog.created.v1",
  "alternativesubject": "/org/991825827",
  "time": "2025-01-31T10:21:17.079Z",
  "resource": "urn:altinn:resource:super-simple-service",
  "data": {
      "foo": "bar6"
  }
}

3. Observer at ingen eventer kommer til webhooken
4. Observer tom liste respons fra GET https://platform.tt02.altinn.no/events/api/v1/events?after=2025&resource=urn:altinn:resource:super-simple-service

Additional Information

No response

[MagnusSandgren]

Etter noe testing med @elsand ser vi at vi får tilbake eventer via subscriptions. Vi fikk fremdeles ikke noe tilbake fra selve get endepunktet i apiet.

[SandGrainOne]

Kan dere gi oss litt flere detaljer om hva slags claims dere har i token som utfører disse kallene. Vi trenger litt flere detaljer en "jeg" ;)

[SandGrainOne]

@MagnusSandgren

Har klart å gjennskape problemet, samt identifisert de mer direkte grunnene til feil.

Når Events genererer en autorisasjonsforespørsel bruker vi informasjon fra eventen(e). En av disse er innholdet i subject feltet. I eventene fra dialogporten har subject en verdi av typen: urn:altinn:person:identifier-no:08895699684 Dette er det ikke støtte for i autorisasjon så Events får "syntax-error" i retur. Autorisasjon har altså ikke støtte for resource attribute id urn:altinn:person:identifier-no. Litt usikker på hva riktig fiks for dette er.

Den neste tingen som gir syntax-error er resource attribute id: urn:altinn:resourceinstance. Her har Events koden benyttet en konstant definert i PEP pakken, men det er mulig vi har benyttet feil konstant. Riktig verdi skal være urn:altinn:resource:instance-id. Dette kan vi rette på i Events.

[SandGrainOne]

Korrigeringer fra forrige melding:
Attribute id urn:altinn:resourceinstance skaper ingen problemer i seg selv, men verdien blir ignorert da Autorisasjon ikke kjenner id'en. Vi venter på en oppdatert PEP mer riktig id.

Attribute id urn:altinn:person:identifier-no kan ikke brukes. En ide er at Events mapper det over til en party id får autorisasjonsrequesten sendes til autorisasjon. Det vil si at Events må gjøre et register oppslag for å finne riktig party id for angitt person. Antall slike oppslag kan reduseres noe ved å ikke inkludere subject når den aktive brukeren er en tjenesteeier.

[SandGrainOne]

@elsand, @MagnusSandgren Er det mulig for dialogporten å angi party id i subject i stedet for personnummer?

[MagnusSandgren]

Kan dere gi oss litt flere detaljer om hva slags claims dere har i token som utfører disse kallene. Vi trenger litt flere detaljer en "jeg" ;)

Sorry, neste gang skal jeg gi mer informasjon enn "jeg" 😅

Antall slike (partyId) oppslag kan reduseres noe ved å ikke inkludere subject når den aktive brukeren er en tjenesteeier.

Event.Subject blir satt fra Dialog.Party - altså hvem dialogen er "til". Tror det tilhører edge-case at tjenesteeier x sender til seg selv, så tror at det ikke er mye å hente her. I de tilfeller tjenesteeier x sender til tjenesteeier y mener jeg også at vi trenger y i subject.

Er det mulig for dialogporten å angi party id i subject i stedet for personnummer?

Dialogporten har ingen forhold til PartyId / UserId. Det kan være et alternativ å slå opp for oss. Vet ikke hva du tenker @elsand? 🤔

[MagnusSandgren]

Trykket feil @SandGrainOne Kan du åpne igjen?

[elsand]

Jeg anser det som uaktuelt å gjøre oppslag i Dialogporten for å veksle fnr en eller annen intern id - det er åpenbart autorisasjon sitt ansvar. Autorisasjon har støtte for fnr gjennom altinn:person:identifier-no, ellers hadde ikke Dialogporten fungert i det hele tatt.

Skal events ha noen som helst relevans utover altinn apps-produserte events, må det være mulig for en produsent å oppgi et subject som ikke benyttet seg av en altinn-intern id.

Så her er det noe events gjør feil. Man er jo tydeligvis i stand til å foreta en autorisasjon av eventet ifm push til subscriptions, da burde det være mulig for get-APIet også?

[elsand]

#376 introduserte håndtering av urn:altinn:organization:identifier-no og urn:altinn:person:identifier-no, som siden ble refaktorert til AddAttributeFromUrn i b27c782 . Denne kalles også fra AddSubjectAttribute.

Kikket litt på koden, og det er ikke åpenbart for meg hvorfor autorisasjon av push (gjennom AuthorizationService.AuthorizeConsumerForGenericEvent) fungerer, mens uthenting gjennom API (gjennom AuthorizationService.AuthorizeEvents) ikke gjør det. Begge deler går gjennom IPDP.GetDecisionForRequest, som requester authorization/api/v1/Decision. Såvidt jeg erindrer er det bare authorization/api/v1/authorize som støtter fnr som subject/resourceparty? cc @jonkjetiloye