Notes on the Derby security features

The Derby security model has some basic limitations.

You can use database properties to specify what users can and cannot access your database. However, if someone gets physical access to your database (for example, if they are able to copy it onto their own disk), they can subvert all other security mechanisms given enough time and skill. Your best Derby defense against this possibility is to encrypt the data (which also encrypts the database properties). However, if the encryption can be broken, the data is vulnerable.

There are no authorization checks for system-wide operations. Anyone who can authenticate at the system level can shut down the Derby engine and restore databases. Your best Derby defense here is to limit the number of users who can authenticate at the system level. This is easy to do with NATIVE authentication: put only one superuser in the system-wide credentials database, and store the database-specific users in their respective databases. With LDAP authentication, you can do this by using different LDAP servers for system-wide and database-specific authentication.

Related concepts
Identity in Derby
Basic security configuration tasks
Working with user authentication
Users and authorization identifiers
User authorizations
Encrypting databases on disk
Signed jar files
User authentication and authorization examples
Running Derby under a security manager