DB2 is a z/OS subsystem that you can connect to through one of the following environments:
When you connect to DB2, DB2 calls the System Authorization Facility (SAF) to authorize your access to the DB2 subsystem. Once authorized, DB2 uses an authorization ID to identify you. Through exit processing, you can then choose to become associated with a different primary authorization ID and one or more secondary authorization IDs, which can provide additional privileges that you can use within DB2.
When you connect to DB2, you can use the CA ACF2 SAF interface to automatically translate SAF calls to CA ACF2 requests.
CA ACF2 Option for DB2 uses a logonid to identify you to DB2. You can use the UID to replace the grouping function that secondary IDs perform for access to resources. The sections that follow describe original and primary authorization IDs, secondary authorization IDs, and how logonids relate to them.
CA ACF2 Option for DB2 supports DDF. You must define the logonid (primary or secondary ID) used for DDF in the CA ACF2 Logonid database that supports the target DDF system. DB2 will provide secondary IDs through the DSN3@ATH exit. Therefore, you must ensure the primary or secondary IDs used in DDF are defined in the Logonid database of the target system.
For example, if primary ID USER01 sends a DDF request from DB2 system A to DB2 system B, CA ACF2 Option for DB2 in system B performs security using the USER01 logonid. USER01 must be defined in the Logonid database for system B.
Or, if USER01 sends a DDF request to system C, system C’s DSN3@ATH exit provides secondary IDs of ACCTPAY and AUDIT for USER01. CA ACF2 Option for DB2 in system C performs security using USER01, ACCTPAY, and AUDIT, all of which must be defined to the Logonid database in system C.
If you pass the SAF security check, your original authorization ID is passed to DB2. This ID becomes your primary authorization ID. Through the sign‑on and attach exits, you can change your original ID to another primary authorization ID. Although you do not actually use it to sign on to DB2, the primary ID identifies you to DB2. It is determined by the type of system from which you are connecting to DB2. For example, if you connect through one of the following, your primary authorization ID is as follows:
|
Environment |
Primary Authorization ID |
|---|---|
|
TSO |
Your sign‑on ID (logonid) |
|
Batch |
USER= parameter from the job statement (or /*LOGONID or //*LOGONID) |
|
CICS |
One of the following specified in the CICS resource control table (RCT): USERID—The eight‑character CICS sign‑on user ID SIGNID—The user‑defined ID in TYPE=INIT of RCT USER/OPIDENT—The three‑character CICS sign‑on operator ID TERM—The CICS terminal name GROUP—The RACF group authorization ID in TYPE=ENTRY of the RCT String—An eight‑character user‑defined ID. |
|
IMS |
Your logonid if you are signed on (otherwise, it is your LTERM name). In non‑message driven regions, the primary ID is the PSB name. |
|
Call Attach Facility (CAF) |
USER= parameter from the job statement (or /*LOGONID or //*LOGONID) |
CA ACF2 Option for DB2 uses the logonid to uniquely identify users to DB2. A logonid is like a DB2 primary or secondary authorization ID and is checked at entry to the z/OS operating system.
An account manager (a user with ACCOUNT specified in his logonid) must define each ID passed to DB2 in the CA ACF2 Logonid database. You might need to define logonids for certain IDs that connect to DB2 through another subsystem, such as CICS. For example, you can use a CICS transaction ID through the CICS resource control table (RCT) to connect to DB2. You must define a logonid for this transaction in the CA ACF2 Logonid database. Ensure that a logonid is defined for any ID that CICS passes to DB2 and for any secondary IDs that you are using.
CA ACF2 Option for DB2 writes violation, trace, and logging records against any original, primary, or secondary ID.
After you connect to DB2, you can become associated with one or more secondary authorization IDs. A secondary ID can give you additional authority to access objects in DB2.
Primary IDs become associated with a list of secondary IDs through a security exit (DSN3@ATH or DSN3@SGN) that is processed after connecting to DB2. The type of connection you make to DB2 determines the exit used. The table below shows which exit is used for a particular connection type.
|
SAF Connection Type |
Attach Exit (DSN3@ATH) |
Sign‑on Exit (DSN3@SGN) |
|---|---|---|
|
BATCH |
TSO Batch jobs Started tasks Utilities CAF jobs Anything other than CICS or IMS tasks |
Does not apply |
|
SASS (CICS) |
CICS recovery coordinator task |
CICS recovery coordinator task CICS transactions |
|
MASS (IMS) |
IMS control region (recovery coordinator) |
IMS control region MPPs BMPs Fast path DL/I batch |
|
DIST |
Distributed data facility (DDF) |
Does not apply |
Before the CA ACF2 Option for DB2 interface, CA ACF2 provided exits to replace the IBM DSN3@ATH and DSN3@SGN exits. You can use these exits to build the secondary ID list based on entries in source group records. This processing enables CA ACF2 to supply secondary IDs to DB2.
With CA ACF2 Option for DB2, you might not need secondary authorization IDs if you are using them to group primary IDs for resource access and to minimize the cascade effect. However, some sites have obtained additional benefits from these IDs that do not involve resource access or eliminating the cascade effect. For example, users running an application that refers to an unqualified table name can use different versions of the table by changing their current SQL ID to one of their secondary IDs. Another example might be a group of users sharing a common group of synonyms by changing the current SQL ID to a common secondary ID. You can continue to use these IDs if you want, however, these IDs can blur the lines of individual accountability. Multiple IDs are difficult to maintain and create significant performance overhead.
In CA ACF2 Option for DB2, the UID accomplishes approximately the same results as the secondary authorization ID when the secondary ID is used to group primary authorization IDs for resource access and to avoid the cascade effect. When specified by the UID parameter in CA ACF2 Option for DB2 rules, the UID identifies which users or groups of users can perform a particular function on a resource. Its fields can correspond to functions identified by secondary IDs. For example, a UID (such as CHFINCLKUSER01) might represent the city (CHicago), the division (FINance), the function (CLerK), and the user (USER01). Historically, secondary IDs might have been created to represent these types of values.
You can also enable the UID to dynamically change by including the GROUP field. GROUP gives users the privileges of another group not represented in their UID. For example, if your UID is designed to include the GROUP field, a TSO or batch user can supply a group value at sign‑on time that he wants to associate with. If he is authorized, he can add the privileges of this group to his logonid privileges for that session. See “Introducing CA ACF2 Option for DB2,” for more information about the UID and about using this feature with CA ACF2 Option for DB2. You also will find complete information about the GROUP field in the CA ACF2 Administrator Guide.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|