dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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
>
>