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 authorization IDs help reduce some of the security issues surrounding the "cascade effect" a DB2 REVOKE causes.
The two exits 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 region 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 user in a MUSASS region 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 authorization IDs that you can be use for validations in addition to the primary authorization ID. The primary authorization 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 authorization 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 the installation CAIMAC library. Assembly and link edit instructions can be found in the CAIMAC members as comments.
To use the CA-ACF2 exit routines at your site, you must define source group records. Source group records identify secondary authorization IDs. To determine the secondary ID, the exits provide CA-ACF2 with the DB2 primary authorization ID. CA-ACF2 reads CA-ACF2 source group records, prepares a list of secondary authorization IDs, and returns this list to DB2.
You can use entry source group (E-SGP) records or cross-reference source group (XSGP) 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.
In the following examples the secondary authids are DB2ID1, DB2ID2 and
DB2ID3. The primary ids are LID1, LID2, LID3 and LID4.
This example shows how to create X-SGP source group entries for
each secondary ID.
ACF
SET XREF(SGP)
INSERT DB2ID1 INCLUDE(LID1 LID4) SOURCE
INSERT DB2ID2 INCLUDE(LID1) SOURCE
INSERT DB2ID3 INCLUDE(LID1 LID4) SOURCE
The next example adds LID2 to the DB2ID2 source group and LID3
to the secondary IDs DB2ID2 and DB2ID3 source groups:
CHANGE DB2ID1 INCLUDE(LID2)
CHANGE DB2ID2 INCLUDE(LID2)
CHANGE DB2ID3 INCLUDE(LID3)
This example shows how to create E-SGP source group entries for
each secondary ID.
ACF
SET ENTRY(SGP)
INSERT DB2ID1 NEWDATA(LID1)
INSERT DB2ID2 NEWDATA(LID1)
INSERT DB2ID3 NEWDATA(LID1)
The next example adds LID2 to the DB2ID2 source group and LID3
to the secondary IDs DB2ID2 and DB2ID3 source groups:
CHANGE DB2ID1 NEWDATA(LID2)
CHANGE DB2ID1 NEWDATA(LID4)
CHANGE DB2ID2 NEWDATA(LID2)
CHANGE DB2ID3 NEWDATA(LID3)
CHANGE DB2ID3 NEWDATA(LID4)
The following chart shows the list of secondary authorization IDs
that CA-ACF2 passes to DB2 when each logonid connects to DB2
based on either of the above X-SGP or E-SGP groups:
[font=Courier New]---------------------------------------------------
If the logonid is: CA-ACF2 passes this list:
---------------------------------------------------
LID1 DB2ID1
DB2ID2
DB2ID3
---------------------------------------------------
LID2 DB2ID1
DB2ID2
---------------------------------------------------
LID3 DB2ID1
DB2ID3
---------------------------------------------------
LID4 DB2ID1
DB2ID3
--------------------------------------------------[font]