DB2 TSS ACCESSOR value in Top Secret
Article ID: 209374
Updated On:
Products
Issue/Introduction
With DB2 access, where does Top Secret obtain the ACCESSOR value?
When a batch job runs with a USER parameter on the JOB statement, activity happens in the CICS region which runs this DB2 application, one of the DBAs name is listed as the ACCESSOR. I would expect to see the value coded as the USER parameter. I am seeing this in both the TSS audit report.
With DB2 access, where does Top Secret obtain the ACCESSOR value?
Resolution
All security calls are checked against the authids(acids) according to DB2 rules for authorization. Those calls occur against a variety of authids depending upon the functions being performed and the environment at the time of the check. For each of those security checks, DB2 provides a primary authorization id and, optionally, a list of secondary authids to be used for the check.
Typically, users should expect a security check to occur against the primary authids for a thread, which normally would be the signed on user in the allied address space such as TSO or CICS. That is normally the case for resource checks such as execute access against DB2PLANs, or with almost any dynamic SQL such as selecting from a table.
There are, however, situations when a static plan is run which requires an access check for a resource against the plan or package owner. Typically, for static plans and packages, there is little to no security checking performed against the primary authids (signed on user) other than the check for execute access to the plan. It is also possible for DB2 applications to specifically set the authids to be used to access a resource via statements such as SET CURRENT SQLID = xxxxxxxx.
* Each situation is unique and would require investigation to see why DB2 has chosen to provide authids for the resource check *
First, from the resource class and entity shown in the case, DB2TABLE(PEPROD.TBLEA1), it seems clear you are using TSSDB2 for external DB2 security. All security calls are checked against the authids(acids) according to DB2 rules for authorization. Those calls occur against a variety of authids depending upon the functions being performed and the environment at the time of the check. For each of those security checks, DB2 provides a primary authorization id and, optionally, a list of secondary authids to be used for the check.
Typically, you might expect a security check to occur against the primary authids for a thread, which normally would be the signed on user in the allied address space such as TSO or CICS. That is normally the case for resource checks such as execute access against DB2PLANs, or with almost any dynamic SQL such as selecting from a table.
There are, however, situations when a static plan is run which require an access check for a resource against the plan or package owner. Typically, for static plans and packages, there is little to no security checking performed against the primary authids (signed on user) other than the check for execute access to the plan. It is also possible for DB2 applications to specifically set the authids to be used to access a resource via statements such as SET CURRENT SQLID = xxxxxxxx.
The bottom line is each situation is unique and would require investigation to see why DB2 has chosen to provide that authids for the resource check.
Additional Information
For information on DB2 reference the link below:
For information on SQLID reference the link below:
Feedback
