Mulitple CICS region - Transaction Access control

[Prem Kannan]

Hello,

 

In one of our system we have four CICS regions sharing the same ACF2 DB, uses the same CICS resource type code [CKC]. I have a request to block a user' access to CEMT transaction on one region only, is this possible, if yes, how can I accomplish it. Thanks in advance.

[Anon Anon]

An interesting situation.  Is there something in particular related to CEMT that the requestor is endeavoring to block?  I ask because such a request should also take into account other means of doing CEMT-like things, i.e., the CECI command interpreter and access to CICS SPI (system programmer interface) commands (or via other CICS programs), as well as other programmatic-type interfaces and/or OEM/ISV vendor products that might do the same thing.

 

As for providing such compartmentalized access in an ACF2 environment - there really are no methods of writing a single resource rule that will behave one way when used on systems A, B, and C - but differently when used on system D.  The only environmental elements that might be used within the rule itself might be the UID string itself (if it were different between these systems, a potential problem area in of itself if it were different), or perhaps the SOURCE name (if there were some means to distinguish between a terminal/source on one system to that of a terminal/source from another system.

 

I should add that you can always write an exit program to handle this type of exception processing, but process clarity and audit procedures may dictate that such an approach not be followed.

 

Keep in mind that one might be able to still get to the CEMT on the system where it requires special protections from another CICS TOR by means of the CICS routing transaction, CRTE, or, if implicit transaction routing names for CEMT transactions were defined - via such a request (e.g. DEMT being an implicitly routed transaction ID defined on systems A, B, and/or C which route the transaction over to SYSTEM D).

 

Hope this helps!

 

Regards,

 

Dave Hrycewicz

Sr. Principal Software Engineer

CA ACF2 Development

Lisle, IL

[Prem Kannan]

Hi Dave, with respect to your response, specifically, with reference to the alternate approach of using SOURCE restriction, thinking out loud, is there a possibility where the 4 char CICS region ID / name be used as a SOURCE name, i.e, the cross-reference or entry source group name be of CICS region id / name, instead of terminal name.

[This may change the entire concept of SOURCE validation, but was wondering if similar such option can be implemented ?].

[Anon Anon]

That's certainly a possibility.  A place to start is the CICS Support Guide and Chapter 10, CICS Interface User Exits, specifically the SOURCE name exit.  I don't know off the top of my head what circumstances exist, if any, for which this exit wouldn't get control.  I'd be curious, for instance, to see what happens in an MRO environment.  Also, the exit documentation gives some description of what is used when a transaction is validated against a default Logonid.  Obvious other things to check would be any existing source restrictions, whether in the Logonid records themselves, resource rules, user exits, and more.  Finally, the auditor and security administrator should be consulted to ascertain whether such a change to source name is acceptable.

[Jake_Phillips]

We use the CICSKEY of the ACF2PARM to drive the use of a different resource type for some regions. Of course this would require rules to be set up for all the transactions used by this region. It may be too administratively burdensome to implement, but it is worth considering...

 

Good luck!

Jake