The original Cloudscape was built as an embedded-only database -- that is, it could only run inside the VM of another application. It did not have a client/server mode. That was added later.

In some areas, Java DB continues to carry have this embedded "legacy" with it. One particular area you should be aware of is authentication and authorization.

By default when you start up the Java DB Network Server, it accepts connections on localhost only [1], but it allows any user/password combination, and it allows any user to do anything they darn well please. And on the client, by default, the user and password are sent in the clear.

If you don't like this (and you shouldn't if you are running Java DB with sensitive data and/or or listening on ports other than localhost), there are some things you can do (NOTE: I'm assuming you're using Java DB 10.2 or greater):

• Enable authentication on the server
• Configure the client to not send the password in the clear
• Control access and privileges using GRANT/REVOKE

In this blog I'll talk about how to enable authentication on the server. In subsequent blogs I'll talk about configuring the client to not send the password in the clear, and how to use GRANT/REVOKE.

First of all, you need to tell Java DB that you want to actually authenticate users. You do this by setting the system property (on the command line or in derby.properties [1]):

derby.connection.requireAuthentication=true

Java DB authentication is pluggable - you can use LDAP, builtin authentication, or authentication driven by a user program. For more information, see the Derby manual section on authentication

The simplest solution is to use builtin authentication for all your databases, and I'll describe how to do that here.

You basically enter in a series of users and passwords in to derby.properties (this means, of course, that you need to set up proper permissions on the derby.properties file)

# Enable builtin authentication
derby.authentication.provider=BUILTIN

# Define users and passwords.  User names and passwors
# are *case sensitive* and can be quoted if desired
derby.user.groucho=cigar
derby.user.harpo=toottoot
derby.user.chico=sanityclause

Now when you try to connect with any old user or password, you will be pleasantly foiled.

More on authentication and authorization in upcoming blogs. I thought it better to do them in simple pieces so you're not overwhelmed by too much information in a single blog.

[1] If you want to listen on a different host or port, use derby.drda.host and derby.drda.portNumber in your derby.properties file

[2] If you're wondering where you should put derby.properties: by default it is in the directory where you start the server or the VM that embeds the server. You can change this by setting the system directory, e.g.

java -Dderby.system.home=/export/home/groucho/movies derbyrun.jar server start