dhis2-devs team mailing list archive

[Abyot Asalefew Gizaw <abyot@xxxxxxxxx>]

Hi,

I have made the change ... authority "ALL" grants access to programs.

--
Abyot A. Gizaw.
Senior Engineer, DHIS2
University of Oslo
http://www.dhis2.org

On Fri, Apr 15, 2016 at 3:47 PM, Jim Grace <jim@xxxxxxxxx> wrote:

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