db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Embretsen <John.Embret...@Sun.COM>
Subject Re: Embedded Security
Date Fri, 04 Jan 2008 16:09:53 GMT
Magnus Prime wrote:
> 
> 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.

Derby's security model can surely be improved. Just to be clear, Derby does have
support for GRANT/REVOKE (since 10.2.1.6), which is commonly referred to as "SQL
authorization" in the Derby community. However, this is not enabled by default
(mainly for backwards compatibility reasons, I think).

There is an ongoing discussion among Derby developers that is quite relevant,
aiming at improving user management in Derby, see
https://issues.apache.org/jira/browse/DERBY-3282 .

> 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.

I guess there are several ways to accomplish what you want, but that's one
common way to do it, yes.

> 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. 

Derby distinguishes between databases and the Derby system (basically an
instantiation of the Derby engine). You can add users before/without creating a
database, but then the users have to be system-wide.

If you are using the BUILTIN authentication provider, the users must be defined
as Java system properties or in a derby.properties file. Note that you can
alternatively use LDAP or your own authentication provider if that doesn't cut
it for you.

This is an approach that should work fine in your case, I guess, unless you are
planning on running multiple databases at the same time with different users for
each database.

> Can someone explain to me the difference between Authentication and 
> Authorization.  I think I am getting confused on that point as well.

Very short version:

Authentication is the act of verifying the identity of a user; that the user is
who he says he is.
Authorization is the act of controlling who can do what in a system or a database.

You can read more about Derby authorization in the Developer's Guide:
http://db.apache.org/derby/docs/dev/devguide/cdevcsecure36595.html

Hope this helps...


-- 
John






Mime
View raw message