Consolidate "seenBy", "performedBy" and "sender" properties to common model

[elsand]

Introduction

There is a need for the serviceOwner to supply information about who did what (perform an activity, send a transmission), which matches that of seen log.

Implementation

We create a common entity for this that includes

• The type of actor associated with this activity/transmission. This is either 1) someone representing the party (ie. a person, system user, an accountant organization etc) or 2) the service owner. At some point in the future other actor types might be introduced (for instance if there are other government actors involved).
  • Enum with the values
    • partyRepresentative
    • serviceOwner
• The natural id for the actor (fnr/dnr/orgnr/system-id etc)
• The resolved name for the actor (Ola Nordmann, Foretak AS)

We need different DTOs for this

• We probably cannot expose PIDs in the enduser-DTOs, but organization numbers are ok
• We instead rewrite PIDs to a hash , generated on the fly for end-user output DTOs

The input validation should:

• Always require actorType
• Require either actorId or actorName, or none of them.
  • If actorId is supplied, actorName should be looked up and stored. If this fails, the entire POST/PUT/PATCH request should fail.
  • If actorName is supplied actorId should be stored as NULL,
  • If neither is supplied:
    • If "actorType" is "serviceOwner", then both id and name is then stored as null. Consumers of the output-DTOs should then assume the "org" of the dialog to be the actorName
    • If "actorType" is "partyRepresentative", then the actorId and resolved name for the dialog party is to be used.

Examples:

In these examples, we see how different inputs DTO from service owners end up as output DTOs.

Inputs

A: ServiceOwner-DTO (input, person representing party):

{
    "actorType": "partyRepresentative", 
    "actorId": "urn:altinn:person:identifier-no:12345678901" 
}

B: ServiceOwner-DTO (input, organization representing party):

{
    "actorType": "partyRepresentative", 
    "actorId": "urn:altinn:organization:identifier-no:912345679"
}

C: ServiceOwner-DTO (input, custom name):

{
    "actorType": "partyRepresentative", 
    "actorName": "Some custom name"
}

D: ServiceOwner-DTO (input, service owner):

{
    "actorType": "serviceOwner" // actorName and actorId must be omitted
}

E: ServiceOwner-DTO (input, for the dialog party):

{
    "actorType": "partyRepresentative" // This should be interpreted as dialog.party
}

X: ServiceOwner-DTO (input, trying to provide both actorId and actorName):

// Below is invalid - cannot supply both actorId and actorName as they might conflict
// This should cause a 400 error
{
    "actorType": "partyRepresentative", 
    "actorId": "urn:altinn:organization:identifier-no:912345679"
    "actorName": "Some custom name"
}

Serviceowner-DTO outputs

A: ServiceOwner-DTO (output, person representing party):

{
    "actorType": "partyRepresentative",
    "actorId": "urn:altinn:person:identifier-no:12345678901", // service owners always gets access to clear text version
    "actorName": "Ola Nordmann" // the resolved name that Dialogporten looked 
}

B: ServiceOwner-DTO (output, organization representing party):

{
    "actorType": "partyRepresentative",
    "actorId": "urn:altinn:organization:identifier-no:912345678",
    "actorName": "Foretak AS" // the resolved name 
}

C: ServiceOwner-DTO (output, custom name):

{
    "actorType": "partyRepresentative", 
    "actorName": "Some custom name"
}

D: ServiceOwner-DTO (output, service owner):

{
    "actorType": "serviceOwner"
}

E: ServiceOwner-DTO (out, for the dialog party):

{
    "actorType": "partyRepresentative" 
}

Enduser-DTOs

A: Enduser-DTO (output, person representing party)

{
    "actorType": "user",
    "actorName": "Ola Nordmann",
    "actorId": "urn:altinn:person:identifier-ephemeral:0676ad6bdf" // hashed version
}

B: Enduser-DTO (output, organization representing party)

{
    "actorType": "partyRepresentative",
    "actorName": "Foretak AS",
    "actorId": "urn:altinn:organization:identifier-no:912345678"
}

C: Enduser-DTO (output, custom name):

{
    "actorType": "partyRepresentative", 
    "actorName": "Some custom name"
}

D: Enduser-DTO (output, service owner):

{
    "actorType": "serviceOwner"
}

E: Enduser-DTO (out, for the dialog party):

{
    "actorType": "partyRepresentative" 
}

Summarized:

• C, D, and E are identical across all DTOs.
• A and B have different input and output DTOs - in the output DTOs both actorName and actorId (if available) should be sent.
• For the output DTOs, only A differs between service owner and end-user

Tasks

Preview Give feedback

1. Implement as described above
2. Prepare documentation (if relevant - either update working document, or add a new file in docs)
3. Add e2e-test (if relevant)

Threat modelling

Preview Give feedback

1. The identifier hash should be non-stable, ie. not be the same across either application lifetimes (ie. restarts and/or replicas), as this will allow for user identification
2. We are storing PIDs here as well as resolved names. This is presumed to be acceptable as there is a need for secure identification for notority reasons.
3. We are exposing end user names (full names). This is PII.

Acceptance criteria

GIVEN ...
WHEN ....
THEN ...

GIVEN ...
WHEN ....
THEN ...

[oskogstad]

@elsand IsCurrentEndUser is missing from the new model, I assume it is still needed?

[elsand]

@elsand IsCurrentEndUser is missing from the new model, I assume it is still needed?

No, that belongs to the Seen class, not the Actor class. The same goes for the "via serviceowner" part, which initially was part of the actorType-enum - also confusing things. I have now simplified the actorType enum to have two values partyRepresentative and serviceOwner, which are the two principal actor types in a dialog. This is not to be conflated with user types.