apache > db
Apache DB Project
Font size:      

Configuring Security for Your Environment

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.

Configuring Security in a Client/Server Environment

This discussion assumes a system with multiple databases and some administrative resources. For systems that have a single database and for which there are no administrative resources, follow the instructions in Configuring Security in an Embedded Environment.

  1. Configure security features as system properties.

    See "System-Wide Properties" in Tuning Derby.

    Provide administrative-level protection for the derby.properties file and Derby databases. For example, you can protect these files and directories with operating system permissions and firewalls.

  2. Turn on user authentication for your system.

    All users must provide valid user IDs and passwords to access the Derby system. See Working with User Authentication for information.

    If you are using Derby's built-in users, configure users for the system in the derby.properties file. Provide the protection for this file.

  3. Configure user authorization for sensitive databases in your system.

    Only designated users will be able to access sensitive databases. You typically configure user authorization with database-level properties. See User Authorization for information. It is also possible to configure user authorization with system-level properties. This is useful when you are developing systems or when all databases have the same level of sensitivity.

Configuring Security in an Embedded Environment

In an embedded environment, typically there is only one database per system and there are no administrative resources to protect databases.

  1. Encrypt the database when you create it.
  2. Configure all security features as database-level properties.

    When you do this, these properties are stored in the database (which is encrypted). See "Database-Wide Properties" in Tuning Derby.

  3. Turn on protection for database-level properties so that they cannot be overridden by system properties.

    Do this by setting the derby.database.propertiesOnly property to true.

  4. To prevent unauthorized users from accessing databases once they are booted, turn on user authentication for the database and configure user authorization for the database.

    See Working with User Authentication for information.

    See User Authorization for information.

  5. If you are using Derby's built-in users, configure each user as a database-level property so that user names and passwords can be encrypted.
Caveat for Configuring Security

Derby does not come with a built-in superuser. For that reason, be careful when configuring Derby for user authentication and user authorization.

  1. When first working with security, work with system-level properties only so that you can easily override them if you make a mistake.
  2. Be sure to create at least one valid user, and grant that user full (read-write) access. For example, you might always want to create a user called sa with the password derby while you are developing.
  3. Test the authentication system while it is still configured at the system level. Be absolutely certain that you have configured the system correctly before setting the properties as database-level properties.
  4. Before disabling system-level properties (by setting derby.database.propertiesOnly to true), test that at least one database-level read-write user (such as sa) is valid. If you do not have at least one valid user that the system can authenticate, you will not be able to access your database.

Previous Page
Next Page
Table of Contents