Authentication:
The process that verifies user identity at OS level is known as "authentication". The security product can be part of the OS or a separate product.
To authenticate a user security facility requires two items:
1. User ID
2. Password
The user ID identifies the user to the security facility. By supplying the correct password, information known only to the user and the security facility, the user's identity (corresponding to the user ID) is verified.
What will happen after being authenticated:
1. The user must be identified to DB2 using an SQL authorization name or authid.
2. This name can be same as user ID, or a mapped value.
3. A list of groups to which the user belongs is obtained.
4. Group membership may be used when authorizing the user.
5. Groups are security facility entities that must also map to DB2 authorization names. This mapping is done in a method similar to that used for user IDs.
The DB2 database manager uses the security facility to authenticate users in one of two ways:
A successful security system login is used as evidence of identity, and allows:
– Use of local commands to access local data
– Use of remote connections when the server trusts the client authentication.
Successful validation of a user ID and password by the security facility is used as evidence of identity and allows:
– Use of remote connections where the server requires proof of authentication
– Use of operations where the user wants to run a command under an identity other than the identity used for login.
Authorization:
Authorization is performed using DB2 facilities. DB2 tables and configuration files are used to record the permissions associated with each authorization name.
When an authenticated user tries to access data, these recorded permissions are compared with the permissions of:
- 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
- Based on this comparison, the DB2 server determines whether to allow the requested access.
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 manager operations. Database-specific 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.
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.
During an SQL statement processing, the permissions that the DB2 authorization model considers are the union of the following permissions:
1. The permissions granted to the primary authorization ID associated with the SQL statement
2. The permissions granted to the secondary authorization IDs (groups or roles) associated with the SQL statement
3. The permissions granted to PUBLIC, including roles that are granted to PUBLIC, directly or indirectly through other roles.
4. The permissions granted to the trusted context role, if applicable.
