Introduction

IMS Connect, a vital component of IBM's mainframe environment, processes millions of IMS transactions per second. However, with the growing demand for secure and reliable mainframe connectivity, users have been seeking ways to enhance security measures for IMS Connect. To address these concerns, IMS Connect Extensions developed security validation for OTMA and Open Database workloads based on combinations of IMS Connect name, client IP address, and target IMS Connect port.

Recently, a new APAR PH57492 was introduced that allows a more granular validation of messages base on Client ID.  This new validation type verifies incoming OTMA transactions based on a combination of the IMS Connect name, client IP address, target IMS Connect port, and the Client ID.

In this blog, we've got the following terms to make it easier for you to understand types of Validation:

• Validation Type 1: IMS Connect
• Validation Type 2: IMS Connect+IP Address+Port
• Validation Type 3: IMS Connect+IP Address+Port+Client ID

It is important to note that Validation Type 2 may be utilized under certain conditions, even if Validation Type 3 is enabled. This is particularly applicable in cases where Validation Type 3 cannot be used for Open Database requests as the requests do not contain a Client ID. In such circumstances, Validation Type 2 is utilized instead. For further information regarding Validation Type 2, refer to the guidelines for validating an incoming OTMA transaction or DRDA request.

Prerequisites

To utilize this feature effectively, it is essential to ensure that your system meets the following requirements:

• An IBM IMS Connect system.
• IBM IMS Connect Extensions v3.1 installed with a minimum APAR level of PH57492.
• Security Access Facility (SAF) product installed.

This blog assumes that the IBM Resource Access Control Facility (RACF) is used as the SAF.

Activating Validation type 3 in IMS Connect Extensions

To utilize the security validation feature, you must select both Activate Security and Activate Validation within the System Definition panel. Once you have done this, you can select Validation Type 3 using the new prompt panel. Press PF4 and choose the desired validation type from the list provided. To choose Validation Type 3, type s next to Type 3.

Once you hit ENTER, the Validation type text IMS Connect+IP Address+Port+Client ID will appear next to the input field.

When you make changes to your subsystem, it's important to refresh it to ensure the changes take effect. Once you've done that, you can explore some common use cases. If you need to create an RACF profile for Validation Type 3, refer to the guidelines for validating an incoming OTMA transaction or DRDA request.

Use cases for Validation Type 3

Let's simplify the use case by assuming the following system environment in the scenarios below. This will make it easier for you to understand and follow along.

• IMS Connect's name is HFUI00
• Validation Type 3 is active for this IMS Connect.
• The OTMA transaction and DRDA request come from the same client, IPV4, at 192.168.54.116.
• Two users, USRID01 and USRID02, send transactions and requests from client applications "Client 1" and "Client 2", respectively.
• The target IMS Connect TCP and DRDA ports are 3302 and 3305, respectively.
• The non-blank Client ID used is TESTCLID.
• The blank Client ID means ' '. (8 spaces) This is equivalent to the situation where the Client ID is not specified.

The following are some images to show you the environment we're discussing.

Figure 1: When Client ID is TESTCLID:

Figure 2: When Client ID is ' ' (8 spaces):

Use case #1: Validate OTMA transactions with non-blank Client ID

Scenario:

1. The incoming OTMA transactions are validated by Validation Type 3.
2. The transaction has a non-blank Client ID.
3. Only the user, USRID01, can send the transactions.

In this case, the following RACF profile with UACC(NONE) must be created in XFACILIT class (XFACILIT class supports profiles up to 256 characters):

RDEFINE XFACILIT CEX.IPV4.HFUI00.192.168.054.116.03302.TESTCLID UACC(NONE)

The RDEFINE statement can be used to create a rule to restrict the IMS Connect server HFUI00 from accepting transactions with Client ID TESTCLID from a client-server 192.168.54.116 going to TCP port 3302. To allow the user USRID01 to send the transactions, READ access must be granted to the user USRID01 by using the following code:

PERMIT CEX.IPV4.HFUI00.192.168.054.116.03302 - 
       CLASS(XFACILIT) ID(USRID01) ACCESS(READ)

By this RACF profile, only USRID01 can send OTMA transactions to the IMS Connect HFUI00 from 192.168.54.116.

You can follow the scenario above if the Client ID is shorter than 8 bytes. Also, masks '*' can be used in the profiles, for example

