To protect data and resources associated with a database server, DB2 uses a combination of external security services and internal access control information. To access a database server you must pass some security checks before you are given access to database data or resources. The first step in database security is called authentication, where the user must prove he is who he says he is. The second step is called authorization, where the database manager decides if the validated user is allowed to perform the requested action or access the requested data.
Authentication of a user is completed using a security facility outside of DB2. The security facility can be part of the operating system, a separate product, or, in certain cases, not exist at all. On UNIX platforms, the security facility is in the operating system itself. DCE Security Services is a separate product that provides the security facility for a distributed environment. There are no security facilities on the Windows 95 or Windows 3.1 operating systems.
The security facility requires two items to authenticate a user: first, the user is identified to the security facility by a user ID; second, the user proves he is this identity by providing a piece of information known only to the user and the security facility; for example, a password.
Once authenticated,
DB2 will obtain a list of groups up to a maximum of 64 groups. If a user is a member of more than 64 groups, only the first 64 that map to valid DB2 authorization names will be added to the DB2 group list. No error is created when this happens, and any groups after the first 64 are ignored by DB2.
DB2 uses the security facility to authenticate users in one of two ways:
Authorization is the process whereby DB2 obtains information about an authenticated DB2 user that indicates the database operations a user may perform and what data objects may be accessed. With each user request there may be more than one authorization check depending on the objects and operations involved.
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 an authenticated user, and those of groups in which the user is a member, are compared against the recorded permissions. Based on the comparison, DB2 decides whether to allow the user the requested access.
There are two types of permissions recorded by DB2: privileges and authority levels. 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 for a given database. Authority levels provide a method of grouping privileges and control over higher level database manager maintenance and utility operations. Database-specific authorities are stored in the database catalogs for each database; system authorities are recorded by group membership and are stored in the database manager configuration file for a given instance.
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 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) and is not considered for static SQL (the exeption to this general case being 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 DB2 documentation, where applicable.
"Privileges, Authorities, and Authorization" presents further details on these topics.
The following section ("Selecting an Authentication Method for Your Server") provides additional information about the system entry validation checking that is particularly relevant if you have remote clients accessing the database.