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 needed. 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. Thanks
> Date: Fri, 4 Jan 2008 11:14:29 +0100> From: [EMAIL PROTECTED]> Subject: Re: > Embedded Security> To: [email protected]> > 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™. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008
