How authorization IDs hold privileges and authorities
Db2 controls access to its objects by using a set of privileges. Each privilege allows an action on some object.
The following figure shows the primary ways within Db2 to give access to data to an ID.
IDs can hold privileges that allow them to take certain actions or be prohibited from doing so. Db2 privileges provide extremely precise control.
- Related privileges
- Db2 defines sets of related privileges, called administrative authorities. By granting an administrative authority to an ID, you grant all the privileges that are associated with it, in one statement.
- Object privileges
- Ownership of an object carries with it a set of related privileges on the object. An ID can own an object that it creates, or it can create an object that another ID is to own. Creation and ownership of objects are separately controlled.
- Application plan and package privileges
- The privilege to execute an application plan or a package deserves special attention. Executing a plan or package implicitly exercises all the privileges that the plan or package owner needed when binding it. Therefore, granting the privilege to execute can provide a detailed set of privileges and can eliminate the need to grant other privileges separately.
For example, assume that an application plan issues the INSERT and SELECT statement on several tables. You need to grant INSERT and SELECT privileges only to the plan owner. Any authorization ID that is subsequently granted the EXECUTE privilege on the plan can perform those same INSERT and SELECT statements through the plan. You don't need to explicitly grant the privilege to perform those statements to that ID.
- Security labels
- Multilevel security restricts access to an object or a row based on the security label of the object or row and the security label of the user.
- Roles
- A role is a database entity that groups together one or more privileges. A role is available only when the process is running in a trusted context. A trusted context is a database entity that is based on a system authorization ID and a set of connection trust attributes. You can create and use a trusted context to establish a trusted connection between Db2 and an external entity, such as a middleware server.
Users are associated with a role in the definition of a trusted context. A trusted context can have a default role, specific roles for individual users, or no roles at all.