Need to handle authorization of app events published by Dialogporten, GET API

[SandGrainOne]

Description of the bug

This issue appear as a copy of issue; #930, but the fix we made didn't cover the GET API.

The algorithm that takes traditional app events where resource starts with urn:altinn:resource:app_ and uses the source value to construct an authorization request, is very limited and fails when the event source points to the Dialogporten API instead of the App API.

Using the current implementation for dialogporten events causes the PDP auth service to return a syntax error and the 'indetermine' status. See the original bug issue: #913

Create a valid authorization request for these types of events by using other fields, omitting the instanceid as part of the request, because it cannot be extracted from the event data.

Steps To Reproduce

Look at the event in the original incident issue above and run it through the PDP mock or port forward to an authorization service running in AKS. If you serialize the XACML request object you will see that "enduser" is an invalid value because the source field has been split incorrectly.
The response contains no Category information, so the consumer cannot be extracted from the multi decision response.

Additional Information

An event published by an app:

{
  "id": "b81d64d4-1c6b-4ec5-9293-5b25e280abde",
  "time": "2026-04-01T00:16:26.2531775Z",
  "type": "app.instance.created",
  "source": "https://ttd.apps.tt02.altinn.no/ttd/apps-test/instances/50055202/29ca3e07-d09f-471c-a565-0889b74f3f25",
  "subject": "/party/50055202",
  "alternativesubject": "/person/15036202391"
  "specversion": "1.0",
}

Both resource and resourceinstance is missing when the event is published by an app. Key values are instead extracted from the source field. This is the part that is failing if the event was published by dialogporten.

An app event published by dialogporten:

{
  "id": "fb3fa34c-305d-4281-a5e1-ab95198f34b5",
  "time": "2026-04-01T00:16:23.3987205Z",
  "type": "dialogporten.dialog.updated.v1",
  "source": "https://platform.tt02.altinn.no/dialogporten/api/v1/enduser/dialogs/019d4665-e739-7c1a-84ca-9df248032097",
  "subject": "urn:altinn:person:identifier-no:15036202391",
  "resource": "urn:altinn:resource:app_ttd_apps-test",
  "specversion": "1.0",
  "resourceinstance": "019d4665-e739-7c1a-84ca-9df248032097"
}

Here we have resource and resourceinstance. Resource is correct, but resourceinstance is pointing to a dialog and not the app instance. The source value is a link for the dialog instead of a link to the related app instance. Authorizing access to the event based on the dialogid isn't going to be possible. We would need to perform authorization without instance.

"Resource subject" will be either

• App produced event: /party/{instanceownerpartyId}
• Dialogporten produced event: urn:altinn:*

Both are supported by the extension method: XacmlMapperHelper.AddSubjectAttribute(). Authorization can do the lookup to find the party id if they need it.

We will need to treat these two cases slightly differently. We can separate them with the content of source or the content of type. Possible candidates include subject and alternativesubject. I lean towards using the type.

Summary of changes

1. Making App events available on the GET /events/api/v1/events endpoint. This is done by using the read action instead of subscribe as well as adding the special appresource events.