dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

On Thu, Jan 28, 2010 at 5:06 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> Theres kind of an assumption here that this *must* be a single user
> scenario.  You wouldn't want to be swapping databases with 3 users logged
> in!


Sure - either this must be standalone installations (like 1.4), or only
superusers should be able to switch, and only when noone else is logged in.


> Putting the web/struts layer to one side and thinking just about a single
> user accessing the database through the secured API it might make sense to
> imagine you were designing a fat client VB/QT/ Swing style application.
>

Yes, pretty much.


> I think you would have 2 approaches:
> 1.  authenticate to the application somehow (many options all hidden behind
> spring security) , then depending on role, open one of a number of possible
> databases possibly without further authentication.  This seems to be similar
> to what dhis 1.4 is doing.
> OR
> 2.  just open the application unsecured and get presented with basic UI and
> menu options, one of which is to open a database, which would require
> subsequent authentication.'
>

This discussion also touches on the ability for us to have DHIS 2 server
installations where we don't require login. Case in point: National (or
global) health observatories with public data. Of course, you would only
expose certain parts of DHIS 2, not including any data input for example.
Currently, the only way to do this is like with the demo, where you tell
people what username and password to use - and could even display that on
the front page.

Knut



>
> This second way would probably have to go along the lines of what I think
> Saptarshi is saying ie. remove the link between authentication and the
> webapp.  The service modules are "natively" secured .  The web layer becomes
> just like a GUI toolkit which you don't require authentication to use.
>
> 2010/1/28 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>
>
>> Hi Lars,
>>
>> I discussed this with Ola and Bob once about how we can easily switch
>> between databases... Is that what you are talking about here?? The better
>> longterm approach would be to couple Spring-based API with the hibernate
>> layer and provide access to the layer only through the API without any
>> web/struts layers
>>
>> Another easy solution is to use/create a TargetSource with different
>> SessionFactories... We create or re-use the TargetSource and point those to
>> the database that we want to use.
>>
>>  Hope you are asking what I'm answering
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>> Director R & D, HISP India
>> Health Information Systems Programme
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>> You Live by CHOICE, Not by CHANCE
>>
>>
>> 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
>>> 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
>
>


-- 
Cheers,
Knut Staring