# 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.

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.

- Configuring security in a client/server environment
  This procedure requires a system with multiple databases and some administrative resources.
- 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.

Parent topic: Derby and Security
Related concepts
Working with user authentication
Users and authorization identifiers
User authorizations
Encrypting databases on disk
Signed jar files
Notes on the Derby security features
User authentication and authorization examples
Running Derby under a security manager