Derby and security

Derby can be deployed in a number of ways and in a number of different environments. The security needs of the Derby system are also diverse.

Derby supplies or supports the following optional security mechanisms:

Authentication
Authentication determines whether you are a legal user. It establishes your identity. Derby verifies user names and passwords before permitting access to the Derby system.

For more information about authentication, see Working with user authentication.
Authorization
Authorization determines what operations can be performed by you, that is, by your Derby identity. Authorization grants users or roles permission to read a database or to write to a database.

For more information about authorization, see User authorizations.
Disk encryption
Derby provides ways to encrypt data stored on disk.

For more information about encryption, see Encrypting databases on disk.
Validation of certificates for signed jar files
Derby validates certificates for classes loaded from signed jar files.

For more information about using signed jar files, see Signed jar files.
Network encryption and authentication
Derby network traffic may be encrypted with SSL/TLS. SSL/TLS certificate authentication is also supported. See "Network encryption and authentication with SSL/TLS" in the Derby Server and Administration Guide for details.

The section "Derby Network Server advanced topics" in the Derby Server and Administration Guide has more information on security issues. The Derby Reference Manual describes many security-related properties and system procedures, as well as such statements as GRANT, REVOKE, CREATE ROLE, DROP ROLE, CREATE PROCEDURE, and CREATE FUNCTION.

Identity in Derby

Derby provides two kinds of identity:

System-wide identity: Currently, any legal system-wide identity enjoys authorization to perform the following operations:
- Create databases
- Restore databases
- Shut down the Derby engine
Database-specific identity: If you are a legal identity in a specific database, you may enjoy the following rights:
- You can connect to that database, provided that coarse-grained connection authorization has not been set to noAccess.
- You can shut down that database, encrypt it, and upgrade it, provided that you are the database owner.
- You can create your own SQL objects and write data to your own tables, provided that your coarse-grained connection authorization has not been set to readOnlyAccess.
- You can access other SQL objects, provided that the owners have granted you fine-grained SQL access to those objects, and provided you have not been limited by coarse-grained readOnlyAccess.

The distinction between fine-grained SQL authorization and coarse-grained connection organization is described in User authorizations.

Security mechanisms in action

The following figure shows some of the Derby security mechanisms at work in a client/server environment. User authentication is performed by accessing an LDAP directory service. The data in the database is not encrypted in this trusted environment.

Figure 1. Using an LDAP directory service in a trusted environment
This figure shows user authentication from an LDAP directory service to the Derby engine, and user authorization to read and write data. The Derby database is a trusted environment, and the data is not encrypted.

This figure shows user authentication from an LDAP directory service to the Derby engine, and user authorization to read and write data. The Derby database is a trusted environment, and the data is not encrypted.

The following figure shows how another Derby security mechanism, disk encryption, protects data when the recipient might not know how to protect data. It is useful for databases deployed in an embedded environment.

Figure 2. Using disk encryption to protect data
This figure shows disk encryption between the Derby engine and the database.

Configuring security for your environment
In most cases, you enable Derby's security features through the use of properties. It is important to understand the best way of setting properties for your environment.
Working with user authentication
Derby provides support for user authentication and user authorization. User authentication determines whether a user is a valid user. It establishes the user's identity. User authorization determines what operations a user's established identity can perform. You are strongly urged to implement both authentication and authorization on any multi-user database used in production.
Users and authorization identifiers
User names within the Derby system are known as authorization identifiers. The authorization identifier is a string that represents the name of the user, if one was provided in the connection request.
User authorizations
When you specify user authorizations, Derby verifies that a user has been granted permission to access a system, database, object, or SQL action.
Encrypting databases on disk
Derby provides a way for you to encrypt your data on disk.
Signed jar files
In a Java SE environment, Derby can detect digital signatures on jar files. When attempting to load a class from a signed jar file stored in the database, Derby will verify the validity of the signature.
Notes on the Derby security features
The Derby security model has some basic limitations.
User authentication and authorization examples
This section provides examples that show user authentication and authorization in Derby in either a client/server environment or in an embedded environment.
Running Derby under a security manager
When running within an application or application server with a Java security manager enabled, Derby must be granted certain permissions to execute and access database files.

Related concepts

Creating, dropping, and backing up databases