Support system user in Storage

[SandGrainOne]

Description

This is a list of tasks and changes that needs to be done before we can say that Storage support system users.

Additional Information

This issue is based on the analysis performed in #471.

Usecase: A system user (representing a user - i.e. sending a party-id) instantiates an instance and populates it with data. E.g. The MVA-report.

Tasks

Authorizaion

• Update to a version of the Altinn.Common.PEP package with support for SystemUser authorization (version later than v4.0.0)
• Update all custom Authorization logic to include system user as AccessSubject in Authorization requests.
  The assumption is that we're mostly using the PEP package and the containing DecisionHelper, but there might be exceptions.

Metadata updates:

• Search for places where the Intance.CreatedBy property is set. Update the logic to use the organization number of the system owner when caller is a system.
• Search for places where the Intance.LastChangedBy property is set. Update the logic to use the organization number of the system owner when caller is a system.
• Search for places where the DataElement.CreatedBy property is set. Update the logic to use the organization number of the system owner when caller is a system.
• Search for places where the DataElement.LastChangedBy property is set. Update the logic to use the organization number of the system owner when caller is a system.
• Expand the PlatformUser class with properties for: SystemUserId (guid), SystemUserOwner (string) and SystemUserName.
• Search for all usage (assignments) of the PlatformUser class and populate the new properties when data is available.
• Update the logic setting the ProcessHistoryItem.PerformedBy property to support an InstanceEvent created with a system user.
• Update IdentityTelemetryFilter to handle system users

Authentication

Not decided yet (optional future improvement):

• Add support for bearer tokens signed by Maskinporten. #509

Testing

Preparation

Testing this will require multiple steps.

1. Find a person with the ability to represent an organization. Preferably the "CEO" (daglig leder). Make node of key data we might need. Like names and ids. There are a few Tenor users we've documented on confluence under Guides.
2. We would then need to create a system user. I have not looked into how this could be done yet. The system user would need to be associated with the organization we've identified previously. It doesn't matter what type of system we use. Keep the data like system id and update the test data table on confluence.
3. Find a working app and instantiate an instance or two with the organization as instance owner. (Or find existing instances).
4. Log in with the organization CEO and delegate at a minimum read access to the system user. I have not looked into how this is done at the moment.
5. Generate a token for the system user using the token generator. There is a new endpoint to do this part. An example:
   api/GetSystemUserToken?env={{Environment}}&scopes=altinn:instances.read&systemUserId=3d7ff126-890c-4e30-953b-4b736c6591ec&systemUserOrg=312508729
6. Run GET requests directly against Storage endpoints using the token as a Bearer token in the Authorization header.

Things to check

1. First of all the GET requests should succeed.
2. Logging of system user id together with request telemetry. Check in Application Insights.

Testing of mutating operations like POST and PUT is even more work and I suggest we postpone that for when we have a working app to test through.

Blockers

Preview Give feedback

1. Add support for system user in PDP endpoint altinn-authorization#578
   kind/user-story status/draft +2
   
2. Feature/systemuserpdp altinn-authorization#1052
   +0

Tasks

Preview Give feedback

1. Get initial session from Rune for building competency
2. Establish feature-flag so e.g. in AT one can activate the new logic and if a system-user is present in TT, it will be rejected #511
   status/pending-feedback +1
3. Establish repeatable test-case/test client for system user #512
   +0
4. Establish test-suite - get control over existing cases and decide if they give sufficient coverage for as-is functionallity #513
   +0
   
5. Clarify UX - how will this be presented to the use? Do we store the needed information? #510
   status/pending-feedback +1
   

Acceptance criteria:

• Component accepts and responds to calls from system users
  • If feature-flag "off", the component gracefully denies calls from system users
• Component behaves as before for calls from other users

[olebhansen]

Candidate for pair programming

[olebhansen]

FYI the competency-session with Rune is scheduled. Ticking off the box and unassigning myself.