Authorization is performed using Db2® facilities. Db2 tables and configuration files are used to record the permissions associated with each authorization name.
- The authorization name of the user
- The groups to which the user belongs
- The roles granted to the user directly or indirectly through a group or a role
- The permissions acquired through a trusted context
The types of permissions recorded are privileges, authority levels, and LBAC credentials.
A privilege defines a single permission for an authorization name, enabling a user to create or access database resources. Privileges are stored in the database catalogs.
Authority levels provide a method of grouping privileges and control over database or schema operations. Database and schema authorities are stored in the database catalogs; system authorities are associated with group membership, and the group names that are associated with the authority levels are stored in the database manager configuration file for a given instance.
LBAC credentials are LBAC security labels and LBAC rule exemptions that allow access to data protected by label-based access control (LBAC). LBAC credentials are stored in the database catalogs.
Groups provide a convenient means of performing authorization for a collection of users without having to grant or revoke privileges for each user individually. Unless otherwise specified, group authorization names can be used anywhere that authorization names are used for authorization purposes. In general, group membership is considered for dynamic SQL and non-database object authorizations (such as instance level commands and utilities), but is not considered for static SQL. The exception to this general case occurs when privileges are granted to PUBLIC: these are considered when static SQL is processed. Specific cases where group membership does not apply are noted throughout the Db2 documentation, where applicable.
A role is a database object that groups together one or more privileges and can be assigned to users, groups, PUBLIC, or other roles by using a GRANT statement or to a trusted context by using a CREATE TRUSTED CONTEXT or ALTER TRUSTED CONTEXT statement. A role can be specified for the SESSION_USER ROLE connection attribute in a workload definition. When you use roles, you associate access permissions on database objects with the roles. Users that are members of those roles then have the privileges defined for the role with which to access database objects.
- The permissions granted to the primary authorization ID associated with the SQL statement
- The permissions granted to the secondary authorization IDs (groups or roles) associated with the SQL statement
- The permissions granted to PUBLIC, including roles that are granted to PUBLIC, directly or indirectly through other roles.
- The permissions granted to the trusted context role, if applicable.