Data Center Strategies for the CIO
Out-of-the-box CICS does a pretty good job of locking down resources. The rules are kept in the very secure Resource Access Control Facility (RACF) repository, and CICS performs authorization
Requires Free Membership to View
checks outside the reach of application code and most system code. However, there are
instances when an enterprise may want to use an existing rule in a new way or seek to secure
something CICS can't understand.
Using the CICS QUERY SECURITY command
Most External Security Manager calls require Authorized Programming Facility authorization, which
is difficult to get in CICS, where most code runs in problem state. IBM gave us the EXEC CICS QUERY
SECURITY command for accessing security services.
As documented in the CICS Application Programming Reference Manual (APRM), EXEC CICS QUERY SECURITY has two basic forms. One form queries rules for CICS defined resources (e.g., transactions, files) based on resource classes specified in the System Initialization Table (SIT). The second form allows a program to check any security rule. The output parameters tell the caller what accesses the user has to the resource: ALTER, CONTROL, READ or UPDATE. Another parameter controls the issuance of security violation messages to the CICS job log. You can eliminate a lot of console clutter by turning off ICH408 messages, but I would recommend leaving a debug switch in the program to enable the error messages in a pinch.
Securing CICS Resources
As mentioned above, CICS already does a pretty good job of securing its resources. However, there
are some cases when you may want to check a user's authorization for a resource before actually
touching it. This enables the application to produce a pretty error message instead of ABENDs or
the dreaded "unpredictable results."
For instance, assume we want to train new employees on the production system where they can read files but not update them. To make the experience as real as possible, we check the user's security and bracket any update logic with a check of the authorization flag.
To do this, we add the following command to the beginning of a business (not CICS) transaction:
XEC CICS QUERY SECURITY RESTYPE('FILE') RESID('CIFFILE') RESIDLENGTH(7) UPDATE(UPDTFLAG) NOHANDLE
This command checks the user's authority against the CICS RACF rules class as specified in the
SIT, just as if the transaction had tried to do I/O against file CIFFILE. After a successful
execution of the command field, UPDTFLAG will be set to CICS Value Data Areas (CVDA) values
UPDATEABLE or NOTUPDATEABLE. Based on that information, the application can set switches to be
passed through the business transaction. As the transaction progresses, each program can check the
flags to see if an update should be actually be done or not. Once the user is fully trained, the
security team can authorize the employee with a simple rule change.
The APRM lists the possible resource types. Note that some of them might return "not found" from
the QUERY command if the resource isn't defined on the region.
Securing non-CICS resources
Sometimes the problem isn't securing a CICS resource, but rather something inside of it. For
instance, a company wants all of its representatives to be able to look at all customer records
while ensuring that they can only update accounts in states for which they are trained. For this,
we assume every customer record has a two-byte state ID for where they live.
The next step is to define a RACF class, for instance STATECTL, to hold the resource rules. There are 50 resources in STATECTL -- one for each of the states. All representatives have read access to each resource in the class. However, employees have update access only to the resources representing the states for which they're authorized.
To check a representative's access, the application should issue this command at some point:
EXEC CICS QUERY SECURITY RESCLASS('STATECTL') RESID(INPSTATE) RESIDLENGTH(2) UPDATE(UPDTFLAG) NOHANDLE
Thus, to check if a representative is able to update records for a customer in Texas, the
program would move "TX" to field INPSTATE and issue the command. If field UPDTFLG comes back
UPDATEABLE, the representative can proceed. Otherwise, the employee should see an error messaging
asking him or her to forward the call to a representative trained for Texan customers.
For the sake of completeness, note that the second form of this command may be used to check CICS
resource access, too. For instance, if SIT parameter XTRAN is set to CICSTRN, CICS uses resource
RACF class GCICSTRN to check transaction authorization rules. Therefore, to check a user's
transaction access, a program could use this command:
EXEC CICS QUERY SECURITY RESCLASS('GCICSTRN') RESID(TRANNAME) RESIDLENGTH(4) READ(READFLAG) NOHANDLE
However, this gets to be complicated quickly, as the program has to be sensitive to the CICS and RACF environment.
Conclusion
These dopey examples break the cardinal rule of keeping security checks out of application code.
However, the additional functionality may be valuable enough to bend the rules a little. There's
also no reason why the QUERY SECURITY command couldn't be isolated into a module owned by technical
support, with its own safeguards around it.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about
your data center concerns at mstansberry@techtarget.com.
This was first published in March 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation