# Basic security configuration tasks

In most cases, you enable Derby security features through the use of properties. It is important to understand the best way to set properties for your environment.

Derby does not come with a built-in superuser. For that reason, be careful to follow these steps when you configure 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. See "Scope of properties" and "Setting system-wide properties" in the Derby Developer's Guide for more information.
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 an embedded environment
  In an embedded environment, typically there is only one database per system, and there are no administrative resources to protect databases.
- Configuring security in a client/server environment
  This procedure requires a system with multiple databases and some administrative resources.

Parent topic: Part Two: Configuring security for Derby
Related concepts
Configuring database encryption
Using signed jar files
Configuring SSL/TLS
Understanding identity in Derby
Configuring user authentication
Configuring user authorization
Restricting file permissions
Putting it all together