RDEFINE XFACILIT CEX.IPV4.HFUI00.192.168.054.116.03302.TEST* UACC(NONE)

RDEFINE XFACILIT CEX.IPV4.HFUI00.192.168.054.116.*.TEST* UACC(NONE)

RDEFINE XFACILIT CEX.IPV4.HFUI00.192.168.054.*.*.TEST* UACC(NONE)

Use case #2: Accepting OTMA transactions with specific non-blank Client ID

Scenario:

1. The incoming OTMA transactions are validated by Validation Type 3.
2. The transactions are prevented if the Client ID has only blanks.
3. The transactions are allowed only if the Client ID is TESTCLID.

Before testing this behavior, this is a quick reminder: In the System Definition panel, you must update Security class field to $CEXVAL3. This will ensure everything runs smoothly, and you can focus on getting the desired results.

To ensure a smooth transition, it's important to note that OTMA transactions with a blank Client ID will not be accepted when working with IMS Connect. To proceed with the migration process, follow the guidelines explained below.

1. Create different resource classes $CEXVAL3 and activate them:

   RDEFINE CDT $CEXVAL3 CDTINFO(DEFAULTRC(8) POSIT(XXX) MAXLENX(246))
   SETROPTS RACLIST(CDT) REFRESH
   SETROPTS RACLIST(CDT)

2. Create the following profile for Validation Type 2:

   RDEFINE $CEXVAL3 CEX.IPV4.** UACC(NONE)

3. This profile prevents all incoming transactions by Validation Type 2.
4. Create profiles for Validation Type 3 and grant READ access to USRID01 as follows:

   RDEFINE $CEXVAL3 CEX.IPV4.HFUI00.192.168.054.116.03302.TESTCLID UACC(NONE)
   PERMIT CEX.IPV4.HFUI00.192.168.054.116.03302.TESTCLID - 
          CLASS($CEXVAL3) ID(USRID01) ACCESS(READ)

IMS Connect Extensions relies on a specific profile for Validation Type 2. This profile allows only OTMA transactions originating from USRID01 with Client ID TESTCLID. As a result, any other following cases are prevented from being processed.

Use case #3: Validate OTMA transactions with blank Client ID by Validation Type2

Scenario:

1. The incoming OTMA transactions are validated by Validation Type 3.
2. The transactions are processed if the Client ID has only blanks.
3. Only the user, USRID01, can send the transactions.

In this case, the following message is displayed in CEXPRINT:

CEX5186W Validation type 2 was performed because validation type 3 was active, and the Client ID was unspecified. Source:192.168.054.116. Target port:03302.

It is worth noting that in this incoming transaction, Validation Type 3 did not apply, and Validation Type 2 was utilized instead, despite Validation Type 3 being active. Additionally, the message about CEX5186W will only be shown once for each set of the client IP Address and the IMS Connect TCP port number.

To handle this case, the following profile should be created to grant READ access to USRID01:

RDEFINE XFACILIT CEX.IPV4.HFUI00.192.168.054.116.03302 UACC(NONE)  
PERMIT CEX.IPV4.HFUI00.192.168.054.116.03302 - 
       CLASS(XFACILIT) ID(USRID01) ACCESS(READ)

Use case #4: Validate DRDA requests

Scenario:

1. The incoming DRDA requests are validated by Validation Type 3.
2. Only the user, USRID01, can send the requests.

Regarding DRDA requests, it's important to note that they cannot have a Client ID, and Validation Type 3 is not applicable. In cases where Validation Type 3 is active for an IMS Connect system, Validation Type 2 is used instead. To properly validate a DRDA request, it's necessary to create the following specific profile:

RDEFINE XFACILIT CEX.IPV4.HFUI00.192.168.054.116.03305 UACC(NONE)

and grant READ access to USRID01:

PERMIT CEX.IPV4.HFUI00.192.168.054.116.03305 - 
       CLASS(XFACILIT) ID(USRID01) ACCESS(READ) 

Only USRID01 can send DRDA requests to port 3305 from 192.168.54.116 in HFUI00.

Conclusion

Throughout our exploration, we have encountered several scenarios where implementing Validation Type 3 could benefit your environment. This is particularly true when it comes to securing IMS transactions and requests. IMS Connect Extensions come equipped with various security features that can help.

If you would like to learn more about these features and how they can be leveraged to enhance the security of your IMS environment, refer to the IMS Connect Extensions documentation.