Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4E79DAB5.8090408@oracle.com>
Date: Wed, 21 Sep 2011 05:38:13 -0700
From: Rick Hillegas <rick.hillegas@oracle.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: making Derby secure by default
References: <4E6F999D.4020002@oracle.com> <4E734848.5060609@oracle.com>
 <4E737423.6050207@sbcglobal.net> <4E739B94.8030006@oracle.com>
 <4E78FF57.9010105@oracle.com>
In-Reply-To: <4E78FF57.9010105@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dag,

Thanks for the questions. Most of these have to do with authentication 
and the notion of identity in Derby. These are issues we need to iron 
out, perhaps as part of DERBY-866. Some comments inline...

On 9/20/11 2:02 PM, Dag H. Wanvik wrote:
> Thanks, Rick!
>
> On 9/16/2011 8:55 PM, Rick Hillegas wrote:
>>
>> CS1) The VM owner would have to specify credentials in order to boot 
>> the server.
>
> How would we store and authenticate these credentials (we have no a 
> priori DB or central repository unless authetication is via LDAP)? 
> Would this require the system privileges to be completed or do you 
> have another model in mind?
Here are two possible approaches:

i) As part of the work on DERBY-866, we build system-wide authentication 
for Derby. The latest proposal on that issue is for database-specific 
credentials. The problem of system-wide credentials baffles me.

ii) If we are using the new authentication scheme proposed on DERBY-866, 
then we just accept the credentials which are provided when the server 
is booted. Those credentials are stored in memory and are required for 
subsequent operations on the server.

More discussion needed.
>
>>
>> CS2) Those credentials would be required in order to shutdown the 
>> server, shutdown the engine, turn server-side tracing on/off, and in 
>> general use any of the public functions of 
>> NetworkServerControl/NetServlet.
>
> and I guess, any interface we expose through our management beans?
Probably. JMX may have its own notion of identity, though.
>
>>
>> CS3) SSL/TLS would be turned on. Unless overridden, certificate/key 
>> stores would be expected/created at some default location.
>>
>> CS4) Some mechanism would control create/restore database powers 
>> across the network. Discussion needed.
>
> Can you elaborate on what you have in mind here? Do you mean changing 
> the data base owner (DBO) for a database? And/or the privileges 
> referred to in CS2?
This might be the almost finished work on DERBY-2109. Alternatively, we 
might consider some sort of certificate-based identity when SSL/TLS is 
enabled. I think this is wrapped up with your earlier question about (CS1).

At this point, we might want to start a separate thread to address the 
question of Derby identity and how to supply builtin authentication 
which is secure and easy to administer. Or continue this discussion on 
DERBY-866.

Thanks,
-Rick
>
> Thanks,
> Dag
>
>