Selecting authorization IDs for performance and maintenance

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. CICS® transactions that acquire a thread into Db2 are considered as processes, and must provide authorization IDs.

Providing authorization IDs to Db2 for the CICS region and for CICS transactions tells you how to choose and set up the authorization IDs that a CICS transaction passes to Db2 when the thread used by the transaction signs on to Db2. The authorization IDs for a transaction are determined by attributes in the resource definition for the thread that the transaction uses. For entry threads, this is the DB2ENTRY definition, and for pool threads or command threads, this is the DB2CONN definition.

When choosing the type of authorization ID that a CICS transaction will use, you should take into account performance and maintenance considerations.

Performance considerations for authorization IDs

From the point of view of performance:
  • Choosing one of the options USERID, OPID, TERM, TX or GROUP on the AUTHTYPE attribute means that any CICS transaction using a Db2 thread is likely to have a different authorization ID from the last transaction that used the thread. This causes sign-on processing to occur.
  • Choosing the SIGN option, or using the AUTHID attribute instead of the AUTHTYPE attribute, means that CICS transactions will have the same authorization ID. If the transactions using a thread have the same authorization ID, sign-on processing can be bypassed.
  • Choosing the ACCOUNTREC attribute can require a partial sign-on. However, the full sign-on process will be bypassed when AUTHTYPE(USERID) is also specified.

However, although the options USERID, OPID, TERM, TX or GROUP have disadvantages for performance, they make Db2 security checking more granular. For example, if a transaction's thread is defined with AUTHTYPE(USERID), Db2 security checking uses the CICS user ID of the individual that is using the transaction. If a transaction's thread is defined with AUTHTYPE(SIGN), the Db2 security checking uses the SIGNID that has been defined for the whole CICS region, so Db2 is only checking that the CICS region is permitted to access Db2 resources. If you do use one of the options that gives the same authorization ID for all transactions, you should use CICS transaction security to restrict access to transactions (see Controlling users' access to Db2-related CICS transactions).

An alternative solution for plans is to use a GRANT command in Db2 to give EXECUTE authority on a plan to PUBLIC, because this also causes sign-on processing to be bypassed. Db2 ignores the changed authorization ID. This is not quite as efficient as using a constant authorization ID and transaction id, because some processing still takes place in the CICS Db2 attachment facility. Security considerations for your Db2 subsystem could prevent the use of this solution, as it allows no security checking for the plan within Db2.

Maintenance considerations for authorization IDs

From the point of view of maintenance:
  • When you use the options USERID, OPID, TERM, TX or GROUP for authorization IDs, you need to grant permissions in Db2 to a greater number of authorization IDs. For example, if a CICS transaction executes a plan in Db2, and the transaction's thread is defined with AUTHTYPE(USERID), you need to grant permission to use the plan in Db2 to all the CICS user IDs of individuals who can use the transaction.
  • If you use the SIGN option, or use the AUTHID attribute instead of the AUTHTYPE attribute, you need to grant permissions to fewer authorization IDs.

However, as already mentioned, using a limited range of authorization IDs makes the Db2 own security checking less granular. If your priority is security, but you are concerned about high levels of maintenance in your Db2 system, a possible solution is to set up secondary authorization IDs for CICS users. Providing secondary authorization IDs for CICS transactions tells you how to do this. You can create a RACF® group, and connect your CICS users to this RACF group. Use the GROUP attribute of the DB2ENTRY definition for the thread used by the transaction, so that the RACF group is one of the secondary IDs that is passed to Db2. Then grant Db2 permissions to the RACF group. To remove a CICS user's Db2 permissions, disconnect them from the RACF group. If you use this solution, Db2 security checking can ensure that individual CICS users are authorized to access resources within Db2, but you do not have to specifically grant permission to each CICS user ID.