Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 44680 invoked from network); 4 Jan 2008 14:57:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jan 2008 14:57:03 -0000 Received: (qmail 63852 invoked by uid 500); 4 Jan 2008 14:56:51 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 63470 invoked by uid 500); 4 Jan 2008 14:56:50 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 63459 invoked by uid 99); 4 Jan 2008 14:56:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 06:56:50 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of magnusprime@hotmail.com designates 65.54.246.171 as permitted sender) Received: from [65.54.246.171] (HELO bay0-omc2-s35.bay0.hotmail.com) (65.54.246.171) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 14:56:26 +0000 Received: from BAY101-W19 ([64.4.56.119]) by bay0-omc2-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jan 2008 06:56:31 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2899c599-7370-41e2-9e1f-601fc1045559_" X-Originating-IP: [141.202.248.11] From: Magnus Prime To: Derby Discussion Subject: RE: Embedded Security Date: Fri, 4 Jan 2008 09:56:31 -0500 Importance: Normal In-Reply-To: <477E0705.8010205@Sun.COM> References: <477E0705.8010205@Sun.COM> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2008 14:56:31.0095 (UTC) FILETIME=[FDB1B870:01C84EE1] X-Virus-Checked: Checked by ClamAV on apache.org --_2899c599-7370-41e2-9e1f-601fc1045559_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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. =20 I have been looking through the Derby Manuals, but I agree with you that th= ey 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. =20 =20 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-st= art it for the users to be in there and needed. =20 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 initi= ally, 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, s= eems odd to me. =20 =20 Can someone explain to me the difference between Authentication and Authori= zation. I think I am getting confused on that point as well. =20 Thanks > Date: Fri, 4 Jan 2008 11:14:29 +0100> From: John.Embretsen@Sun.COM> Subje= ct: Re: Embedded Security> To: derby-user@db.apache.org> > Magnus Prime wro= te:> > > > 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 b= oot password?> > Should I use an encrypted database?> > Good question - I t= hink the answer depends on your specific requirements.> > This topic is men= tioned in the Developer's Guide, in the section "Configuring > security in = an embedded environment", e.g. at> http://db.apache.org/derby/docs/dev/devg= uide/tdevcsecure81850.html.> > Encryption/bootPassword is well suited to re= strict unauthorized startup (boot) > of the database. However, if the datab= ase is already booted, this will not help > you at all because only the fir= st connection needs to provide the boot password > or encryption key. So, u= nless 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 > laye= r of protection of your data.> > My suggestion is to start with database-le= vel user authentication and expand > with database encryption and/or author= ization 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 an= d require you connect > > with a username/password, how does that work, sin= ce at the time of > > creation, those user do not exist for that db.> > Fir= st, there is no authentication enabled by default. You enable authenticatio= n > by setting the derby.connection.requireAuthentication property to true.= If you > are using Derby's built-in authentication provider you should alw= ays define at > least one user before you enable authentication (important = if you use database > properties only).> > The requireAuthentication proper= ty is static, however, so it won't take effect > until you reboot the datab= ase (when defined as a database property).> > So, if you are able to create= the database in a secure environment:> - create the database without authe= ntication enabled> - define one or more users (as database properties)> - e= nable authentication (as database property)> - configure your database to i= gnore system properties (set the > derby.database.propertiesOnly database p= roperty), otherwise system-defined > properties may override the database p= roperties.> - restart the application and the database> > If you need to au= thenticate the very first database boot (creation) as well, you > can defin= e a (temporary) system-level user and require authentication as system > pr= operties before booting the embedded driver, then switch to database > prop= erties only when ready.> > One more thing: If you consider using SQL author= ization at some point, I believe > it is wise to think through which user y= ou specify when creating the database, > since that user will become the da= tabase 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 t= o ask questions on this > list if you can't find the information you are lo= oking for...> > [1]: http://db.apache.org/derby/docs/dev/devguide/cdevcsecu= reDbOwner.html> > > -- > John> > >=20 _________________________________________________________________ Put your friends on the big screen with Windows Vista=AE + Windows Live=99. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=3DTXT_TAGLM_C= PC_MediaCtr_bigscreen_012008= --_2899c599-7370-41e2-9e1f-601fc1045559_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks for the great detailed response. = I am just used to working with DB's like MySQL and SQL Server Express, whi= ch 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 th= ey 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.  <= BR>  
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-st= art 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, bu= t still, seems odd to me. 
 
Can someone explain to me the difference between Authentication and Authori= zation.  I think I am getting confused on that point as well.
 
Thanks




> 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 a= m 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?
> <= BR>> Good question - I think the answer depends on your specific require= ments.
>
> This topic is mentioned in the Developer's Guide, i= n the section "Configuring
> security in an embedded environment", e= .g. at
> http://db.apache.org/derby/docs/dev/devguide/tdevcsecure8185= 0.html.
>
> Encryption/bootPassword is well suited to restrict= unauthorized startup (boot)
> of the database. However, if the data= base is already booted, this will not help
> you at all because only= the first connection needs to provide the boot password
> or encryp= tion key. So, unless you have complete control over all connections to
= > your database at all times, I think using authentication as well is re= quired.
>
> Then again, database encryption is quite easy to d= o, and provides an additional
> layer of protection of your data.>
> My suggestion is to start with database-level user authentic= ation 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/passwor= d, how does that work, since at the time of
> > creation, those u= ser do not exist for that db.
>
> First, there is no authentic= ation enabled by default. You enable authentication
> by setting the= derby.connection.requireAuthentication property to true. If you
> a= re using Derby's built-in authentication provider you should always define = at
> least one user before you enable authentication (important if y= ou use database
> properties only).
>
> The requireAuth= entication property is static, however, so it won't take effect
> un= til 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
> - de= fine one or more users (as database properties)
> - enable authentica= tion (as database property)
> - configure your database to ignore sys= tem properties (set the
> derby.database.propertiesOnly database pro= perty), otherwise system-defined
> properties may override the datab= ase 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 requ= ire authentication as system
> properties before booting the embedde= d driver, then switch to database
> properties only when ready.
&= gt;
> One more thing: If you consider using SQL authorization at som= e point, I believe
> it is wise to think through which user you spec= ify when creating the database,
> since that user will become the da= tabase 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 fin= d the information you are looking for...
>
> [1]: http://db.ap= ache.org/derby/docs/dev/devguide/cdevcsecureDbOwner.html
>
> <= BR>> --
> John
>
>
>


Put = your friends on the big screen with Windows Vista=AE + Windows Live=99. Start now! = --_2899c599-7370-41e2-9e1f-601fc1045559_--