How can I setup DB2 with Secondary Authorization IDs with ACF2?
Article ID: 28125
Updated On:
Products
Issue/Introduction
Under native DB2 security, many DB2 security administrators use secondary authorization IDs (Auth IDs) to simplify DB2 security administration. Secondary auth IDs enable more than one user to exercise ownership privileges over a group of objects. With secondary Auth IDs, users can easily obtain additional privileges in a DB2 subsystem without these privileges being granted specifically to them. This eliminates the need to revoke privileges from users who are terminated or transferred, which in turn eliminates the cascade effect. With secondary Auth IDs, security administrators maintain only who has access to the secondary Auth IDs and do not have to worry about revoking privileges from the wrong people.
Some sites have used the architecture of secondary Auth IDs for purposes other than to obtain the privileges of a group authorization ID for resource access. For example, sites have designed applications that use unqualified table names so that users can access different versions of the table by changing the current SQL ID. However, if you do use secondary Auth IDs strictly to grant access to group authorization IDs and to avoid the cascade effect, you may be able to use the UID string in CA-ACF2 for DB2 product. Using this feature would eliminate the need for secondary Auth IDs (see below). You may want to do this because secondary Auth IDs can blur the lines of individual accountability, which is central to CA-ACF2 security philosophy. CA-ACF2 for DB2 uses logonids at connection time to uniquely identify users. A unique logonid prevents one user from posing as another and makes it possible for CA-ACF2 for DB2 to trace the activity to a specific individual.
While the logonid identifies individuals at connection time and in reports, CA-ACF2 for DB2 uses the user identification string (UID) to determine who can access a resource. For CA-ACF2 for DB2, the UID accomplishes the same results as a secondary Auth ID when it is used to group IDs for resource access. The UID enables a user to access resources based on the user's UID values assigned to him. The CA-ACF2 for DB2 Administrator Guide contains a section entitled What Is a UID explaining the UID further. The UID in CA-ACF2 for DB2 eliminates the cascade effect and thus one of the reasons to use secondary Auth IDs.
If your site has already defined secondary Auth IDs and wants to continue using them, CA-ACF2 for DB2 supports the use of these IDs. Refer to Appendix A, "Using Secondary IDs," in the CA-ACF2 for DB2 Planning and Installation Guide for information about using these secondary Auth IDs with CA-ACF2 for DB2.
For sites not using CA-ACF2 for DB2, when using secondary Auth IDs an exit must be used and source groups must be defined in the CA-ACF2 base product
Environment
Component: ACF2MS
Resolution
DB2 provides two exits that let you inspect or modify a user's identity to DB2. These exits supply a list of alternate or "secondary" authorization IDs that DB2 can use in its internal verification routines. These secondary Auth IDs help reduce some of the security issues surrounding the "cascade effect" a DB2 REVOKE privilege causes.
The exits you use are DSN3@ATH and DSN3@SGN. You must link-edit them into the DB2 library. DSN3@ATH is a connection authorization exit that gets control at MUSASS startup and during each TSO or batch job access to DB2. DSN3@SGN is a sign-on exit similar to DSN3@ATH. DSN3@SGN gets control whenever a MUSASS user requests a DB2 resource. DB2 invokes these exits to let you to inspect or modify the user's primary authorization ID. Both exits can provide DB2 with a list of secondary Auth IDs that you can use in addition to the primary authorization ID. The primary Auth ID is usually the logonid of the user accessing the system.
CA-ACF2 provides two sample exits that you can use instead of IBM-supplied default exits. They associate a list of secondary Auth IDs to a logonid or primary authorization ID. They also set the value of the current SQL ID. These exits, CSECT DSN3@ATH and CSECT DSN3@SGN, reside in members ACF3@ATH and ACF3@SGN, respectively, of ACF2.CAX1MAC0 installation library.
Note these exits should be re-assembled and linked anytime there is an upgrade to DB2 or CA ACF2 for z/OS.
Instructions:
To use the CA-ACF2 exit routines at your site, you must define source group records. Source group records identify secondary Auth IDs. To determine the secondary Auth ID, the exits provide CA-ACF2 with the DB2 primary authorization ID. CA-ACF2 reads the source group records, prepares a list of secondary Auth IDs, and returns this list to DB2.
You can use entry source group (E-SGP) records or cross-reference source group (X-SGP) records to identify the secondary IDs. However, if you plan to convert to CA-ACF2 for DB2 in the future, be aware that the CA-ACF2 for DB2 conversion utility that translates DB2 catalog entries into rule entries does not accept X-SGP records. You must use E-SGP records with the conversion utility.
The following examples show how to define entry source group (X-SGP) records for secondary Auth IDs. In these examples, LID1, LID2, and LID3 are the logonids. The secondary Auth IDs are DB2ID1, DB2ID2, and DB2ID3. This example shows how to create source group entries for each secondary Auth ID. For full use of XREF groups, please refer to the CA-ACF2 Administrator Guide.
ACF
SET XREF(SGP)
INSERT DB2ID1 INCLUDE(LID1) SOURCE
INSERT DB2ID2 INCLUDE(LID1) SOURCE
INSERT DB2ID3 INCLUDE(LID1) SOURCE
The next example adds LID2 to the DB2ID2 source group and LID3 to the secondary AUTH IDs DB2ID2 and DB2ID3 source groups
CHANGE DB2ID2 INCLUDE(LID2)
CHANGE DB2ID2 INCLUDE(LID3)
CHANGE DB2ID3 INCLUDE(LID3)
The chart below shows the list of secondary Auth IDs that CA-ACF2 passes to DB2 when each logonid connects to DB2:
| If the logonid is: | CA-ACF2 passes this list: |
| LID1 | DB2ID1 DB2ID2 DB2ID3 |
| LID2 | DB2ID1 DB2ID2 |
| LID3 | DB2ID1 DB2ID3 |
Feedback
