| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Fix pack 6.0.2.8 change - JMS and SVRCONN |
View previous topic :: View next topic |
| Author |
Message
|
| rickwatsonb |
 Posted: Tue Feb 01, 2011 7:52 am Post subject: Fix pack 6.0.2.8 change - JMS and SVRCONN |
 |
|
Voyager
Joined: 15 Aug 2006
Posts: 87
Location: USA: Mid-West
|
Hi,
I am trying to understand the significance of the “JMS note” in the 6.0.2.8 MQ fix pack with respect to a SVRCONN channel. What does it matter if an empty string is passed to the queue manager?
I have not found one concise section on SVRCONN channels in the manuals; the subject seems to be interspersed in the client channel and client configuration sections. But, from what I have pulled together from numerous posts in this forum is that the channel authority will be the overriding factor.
In the “MQ Authorities for Java Clients” forum thread, Peter’s post was the most technically explicit: “Technically I think the channel in this scenario then runs under the authority of the ID that the listener process is running as, which is almost always mqm (or MUSR_MQADMIN on Windows).”
Is the change in 6.0.2.8 only significant if you are using a security exit on the user ID passed by the JMS?
Shown below is an excerpt from the 6.0.2.10 Read me file – notes concerning the 6.0.2.8 fix pack:
Using Classes for Java™ Message Service (JMS)
---------------------------------------------
WebSphere MQ Version 6.0.2.8 changes the way applications using the
classes for Java Message Service (JMS) handle User IDs when creating
JMS Connections.
Applications would create Connections by calling one of the following
methods:
QueueConnectionFactory.createQueueConnection(String userName, String password)
TopicConnectionFactory.createTopicConnection(String userName, String password)
ConnectionFactory.createConnection(String userName, String password)
If you specify a null value or an empty string as the username, an
empty string will now be sent to the queue manager for authorization
checks.
Prior to this Fix Pack, if you specified a null value as the username,
then the User ID under which the application was running was sent to
the queue manager for authorization checks.
…
For more details, please refer to APAR IZ49302
http://www.ibm.com/support/docview.wss?rs=171&uid=swg1IZ49302
...
End of excerpt |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Feb 01, 2011 11:16 am Post subject: Re: Fix pack 6.0.2.8 change - JMS and SVRCONN |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| rickwatsonb wrote: |
| ...Is the change in 6.0.2.8 only significant if you are using a security exit on the user ID passed by the JMS?... |
I'm no expert (lord knows my posts bear that out) but my twisted logic dictates that if your exit is expecting a value and not an empty string I would expect your exit to:
a) Have a dummy spit and terminate the connection; or
b) Have a dummy spit and terminate the connection.
I would hazard that as the implication is that the change of behaviour will affect you, and therefore you will need either to change your exit (difficult one that, how do you determine what the 'default' user behaviour should be on receipt of an empty string?) or the application code (my preference - make the illegitimate developers work for a living!).
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Feb 01, 2011 11:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| rickwatsonb |
| Posted: Tue Feb 01, 2011 11:32 am Post subject: |
|
|
Voyager
Joined: 15 Aug 2006
Posts: 87
Location: USA: Mid-West
|
Thanks for the reply exerk, but my question was meant to be at a higher level.
I am not sure what the JMS change in 6.0.2.8 affects. My guess was that the change affects security exits. This could be incorrect...
In other words, we shall be upgrading MQ and it would be helpful to understand the implications of the changes in 6.0.2.8 relative to JMS. At this point, being a novice, I am unsure of the exact side affects of the changes. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 01, 2011 11:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
At a higher level, the JMS provider was changed because using a null value to assume the ID used to run the container was not the correct thing to do. The JMS code should either explicitly ask for and use the ID used to run the container, or use a JAAS authentication alias to allow for the ID to be specified by the container admins.
Passing in a null value and having it pick up the container id was a mechanism to avoid doing the right thing. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Feb 01, 2011 1:27 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
 The clock is ticking - only 8 months to the demise of V6.0
_________________
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 |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
