In the CICS® region, CICS users might need to perform the
following DB2®-related activities:
- Inquire on, modify, create or discard DB2CONN, DB2ENTRY, and DB2TRAN
resource definitions.
- Use a transaction that accesses DB2 to obtain data, or issue CICS
DB2 attachment facility commands or DB2 commands using the DSNC transaction.
As far as the CICS region is concerned, you can control access
to all these resources and initiate security checking for them, by
enabling RACF®, or an equivalent external security manager,
for the CICS region, and enabling the appropriate CICS security mechanism
(transaction-attach security, resource security, command security,
or surrogate security). When a user tries to access protected resources,
CICS calls the external security manager to perform security checking.
RACF makes security checks using the CICS user's ID, which is authenticated
when the user signs on to CICS. If a user does not sign on to CICS,
they are given the default user ID, unless a user ID has been permanently
associated with a terminal using preset security.
This topic describes how to control users' access to DB2-related
resources in the CICS region, as follows:
Some of the DB2-related resources in the CICS region are subject
to further security checking by DB2's security mechanisms, and this
topic tells you where this applies.
For wider information about the CICS security topics discussed
here, such as command and resource security in general, see the CICS RACF Security Guide.
You can control users' access to DB2CONN, DB2TRAN, and DB2ENTRY
resource definitions on several levels, by enabling different CICS
security mechanisms:
- Control users' ability to access particular resources by using
the CICS resource security mechanism. Resource
security is implemented at the transaction level. For example, you
could prevent some users from modifying a particular DB2ENTRY definition. Using resource security to control access to DB2ENTRY and DB2TRAN
resources tells you how to use this security mechanism.
- Control users' ability to issue particular SPI commands against
DB2-related resources by using the CICS command security mechanism.
Command security is also implemented at the transaction level. For
example, you could permit only certain users to issue CREATE and DISCARD
commands against DB2ENTRY resource definitions. Using command security to control using SPI commands for DB2
resources tells
you how to use this security mechanism.
- Control users' ability to modify the authorization IDs that CICS
provides to DB2, by using the CICS surrogate security
and AUTHTYPE security mechanisms. The authorization IDs are used
for DB2's own security checking, and they are set by the AUTHID, COMAUTHID,
AUTHTYPE and COMAUTHTYPE attributes on DB2-related resource definitions,
and by the SIGNID attribute on the DB2CONN definition for the CICS
region. CICS checks that the user who wants to modify the authorization
ID, is permitted to act on behalf of the existing authorization ID
that is specified in the resource definition. Using surrogate security and AUTHTYPE security to control access
to authorization IDs tells
you how to use these security mechanisms.
The CICS resource security mechanism controls users' access to
named CICS resources. For example, you can use it to protect certain
resources -- such as a particular DB2ENTRY definition --
from being modified by particular users. CICS command security, which
is also described in this section, can prevent users from performing
certain actions on types of resources, such as "all DB2ENTRY definitions",
but it cannot protect individual items within the resource type.
Because your CICS region only has one DB2CONN definition, you do
not need to use resource security to protect it; you can control access
to the DB2CONN definition using command security. Also, DB2TRAN definitions,
for the purpose of resource security, are treated as extensions of
the DB2ENTRY definition to which they refer, and are not defined for
resource security in their own right. If you give a user permission
to access a DB2ENTRY definition, you also give them permission to
access the DB2TRAN definitions that refer to it.1 For
resource security, you therefore only need to define your DB2ENTRY
definitions to RACF.
When resource security is enabled for a transaction, the external
security manager checks that the user ID associated with the transaction
is authorized to modify the resource that is involved. "Resource security" in the CICS RACF Security Guide has
more information about this process.
To protect your DB2-related resources using resource security,
complete these steps:
- To enable RACF, or an equivalent external security manager, and
make resource security available for a CICS region, specify SEC=YES
as a system initialization parameter for the CICS region.
- In RACF, create general resource classes to contain your DB2-related
resources. You need a member class and a grouping class. Unlike the
RACF default resource class names for CICS, there are no IBM®-supplied
default class names for DB2ENTRYs. Create your own installation-defined
class names by adding new class descriptors to the installation-defined
part (module ICHRRCDE) of the RACF class descriptor table (CDT). For
an example of how to do this, see the IBM-supplied sample job, RRCDTE,
supplied in member DFH$RACF of CICSTS31.CICS.SDFHSAMP. This gives
an example of a member class called XCICSDB2, and a grouping class
called ZCICSDB2. This example uses the same naming convention as the
default resource class names for CICS. Do not use existing CICS class
names for DB2-related resource definitions; instead, create new class
names using a similar naming convention.
- Define profiles for your DB2ENTRY definitions in the resource
classes that you have created. For example, to add a number of DB2ENTRY
names to the XCICSDB2 resource class, use the RDEFINE command as follows:
RDEFINE XCICSDB2 (db2ent1, db2ent2, db2ent3.., db2entn) UACC(NONE)
NOTIFY(sys_admin_userid)
Protecting DB2ENTRY
resource definitions also protects access to associated DB2TRAN definitions,
because a DB2TRAN is considered to be an extension to the DB2ENTRY
to which it refers. You do not need to protect your DB2CONN definition
using resource security.
- To activate resource security for your DB2-related resources,
specify XDB2=name as a system initialization
parameter for the CICS region, where name is
the general resource class name that you defined for your DB2-related
resources.
- Specify RESSEC=YES in the resource definition for any transactions
involving DB2-related resources for which you want to enable resource
security. Now, when a user tries to use one of these transactions
to access one of the DB2-related resources that you have protected,
RACF checks that the user ID is authorized to access that resource.
- Give permission to your CICS users, or groups of users, to perform
appropriate actions on each DB2-related resource that you have protected.
Remember that if a user has permission to perform actions on a DB2ENTRY
definition, they are automatically authorized to perform the same
actions on DB2TRAN definitions associated with it.
The access that
users need to perform certain actions is as follows:
- INQUIRE command
- Requires READ authority
- SET command
- Requires UPDATE authority
- CREATE command
- Requires ALTER authority
- DISCARD command
- Requires ALTER authority
For example, you can use the PERMIT command to authorize
a group of users to modify a protected DB2ENTRY, db2ent1 in
class XCICSDB2, with UPDATE authority, as follows:
PERMIT db2ent1 CLASS(XCICSDB2) ID(group1) ACCESS(UPDATE)
The CICS command security mechanism controls users' ability to
issue particular SPI commands against types of DB2-related resource.
For example, you can use it to control which users are allowed to
issue CREATE and DISCARD commands against DB2ENTRY resource definitions.
Unlike resource security, CICS command security cannot protect individual
named resources; it is designed to protect types of resource. You
can use command security to protect DB2CONN, DB2ENTRY, and DB2TRAN
resource definitions.
When command security is enabled for a transaction, the external
security manager checks that the user ID associated with the transaction
is authorized to use that command to modify the type of resource that
is involved. "CICS command security"
in the CICS RACF Security Guide has more information about this process.
If you have both resource security and command security enabled
for a particular transaction, RACF performs two security checks against
the user ID. For example, if a transaction involves the user issuing
a DISCARD command against DB2ENTRY definition db2ent1,
RACF checks:
- That the user ID is authorized to issue the DISCARD command (ALTER
authority) against the DB2ENTRY resource type.
- That the user ID is authorized to access the DB2ENTRY definition db2ent1 with
ALTER authority.
To protect your DB2-related resources using command security, complete
these steps:
- To enable RACF, or an equivalent external security manager, for
a CICS region, specify SEC=YES as a system initialization parameter
for the region.
- Add the DB2 resource names DB2CONN, DB2ENTRY, and DB2TRAN as resource
identifiers in one of the IBM-supplied RACF resource classes for CICS
commands, CCICSCMD or VCICSCMD. Alternatively, you can use a user-defined
general resource class for your CICS commands. "CICS
resources subject to command security checking" in the CICS RACF Security Guide tells
you more about this. For example, you can use the REDEFINE command
to define a profile named CMDSAMP in the default class VCICSCMD, and
use the ADDMEM operand to specify that the DB2 resource types are
to be protected by this profile, as follows:
RDEFINE VCICSCMD CMDSAMP UACC(NONE)
NOTIFY(sys_admin_userid)
ADDMEM(DB2CONN, DB2ENTRY, DB2TRAN)
- To make command security available for a CICS region:
- If you have used the IBM-supplied RACF resource classes CCICSCMD
or VCICSCMD for CICS command profiles, specify XCMD=YES as a system
initialization parameter for the region. Specifying YES means that
CCICSCMD and VCICSCMD are used to build RACF's in-storage profiles.
- If you have used a user-defined general resource class for CICS
commands, specify XCMD=user_class as a system
initialization parameter for the region, where user_class is
the name of the user-defined general resource class.
- Specify CMDSEC=YES in the resource definition for any transactions
involving DB2-related resources for which you want to enable command
security. Now, when a user tries to use one of these transactions
to issue a command to modify one of the DB2-related resources that
you have protected, RACF checks that the user ID is authorized to
issue that command against that type of resource.
- Give permission to your CICS users, or groups of users, to issue
appropriate commands against each type of DB2-related resource. For
command security, you need to give separate permissions relating to
the DB2TRAN resource type, as well as to the DB2ENTRY resource type.
You can also protect the DB2CONN resource type (that is, the CICS
region's DB2CONN definition).
The access that users need to issue
certain commands is as follows:
- INQUIRE command
- Requires READ authority
- SET command
- Requires UPDATE authority
- CREATE command
- Requires ALTER authority
- DISCARD command
- Requires ALTER authority
For example, if you have defined the DB2 resource
types in the CMDSAMP profile as in the example in Step 2, you can
use the PERMIT command to authorize a group of users to issue EXEC
CICS INQUIRE commands against the DB2 resource types as follows:
PERMIT CMDSAMP CLASS(VCICSCMD) ID(operator_group) ACCESS(READ)
Within
a transaction, you can query whether a user ID has access to DB2 resource
types by using the EXEC CICS QUERY RESTYPE(SPCOMMAND) command, with
the RESID parameter specifying DB2CONN, DB2ENTRY, or DB2TRAN.
The CICS surrogate security and AUTHTYPE security mechanisms control
users' ability to modify the authorization IDs that CICS provides
to DB2. You can use it to ensure that only certain users are permitted
to change these authorization IDs, which are used for DB2's own security
checking. Surrogate security and AUTHTYPE security are set for the
whole CICS region, and any transactions that involve changes to the
authorization IDs are subject to them.
Providing authorization IDs to DB2 for the CICS region and
for CICS transactions explains how to select and change these
authorization IDs. To summarize, the authorization IDs that CICS provides
to DB2 are set by the AUTHID, COMAUTHID, AUTHTYPE and COMAUTHTYPE
attributes on DB2-related resource definitions, and by the SIGNID
attribute on the DB2CONN definition for the CICS region. To change
the authorization IDs, you first need authority to modify the DB2CONN
and DB2ENTRY definitions, which might be protected by command security
or resource security. Surrogate security provides an extra layer of
protection, because it involves CICS acting on DB2's behalf to check
that the user modifying the authorization ID, is permitted to act
as a surrogate for the existing authorization ID that is specified
in the resource definition.
True surrogate security provides security checking when a user
attempts to change the SIGNID, AUTHID or COMAUTHID attributes on a
DB2CONN or DB2ENTRY definition, all of which specify an authorization
ID that is used when a process signs on to DB2. CICS uses the surrogate
user facility of RACF to perform this checking. A surrogate user is
one who has the authority to do work on behalf of another user, without
knowing that other user’s password. When a user attempts to change
one of the SIGNID, AUTHID or COMAUTHID attributes, CICS calls RACF
to check that the user is authorized as a surrogate of the authorization
ID that is presently specified on the SIGNID, AUTHID or COMAUTHID
attribute.
For the AUTHTYPE and COMAUTHTYPE attributes, which give a type
of authorization ID to be used rather than specifying an exact authorization
ID, CICS cannot use true surrogate security. Instead, it uses a mechanism
called AUTHTYPE security. When a user attempts to change one of the
AUTHTYPE or COMAUTHTYPE attributes, CICS calls RACF to check that
the user is authorized through a profile that you have defined for
the resource definition in the RACF FACILITY general resource class.
Although AUTHTYPE security is not true surrogate security, it is enabled
by the same system initialization parameter, and you will probably
want to use it in addition to surrogate security, so the instructions
in this topic tell you how to set up both types of security.
Note that when DB2CONN and DB2ENTRY resource definitions are installed
as part of a cold or initial start of CICS, if surrogate security
and AUTHTYPE security are enabled, RACF makes surrogate security and
AUTHTYPE security checks for the CICS region user ID. If you install
DB2CONN and DB2ENTRY resource definitions in this way, ensure that
the CICS region user ID is defined as a surrogate user for any authorization
IDs specified in the resource definitions, and also that it is authorized
through the correct profiles in the RACF FACILITY general resource
class.
To implement surrogate security and AUTHTYPE security to protect
the authorization IDs that CICS provides to DB2, complete the following
steps:
- To enable RACF, or an equivalent external security manager, for
a CICS region, specify SEC=YES as a system initialization parameter
for the region.
- To activate surrogate security and AUTHTYPE security for a CICS
region, specify XUSER=YES as a system initialization parameter for
the region. This system initialization parameter enables both the
security mechanisms. When the security mechanisms are enabled, CICS
calls RACF to perform security checks whenever a transaction involves
EXEC CICS SET, CREATE, and INSTALL commands that operate on the SIGNID,
AUTHID, COMAUTHID, AUTHTYPE and COMAUTHTYPE attributes of DB2CONN
and DB2ENTRY resource definitions. For the SIGNID, AUTHID and COMAUTHID
attributes, RACF performs the surrogate security check, and for the
AUTHTYPE or COMAUTHTYPE attributes, RACF performs the AUTHTYPE security
check.
- For the purpose of surrogate security, you need to define appropriate
CICS users, or groups of users, as surrogates of any authorization
IDs that are specified on the SIGNID, AUTHID or COMAUTHID attributes
of your DB2CONN and DB2ENTRY definitions. To define a user ID as a
surrogate of an authorization ID:
- Create a profile for the authorization ID in the RACF SURROGAT
class, with a name of the form authid.DFHINSTL,
with the authorization ID defined as the owner. For example, if you
have specified DB2AUTH1 as an authorization ID on a SIGNID, AUTHID
or COMAUTHID attribute, use the following command to create a profile:
RDEFINE SURROGAT DB2AUTH1.DFHINSTL UACC(NONE) OWNER(DB2AUTH1)
- Permit appropriate CICS users to act as a surrogate for the authorization
ID, by giving them READ authority to the profile you have created.
For example, to permit a user with the ID CICSUSR1 to act as a surrogate
for the authorization ID DB2AUTH1, and therefore to install or modify
any SIGNID, AUTHID or COMAUTHID attributes that specify DB2AUTH1 as
the existing authorization ID, use the following command:
PERMIT DB2AUTH1.DFHINSTL CLASS(SURROGAT) ID(CICSUSR1) ACCESS(READ)
Repeat this process for all the authorization IDs that you have
specified on SIGNID, AUTHID or COMAUTHID attributes. Also, if you
might need to install DB2CONN and DB2ENTRY resource definitions containing
SIGNID, AUTHID or COMAUTHID attributes as part of a cold or initial
start of CICS, permit the CICS region user ID to act as a surrogate
for any authorization IDs specified by those attributes. (The defaults
for DB2CONN and DB2ENTRY resource definitions do not involve the AUTHID
and COMAUTHID attributes. The default SIGNID for an installed DB2CONN
definition is the applid of the CICS region.)
- For the purpose of AUTHTYPE security, you need to create a profile
for each of your DB2CONN or DB2ENTRY resource definitions in the RACF
FACILITY general resource class, and give appropriate CICS users,
or groups of users, READ authority to the profiles. (This process
imitates the true surrogate security mechanism, but does not involve
the use of a specific authorization ID; instead, it protects each
resource definition.) To do this:
- Create a profile for the DB2CONN or DB2ENTRY resource definition
in the RACF FACILITY general resource class, with a name of the form
DFHDB2.AUTHTYPE.authname, where authname is the name of the DB2CONN or DB2ENTRY
resource definition. For example, to define a profile for a DB2CONN
resource definition named DB2CONN1, use the following command:
RDEFINE FACILITY DFHDB2.AUTHTYPE.DB2CONN1 UACC(NONE)
- Give appropriate CICS users READ authority to the profile you
have created. For example, to permit a user with the ID CICSUSR2 to
install or modify the AUTHTYPE or COMAUTHTYPE attributes on a DB2CONN
resource definition named DB2CONN1, use the following command:
PERMIT DFHDB2.AUTHTYPE.DB2CONN1 CLASS(FACILITY) ID(CICSUSR2) ACCESS(READ)
Repeat this process for each of your DB2CONN and DB2ENTRY resource
definitions. Also, if you might need to install DB2CONN and DB2ENTRY
resource definitions containing AUTHTYPE or COMAUTHTYPE attributes
as part of a cold or initial start of CICS, give READ authority to
the CICS region user ID on the profiles for those resource definitions.
You can control users' access to
- CICS transactions that access DB2 to obtain data
- The DSNC transaction, and any other transactions that you have
set up, to issue CICS DB2 attachment facility commands and DB2 commands
by using the CICS transaction-attach security mechanism. When
transaction-attach security is enabled, RACF, or an equivalent external
security manager, checks that the CICS user is authorized to run the
transaction that they have requested.
To protect DB2-related transactions using transaction-attach security,
follow the instructions in "Transaction
security" in the CICS RACF Security Guide. The process is the same for all
CICS transactions; there are no special considerations for DB2-related
transactions as far as the transaction-attach security mechanism is
concerned. The instructions tell you how to:
- Set up appropriate system initialization parameters for the CICS
region to activate transaction-attach security (see "CICS
parameters controlling transaction-attach security" in the CICS RACF Security Guide ).
- Define transaction profiles to RACF for the transactions that
you want to protect (see "Defining transaction
profiles to RACF" in the CICS RACF Security Guide).
If you have defined transactions other than DSNC to issue CICS
DB2 attachment facility commands and DB2 commands (for example, if
you have created a separate transaction to run each command), remember
to define these transactions to RACF as well.
You can now control which CICS users can use transactions that
access DB2. Add the appropriate users or groups of users to the access
list for the transaction profiles, with READ authority. "Defining transaction profiles to RACF"
in the CICS RACF Security Guide has some recommendations about this.
For transactions that issue CICS DB2 attachment facility commands
and DB2 commands, bear in mind that:
- CICS DB2 attachment facility commands operate on the connection
between CICS and DB2, and they run entirely within CICS. DB2 commands
operate in DB2 itself, and they are routed to DB2. You can distinguish
DB2 commands from CICS DB2 attachment facility commands by the hyphen
(-) character, which is entered with DB2 commands.
- If you have access to the DSNC transaction, CICS allows you to
issue all of the CICS DB2 attachment facility commands and DB2 commands.
- If you have defined separate transactions to run individual CICS
DB2 attachment facility commands and DB2 commands, you can give different
CICS users authorization to subsets of these transaction codes, and
therefore to subsets of the commands. For example, you could give
some users authority to issue CICS DB2 attachment facility commands,
but not DB2 commands. CICS-supplied transactions for CICS DB2 has the names of the
separate transaction definitions that CICS supplies for the CICS DB2
attachment facility commands and the DB2 commands.
CICS DB2 attachment facility commands do not flow to DB2, so they
are not subject to any further security checking. They are only protected
by CICS transaction-attach security. However, DB2 commands, and CICS
transactions that access DB2 to obtain data, are subject to further
stages of security checking by DB2's own security mechanisms, as follows:
- When a transaction signs on to DB2, it must provide valid authorization
IDs to DB2. The authorization IDs are checked by RACF or an equivalent
external security manager.
- Because the transaction is issuing a DB2 command or accessing
DB2 data, the authorization IDs that it has provided must have permission
to perform these actions within DB2. In DB2, you can use GRANT statements
to give the authorization IDs permission to perform actions.
In addition, the CICS region itself must be authorized to connect
to the DB2 subsytem.
Providing authorization IDs to DB2 for the CICS region and
for CICS transactions tells you how to authorize the CICS region
to connect to the DB2 subsystem, and how to provide valid authorization
IDs for transactions.
Authorizing users to access resources within DB2 tells you how to grant permissions to the
authorization IDs that the transactions have provided to DB2.
In the case where
a transaction changes the name of the DB2ENTRY with which a DB2TRAN
definition is associated, a double security check is performed, to
verify the user's authority to modify both the old DB2ENTRY to which
the definition referred, and the new DB2ENTRY to which it will refer.
[[ Contents Previous Page | Next Page Index ]]