| Author |
Message
|
| klamerus |
 Posted: Thu May 08, 2008 6:12 pm Post subject: Queue forwarding? |
 |
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Our client is in the process of re-architecting several applications (including those using Websphere MQ) to support use by other companies by moving some servers into firewalled networks that can be shared.
The systems are all Windows 2003 and sit within different domains as well. By that I mean there is one domain for the shared environment, one for the internal environment, and even others outside the shared environment.
They don't want to allow direct access from those environments outside the shared environment to their internal environments and so we're looking at ways of setting up some of this to minimize holes in the firewalls and to limit trusts of accounts.
It's a bit hard to describe this without pictures, but we want to set some of the applications in the least secure network, but allow them to send WebSphere MQ requests to the most secure (the internal) network.
One way of doing this would be to set up an MQ server in the shared area and have the least secured write to it, and for it to "forward" those requests to the internal system.
This would require only one "hole" to the internal network and only one account to do the WebSphere MQ writes onto our internal system.
We'd like to know if it is possible to set up a queue that applications in the least secure network write onto, but which simply forward to a queue on the most secure (internal) network. The "client" applications could write onto the queue in the middle, but have it immediately forward these somehow to the internal queue.
Is this possible? How would we best set this up? Would we use channels or is there some other approach that is better?
Thanks,
Gene
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
 |
| klamerus |
| Posted: Thu May 08, 2008 6:14 pm Post subject: Clarification |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Maybe I wasn't clear enough.
Our client has their internal network. This would be connected to a shared network (separated by a firewall). This shared network would be connected to an "exposed" network (firewall between these two as well).
The "exposed" network is connected to the shared and it's connected to the internal, but the exposed and the internal are not. There is no trust between the exposed and the internal networks either, although the shared network trusts both of these.
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| klamerus |
| Posted: Thu May 08, 2008 6:20 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Another data point.
We're still using Websphere MQ 5.3, but we are migrating, so we need to know if this will work (or whatever will work) with both 5.3 and 6.0.
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu May 08, 2008 6:33 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
|
| Back to top |
|
|
| klamerus |
| Posted: Thu May 08, 2008 6:39 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
This doesn't really apply.
This discusses the wraping of WebSphere MQ within HTTP.
We don't have that issue.
We do have the issue that we do not want to allow direct access from this unsecured network to the internal network. We want to limit that access to the shared network. We do allow access to the shared network from the unsecure network.
So, the only acceptable answer to the client's security is hopping, or forwarding, or whatever we want to call what I'm describing in my posts.
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 08, 2008 9:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You want to use the MQIPT Support Pack, MS81.
Put an MQIPT server in the DMZ. It acts as a proxy fronting your internal MQ infrastructure. Because there is no queueing on MQIPT (everything passes in memory) you don't risk data sitting on a server in the DMZ.
So they connect to your MQIPT server, which then forwards the connection to one extra secure MQ Queue Manager inside your firewall. I call this extra secure Queue Manager the "Edge" queue manager. From it you have conventional channels out to the rest of your internal QMs.
Make the Edge QM H.A. a with hardware cluster.
Use 2 MQIPT servers fronted by a VIP so if one goes down the connections swings to the other with no changes to your MQ or their MQ.
We've been doing this for years.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| klamerus |
| Posted: Fri May 09, 2008 2:23 am Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
This is exactly what I'm talking about.
This DMZ is the only environment that can write to the internal systems. If we put this product there, then we only need to open one port between this server and the internal system (point-to-point), which is the ideal for the customer from a security point of view.
While HA is generally desirable, this doesn't need to be HA. The internal system isn't HA at the moment.
What "package" does MQIPT come in? Is there a link where I can read up on this some more?
Thanks
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 09, 2008 2:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| klamerus wrote: |
What "package" does MQIPT come in? Is there a link where I can read up on this some more?
|
IIRC MQIPT is the MS81 support pac. 
It's certainly a support pac; Mr Google will know the details.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| klamerus |
| Posted: Fri May 09, 2008 2:31 am Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
okay, duh. I just searched on MQIPT. Mr. Google shoed me.
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 09, 2008 7:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And its a Cat 3 Support Pack, fully supported by IBM. Long ago I opened up a PMR on it and did receive prompt help. The only thing I don't like about it are its logs are very cryptic.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| klamerus |
| Posted: Fri May 09, 2008 1:59 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Just double checking, but if we install this and point the client senders at this they will work, yes? The standard client-side libraries can be used, not some special or different library, yes?
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 09, 2008 3:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The Queue Managers and/or MQ Clients on either side of your MQIPT server are completely unaware that its sitting in the middle.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| klamerus |
| Posted: Fri May 09, 2008 5:31 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Well, we do need to point the clients at the middle system I expect.
_________________
Careful with that VAX Eugene |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat May 10, 2008 7:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Well, yes, the MQ Clients need to use the IP and port # of the MQIPT server, which then forwards it to the IP and port # of the QM. But if they are unaware that the IP/port they are using is really MQIPT and not the QM they are none the wiser.
Same thing for QM to QM channels with MQIPT in between.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
