db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Magnus Prime <magnuspr...@hotmail.com>
Subject RE: Embedded Security
Date Fri, 04 Jan 2008 14:56:31 GMT
Thanks for the great detailed response.  I am just used to working with DB's like MySQL and
SQL Server Express, which have a true user security model, where you install the engine, and
then create users, and then those users get GRANTS/REVOKES/etc, which Derby does not have.
I have been looking through the Derby Manuals, but I agree with you that they are not that
well structured, and I often find it difficult to find the information I am looking for, or
I need to look in 4 guides for it.  
So, if I am following this correctly, and follow your steps, I need to boot/create the database,
then set some properties, then shut it down and re-start it for the users to be in there and
Is there no way to start embedded derby and add users without specifying a database (like
MySQL?).  Otherwise, It seems that anyone can start it initially, and do what they want prior
to it being shutdown.  Granted, this is a simple Dekstop App, and the app is the only one
using the DB, but still, seems odd to me.  
Can someone explain to me the difference between Authentication and Authorization.  I think
I am getting confused on that point as well.

> Date: Fri, 4 Jan 2008 11:14:29 +0100> From: John.Embretsen@Sun.COM> Subject: Re:
Embedded Security> To: derby-user@db.apache.org> > Magnus Prime wrote:> > >
> If I am using an embedded DB, which will have one user only able to > > connect,
what is the best way to do this? > > Should I use only a boot password?> > Should
I use an encrypted database?> > Good question - I think the answer depends on your specific
requirements.> > This topic is mentioned in the Developer's Guide, in the section "Configuring
> security in an embedded environment", e.g. at> http://db.apache.org/derby/docs/dev/devguide/tdevcsecure81850.html.>
> Encryption/bootPassword is well suited to restrict unauthorized startup (boot) > of
the database. However, if the database is already booted, this will not help > you at all
because only the first connection needs to provide the boot password > or encryption key.
So, unless you have complete control over all connections to > your database at all times,
I think using authentication as well is required.> > Then again, database encryption
is quite easy to do, and provides an additional > layer of protection of your data.>
> My suggestion is to start with database-level user authentication and expand > with
database encryption and/or authorization if needed.> > > Better yet, when you first
create the DB, you must give it a name. Now, > > I want to add DB level properties for
users/etc and require you connect > > with a username/password, how does that work,
since at the time of > > creation, those user do not exist for that db.> > First,
there is no authentication enabled by default. You enable authentication > by setting the
derby.connection.requireAuthentication property to true. If you > are using Derby's built-in
authentication provider you should always define at > least one user before you enable
authentication (important if you use database > properties only).> > The requireAuthentication
property is static, however, so it won't take effect > until you reboot the database (when
defined as a database property).> > So, if you are able to create the database in a
secure environment:> - create the database without authentication enabled> - define
one or more users (as database properties)> - enable authentication (as database property)>
- configure your database to ignore system properties (set the > derby.database.propertiesOnly
database property), otherwise system-defined > properties may override the database properties.>
- restart the application and the database> > If you need to authenticate the very first
database boot (creation) as well, you > can define a (temporary) system-level user and
require authentication as system > properties before booting the embedded driver, then
switch to database > properties only when ready.> > One more thing: If you consider
using SQL authorization at some point, I believe > it is wise to think through which user
you specify when creating the database, > since that user will become the database owner
[1].> > There is lots of information about this in the manuals, but it is (in my >
opinion) not very well organized, so don't be afraid to ask questions on this > list if
you can't find the information you are looking for...> > [1]: http://db.apache.org/derby/docs/dev/devguide/cdevcsecureDbOwner.html>
> > -- > John> > > 
Put your friends on the big screen with Windows Vista® + Windows Live™.
View raw message