Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (herse.apache.org: domain of francois.orsini@gmail.com
 designates 209.85.146.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=dILmrdLW1qtMl2mMmmu7BZrQYjTHtKBOlfk54NtXYiUtlQrqgktzRXF+S/6RW7L6djXVytGwKFQmLSqc59s8UIsIEz/0SBsCy8Uw+4yiDDOcd9OxlAzvSw5Z3CoCVxsJ6AJtv0MwXhdHHUCGtiXeYEDV/O2hF/nfLzKY7OSKArc=
Message-ID: <7921d3e40706181306q39e965f4xafb0b9e8650c6c24@mail.gmail.com>
Date: Mon, 18 Jun 2007 13:06:05 -0700
From: "Francois Orsini" <francois.orsini@gmail.com>
To: "Derby Discussion" <derby-user@db.apache.org>
Subject: Re: Users authentication - design problem
In-Reply-To: <3e420d300706181214k1a23a5d5sd61d0c237e9598a0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_95485_16735525.1182197165573"
References: <3e420d300705301142w6f5d7c73r6f2d6c459d604426@mail.gmail.com>
	 <56a83cd00705301605w2e533851xbd9f6194b1ab99e7@mail.gmail.com>
	 <465E919D.9000905@xoetrope.com>
	 <7921d3e40705311539u53a207a5ta0e8dc4d8846c3a4@mail.gmail.com>
	 <3e420d300706181214k1a23a5d5sd61d0c237e9598a0@mail.gmail.com>

------=_Part_95485_16735525.1182197165573
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Stanley,

Yes, this is a good approach. I'm assuming that it is ok for users to have
their separated (and encrypted) data sets which do not need to be reconciled
or joined accross all the users? You can create separate databases and
encrypt each of them based on some encryption pass-phrase entered by each
user (such as a password they would have to enter to access and encrypt
their data automatically), upon logging in to the application. You may want
to implement some auto-logout to shutdown the database when there is no
activity after a period of time...Additionally, you can use GRANT/REVOKE
(authorization) statements to enforce that only a particular user can have
access to the data for a particular database (if this last one has not been
closed when a user logs off - which of course should be taken care by the
application and ensuring the database gets closed upon inactivity or log off
for a user).

Since, it is an application shared across one single desktop, it should be
fine as only one user will be able to use the application and open its
encrypted database (with its data sets) to manipulate it. Of course, you can
always add security at the OS level to re-enforce access restriction to some
database directory, as long as the Derby engine can have access to it...

Cheers,

--francois

On 6/18/07, Stanley Styszynski <diabeteo@gmail.com> wrote:
>
> Hello,
>
> Once again thanks for your responses.
>
> I decided that my application will be creating a hidden directory with
> database files in user's home directory at first use. It means that there
> will be separate databases for each user on a particular machine. This
> allows to encrypt the database and prevents users from seeing each other's
> measurements.
>
> Is this a right approach? I hope so ;)
>
> Later on, I plan to create a server side application (to keep track of
> many patients measurements in the hospital) and then I will probably use
> JavaCards (I would like to thank Mr Francois Orsini for pointing it out).
>
> Regards,
>
> Stanley
>
>

------=_Part_95485_16735525.1182197165573
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Stanley,<br><br>Yes, this is a good approach. I&#39;m assuming that it is ok for users to have their separated (and encrypted) data sets which do not need to be reconciled or joined accross all the users? You can create separate databases and encrypt each of them based on some encryption pass-phrase entered by each user (such as a password they would have to enter to access and encrypt their data automatically), upon logging in to the application. You may want to implement some auto-logout to shutdown the database when there is no activity after a period of time...Additionally, you can use GRANT/REVOKE (authorization) statements to enforce that only a particular user can have access to the data for a particular database (if this last one has not been closed when a user logs off - which of course should be taken care by the application and ensuring the database gets closed upon inactivity or log off for a user).
<br><br>Since, it is an application shared across one single desktop, it should be fine as only one user will be able to use the application and open its encrypted database (with its data sets) to manipulate it. Of course, you can always add security at the OS level to re-enforce access restriction to some database directory, as long as the Derby engine can have access to it...
<br><br>Cheers,<br><br>--francois<br><br><div><span class="gmail_quote">On 6/18/07, <b class="gmail_sendername">Stanley Styszynski</b> &lt;<a href="mailto:diabeteo@gmail.com">diabeteo@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br><br>Once again thanks for your responses. <br><br>I decided that my application will be creating a hidden directory with database files in user&#39;s home directory at first use. It means that there will be separate databases for each user on a particular machine. This allows to encrypt the database and prevents users from seeing each other&#39;s measurements.
<br><br>Is this a right approach? I hope so ;)<br><br>Later on, I plan to create a server side application (to keep track of many patients measurements in the hospital) and then I will probably use JavaCards (I would like to thank Mr 
<span style="color: rgb(204, 0, 96);">Francois Orsini</span> for pointing it out).<br><br>Regards,<br><span class="sg"><br>Stanley<br><br>
</span></blockquote></div><br>

------=_Part_95485_16735525.1182197165573--