1.1

Table Of Contents
After SQLFire authenticates a user, it grants the user access to the SQLFire distributed system, either by starting
up the SQLFire member in a new distributed system, joining the member to an existing distributed system, or
simply connecting to a distributed system as a client. Authenticated users may also access to database objects
according to the SQL authorization conguration. (SQL authorization is not enabled by default).
Note: Because SQLFire can be embedded within a Java application, it is also possible to deploy a system
in which the Java application, rather than the embedded SQLFire process, handles user authentication.
User Authentication and Member Ownership
The authenticated system user that starts up a SQLFire member is the owner of that member JVM.
The owner of a SQLFire member cannot be changed after the JVM is started. However, member ownership can
be changed by stopping the member process and then restarting it using the credentials of another user.
The owner of a SQLFire member owns any schemas and database objects that they create in the distributed
system. The owner also owns any schemas and database objects in the JVM that were created by other JVM
owners. In other words, SQLFire treats all JVM owners interchangeably when a SQLFire member is booted.
See also SQLFire Member JVM Owner on page 246.
Enable User Authentication
To enable user authentication with SQLFire, you must use a SQLFire locator for member discovery. SQLFire
uses mutual authentication between the SQLFire locator and subsequent SQLFire members that boot and join
the distributed system. User authentication is not supported if you use multicast for member discovery.
Procedure
1. For each member of the SQLFire cluster (servers, locators, and accessors), set the
sqlfire.auth-provider property to enable user authentication and to specify the mechanism that
SQLFire uses to authenticate users.
For servers and locators, specify -auth-provider=provider_name at the command line, or dene the
sqlfire.auth-provider=provider_name property in the sqlfire.properties le.
For development and testing only, specify BUILTIN as the provider name to use the SQLFire built-in
authentication mechanism. For production purposes, specify LDAP to use an existing LDAP repository, or
specify the name of a custom provider class that implements the UserAuthenticator interface.
2. Congure user credentials in your specied authentication provider. See Creating Users for BUILTIN
Authentication on page 239 or Conguring LDAP Directory Service on page 241.
Note: If you start a SQLFire system with user authentication enabled but without dening at least
one user, you will not be able to shut down the system at once with sqlf shut-down-all. To
create users, see Creating Users for BUILTIN Authentication on page 239 or Conguring LDAP
Directory Service on page 241.
3. Start one or more SQLFire locators with the authorization conguration, before starting any additional
SQLFire data stores or accessors.
When using BUILTIN authentication, the locator must dene all system user accounts as well as the
authentication provider for the distributed system as a whole. SQLFire uses the specied provider and users
to perform mutual authentication when new members attempt to join the distributed system.
4. When shutting down the distributed system, use sqlf shut-down-all with authenticated user credentials. By
default this command shuts down all servers and accessors, but leaves standalone locator members running.
Always leave at least one locator running in the distributed system, until all data stores have nished shutting
down.
vFabric SQLFire User's Guide238
Deploying vFabric SQLFire