dhis2-devs team mailing list archive

[Jim Grace <jim@xxxxxxxxx>]

Looping Tim back in, who started this thread but seems to have been dropped
from it.

On Fri, Apr 15, 2016 at 9:38 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> 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.
>
>
> On 14 April 2016 at 09:52, Abyot Asalefew Gizaw <abyot@xxxxxxxxx> 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.
>>
>> --
>> 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@xxxxxxxxxxxx>
>> 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.
>>>
>>> *R*
>>>
>>>
>>> On 13 April 2016 at 21:32, Jim Grace <jim@xxxxxxxxx> 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
>>>>
>>>>
>>>> On Fri, Apr 8, 2016 at 11:44 AM, Timothy Harding <
>>>> tharding@xxxxxxxxxxxxxx> 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.*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Timothy Harding*
>>>>> Sr. Systems Analyst, BAO Systems
>>>>> +1 202-536-1541 | tharding@xxxxxxxxxxxxxx | http://www.baosystems.com
>>>>> | Skype: hardingt@xxxxxxxxx | 2900 K Street, Suite 404, Washington
>>>>> D.C. 20007
>>>>>
>>>>> On Fri, Apr 8, 2016 at 7:53 AM, Abyot Asalefew Gizaw <abyot@xxxxxxxxx>
>>>>> 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@xxxxxxxxx> 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@xxxxxxxxx> 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.
>>>>>>>>
>>>>>>>> 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@xxxxxxxxxxxxxx> 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
>>>>>>>>> 1. Create blank database in 2.21 or 2.22 (or use the SL demo)
>>>>>>>>> 2. Add root ou/set level
>>>>>>>>> 3. Add single tracker data element and single aggregate data
>>>>>>>>> element
>>>>>>>>> 4. Create a program (SENR) and a dataset to use the above
>>>>>>>>> respectively
>>>>>>>>>     - In the program's single stage, specify the tracker element
>>>>>>>>> above
>>>>>>>>> 5. Assign both the program and the dataset to the root ou
>>>>>>>>> 6. 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@xxxxxxxxxxxxxx |
>>>>>>>>> http://www.baosystems.com | Skype: hardingt@xxxxxxxxx | 2900 K
>>>>>>>>> Street, Suite 404, Washington D.C. 20007
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>>>> 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 <https://www.dhis2.org/>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jim Grace
>>>> Core developer, DHIS 2
>>>> HISP US Inc.
>>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> 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 <https://www.dhis2.org/>