dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

DHIS 1.4 has a separate user database and authentication is needed to run
the application (front end database).
No authentication on the back end databases (what we call database in DHIS
2), but swapping of database is done inside the front end which needs
authentication.


Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@xxxxxxx|Tel:
+41 788216897
Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.


2010/1/28 Bob Jolliffe <bobjolliffe@xxxxxxxxx>

> Sorry don't really know too much about DHIS1.4 authentication.  How does it
> work?  Is it that no authentication is required to run the application and
> the users require username and password to open different mdb files?
>
> 2010/1/28 Lars Helge Øverland <larshelge@xxxxxxxxx>
>
>>
>>
>> 2010/1/28 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>
>> Hi Lars
>>>
>>> 2010/1/28 Lars Helge Øverland <larshelge@xxxxxxxxx>
>>>
>>>>
>>>>>
>>>>> Ideally IMHO we might have a super-admin view of dhis without the
>>>>> database connection with a set of simple web steps to setup the connection
>>>>> rather than fiddling manually with hibernate.properties.  Not unlike the
>>>>> openmrs installer.  A puzzle to solve is that we use the same database for
>>>>> user authentication that we use for data.  So without connection you can't
>>>>> log in ... and without login you can't set up connections ... etc.  Would be
>>>>> nice one day to separate these.
>>>>>
>>>>>
>>>> What would the alternatives be for storing user authentication?
>>>>
>>>
>>> I'm not sure exactly.  As I say it's a bit of a puzzle and the best
>>> authentication mechanism depends quite a bit on the installation context.
>>>  DHIS2 running "in the cloud" and accessed over the internet as in India is
>>> a very different proposition to running browser, tomcat and db server on the
>>> shared pentium III machine in a dusty office.
>>>
>>> But there could be a few.  I guess the question is whether we want to
>>> separate access to the application from access to a particular database
>>> (from a developer perspective this is obviously useful because we flip
>>> databases all the time - might be less so for a real user whose only need to
>>> be authenticated is to access a particular database).  But off the top of my
>>> head there might be:
>>> (i) a separate user/password database perhaps using h2 or .htpasswd style
>>> files
>>> (ii) a separate ldap service
>>> (iii) the database native user/privilege system
>>> (iv) some kind of hybrid separating authentication to the application
>>> from database authentication
>>>
>>> I guess each of the above throws up little (and big) challenges regarding
>>> how and when to instantiate hibernate sessions.  The idea of all the user
>>> authentication stuff being in the database seems to fit best when (i) the
>>> internet is in the way of physical access to hibernate.properties or (ii)
>>> when using databases like h2 or MSAccess where there is no database server
>>> between the user and the data.
>>>
>>> A hybrid solution might be something like there being a single
>>> super-admin user who can login without the database connection and who can
>>> modify hibernate.properties.  Or in a variation on this theme, a
>>> "pre-installed" mode where the first user is able to configure the system
>>> like the openmrs setup wizard.
>>>
>>> I do think that using (iii) is the only reasonably secure option when
>>> considering standalone desktop systems.  Each user having his/her own
>>> password to the database rather than all users effectively sharing the one
>>> which is plaintext in hibernate.properties.  But this does present enormous
>>> challenges of creating hibernate.sessions on the fly, when to run startup
>>> routines etc.  This would probably require to request an admin password
>>> through a dialog when dhis2 is started which might or might not be
>>> reasonable depending on context.
>>>
>>> I guess there are different security profiles which depend a lot on
>>> context which are really hard to take into account with a simple automated
>>> installer.  Hence my taking the easy way out with h2. Will think about this
>>> later.
>>>
>>> Cheers
>>> Bob
>>>
>>>
>>>
>> OK. A separate database seems doable and would not make things less secure
>> than today at least.
>>
>> Reason for asking is that here in SA people are really used to the notion
>> of "switching datafiles" during runtime, and they keep asking how to do it
>> with 2. I have googled for similar experiences but it doesn't seem to be
>> many. Will think some more too.
>>
>>
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>
>