|
|
|
Groups and roles can simplify control of database access. Groups are used to apply permissions to a list of users, while roles are used to associate subject privileges and permissions with an application.
|
|
|
A group allows multiple users to be referenced by a single name.
For example, a company has an accounting group to identify the accounting department employees as a whole, and a payroll group to identify the payroll department employees as a whole. To define these groups, the DBA creates the groups and adds all the users in the associated departments to their respective groups. The groups can be easily maintained by adding and dropping users as they join or leave the departments.
Note: A user can be a member of more than one group.
|
|
|
You can perform the following basic operations on group objects:
In VDBA, use the Groups branch in the Database Object Manager window.
In SQL, you can accomplish these tasks with the create group, alter group, and drop group statements. For more information, see the SQL Reference Guide.
|
|
|
Groups are a convenient way to give the same permissions to many users at once.
After a group is created, associate permissions with it, as described in Object Permissions in the chapter "Ensuring Access Security." When you grant permission to a group, you are, in effect, granting that same permission to each user in the group.
Groups also make managing the permissions easy by allowing you to add users to (and remove users from) the group. For example, grant the payroll group insert, delete, and select permissions on the payroll tables, which gives all the users in the group those permissions. If an employee leaves the payroll department, or if a new employee joins, you simply have to drop or add a user from the group, without modifying the permissions. Similarly, if you find that the group needs fewer or more permissions, revoke or grant the permissions once, for the entire group, rather than individually for each member of the group.
Being a member of a group, however, does not automatically give a user the permissions granted to the group. Users must specifically identify themselves as part of a group to be allowed the associated permissions. A user can be identified as part of a group in two ways:
|
|
|
When starting a session, specify a group identifier. For example, use the –G flag to specify a group identifier for many system commands and with the connect statement as part of an application. For more details, see the Command Reference Guide.
Specify a group identifier as part of the connection profile for an OpenROAD session. For more information, see online help for the Create Connection Profile dialog in OpenROAD.
|
|
|
A default group can be specified for a user when a user object is created or modified. Users who have a default group defined are automatically associated with that group whenever they start a session for which a group identifier is not otherwise specified.
Group identifiers are not validated if you are the DBA of the specified database or a user, such as the system administrator, who has the security privilege. For any other user to specify a group or use it as a default, the user must be a member of that group. If the user is not a member of that group, the connection is refused.
|
|
|
A role is typically associated with one or more applications for the purpose of granting permissions to those applications. For example, a company uses a restricted application that performs some checks before updating the payroll tables to ensure that these tables are updated correctly. The DBA defines a role, for example update_payroll, and later assigns appropriate permissions for the necessary tables. The application developer associates the role with the application.
Note: When defining a role, the DBA normally works with the application developer, so that they can agree on what role identifier and password to use for specific applications.
|
|
|
In VDBA, roles are implemented using role objects. Using the Roles branch in the Database Object Manager window, you can:
Note: Passwords can be associated with role objects as well as with user objects. The section User Passwords contains more information on passwords.
In SQL, you can accomplish these tasks with the create role, alter role, and drop role statements. For more information, see the SQL Reference Guide.
|
|
|
After a role is created, associate permissions with it and create grants to it for individual users. For example, for the associated application to execute properly, grant update permission to all payroll tables for the update_payroll role. For details, see Object Permissions in the chapter "Ensuring Access Security."
When you grant a permission or a subject privilege to a role, you are, in effect, granting that same permission or privilege to any session that is started using that role.
|
|
|
When starting a session, you must specify a role identifier, which puts into effect the associated permissions and subject privileges.
For example, use the –R flag to specify a role identifier for many system commands and with the connect statement as part of an application. For details, see the Command Reference Guide.
Specify a role identifier for an application image as part of the connection profile for an OpenROAD session. For more information, see online help for the Create Connection Profile dialog in OpenROAD.
For the DBA or a user (such as the system administrator) who has the security privilege, neither role identifier nor password is validated. For any other user, the specified role must exist, the user must be granted permission to use the role, and any required password must be specified correctly. Otherwise, the connection is refused.