| Author |
Message
|
| zpat |
 Posted: Fri Jun 24, 2011 8:06 am Post subject: WMQ security exit, buffer data and EBCDIC vs ASCII |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
We have a security exit (coded in C) on a SENDER channel, from a Solaris Queue manager (WMQ 7.0.1.5) to a z/OS queue manager.
Convert is set to YES for this sender channel (ASCII to EBCDIC).
The channel security exit is required to provide authentication information (a fixed value of clear text id/password) in the exit data buffer to allow connection.
My question is - does WMQ convert the security exit data buffer values from ASCII to EBCDIC in this example?
Because if it doesn't, it probably won't pass the validation at the other end. |
|
| Back to top |
|
 |
| skoobee |
| Posted: Sun Jun 26, 2011 8:50 pm Post subject: |
|
|
Acolyte
Joined: 26 Nov 2010
Posts: 52
|
| No. When the CONVERT attribute of a channel is set to YES, it causes the MQGET of a msg from the xmitq to set MQGMO_CONVERT, and so use the normal conversion mechanism for a msg oin the queue. |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Jun 26, 2011 10:22 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Well, yes I know what convert(yes) does to the message.
Do you have certain knowledge that the security exit agent buffer is not subject to any kind of data conversion? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 27, 2011 2:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| zpat wrote: |
Well, yes I know what convert(yes) does to the message.
Do you have certain knowledge that the security exit agent buffer is not subject to any kind of data conversion? |
Have you tried? What have your efforts shown so far?
Any weird behavior?
I am sure Roger would be able to give you more targeted info... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Jun 27, 2011 3:56 pm Post subject: Re: WMQ security exit, buffer data and EBCDIC vs ASCII |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
| zpat wrote: |
| My question is - does WMQ convert the security exit data buffer values from ASCII to EBCDIC in this example? |
Are you referring to the fields passed into the security exit?
i.e.
| Code: |
SecExit(PMQCXP pCXP,
PMQCD pChDef,
PMQLONG pDataLen,
PMQLONG pAgentBufferLen,
PMQBYTE pAgentBuffer,
PMQLONG pExitBufferLen,
PMQPTR pExitBufferAddr) |
If so, then the only items that are converted are the MQLONGs.
Or are you referring the "security flows" that are documented in Chapter 34 Channel-exit programs of the WMQ Intercommunication manual?
If so, then the answer is no. You need to handle ASCII <--> EBCDIC and possibly any encodings.
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
P.S. Don't there is a product (MQAUSX) that already does it all for you. 
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jun 27, 2011 4:12 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
From my experience, the security exit data buffer is not converted. If you are using security messages between z/OS and Solaris you will need to handle conversion of character information yourself. I advise against sending clear text userids, passwords or any other id tokens in security messagess unless you are also using SSL encryption of message traffic.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Jun 27, 2011 10:10 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| It's the AgentBufffer that I am interested in. We are constrained by the other party involved in how this is handled. I've tried EBCDIC but looks like the problem is more fundamental. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jun 28, 2011 12:56 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
| zpat wrote: |
| It's the AgentBufffer that I am interested in. We are constrained by the other party involved in how this is handled. I've tried EBCDIC but looks like the problem is more fundamental. |
The AgentBuffer is not is not converted. Did you remember to handle 'Big Endian' and 'Little Endian' issues?
http://en.wikipedia.org/wiki/Endianness
There are lots and lots of issues that you need to deal with.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 28, 2011 11:38 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jun 29, 2011 11:31 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| zpat wrote: |
Scy exit called for SEC_MSG
Scy exit called for SEC_MSG
Scy exit called for SEC_MSG
(ad infinitum) |
OK that's how MQ is calling you, how are you responding (ExitResponse etc.)? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jun 29, 2011 3:51 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| zpat wrote: |
| I've tried with ASCII and EBCDIC and still not working. It appears to loop in the SEC_MSG stage of the handshake |
Print it out in hex to the exit debug log file, it might make more sense if you can actually eye-ball the data.
I hope you have included code for debug logging in your exit. On z/OS you can just use fprintf(stdout,......) and it will go to SYSPRINT of the CHIN address space. On Unix you can fopen a text file for append, fprintf to it, and fclose when leaving the exit.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 29, 2011 9:22 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| As I mentioned, this is Solaris. I am going to apply the fix for that APAR. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jul 01, 2011 12:19 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Working now. Seems the other end didn't set their part up correctly and managed to remove their exit definition. ....
If you just have a sender exit and no receiver exit you get the pattern of usage described here.
This info gleaned during a recent visit to the Temple of the Gods (Hursley Park). |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Jul 02, 2011 1:23 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| This info gleaned during a recent visit to the Temple of the Gods (Hursley Park). |
Are you making the pilgrimage there on the 13th of July?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Jul 02, 2011 2:44 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| zpat wrote: |
| If you just have a sender exit and no receiver exit you get the pattern of usage described here. |
I think there's a bug in your server-side exit, because nothing the client does should cause your server-side code to tolerate looping like that.
You should check the ExitResponse and so on - if your sec exit needs or wants to suppress the channel from starting or continuing, it can do so. |
|
| Back to top |
|
|
|
|
