Closed SandGrainOne closed 2 weeks ago
olebhansen
commented
4 weeks ago Need to know a bit more:
elsand
commented
4 weeks ago This should not conflate the need for a agnostic association id mechanism with the (somewhat future) need to be able to authorize a notification order endpoint owner based on an instance delegation. I assume this issue about the latter.
Regarding the former, the notification component should not have to know anything particular about the nature of the associations the service owner enters into a notification order, but merely define a structured way to define them and to query them later.
I would expect to be able (as a service owner using the notification component) to do something like this:
// POST varsling.altinn.no/api/v1/....
[
// "Main" notification, to be sent immediately
{
"resource": "urn:altinn:resource:ske_tredjepartsopplysninger_boligsameier",
"resourceinstance": "{{some-dialog-guid-here}}",
"party": "urn:altinn:organization:identifier-no:912345678",
// associatedWith used by "Arbeidsflate" and other end-user systemers to find notification orders associated with an arbitrary resource
"associatedWith": [
{ "type": "urn:altinn:dialogporten:dialog-id", "id": "{{some-dialog-guid-here}}" }
{ "type": "urn:altinn:dialogporten:transmission-id", "id": "{{some-transmission-guid-here}}" }
],
"channel": "both",
"content": [ /* .... */ ]
},
// Reminder, to be sent in 7 days in the condition is met
{
"resource": "urn:altinn:resource:ske_tredjepartsopplysninger_boligsameier",
"resourceinstance": "{{some-dialog-guid-here}}",
"party": "urn:altinn:organization:identifier-no:912345678",
"associatedWith": [
{ "type": "urn:altinn:dialogporten:dialog-id", "id": "{{some-dialog-guid-here}}" }
{ "type": "urn:altinn:dialogporten:transmission-id", "id": "{{some-transmission-guid-here}}" }
],
"channel": "both",
"content": [ /* .... */ ],
"delayFor": "+7 days",
// returns something like { "conditionMet": true } based on where
"conditionUrl": "https://dialogporten.no/api/v1/serviceowner/{{some-dialog-guid-here}}activitylog/?condition=notexists&type=transmissionOpened&relatedTransmissionId={{some-transmission-guid-here}}"
}
]With this information, the notification component will have sufficient information to construct a XACML authorization request (based on the authenticated principal claims, resource, resourceinstance and party) to support both resource (ie. app) as well as instance level access (when the PDP gets support for it).
Keeping the association mechanism disconnected from authorization, we enabliethe component to support a structured identifier representing any abstract association in the future - which doesn't necessarily have to do anything with Altinn alltogether (urn:ks:svar-ut:someidhere or whatever).
SandGrainOne
commented
2 weeks ago We've decided not to move forward with this for now. The idea were to give Notifications support for situations where there has been an instance delegation. It's possible to think up situations were it would be nice to have, but we're assuming the cases will be rare.
The most notable case is with reminders. In most cases the notifications will be sent before any instance delegation can have occurred, but reminders is an exception. Reminders can be triggered after some time.
The thing that reduce the need is the fact that the delegation in and of itself will probably stop reminders. It's logical that the person performing the delegation will have read the instance and changed the state in a way that will stop reminders from being sent. Instance delegation will probably also include a notification to the recipient of the rights.
The person receiving the delegation would also need to have contact information registered on the organization.
Description
We need to expand the resource indicator on a notification order to support the id of a specific instance of a resource.
Update external and internal models. Update persistence layer to keep the new data.
Additional Information
No response
Tasks
No response
Acceptance Criterias
No response