Providing authorization IDs to DB2 for the CICS region and for CICS transactions

For the purposes of security, DB2 uses the term “process” to represent all forms of access to data, either by users interacting directly with DB2, or by users interacting with DB2 by way of other programs, including CICS. A process that connects to or signs on to DB2 must provide one or more DB2 short identifiers, called authorization IDs, that can be used for security checking in the DB2 address space. Every process must provide a primary authorization ID, and it can optionally provide one or more secondary authorization IDs. DB2 privileges and authority can be granted to either primary or secondary authorization IDs. For example, users can create a table using their secondary authorization ID. The table is then owned by that secondary authorization ID. Any other user that provides DB2 with the same secondary authorization ID has associated privileges over the table. To take privileges away from a user, the administrator can disconnect the user from that authorization ID.

During connection processing and sign-on processing, DB2 sets the primary and secondary authorization IDs for the process to use in the DB2 address space. By default, DB2 uses the authorization IDs that the process has provided. However, both connection processing and sign-on processing involve exit routines, and these exit routines allow you to influence the setting of the primary and secondary authorization IDs. DB2 has a default connection exit routine and a default sign-on exit routine. You can replace these with your own exit routines, and a sample connection exit routine and sign-on exit routine are supplied with DB2 to assist you with this.