Permission Constraint Exemption At Resource Level

[t83714]

Permission Constraint Exemption At Resource Level

Since v2, we have introduced a more complete authz model.

The model allows us to create permissions with 3 types of constraints:

• ownership
• organisational unit
• pre-authorized

Permission with constraints allows us to grant conditional access to some users/roles to achieve the fine-gain access control management from the admin side.

However, for many cases, the resource owner might want to nominate some resources to be exempted from those constraints as data custodians.

One use case would be:

• We grant read with organisational unit constraint permission to anonymous users
• based on current rules, anonymous users can only see those records doesn't assigned to any organisational unit (i.e. access-control.orgUnitId is not set or empty)
• However, the data custodian wants to make one dataset owned by his branch (i.e. access-control.orgUnitId is set to his branch id) to be accessible by anonymous users (i.e. make it public)
• To make it happen:
  • The system admin should set allowExemption field to true on the "read with organisational unit constraint permission" that has been assigned to anonymous users
  • the data custodian can set access-control.constraintExemption = true on records that should be "public" visible to anonymous users
  • Although anonymous users's read permission comes with "organisational unit constraint", as:
  • the permission is set to allowExemption
  • therefore, anonymous users are also allowed to see any records that are exempted from the constraint (access-control.constraintExemption = true)

Currently, if a data custodian needs to make a record public, he will have to set access-control.orgUnitId to empty. This might impact permission set at organisational unit levels. e.g. users who have permissions with organisational unit constraints within the previously set organisational unit will lose the access to the dataset.

Update 25th July 2023: we only need one allowExemption field to offer the exemption for all 3 current available constraints.

[mwu2018]

@t83714 What will happen if allowExemption is set to false but access-control.constraintExemption is set to true?

[t83714]

@t83714 What will happen if allowExemption is set to false but access-control.constraintExemption is set to true?

In this case, the permission would have NO access even access-control.constraintExemption is set to true.

So the idea is that:

• data custodians are allowed to set constraintExemption to indicate / flag the intention of their dataset
  • i.e. From data custodians's view, the dataset is OK to be accessible by public.
• But system admin can control overall system policy at authz (permission) level
  • i.e. the system owner / admin can still make the final decision (on whether or not to sponsor this intention) at policy level

[mwu2018]

The above arrangement potentially could cause confusion at the UI level. I.e., a restricted dataset might not have a padlock icon attached to it.

[t83714]

The above arrangement potentially could cause confusion at the UI level. I.e., a restricted dataset might not have a padlock icon attached to it.

I think if a dataset's access potential should be restricted at a certain level (constrained), the data custodian should never set constraintExemption to true, right?

If this case, the dataset would be considered as a "non-public" (restricted) dataset( and work as expected)?

I think the padlock feature refers to the DT project? If so, I think the constraintExemption field could be a great indicator field for that purpose.

In the DT project, I think people want to know which datasets are "non-public". But the term "non-public" is not an accurate description of the situation of the access scope -- a dataset might be accessible to many roles but still can be considered as "non-public". e.g. A dataset can be public (i.e. visible to the whole organisation) but the system owner might not want it to be visible to the general public (anonymous users)

In the DT project, I think the meaning of "non-public" is closer to the data custodian's view of access scope. i.e. datasets with padlock should be interpreted as:

• all datasets (in the data custodian's view) are not considered as public datasets.

[mwu2018]

The padlock icon in the DT is to inform users if a dataset is public or not. If a dataset is only accessible to certain roles of users , a padlock should show up so that the user is aware of that there is constraint to this dataset. When the user tries to share the dataset, he knows users without those specific roles will not be able to see it.

[t83714]

closed via PR: https://github.com/magda-io/magda/pull/3475