I have made the change … authority “ALL” grants access to programs.
···
On Fri, Apr 15, 2016 at 3:47 PM, Jim Grace jim@dhis2.org wrote:
Looping Tim back in, who started this thread but seems to have been dropped from it.
–
Abyot A. Gizaw.
Senior Engineer, DHIS2
University of Oslo
http://www.dhis2.org
On Fri, Apr 15, 2016 at 9:38 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Its an interesting problem. In general Role Based Access Control (RBAC) is known to be an insufficient security mechanism/framework for handling issues of patient confidentiality without some additional parameterization to model things like legitimate relationships, patient consent management etc. In dhis2 we do in fact have just that sort of extension to RBAC by having affinity to orgunits and programs.
The problem is that this gets broken by the idea of a super-user, so I understand where Abyot was going with this. There is a reasonable difference between having ALL roles and having a legitimate relationship with all entities. I don’t think this is a question of inconsistency so much as a misunderstanding of the refinement to RBAC that we have implemented.
Of course the problem with ALL is that, being god-like, it remains possible for the superuser to assign him/herself access anyway so there is possibly no point having an artificail barrier of “security theatre”. Unless we ensure that adequate alarms are sounded when a superuser accesses individual records - messaging, WARNING logs etc.
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Jim Grace
Core developer, DHIS 2
HISP US Inc.
http://www.dhis2.org
On 14 April 2016 at 09:52, Abyot Asalefew Gizaw abyot@dhis2.org wrote:
Thank you all !
Seems I should give up and put back “All” authority on programs.
It would have been nice if we get the view of those working in “patient” or clinical settings.
One thing we need to keep in mind is the way we deal with programs is totally different from that of data sets. There is a lot more workflow and confidentially with programs, their attribute values and events.
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Abyot A. Gizaw.
Senior Engineer, DHIS2
University of Oslo
http://www.dhis2.org
On Thu, Apr 14, 2016 at 12:55 AM, Rodolfo Melia rmelia@knowming.com wrote:
Hi - I learned to live with this odd situation since at least 2.20, which I have in multiple boxes. It doesn’t make sense that you have access to all data sets, but not to the programs. I really would like to see the ‘All’ authority having access to all programs, for consistency sake.
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
R
On 13 April 2016 at 21:32, Jim Grace jim@dhis2.org wrote:
Thank you all. I’m with Tim. I don’t know if this is still up for reconsideration or reversal, but it seems to me a bad idea to ship with a “Superuser” role, and an “ALL” authority, neither of which gives access to all authorities.
For installations that do not use tracker for personal data that needs protection (like DATIM, which uses tracker for site surveys), this is just confusing. User interface design is all about predictability, and words like “all” and “superuser” have unquestioned meanings in many of our heads. I know this wasted a bit of Tim’s time, and it would have done the same for me. It would never occur to me that we would intentionally design software to use words like these and not have them mean the obvious things. For users who are just getting to know the product, either they don’t know about these exceptions in which case they misunderstand the software and could be in for a surprise of unpredictable behavior, or they know about them in which case they will have the feeling that this is strangely-designed software that doesn’t always live up to expectations. The more unpredictable or inconsistent our software is, the lower will be our users’ opinion of it.
For installations that use tracker for personal data that needs protection, they need to be serious about protecting the data. If they hand out too many superuser roles with the “ALL” authority, they will have a problem in any event, as Tim points out, since these users could assign themselves the tracker authority. A much better solution, and one we should recommend, is to not assign either the “ALL” authority or the tracker authorities except to users who really need them. It’s better to have a well-planned security system than to have the illusion that they are protected when they are not really. This feature could actually reduce security by giving the illusion that it is there.
In short, I think the benefits of having Superuser and ALL not include the tracker are at best questionable and at worst misleading into a false sense of security, while the costs are real and negative.
My humble opinion.
Cheers,
Jim
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
On Fri, Apr 8, 2016 at 11:44 AM, Timothy Harding tharding@baosystems.com wrote:
Thanks Morten, Jim, Abyot,
Abyot:
Is the point of restricting a super user moot though since the super user has the ability to assign themselves to whatever they like? It feels like an extra step that shouldn’t be needed for a superuser.
But, if there is indeed a need for the functionality to be this way, my follow up questions are still out there: Will datasets eventually act this way as well? If not, why the discrepancy?
I admit though I am a bit bias having spent more time that I care to admit to yesterday trying to figure out why my program would not appear in a vanilla instance.
–
Jim Grace
Core developer, DHIS 2
HISP US Inc.
http://www.dhis2.org
Timothy Harding
Sr. Systems Analyst, BAO Systems
+1 202-536-1541 | tharding@baosystems.com | http://www.baosystems.com | Skype: hardingt@gmail.com | 2900 K Street, Suite 404, Washington D.C. 20007
On Fri, Apr 8, 2016 at 7:53 AM, Abyot Asalefew Gizaw abyot@dhis2.org wrote:
Hi,
It was like that before … I think I changed it because at some point there was a discussion saying we have to be careful on granting blanket access in tracker.
One could be a superuser, but does this really mean this user will have access to clinical data, names and everything implicitly?
By forcing users to explicitly go and assign a program, they know the consequence of doing that…
We am open for suggestions and discussions.
–
Abyot A. Gizaw.
Senior Engineer, DHIS2
University of Oslo
http://www.dhis2.org
On Fri, Apr 8, 2016 at 4:34 PM, Jim Grace jim@dhis2.org wrote:
Perhaps it was just an oversight in the code, forgetting to check for the “ALL” authority in addition to the particular authority?
I would certainly expect “ALL” to grant the same access as all authorities. It would surprise me if there is any good rationale to make it otherwise.
On Thu, Apr 7, 2016 at 11:19 PM, Morten Olav Hansen morten@dhis2.org wrote:
Yes, that is correct. I’m not sure when it was decided so, but you need to give the userrole access to that program.
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Jim Grace
Core developer, DHIS 2
HISP US Inc.
http://www.dhis2.org
–
Maybe Abyot remember exactly why?
–
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org
On Fri, Apr 8, 2016 at 9:51 AM, Timothy Harding tharding@baosystems.com wrote:
Hey devs,
Just wanting to make sure of this: It looks like in version 2.21 and beyond, the “ALL” authority no longer gives the super user access to everything (about the same time programs were given their own entry in the roles). This means when that user makes a new (public) program, they need to also add that program to their superuser role. Is this intended? Will datasets eventually act this way as well? If not, why the discrepancy?
Steps to reproduce
- Create blank database in 2.21 or 2.22 (or use the SL demo)
- Add root ou/set level
- Add single tracker data element and single aggregate data element
- Create a program (SENR) and a dataset to use the above respectively
- In the program’s single stage, specify the tracker element above
- Assign both the program and the dataset to the root ou
- Notice that the dataset will show up in the “Data Entry App” and the program will NOT show up in the event viewer.
Timothy Harding
Sr. Systems Analyst, BAO Systems
+1 202-536-1541 | tharding@baosystems.com | http://www.baosystems.com | Skype: hardingt@gmail.com | 2900 K Street, Suite 404, Washington D.C. 20007
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
