| Author |
Message
|
| hooman24 |
 Posted: Sat Mar 04, 2017 5:40 am Post subject: Using intermediate QM with Server-Connection Channel |
 |
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
Hi,
In our environment, we have print applications that connect to our QM using a server-connection. For security reasons we don't want our clients to connect directly to our production QM, therefore we've decided to use an intermediate QM so our clients first connect to this QM and then connect to production QM.
1) Is there any configuration that we can use with the least changes to our client print program?
2) can we use QM Alias as our intermediate QM? for example we define server-connection channel on intermediate QM and then define sender-receiver channel to production QM, and define intermediate QM as an Alias QM.
Thanks in advance
Hooman |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sat Mar 04, 2017 10:27 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
With recent versions of MQ you can really restrict what a client can do over a connection. You can restrict things like the
- Account name/password being used for connection
- IP range for the incoming connections
- Use SSL/TLS
- Limit what MQ Objects can be accessed and what the client can do with them.
If this is still not good enough please tell us what the current product is missing from a security point of view.
Many, many clients connect to prod QMGRS. The changes since V7.5 and more in V8 really go a long way to resolving the sort of concerns you may have.
Who knows, there may be a way of resolving your issues with the current product.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| hooman24 |
| Posted: Sun Mar 05, 2017 12:26 am Post subject: |
|
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
Thank you smdavies99 for your reply.
You are right. There are really good solutions for securing client server connections using new security features of MQ(AMS and security exit,...).
However our customer wants to setup an intermediate QM. It is really interesting for me whether there is anyway to use this QM as an Alias QM(I know we can do it for sender-receiver channels) with a new server-connection channel then routes input messages to production QM?
Thanks
Hooman |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Mar 05, 2017 3:52 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
1. Set up your Intermediate queue manager with the required SVRCONN channel and secure it. If you are supplying a CCDT file to the client, ensure the QMNAME attribute is blank and direct them to supply * as a queue manager name. This will allow you to change the Intermediate queue manager as and when you need (assuming that NAT is used on the incoming connection, or that MQ IPT is being used to front the Intermediate queue manager). If they are specifying the connection details tell them to use * anyway;
2. Set up an appropriate QREMOTE (fronted by a QALIAS if you feel the need) for the client to use, and use that to forward the messages to a QLOCAL on the Production queue manager;
3. Connect the Intermediate queue manager to your Production queue manager with SDR/RCVR channels, and secure those channels. Use separate channels per client to ensure one client's traffic does not impact other client's traffic.
4. If the traffic is bidirectional, do the same as 3. above but from the Production queue manager to the Intermediate queue manager.
Basically you are describing the use of a Gateway queue manager, which is a good thing. Read the Secure Messaging Scenarios with WebSphere MQ Redbook, it's pretty much the MQ security bible.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sun Mar 05, 2017 5:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hooman24 wrote: |
You are right. There are really good solutions for securing client server connections using new security features of MQ(AMS and security exit,...) |
AMS and Security exits are not new to MQ. They have been available for a very long time.
smdavies99 is referring you to CHLAUTH rules.
| hooman24 wrote: |
However our customer wants to setup an intermediate QM. |
You have to understand why. They have a reason. If you don't understand that reason and just add another QM to the topology, the architecture becomes more complicated, more difficult to support and you may not even accomplish what they hoped to accomplish with that queue manager. Ask the requirement, and solve for that, which may require an intermediate queue manager. Or not.
Maybe the requirement is they get paid extra for every QM they have to support, and this extra QM pushes them to the next tier of what they can charge - it may be as dopey as that. Or they may have a technical (i.e. "real") reason that might be accomplished with the 2nd QM, but only if you are aware what it is and can implement it as such.
| hooman24 wrote: |
For security reasons we don't want our clients to connect directly to our production QM, |
Describe these security reasons.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Mar 05, 2017 6:17 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| hooman24 wrote: |
For security reasons we don't want our clients to connect directly to our production QM, |
Describe these security reasons. |
Would you really be happy for a Third-Party to connect directly to your back-end infrastructure? Would you not want to abstract them from that infrastructure? And what happens when you want to move the service and need to involve the Third-Party, networks, firewalls etc. in that move?
_________________
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 |
|
|
| smdavies99 |
| Posted: Sun Mar 05, 2017 8:15 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| exerk wrote: |
| PeterPotkay wrote: |
| hooman24 wrote: |
For security reasons we don't want our clients to connect directly to our production QM, |
Describe these security reasons. |
Would you really be happy for a Third-Party to connect directly to your back-end infrastructure? Would you not want to abstract them from that infrastructure? And what happens when you want to move the service and need to involve the Third-Party, networks, firewalls etc. in that move? |
Some orgs allow it. One I know mandates it. Others are happy with MQIPT.
Using SSL on the Link and with appropriate secutity are good enough for others.
Objcect Access can be restricted as can username/password.
So it sort of depends.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Mar 05, 2017 11:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| exerk wrote: |
| PeterPotkay wrote: |
| hooman24 wrote: |
For security reasons we don't want our clients to connect directly to our production QM, |
Describe these security reasons. |
Would you really be happy for a Third-Party to connect directly to your back-end infrastructure? Would you not want to abstract them from that infrastructure? And what happens when you want to move the service and need to involve the Third-Party, networks, firewalls etc. in that move? |
"We don't want them to connect to our Production QM."
So we will have them connect to a new Production QM. To what end? What do you hope to accomplish, or prevent? If you can't answer that, you can't know that a new intermediate QM accomplishes or prevents what you are after.
I'm not saying its wrong to have the client connect to a new intermediate QM. But to say its for "security reasons" and then not be able to articulate what those security reasons are means you quite likely will not be mitigating the things you think you are.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Mar 05, 2017 12:37 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
| So we will have them connect to a new Production QM. To what end? |
So that I can control the point of entry and change where it routes internally any time I like...
| PeterPotkay wrote: |
| What do you hope to accomplish, or prevent? |
Not just prevention but the ability for me to 'swing' that connection anywhere I like within my infrastructure without getting the Third-Party involved.
Use Case: At the moment I'm involved in a migration project that will involve Third-Parties having to make changes and at the moment just getting one of them to make a change is like the mating of elephants.
To have a Gateway through which all Third-Parties connect, and which I can control independent of them because channel names etc. will be generic and aliasing will be used - they won't know my internal queue naming conventions and so on - and concentrate various CA certificates (some of which may be self-signed) and bodges to site standards all in one place.
Or, I can open up multiple holes in a firewall, pollute a number of queue managers with various CA certificates, funny queue names, and so on...
| PeterPotkay wrote: |
| I'm not saying its wrong to have the client connect to a new intermediate QM. But to say its for "security reasons" and then not be able to articulate what those security reasons are means you quite likely will not be mitigating the things you think you are. |
And I fully agree with you.
_________________
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 |
|
|
| hooman24 |
| Posted: Mon Mar 06, 2017 8:54 am Post subject: |
|
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
Thank you exerk for your really good information and answer. We will try that.
PeterPotkay as you said MQ has security features that can assure users. However, our customer has a lot of different organizations connected to the same QM and they feel safer with separated entry points. Besides, it is easier to see who's who if you keep them connecting to separate intermediate queue managers.
Our problem was if we set up an intermediate QM how could client apps put and get messages from original QM without knowing there is any concentrator.
As exerk said there is a change in client app(* for QMNAME) and QREMOTE in intermediate QM for any applications that put message and probably QREMOTE in production QM for apps that get a message and also defining SNDR/RCVR channels between intermediate and production. We will test this scenario, I hope this works.
Thank you all |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 06, 2017 8:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Your apps wouldn't put or get to the remote queue manager.
They put and get to the local (intermediate) queue manager.
Then you configure the MQ network so that messages the client apps send will go to the right place, and the messages that the client apps need to read go to the right place.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Mar 06, 2017 9:57 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hooman24 wrote: |
| ...our customer has a lot of different organizations connected to the same QM and they feel safer with separated entry points. Besides, it is easier to see who's who if you keep them connecting to separate intermediate queue managers... |
You don't need separate Gateway queue managers for each connecting Third-Party, you just need separate channels, and separate in/out routes if you front it with an IPT.
| hooman24 wrote: |
| Our problem was if we set up an intermediate QM how could client apps put and get messages from original QM without knowing there is any concentrator. |
See mqjeff's comment, and the Redbook I mentioned shows you exactly how.
_________________
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 |
|
|
| hooman24 |
| Posted: Tue Mar 07, 2017 1:51 am Post subject: |
|
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
Thank you exerk and mqjeff. Your comments are really helpful.
For clarification since I haven't worked with MQIPT yet, I just want to make sure that using MQIPT is not mandatory for this kind of architecture and I can use QM server as my intermediate QM.
Thanks a lot |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 07, 2017 5:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQIPT is mandatory if your requirements can't be solved without it.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 07, 2017 6:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| hooman24 wrote: |
| ...I just want to make sure that using MQIPT is not mandatory for this kind of architecture and I can use QM server as my intermediate QM. |
Just to be absolutely and crystal clear, MQ IPT does not take the place of an 'intermediate QM'. Look at the diagrams in the Redbook, which explain it in a very simple way.
_________________
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 |
|
|
|
|
