Notes on the Derby security features

Because Derby does not support traditional grant and revoke features, the security model has some basic limitations. For both embedded and client/server systems, it assumes that users are trusted. You must trust your full-access users not to perform undesirable actions. You lock out non full-access users with database properties, which are stored in the database (and in an encrypted database these properties are also encrypted). Note, however, for a distributed/embedded system that a sophisticated user with the database encryption key might be able to physically change those properties in the database files.

In addition, in the Derby system, it is not necessary to have a specific connection (or permission to access a particular database) to shut down the system. Any authenticated user can shut down the system.

Other security holes to think about are:

Related concepts
Configuring security for your environment
Working with user authentication
Users and authorization identifiers
User authorization
Encrypting databases on disk
Signed jar files
User authentication and authorization examples
Running Derby under a security manager