Systemlabel authorization requirements considerations

[elsand]

Introduction

We need to figure out the authorization requirements and functionality for system labels

Description

System labels were specified to require having "write" on the serviceresource referred to by the dialog. This is not correctly implemented, as it now only checks for any access to the main resource. This is in itself a bug, but implementing a fix would impose another issue; there is no way for frontends to know whether or not a user has access to perform a systemlabel operation without performing a details call for each and every dialog, which isn't very practical.

So this issue has to figure out how to balance security and usability issues here.

• If we can loosen the authorization requirement such that any access (ie. you're able to see the dialog) is sufficient, the fix is trivial (fallback to list auth if access to main resource is missing).
  • Even though labeling doesn't affect the process, this is granting global state changing access to someone who as of now do not possess it
  • What are the threats here and possible abuse scenarios? Instance delegations?
• If we require "write", we need a way to indicate in the lists whether the user can set systemlabels or not. This will require having to preload and cache additional information about the service resource policies, which are checked runtime in the list view (similar to issues in Implementere støtte for å definere og kontrollere krav til scope i token ved referanse til tjenesteressurs #40, Fetch and store required authentication level for services #1214, Use Altinn-actions from RR for details authorization #1247)
  • Could possibly be solved with joining another table in SubjectResource (SubjectResourceAction ?)

Implementation

If there are guidelines on architecture or other implementation choices, they are added here. Different approaches can also be discussed here.

Tasks

Beta Give feedback

1. Implementation tasks are added here
2. Prepare documentation (if relevant - either update working document, or add a new file in docs)
3. Add e2e-test (if relevant)

Threat modelling

Beta Give feedback

1. Does this change introduce any potential security issues?