| Author |
Message
|
| Scooter |
 Posted: Wed May 05, 2004 6:14 am Post subject: IMSBridge use with UserId |
 |
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
Ok, I have been working on this issue for about 2 days straight and have looked at several zOS and Windows manuals without any success. We are using a Windows Qmgr to sent messages to excute a IMS transaction using the IMSBridge. We have been successful in doing this while OTMA security has been set to NONE. Now we are attempting to turn on OTMA so we can access secure IMS transactions. We have set the UserId field in the MQMD and opened the Window Local Queue with MQC.MQOO_SET_ALL_CONTEXT. When we do this all IMS transactions fail with "DFS1292E SECURITY VIOLATION", even transactions that are not secured IMS transactions. I don't do much IMS work but the people who setup MQ on IMS are telling me everything is in place to use security. So I'm not sure what to tell them to look at or if it is a problem in the message. Can anyone point me in the right direction?
P.S. We are using Windows MQ 5.3 (CSD05). |
|
| Back to top |
|
 |
| Scooter |
| Posted: Wed May 05, 2004 6:47 am Post subject: |
|
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
More information:
We have been able to open the message after it was dumped to the DLQ and the UserId contains the userid of the user that opened the queue and not the userid that was placed in the MQMD field UserId. Guess I don't fully understand the use for the MQMD field UserId or I'm missing something. |
|
| Back to top |
|
|
| offshore |
| Posted: Wed May 05, 2004 7:29 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Scooter,
I've worked with IMS <some> and MQ, but never connecting them together but I'll give it my @0.000002 worth.
1.] How are you verifying that
| Quote: |
| the UserId contains the userid of the user that opened the queue and not the userid that was placed in the MQMD field UserId |
From the Sys Mgmt Guide there is a note documenting something very similar to what you've explained.
If profile qmgr.NO.SUBSYS.SECURITY exists in the MQADMIN class, no user ID will be passed to IMS and the connection will fail unless the /SECURE OTMA setting is NONE. |
|
| Back to top |
|
|
| Scooter |
| Posted: Wed May 05, 2004 8:02 am Post subject: |
|
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
We verified the value in the UserId field by using MainView on IMS to open the message in the DLQ and the UserId field was the user that opened the Windows Local Queue. If I display the MQMD field UserId before it is put to the queue, it is the value that I set in the code.
Thanks for the note about the NO.SUBSYS.SECURITY, I saw that but didn't mean much to me. I will go talk to the people that setup MQ on IMS and have them check for this profile. I did find one mistake in the code: I was using the "MQC.MQOO_SET_ALL_CONTEXT" and not "MQC.MQOO_SAVE_ALL_CONTEXT". But this made no difference.
As a side note I found a note in the manuals that Remote Queues can not use the MQOO_SAVE_ALL_CONTEXT option. Which means I can't use it because we are using a remote queue to get the message to IMS.
So.. How do you pass a userid to IMSBridge to run a secured IMS Transaction?
Thanks once again for your help |
|
| Back to top |
|
|
| offshore |
| Posted: Wed May 05, 2004 9:24 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Scooter,
Passing a UserID to the IMSBridge you are doing it correctly, by specifying a UserIdentifier in the MQMD.
I would check the "queue" you are putting to before the IMS transaction is triggered.
I'm guessing you flow goes something like this:
Queue (on Windows) -> MCA -> Queue(on MVS, that triggers IMSBridge)
MQ Admins
I would turn off the trigger on Queue(on MVS, that triggers IMSBridge). At this point your original message will be sitting on the mainframe and you can check the MQMD to see what is in the UserIdentifier field.
IMS
The IMS folks need to see what the OTMA security is set to. This is done by a /DISPLAY OTMA or by checking the OTMASE= setting.
External Security Manager (assuming you use RACF)
The security ppl need to see if IMSXCF.group.client_member_name is defined the FACILITY class.
If so the userid you're passing in the UserIdentifier field of the MQMD will need READ access to FACILITY class.
One more thing, have the security ppl run a trace when you try to execute the program. |
|
| Back to top |
|
|
| Scooter |
| Posted: Wed May 05, 2004 1:03 pm Post subject: |
|
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
More Information:
I ran a trace on the Window server and the trace shows that the MD has the correct UserId when the message is put on the Local Queue. But the trace also shows that when the message is put to the Remote Definition to send it to IMS the UserId is set to the user that opened the Local Queue.
I have set the MQOpen to use "MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING + MQC.MQOO_PASS_ALL_CONTEXT" and I populate the "UserId" field in the MQMD before putting the message on the local queue. Is there something else that I'm missing in the message or configuration setting on the queue to keep the Remote Definition Queue from replacing the field?
We will address the security issues on IMS once I'm able to get the UserId field to pass the correct value.
Thanks |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed May 05, 2004 1:23 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
To save the context information from the original message, you must use the
MQOO_SAVE_ALL_CONTEXT option when you open the queue for getting the
message. This is in addition to any other options you use with the MQOPEN call.
Note, however, that you cannot save context information if you only browse the
message.
When you create the second message, you must:
v Open the queue using the MQOO_PASS_IDENTITY_CONTEXT option (in
addition to the MQOO_OUTPUT option).
v In the Context field of the put-message options structure, give the handle of the
queue from which you saved the context information.
v In the Options field of the put-message options structure, specify the
MQPMO_PASS_IDENTITY_CONTEXT option.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Scooter |
| Posted: Thu May 06, 2004 5:10 am Post subject: |
|
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
Ok... I think I understand what you said. He is what I did. I opened the Remote Definition Queue with the following options "MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING + MQC.MQOO_PASS_IDENTITY_CONTEXT + MQC.MQOO_SAVE_ALL_CONTEXT". I then set the Context Reference in the Put Message options to the Remote Queue and set the following put options "MQC.MQPMO_PASS_IDENTITY_CONTEXT". When this code is executed a I get a "CompCode: 2, Reason: 2046" which states that the Context Reference is invalid or Options parameter is not valid. I have confirmed the Context Reference is valid.
I found a note in the Application Programming Reference that states the following about the MQOO_SAVE_ALL_CONTEXT option:
| Quote: |
| This option is valid only for local, alias, and model queues; it is not valid for remote queues, distribution lists, and objects which are not queues. |
This statement would indicate to me that what we are attempting can't be done in this manner. Any ideas on how to pass custom UserIds in the MQMD to IMSBridge to use to run secure IMS transactions?
Sorry for the lengthy message, just want to provide as much information that I have.
Thanks |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 06, 2004 6:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
QueueA is your local queue on QM1, that has a message with an ID of "SCOOTER"
QueueB is the remote queue def on QM1 that goes to QueueB on QM2 where IMS is.
You open QueueA with the following options:
MQOO_INPUT_AS_Q_DEF
MQOO_SAVE_ALL_CONTEXT
When you open QueueB, use the following options:
MQOO_OUTPUT
MQOO_PASS_IDENTITY_CONTEXT
And when you PUT the message to QueueB, use this:
MQPMO_PASS_IDENTITY_CONTEXT
(Make sure you fill in te CONTEXT field in MQPMO as well for this to work)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Scooter |
| Posted: Thu May 06, 2004 7:24 am Post subject: |
|
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
Just to confirm that I understand you. I need to put the message into a Local Queue to save the context. Then retrieve it and put it into the Remote Queue to have it pass the UserId? I can't just build a message in a program and put it in the Remote Queue directly and have the UserId passed?
My current test sequence:
Program ---> Remote Queue ---> IMS
Your suggested sequence:
Program ---> Local Queue(saving context) ---> Remote Queue ---> IMS
Thank you very much for your help! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 06, 2004 7:36 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
AppA puts to Queue1l. The message on Queue1 has an ID of SCOOTER.
AppB wakes up, opens Queue1 with the options I mentioned above, and gets the message.
AppB then opens Queue2 with the options I mentioned above, then puts the message with options I mentioned above.
The message arrives on QM2 with SCOOTER in the header.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Scooter |
| Posted: Thu May 06, 2004 9:09 am Post subject: |
|
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
That is alot of work just to get the UserId passed to IMS. I hate the idea of having a extra queue in order to save the Identity Context. But if that is what it takes, we will make the changes to our MQ Queue structures and applications to do it. I will give it a shot.
Thank you very much. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 06, 2004 9:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
???
I though you had the other queue in there for some other reason. I didn't add it to the design. It was already there in your post.
| Quote: |
I ran a trace on the Window server and the trace shows that the MD has the correct UserId when the message is put on the Local Queue. But the trace also shows that when the message is put to the Remote Definition to send it to IMS the UserId is set to the user that opened the Local Queue.
|
Here you are talking about the message already sitting in a local queue (Queue1) and putting to a remote queue (Queue2).
What exactly are you trying to do again? You certainly don't need to go thru another queue just to set IDs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Scooter |
| Posted: Thu May 06, 2004 9:35 am Post subject: |
|
|
Apprentice
Joined: 01 May 2003
Posts: 35
Location: Dallas, Tx
|
I'm sorry, I mentioned the Local Queue because we were having problems getting the Remote Queue to hold the UserId. What I we are trying to do is have a App create and put a message into a Remote Queue with a custom UserId in the MQMD field. In my traces of the attempts shows that the first MQPUT with the MQMD UserId contains the id. But shortly after that MQPUT is a strange second MQPUT and the MQMD UserId field has been change to the ID of the user that opened the Remote Queue. I'm not sure where the second MQPUT is coming from in the trace, I'm guessing it has something to do with the Remote Queue sending it to IMS.
When we view the message on mainframe it contains the ID of the user that opened the Remote queue and not the one I sent in code.
Thanks....sorry for the misunderstanding. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 06, 2004 12:53 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
OK, App1 wants to open Remote Queue Def Queue1 on QM1 to put a message with an ID of SCOOTER. That remote queue def points to Queue1 on QM2. You want to see the ID SCOOTER in the MQMD header on Queue1 on QM2.
App1 opens the remote queue def with the following options:
MQOO_OUTPUT
MQOO_SET_IDENTITY_CONTEXT
App1 populates the MQMD_UserIdentifier with SCOOTER
App1 does the MQPUT with the following options:
MQPMO_SET_IDENTITY_CONTEXT
The message will arrive on Queue1 on QM2 with SCOOTER in the header.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
