MAINFRAME > Tips & Techniques > Systems Management

Securing the CICS Environment With RACF

In my career I worked in RACF administration for a few years without ever encountering the complexities of RACF grouping classes that CICS uses. When I finally did, I found it difficult to understand at first.

In my career I worked in RACF administration for a few years without ever encountering the complexities of RACF grouping classes that CICS uses. When I finally did, I found it difficult to understand at first.

CICS* RACF* security is a complex and difficult subject with many layers and facets. A good understanding of basic RACF functions is essential to appreciate the sophisticated exploitation of RACF classes that CICS employs.

In my career I worked in RACF administration for a few years without ever encountering the complexities of RACF grouping classes that CICS uses. When I finally did, I found it difficult to understand at first. Hence, this article is primarily about RACF grouping classes - it just happens that CICS (and many other z/OS* subsystems and applications) use this RACF feature. This article should provide an understanding of how RACF is used to secure the CICS environment, primarily CICS transactions. To do this I must explain RACF grouping classes, starting first with basic RACF classes and their access lists.

Resources and Profiles

Remember that RACF protects resources with profiles. It's important to distinguish the difference between these two concepts. A resource is something that exists - it's real, perhaps a dataset or a business process implemented as a CICS transaction. Resources do or are something. A profile doesn't exist in the same sense - it's a construct defined in the RACF database that describes the security privileges to be applied to the resource it protects. Normally profiles protect resources based on the masking of the profile name (using generic pattern matching) to the resource name. A RACF profile can be thought of as metadata used by z/OS (via RACF) to manage the resource.

For example, the dataset class profile SYS1.** may protect the resource SYS.PARMLIB. The association between the resource and the profile in this case is obvious - they match using generic pattern matching. With grouping classes the association may not be so obvious. Grouping classes work differently than "normal" RACF classes in that the profile you typically work with in RACF isn't a generic pattern match for the resources you use it to protect. Instead, the profile contains structures referred to as members, which actually match the resource(s) to be protected.

RACF Grouping Classes

An example with help explain members. Assume I have two CICS transactions named RTCK and XFAB. These transactions are involved in a particular business function, and all users requiring access to one also require access to the other. In other words, these transactions require identical RACF access lists in the profile(s) that protect them.

I could simply create two RACF profiles with names such as RT* and XF*, each with its own access list, to protect the application resources. But if a new transaction is added to this application - say transaction ABCD - I must create a third profile AB*, and duplicate the access list associated with the other transactions to this new one. This would eventually become a maintenance nightmare, with multiple transactions defined with the same access list. If I need to change the access list to add a new group of business users, for instance, then I need to make this simple update in multiple places. Additionally, how will I know which transaction definitions need to be updated? There's no easy method in native RACF to find profiles with identical access lists. Eventually business operations will be impacted as a result of this overly complex situation.

This is where RACF grouping classes come to our rescue. With a grouping-class profile you can define one access list and associate this with many transaction definitions, thus effectively cloning the access list through all the relevant transaction definitions. These cloned-transaction definitions are known as grouping-class members. Two RACF classes are involved in CICS transaction-level security: GCICSTRN and TCICSTRN - respectively the grouping- and member-related classes. These classes are the defaults that RACF provides and are sometimes supplemented by additional pairs of classes using site modifications to the RACF Class Descriptor Table.

Michael Cairns works for IBM as a technical specialist in the Tivoli zSecure range of software. Michael can be reached at mike.cairns@au1.ibm.com.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Optimal Service Delivery

Overcome eight key challenges and reduce costs

MAINFRAME > TIPS & TECHNIQUES > SYSTEMS MANAGEMENT

An Accurate Benchmark Is Important

Advice for the Lazy Administrator

Steps you can take to avoid late nights and system frights.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters