Hello,
I have a user account with access restricted to only 3 organisations units. When I login to this account, I can only see the assigned OUs in the interface.
However when I access the end-point /api/29/organisationUnits.json , I am able to view all the OUs in the DHIS2 instance, even though the account does not have permission to see them.
Additionally, there are no sharing settings applied to the OUs. Is there a way to protect the organization units?
@Gassim @dhis2-security
Thanks
if you mean you configured the user to limit the read/write of data on only 2 orgunits like here
I think it’s the “expected” behavior : this will only prevent the user to encode data for other orgunits or to see data or analytics of other orgunits.
by data dhis2 mean :
the metadata (data elements, datasets, orgunits…) will probably be visible to him
except if you really configured the sharing settings to prevent that.
see on play user limitdUse_123 (password limitdUse_123)
Thank you for the response.
When I access the endpoint below using a user account that only has access to two organization units (OUs), they are still able to see all OUs, as shown in the attached screenshot. I want to restrict users from viewing all OUs.
@Gassim @Stephan_Mestach is there a way to restrict users from viewing all the OUs using the API?
/api/organisationUnits
@sami12111 : This is by design. In order to be able to properly render an organisation unit tree with the appropriate hierarchy, the user needs to have access to metadata for organisation units for which they do not have view or write access.
Please let us know if you have specific concerns about the current read access to organisation unit metadata.
@tzemp why would I expect organisation units for which a user does not even have view access to “properly” render in an organisation unit tree?
My concern would be to disclose information about an organisation unit (or fwiw even it’s existence in the system) to users that have no reason or right to have this information.
This design looks a bit fishy to me tbh.
I can understand if that’s some legacy behaviour that is hard to remove because organisation units are a very central concept of DHIS2, but telling me that this is the way it should be would leave me surprised and unhappy.
Hi @brar : first of all welcome to the DHIS2 Community of Practice! Thanks for taking the time to write us.
I understand your surprise and concern. The organisation unit metadatsharing works quite differently from metadata sharing for other objects in DHIS2, for which read and write access can be restricted to individual users/user groups.
As mentioned above, the reason why we have a different approach for organisation unit sharing is because of the need to be able to present a logical way to navigate an organisation unit hierarchy, particularly as we allow users to be assigned to multiple organisation units at different levels.
We made this decision after a consideration of the potential consequences for ours users and thought it was the best option at the time, but we welcome input (and/or disagreement) as to what we could do better / differently.
If you have a particular use case where you think the lack of ability to restrict users’ ability to see organisation unit metadata, I think our design and product teams would be very interested in hearing and considering that.
Thanks again.
Thanks @tzemp for your detailed response!
I can absolutely see, where the decision to make all organisation uints visible to any user comes from.
The system we are currently modeling in DHIS2 may indeed go beyond the use cases you had in mind when modeling the DHIS2 organisation unit visibility behavior, because we consider both, an organisation unit’s data as well as the fact that an organisation unit even participates in the system as confidental.
With the current behavior we can only remove OUs a user has no business with from UI components (in fact many of them already remove them) but there is no means to prevent users from opening organisationUnits API endpoint and accessing any other OU’s data.
Apart from the problem of an OUs participation being considered as confidental (problem 1), there are other data (e. g. the unit contact, their e-mail-address, phone number, coordinates, and maybe custom attributes) that are stored in the OU object and that we don’t want to be accessible to users without read access to that OU (problem 2).
Regarding problem 1 it would be feasible for us if a user would have read access to the vertical organisation unit tree hierarchy of units they have access to (parents and children) but would not be able to acces nodes hoizontally (e. g., “brother/sister nodes”, “cousin nodes”, …) for which they don’t have explicit access.
This does not solve problem 2 (“sensitive” data in parent or child OUs), though, but this seems less important to me since (afaik) child OUs currently inherit access rights in any case and parent OUs are typically more or less relevant to an OU at a lower level, so accessing their contact data may even be considered as a feature.
In general if I were to design the system today, I would probably not give any implicit OU or data access via the OU tree/hierarchy and would enforce an explicit access right requirement for every single OU in the tree ath the price of:
a) needing UI tooling to do mass assignment of OU rights to a user (iirc this even exists already)
and
b) the organisation unit tree no longer being a single rooted tree but rather having multiple roots with (potentially) sub-branches attached to each of them, some of them possibly even being at different hierarchical levels.
In any case, given that this would probably break every currently existing DHIS2 deployment, the “implicit vertical read access only” model would probably be the next best approach.
Thanks for your interest in our use cases and for considering my concerns.
Thank you very much for taking the time to write out your concerns and more details about your use case @brar. I think we can safely say that there are things that we would do differently if we were creating the system today.
I’ll share your response with the team that assess and prioritize feature requests.
Thanks again.
Thanks for the feedback @brar . As mentioned before, you could end up in a really difficult situation to render a tree if a given user only has access to certain parts which might not be even connected to each other.
While I understand your concern about confidentiality of locations, there could potentially be other routes to solve this problem, namely the use of an attribute option combo.
We have strongly reccomended in the past that the organisation unit hierarchy should only be used to model a geographical hierarchy. Obviously, you could have situations where there are sensitive locations which some users in the system might not should even know exist, but I think this is really a bit of a corner case for the original design, where the orgunit dimension was basically just used to model a geopolitical hierarchy and potentially locations of health facilities. All of that information is generally public information anyway (there of course can be exceptions to this)
There have been many discussions over the years about multiple roots and again, for the sake of performance and simplicity, we have the current model which addresses the vast majority of use cases.
If you need something special, then I would suggest to investigate using an attribute option combo, which allows you to basically freely design a dimension as you wish (and apply sharing to it).
Best regards,
Jason
