User accounts identify connections to the database. The database and dataset privileges granted or denied to a user account determine what the user can access. User accounts can be grouped together based on what tasks they need to perform to simplify the management of privileges.
User accounts
User accounts are unique names and passwords used to identify a person or client application that connects to your database. In ArcGIS, user accounts determine who owns what data. User accounts also provide a way to control what type of access (if any) a person or client application has to a database or geodatabase and its datasets.
In Oracle, you can create user accounts in the database, or map network or operating system logins to database user accounts.
Do not use delimiters, such as quotation marks, to force the creation of a user account or group name that contains characters or casing not supported by the underlying database. If a database object, such as a username, is created using delimiters, delimiters must be used when the database is queried for that object. ArcGIS does not place delimiters around object names when querying the database. Therefore, if the database does not support the characters in your undelimited user account or group name, your connection to the database from ArcGIS will fail.
Data ownership
For ArcGIS, the user who creates tables, feature classes, and views in a geodatabase or database owns those datasets. For example, the geodatabase administrator creates the geodatabase; therefore, the geodatabase system tables that are created in the database at that time are owned by the geodatabase administrator. Similarly, a user who creates a feature class owns that feature class.
The username used to make the connection to the geodatabase at the time the datasets are created is the one who owns them.
For instance, part-time staff members Boris and Basil are allowed to create datasets in the geodatabase. Boris and Basil use the same computer. If both use Basil's account to connect to the geodatabase in ArcGIS, all datasets created by either Boris or Basil will be owned by Basil and stored in his schema.
If Boris wants the data he creates to be stored in his schema, he must alter the database connection properties and connect to the database with his own username before he starts creating data.
Knowing who owns the data is important because you cannot remove a user account from the database if the user owns data, and it is the user who created the dataset who controls the level of access other users have to the dataset.
User access
Your database must be able to verify the user accounts that attempt to connect to it. That means the database administrator has to add users to the database. The database checks the list of users to make sure a user is allowed to make a connection. This process is called authentication.
There are two types of authentication used with Oracle databases: operating system authentication and database authentication.
Operating system (OS) authentication indicates a user logs in to the computer and the credentials for authorization are supplied to the database by the operating system of the user's computer. For the connecting user, that means he or she only has to log in at his or her computer and does not have to log in separately to the database. For the database administrator, this means the existing login must be added to the database and the database must be configured to recognize the user's existing login.
If you use database authentication, users log in to the server and then must separately log in to the database.
Once users are added, the database administrator must grant specific privileges to users to determine what they can and cannot do in the database. The database checks these privileges when an authenticated user tries to access or alter the database. This process is called authorization. In ArcGIS, data owners can also grant privileges on their data to other users or groups.
The types of privileges granted to a user are based on the type of work the user needs to perform. Some users only need to connect to the database and view specific data. Other users need to create new datasets. The following section explains how user accounts can be grouped to simplify privilege management.
Groups or roles
Most database management systems provide ways for the database administrator to group users based on their data access needs and assign privileges to the group. This can reduce the time spent altering each individual user's privileges and simplifies administration of large numbers of privileges for large numbers of users. You could, therefore, use groups (also called roles, types, or authorities depending on the database management system) that grant rights to users based on their common functions.
Common categories or groups of users are those who view data, those who edit data, and those who create data.
In most cases, granting rights to groups does not preclude granting rights to individual users in enterprise geodatabases. For instance, you could grant the minimum privileges required to create data in the database to the data creator group (which could include the geodatabase administrator), and grant additional privileges to only the geodatabase administrator user. Each database management system handles privilege precedence differently, though, so consult your database management documentation for details on the behavior of privileges for roles and individual users.
In addition, most database management systems provide predefined groups. One of these is the PUBLIC role.
The PUBLIC group or role is basically a variable that equates to anyone connected to the database; therefore, any right granted to PUBLIC is granted to everyone with a database connection. There may be cases in which all users require a certain privilege. For example, to connect to SQL Server or Db2 databases, users must be granted the CONNECT privilege. Because all users need this privilege to connect, SQL Server and Db2 grant this privilege to PUBLIC by default.
Sometimes, high-level privileges are given to PUBLIC by default when the database is created. However, for security reasons, granting privileges to PUBLIC should be used only when absolutely necessary.
For other predefined groups, consult your database management system documentation.
Tips for grouping users
The following are a few tips for grouping users in the database management system:
- Create separate groups (roles) for system and object privileges. This enables the database administrator to manage database privileges by granting them on the system groups, and data owners to grant privileges on their datasets by granting them to the object groups.
- Choose a naming convention that reflects each type of group (role) for easy reference. For example, for a group that will be able to edit all the land base data, you could name the group LANDBASE_EDITORS.
- Grant privileges directly to the geodatabase administrator and grant privileges via groups (roles) for all other users. The geodatabase administrator is a unique entity. In most cases, only one such user exists for any geodatabase and it is not part of a larger logical group of users. Experienced database administrators consider it good design to grant privileges directly to such application administrator accounts. By contrast, accounts for nonadministrators should receive privileges through groups that represent their job description, project responsibilities, or other logical classification within the organization.
- Avoid mixing roles with directly granted privileges for nonadministrator accounts. When nonadministrator accounts receive privileges through roles and have privileges granted to their accounts directly, a well-planned security model can quickly devolve into an unmanageable mess, requiring considerable time and effort to restore to an organized state. Set policies for data owners to follow when granting access to their data.
In the rare case that a nonadministrator account has truly unique security requirements, consider granting some privileges directly to avoid complicating the role-based security model. Document these cases; they should be the exception rather than the rule.