| Author |
Message
|
| BBM |
 Posted: Tue Mar 06, 2012 7:55 am Post subject: Can MCAUSER set message User Identity? |
 |
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
We have multiple channels from multiple externals that all get aggregated into one queue.
We would like to identify the sender of each message using a value in the MQ header.
We have set the MCAUSER on each incoming receiver channel to unique values but the user id in the MCAUSER field is not being stamped within the message.
Is there any way to replace the user id set from the sending application with the MCAUSER value or does the the user id set at PUT time take precedence?
Many thanks,
BBM |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Mar 06, 2012 8:05 am Post subject: Re: Can MCAUSER set message User Identity? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBM wrote: |
| Is there any way to replace the user id set from the sending application with the MCAUSER value or does the the user id set at PUT time take precedence? |
The MCAUser is only used to determine authorisation against the queue manager; it doesn't affect message / header contents.
You could probably come up with a channel exit that copies the value across but that sounds like a sledgehammer to crack a nut. I'd be inclined to use the PutApplName or better still have the sending applications set ApplOriginData & use that to determine the origin. Crazy I know, thinking that sending applications can be changed....
Someone will be along with a better idea in a minute.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 06, 2012 8:13 am Post subject: Re: Can MCAUSER set message User Identity? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| BBM wrote: |
| We would like to identify the sender of each message using a value in the MQ header. |
What values are in the context fields of the messages now?
Is PutApplType = MQAT_NO_CONTEXT? If so, the app that creates the messages specified MQPMO_NO_CONTEXT.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Mar 06, 2012 8:20 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
We only at the POC stage so we've been passing messages created within MQ Explorer between queue managers.
Eventually we will have 300+ incoming channels and need to be able to positively identify each message's sender. This is why I mistakenly though MCAUSER could help me out as there would be reduced risk of spoofing if we are setting the header value at our end.
Any other suggestions welcome - I'm guessing going down the exit route is our only option.
Thanks,
BBM |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 06, 2012 8:35 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
It is the default behavior of the qmgr to populate the Context fields (with userid, application name, etc.).
The WMQ Explorer does this. You should be able to see these fields using the WMQ Explorer (or any other utility) to display the messages.
Tell the developers NOT to suppress the Context fields.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 06, 2012 8:40 am Post subject: Re: Can MCAUSER set message User Identity? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| BBM wrote: |
We would like to identify the sender of each message using a value in the MQ header.
...
Is there any way to replace the user id set from the sending application with the MCAUSER value or does the the user id set at PUT time take precedence?
|
You appear to be contradicting yourself in these two sentences.
Sentence 1): By default, the queue manager where the app connects will populate the message Context fields.
Sentence 2): You want to ignore the inbound message Context fields, and replace them with Context data of your own choosing. You can write an application that gets the messages from a queue on the receiving qmgr, then alter the context fields, then put the message to another queue. Or, you can write (or buy) a message exit that alters the Context fields before the message is put to the queue.
I'm confused.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Tue Mar 06, 2012 8:53 am; edited 1 time in total |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Mar 06, 2012 8:50 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi Bruce,
Yes we'd like to stamp the message with a unique identifier as it comes in so we can later on identify which channel it came in on and therefore who sent it.
Any way to change the context info in the header would be good.
Thanks
BBM |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 06, 2012 8:52 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Use AMS 
_________________
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 |
|
|
| Vitor |
| Posted: Tue Mar 06, 2012 8:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBM wrote: |
| Yes we'd like to stamp the message with a unique identifier as it comes in so we can later on identify which channel it came in on and therefore who sent it. |
Presumably you're using SSL here to secure the channels? As described, this solution would promote spoofing without it as any spoof message inserted via a channel would automatically be tagged as genuine from the sender.
| BBM wrote: |
| Any way to change the context info in the header would be good. |
The sending applications can do this quite easily.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 06, 2012 8:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| BBM wrote: |
Hi Bruce,
Yes we'd like to stamp the message with a unique identifier as it comes in so we can later on identify which channel it came in on and therefore who sent it.
Any way to change the context info in the header would be good.
Thanks
BBM |
What is the business requirement? Not the technical requirement you have artfully stated.
I suspect that there is a auditor standing over your shoulder asking for this.
It makes little sense, unless you intend to create a separate channel for each and every user.
Is the ultimate purpose of this to capture channel/application statistics?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Mar 06, 2012 9:10 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
Yes to give a bit more detail, the channels are coming in from external companies. We are using SSL to secure our channels and they are coming in over a private cloud.
Normally we would have one channel and one local queue for each external to send to. However, our receiving application server cannot handle large numbers of local queues as it creates multiple connections per local queue. With the number of clients we are expecting these large number of local queues and hence connections would be enough to seriously impede the queue manager - we have seen this happen.
So instead, the externals will be sending to their own alias, in turn these aliases all point to the same local queue. This gets around the resource constraints of the application server but means we cannot positively identify from where the messages came from - apart from content which we don't want to rely on.
I hope this make things a little clearer.
I think the only way to achieve what we are aiming to do is by re-PUTing the message using an exit of some kind.
BBM |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 06, 2012 9:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Again I ask, why does it make a difference which channel a message arrives on?
What business processing will be different? Doesn't the application data payload identify the external organization in some way?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 06, 2012 9:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BBM wrote: |
| I think the only way to achieve what we are aiming to do is by re-PUTing the message using an exit of some kind. |
I stand by getting the external applications setting the header as the ideal solution, but I think you're right; this is going to be an exit.
At least it's going to be the same exit on all 300 (gulp!) channels.
I echo the question of why you need to know this. Given that you're using SSL so you can be sure the message is from someone valid, what's the requirement to know which someone?
Could you have 1 channel & identify by SSL certificate? I'm genuinely asking here not proposing an alternative. Could you extract the distinguished name from the certificate used to connect to the channel? Anyone?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 06, 2012 10:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You really are missing the point of MQ here.
You have a set of senders, A.
You have a receiver app B.
You wish to a) alter the messages that come from A, b) ensure that they all end up in a single queue for processing by B.
This means you need a second App, C, that will listen to a large set of queues A1-An, and use the source queue information to tag them appropriately and then write them to the queue being read by B.
You could, for example, consider using DataPower to act as the application C. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 06, 2012 10:17 am Post subject: Re: Can MCAUSER set message User Identity? |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| BBM wrote: |
| Is there any way to replace the user id set from the sending application with the MCAUSER value or does the the user id set at PUT time take precedence? |
The MCAUser is only used to determine authorisation against the queue manager; it doesn't affect message / header contents.
|
On QM to QM channels yes, but its different on SVRCONN channels, where the MCAUSER value of the SVRCONN channel will dictate the MQMD's User Identity field. Doesn't apply to this particular user's scenario, but the specific question and your reply did not exclude SVRCONNs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
