Support Identity-Propagation via JMS/MQ

This requirement has been re-evaluated. Looking at current plans, it is not likely that this would be implemented in the next two CICS TS releases, so correspondingly this requirement is being rejected. You have an opportunity to resubmit in twelve months time if you wish it to be considered then.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

This is a candidate for a future release

You can email us an enhanced business justification. Please send to cicsrfe@uk.ibm.com

Hello, regarding to your questions:

Question 1:
No, the requirement includes not only Websphere Application Server. We also need it for Microsoft .Net Application Server (IIS)

Question 2:
* The requirement includes JMS and native MQ-API.
* We agree, that existing 12-character UserID in MQMD is too short to store the distributed identity. A new field in MQMD oder RFH is more suitable.
* We think the best way will be to support ID-Prop without changing existing application code. Maybe a switch via configuration or via installing a APAR is a suitable way.
* Regarding a business use-case: I'm not able to change field: "Business Justification". How can I provide you with a potential Business Case?

Question 3:
Currently we don't use DPL bridge, but we agree with you, that it will be much easier to support id-prop in DPL-bridge as in MQGET or JMS-API. We realize that it's not possible to change the security context of running application. But if using triggering we suppose it should be possible (assuming the TriggerMessage is enhanced to also have to carry the distributed identity), because CICS starts a new task. We understand that this will be treated carefully (maybe only if Triggering is set to “TriggerEvery”), because if task makes subsequent MQGETS in same application, then identity cannot be changed and security context is that from first MQ-Message. For these scenarios (processing messages from different distributed identities within one triggered CICS transaction) it will be reasonable to have a API to examine identity from the WMQ message.

Question 4:
Regarding outgoing messages: if a distributed identity is present then it should be propagated automatically. But for special applications it should also be possible (assuming that the necessary authorization is given) to set the identity on a MQPUT-call, like you support it for MQMD UserIdentitifier.

Best regards,
Juergen

This requirement is about extensions to CICS support for identity propagation as done via CTG. The existing CICS support is for identity propagation via CTG only and is restricted to requests from WebSphere Application Server. We want to understand the scope of the requirement and, if possible, separate out and prioritise different aspects of the requirement. Specifically:

1. WebSphere Application Server has a well-defined security model that can provide CICS with a clearly defined set of security credentials. This is not necessarily true for any arbitrary software or devices that CICS can communicate with. Does this requirement include only communication with WebSphere Application Server (as done via CTG) or does it include communication with other systems. For example does it include:

   * Other Java EE Application Servers
   * Other Transaction monitors or application runtimes
   * Other arbitrary applications, devices, or whatever.

2. The requirement specifically asks for identity propagation support of JMS/MQ. Does this mean "JMS with WebSphere MQ as the provider" (so that the API and message formats are JMS) or does it mean "JMS or WebSphere MQ" (so that the API and message formats include JMS and everything else that WMQ supports)?

We believe that this requirement requires passing more -- and more complex -- identity information than just a "User ID". For JMS it is reasonably easy to transport such identity information -- either as well as or instead of the existing simple User ID -- in message properties. The existing JMSXUserID property could possibly be used for this or the JMSXUserID could continue to be used unchanged but with other property or properties containing supplementary identity information. Either way, this would need agreement between the producing and consuming systems and/or as a more generally applied standard. But it could be done in a way that does not require any code changes to existing JMS-compliant application programs.

We assume the existing 12-character user-ID (MQMD UserIdentifier) in WebSphere MQ would not be suitable for extended identity information. It would be possible to use new WMQ header fields (though not in the MQMD) or, ion WMQ v7 or later, message properties. This would be difficult to do without potential disruption to existing application programs. But it would not significantly affect completely new application programs or application programs (such as CICS-WMQ bridge application programs) which do not process the WMQ message directly.

We think that we need some business use-cases to help us understand what constraints would apply to an acceptable solution for this requirement. In particular, does this requirement need an identity propagation mechanism that can be "switched on" (=  configured) to provide identity propagation for an existing system without requiring changes to existing application design or code?

3. It is reasonably clear how we could add identity propagation for inbound WMQ messages to the CICS-WMQ DPL bridge. You can already configure the bridge so that the DPL program runs with the identity of the User-ID in the MQMD UserIdentifier, or (for JMS) of the JMSXUserID, in the request message and the code that manages this could be enhanced to process more complex identity information. This is possible because CICS code receives the message rather than the application program receiving the message itself.

There is no mechanism for "passing on" security or identity context information from an inbound message when a consuming application receives the message itself with an MQGET or JMS receive. (This includes applications designed to the triggering pattern.) Does the requirement apply to this kind of application? If so, how do you envisage it working?

Would the MQGET or JMS receive change the security context for the already running application program?

Your requirement says that for business-reasons it would be necessary to know the identity of the end-user in the message-consumer. Does this mean an already running application needs a defined programming interface to extract and examine the identity information in the WMQ message?

Alternatively, would it be enough to provide JMS/WMQ identity propagation only for the CICS-WMQ DPL bridge?

4. The requirement also asks for identity propagation for outgoing messages. Would you expect this to happen automatically for all outbound WMQ/JMS messages or would you expect it to be applied selectively, based on new configuration options or programming interfaces?