Authorization IDs designate a list of privileges that enable a process to take certain actions. Privileges are given to authorization IDs through SQL GRANT statements. DB2 uses authorization IDs to give a process authority to execute an SQL statement and to supply implicit qualifiers for the names of tables, views, and indexes.
Every process is represented by one primary authorization ID and possibly one or more secondary authorization IDs. DB2 uses your current SQL ID to designate the authorization ID that holds the privileges exercised when certain dynamic SQL statements are executed.
A primary authorization ID represents the process to DB2. Although you do not use it to sign on, this primary ID identifies you to DB2. Typically, the primary authorization ID is the user’s original authorization ID, unless an exit changes it at connection time. CA ACF2 Option for DB2 uses the original ID for reporting purposes only. If a DB2 exit does not change it, the primary authorization ID is determined by the type of system from which you are connecting to a DB2 subsystem. For example, if you connect through TSO, your primary authorization ID is the ID that you use to sign on to TSO (your logonid).
DB2 calls one of two connection exits at authorization time. The attach exit is used for connecting from TSO, batch, IMS control regions, and the CICS recovery coordinator task. The sign‑on exit is used for IMS and CICS sign‑on processing. If used, these exits can change your original authorization ID to a different primary ID and also associate you with a list of secondary authorization IDs.
A secondary authorization ID is an optional ID that can hold additional privileges available to the process. These secondary or group IDs also enable DB2 objects and plans to have more than one owner. This reduces the amount of administration required to maintain the DB2 catalog authorization tables. Because multiple users can own a secondary ID, multiple rows that grant access to individual users can be consolidated into one row that grants access to the secondary ID.
A process can have up to 245 secondary IDs. During an authorization check, DB2 searches the catalog authorization table until it finds the user’s authorization ID that holds the required privileges. This search can be time‑consuming if multiple IDs are used.
One reason that DB2 added secondary IDs was to attempt to reduce some of the administrative burden caused by the cascade effect. This occurs when individual privileges are revoked from an ID. DB2 then revokes the privileges from all IDs that were granted those privileges by that ID. With secondary IDs, privileges are assigned to the secondary ID instead of the primary ID. Instead of revoking individual privileges from a primary ID, you can stop a primary ID from associating with a secondary ID.
Processes become associated with secondary IDs through the sign‑on or attach exit at connection time. The type of connection you make to DB2 determines the exit used.
The current SQL ID is the authorization ID that holds the privileges exercised when certain dynamic SQL statements are issued. It designates the owner of an object or the implicit high‑level qualifier used during dynamic SQL. You can set it to your primary authorization ID, a secondary authorization ID, or (if you have SYSADM authority) any authorization ID. You can change the SQL ID by using this statement:
SET CURRENT SQLID = idname
The value of idname can be a literal, a variable, or the special keyword, USER.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|