[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] GNUmed options for security (authentication) includin
Re: [Gnumed-devel] GNUmed options for security (authentication) including kerberos
Sat, 16 Dec 2006 11:01:39 +1100
I will rewrite this, as it was a bit rushed.
Start with making bind work.
On Fri, 2006-12-15 at 09:26 -0800, J Busser wrote:
> I was looking over some wiki pages and came across
> Am I correct that a browser based client (like Oscar) --- if required
> to use https --- avoids interception (in the clear) of the user's id
> and password at any point along the network?
> Am I correct to think that when one accesses a GNUmed server that was
> set up following the basic installation procedures, there is no
> protection against such interception, unless extra measures (like
> kerberization of the server as per Syan's notes) are taken?
> If skipping this step or equivalent could be considered poor practice
> (poor protection of access to patient data) then must we make some
> reference to this in the installation notes?
> Related questions:
> - are there any extra dependencies for client machines to access
> kerberized GNUmed or do the basic installations of Linux distros and
> Windows include support for kerberos so the user would need set up
> nothing extra on the client machine(s)?
> - when adding a new office worker or doctor into kerberized GNUmed
> would each new person somehow have to be separately registered with
> kerberos? Would this require user maintenance of a public and private
> key separate from their GNUmed userid & password?
> - though some recommend the kerberos server run no other processes
> would people feel it is reasonable to run postgres and to serve
> GNUmed on the same server? Are there additional process that people
> feel should run on the same server or on a different machine, for
> example the fetching of results and the handling of email...
> different machine??? Would running different virtual machines on the
> same physical machine be a good way to achieve what is desirable,
> supposing data could be "pushed" across the machines as required?
> Gnumed-devel mailing list