Configuring security for Derby

Derby can be deployed in a number of ways and in a number of different environments, ranging from a single-user deployment for small-scale development and testing to a multi-user deployment of a large database. For all but the smallest deployments, however, it is essential to make the Derby system secure.

To secure a Derby database or databases, take the following steps.

1. Understand the concept of identity in Derby.

   See Identity in Derby for details.

2. Understand the basic tasks involved in configuring security in a client-server environment or an embedded environment.

   See Basic security configuration tasks for details.

3. Configure authentication by setting up users and passwords.

   Authentication determines whether someone is a legal user. It establishes a user's identity. Derby verifies user names and passwords before permitting access to the Derby system.

   For more information about authentication, see Working with user authentication.

4. Configure user authorization for the system.

   Authorization determines what operations can be performed by a user's 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.

5. Encrypt your databases.

   Derby provides ways to encrypt data stored on disk.

   For more information about encryption, see Encrypting databases on disk.

6. Sign any jar files that you use in your databases.

   Derby validates certificates for classes loaded from signed jar files.

   For more information about using signed jar files, see Signed jar files.

7. Encrypt network traffic 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.

8. Customize the default security policy.

   For details, see Running Derby under a security manager, and see "Running the Network Server under the security manager" in the Derby Server and Administration Guide.

9. If necessary, restrict database file access to the operating system account that started the JVM.

   For details, see "Controlling database file access" in the Derby Server and Administration Guide.

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 and database-specific identity.
• Basic security configuration tasks
  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.