This changes how details authorization are performed to use information from the resource policy instead of the dialog itself
Description
As of now, in order for a user to be authorized to see dialog details, the dialog must either
Refer a resource with a policy having a rule granting access to the XACML-action "read" to the user
Have gui/api-actions that refer to any XACML-action defined in the policy that the user has access to
This means that there are cases where the user can see the dialog in the list, but not in the details view, eg. when the service resource policy only defines a "write" XACML-action, and the dialog itself does not refer the "write" XACML-action for any gui/api-action.
This introduces an extension to the RR integration, where the policies are enumerated and parsed and the list of actions defined are cached and used instead of the current implementation that merely enumerates the actions defined on the dialog itself as well as "read" (see DialogEntityExtensions.GetAltinnActions)
The requirements has similarities to those defined in #1214 and #40 which should be considered in implementation.
Implementation
As with #1214 and #40, there is need to establish a way to get additional information from each resource policy.
The policy for each service resource will have to be parsed, in order for DialogEntityExtensions.GetAltinnActions to produce the same kind of output to be used for the XACML request (ie List<AltinnAction> which is a list of action and subresource (aka authorization attribute) pairs. The basic algorithm is:
Foreach rule in the XACML-policy
Foreach AnyOf in the policy
Foreach AllOf
If the attribute category indicates that it is an action
Add the AttributeValue to the action list
if the attribute category indicates that it is a resource
if the AttributeDesignators AttributeId is NOT urn:altinn:resource and NOT urn:altinn:app
Add the AttributeValue to the authorizationattribute list, associated with the actions within the same AllOf
This should be expanded to a list of AltinnAction (ie. actionName/authorizationattribute pairs)
### Tasks
- [ ] Implementation tasks are added here
- [ ] Prepare documentation (if relevant - either update working document, or add a new file in `docs`)
- [ ] Add e2e-test (if relevant)
### Threat modelling
- [ ] Does this change introduce any potential security issues?
Introduction
This changes how details authorization are performed to use information from the resource policy instead of the dialog itself
Description
As of now, in order for a user to be authorized to see dialog details, the dialog must either
This means that there are cases where the user can see the dialog in the list, but not in the details view, eg. when the service resource policy only defines a "write" XACML-action, and the dialog itself does not refer the "write" XACML-action for any gui/api-action.
This introduces an extension to the RR integration, where the policies are enumerated and parsed and the list of actions defined are cached and used instead of the current implementation that merely enumerates the actions defined on the dialog itself as well as "read" (see
DialogEntityExtensions.GetAltinnActions
)The requirements has similarities to those defined in #1214 and #40 which should be considered in implementation.
Implementation
As with #1214 and #40, there is need to establish a way to get additional information from each resource policy.
The policy for each service resource will have to be parsed, in order for
DialogEntityExtensions.GetAltinnActions
to produce the same kind of output to be used for the XACML request (ieList<AltinnAction>
which is a list of action and subresource (aka authorization attribute) pairs. The basic algorithm is:This should be expanded to a list of AltinnAction (ie. actionName/authorizationattribute pairs)
Acceptance criteria
GIVEN ... WHEN .... THEN ...
GIVEN ... WHEN .... THEN ...