ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Alter access to allow only one user to put clustered queue

Post new topic  Reply to topic Goto page 1, 2  Next
 Alter access to allow only one user to put clustered queue « View previous topic :: View next topic » 
Author Message
meaton78
PostPosted: Mon Sep 27, 2010 5:55 pm    Post subject: Alter access to allow only one user to put clustered queue Reply with quote

Centurion

Joined: 16 Oct 2008
Posts: 100

I have looked around here and in the manual and haven't found a real great explanation on this topic. We have some brokers that host multiple cluster queues for cluster A. Application B resides on a remote server/qmgr and puts to the clustered queues. We would like to restrict access to one of the clustered queues so that only user C can put to that queue (I'll call it QD).

On the brokers that host the queue, we have ssl and a mcauser set on the clusrcvr channel, so the mcauser obviously has to access to the queue on that end. On the remote end where the application resides, I tried something from the InfoCenter, where I created QA(QD) TARGQ(QD). I then tried to do setmqaut -m QMGR -g TEST -n 'QD' -t queue -all + none but I was still able to put to the queues. I'm guessing that I was bypassing the local QA and hitting the clustered queues directly.

http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzah.doc/qc11430_.htm

Is there some eloquent way that I am missing that I could use to do this? I was thinking I might somehow be able to use an mcauser on the cluster sender channel, but I have never done that before and am not sure how the authorization works that way. Thanks for any help or pointers. This one is driving me mad.

We are running MQ 6.0.2.8 on AIX if that matters.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Sep 27, 2010 7:33 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

You need an mcauser that has no priviledges to the SystemClusterTransmitQueue (SCTQ). Then you need an authorized queue remote, defined locally, that will resolve to the cluster queue (difference with queue alias is that you can do a put when the destination is not available, the message will go to the DLQ).

Have fun.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Tue Sep 28, 2010 1:45 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

So the MCAUSER on the CLUSRCVR is only active once the message passes down the cluster channel.

As FJ says, you need to stop the application from being able to write directly to SCTQ.

But you need to make sure you know what user is in effect for the connection to the local qmgr.... That's *not* the MCAUSER on the clusrcvr. It's whatever MCUASER is set on your clntconn/svrconn or whatever local user is running your code on a bindings connection (with caveats, alas).
Back to top
View user's profile Send private message
meaton78
PostPosted: Tue Sep 28, 2010 7:25 am    Post subject: Reply with quote

Centurion

Joined: 16 Oct 2008
Posts: 100

If I created a QR named QD pointing to the cluster queue, would all local traffic on the application box be forced to use that queue and not the cluster queue of the same name?

The piece I am having trouble with is this. Say we have 10 clustered queues. I want mqm to be able to put to 9 of them for testing purposes since they are inquiry only. The 10th queue is for transactions that we are not able to test since they make actual system changes. I also want the application, which puts messages as user 'app' to also be able to put to all 10 of the clustered queues. Then, in theory, with the proper monitoring, I should be able to say that there has been a breach if someone not authorized logged on as app and put a message to the secured queue.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Sep 28, 2010 7:34 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

So, you are testing in production??
_________________
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
View user's profile Send private message
meaton78
PostPosted: Tue Sep 28, 2010 7:37 am    Post subject: Reply with quote

Centurion

Joined: 16 Oct 2008
Posts: 100

bruce2359 wrote:
So, you are testing in production??


Absolutely. Once I have done an MQ or WAS upgrade I'd prefer to know that it is working properly. We probably have more testing regions than most, but that doesn't mean that I can guarantee an upgrade in Prod has worked simply because it did in dev...
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Sep 28, 2010 7:47 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

Uh....

So, you have no QA environment for doing pre-production testing?
_________________
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
View user's profile Send private message
meaton78
PostPosted: Tue Sep 28, 2010 7:50 am    Post subject: Reply with quote

Centurion

Joined: 16 Oct 2008
Posts: 100

Of course we do. Do you not validate your upgrades after you have completed them in Prod?
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Sep 28, 2010 8:00 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

Quote:
Do you not validate your upgrades after you have completed them in Prod?

End-users validate first in QA - often with real production data; then end-users do production work in prod.

I guess I'm wondering how testing in prod passes any audit...
_________________
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
View user's profile Send private message
Vitor
PostPosted: Tue Sep 28, 2010 8:27 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
I guess I'm wondering how testing in prod passes any audit...


With proper controls to ensure that either no data escapes during the testing window or it's captured by other systems which are using the same window to test their production environments, with a restore back to a known point after you're done.

It's not just this sort of thing, but also security & connectivity testing typically has to be done in situ. Takes months of meeting to plan & organize but it's not uncommon.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Sep 28, 2010 8:03 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Vitor wrote:
bruce2359 wrote:
I guess I'm wondering how testing in prod passes any audit...


With proper controls to ensure that either no data escapes during the testing window or it's captured by other systems which are using the same window to test their production environments, with a restore back to a known point after you're done.

It's not just this sort of thing, but also security & connectivity testing typically has to be done in situ. Takes months of meeting to plan & organize but it's not uncommon.

Sure but wouldn't you have tested this out in Qual first, to make sure that the concept and the authorizations work, and then tested in prod once installed according to the configuration that worked in Qual, modified as needed for prod?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Tue Sep 28, 2010 8:18 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

I'd guess that there is little/no demarcation between QA and PROD; and that QA procedures are lack sufficient rigor to validate what is headed for PROD; and that the procedures for percolating QA to PROD are lacking.

I doubt this would pass internal audit or Soxley...
_________________
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
View user's profile Send private message
Vitor
PostPosted: Wed Sep 29, 2010 4:15 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

fjb_saper wrote:
Sure but wouldn't you have tested this out in Qual first, to make sure that the concept and the authorizations work, and then tested in prod once installed according to the configuration that worked in Qual, modified as needed for prod?


Sometimes and under ideal conditions but sometimes for operational reasons QA & PROD differ. Often they don't have the same security & network set up just because of how they're used or where they're hosted.

Strange yet true.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Sep 29, 2010 4:18 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

bruce2359 wrote:
I'd guess that there is little/no demarcation between QA and PROD;


Nope

bruce2359 wrote:
and that QA procedures are lack sufficient rigor to validate what is headed for PROD;


Nope

bruce2359 wrote:
and that the procedures for percolating QA to PROD are lacking.


Nope.

(I have a couple of specific clients in mind with those nopes).

bruce2359 wrote:
I doubt this would pass internal audit or Soxley...


It does. My knowledge of Soxley is about the same as my knowledge of the surface of the Moon (I can recognise it & talk in general terms) but auditors never seem to mind as long as the agreed procedures I mention above are followed and that the following of the procedures can be proved.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Sep 29, 2010 6:23 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.

I've seen a few shops where the lines between TEST, QA and PROD, were blurred; and where there were different apps, different security, different whatever.

When I've had the opportunity, I've required that QA be pre-PROD, not a test-PROD. QA, when certified prod-ready by end-users and auditors, is cloned into PROD.

I shall consider myself fortunate that I've worked mostly in shops with clear delineation between TEST, QA, and PROD.

Maybe an ALMOST-PROD is necessary to do any last minute testing.
_________________
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » Alter access to allow only one user to put clustered queue
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.