| Author |
Message
|
| PeterPotkay |
 Posted: Wed Feb 10, 2010 5:27 pm Post subject: SSL stores, HTTP nodes and SOAP nodes |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Can someone confirm or correct the following?
#1 HTTP nodes use the Broker level keystore and truststore (if seperate from the keystore).You would use this link to set the EG's SSL related properties:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/an09141_.htm
#2 SOAP nodes use the Execution Group level keystore and truststore (if seperate from the keystore). You would use this link to set the EG's SSL related properties:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/an09148_.htm
#3 If there is a HTTP node that uses SSL and it is in an EG that has a key/trust store set up at the EG level for some other SOAP nodes, that HTTP node ignores the EG level store and still goes out to the Broker level stores and SSL settings
#4 If there is a SOAP node that uses SSL it does not matter what you do to the store at the Broker level because that SOAP node will only ever consider the EG level store(s) and its SSL settings.
#5 There are no other keystores or truststores besides these 2 that could be somehow used.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Feb 10, 2010 5:58 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The Soap Listener is an entirely separate process from the HTTP listener.
That's part of why they have separate ports.
More specifically, the SOAPListener *is* the ExecutionGroup (DataFlowEngine process), and the HTTPListener is the bipHTTPListener process.
The two processes don't share any information.
I suppose if you were feeling masochistic, you could use file system trickery to overlap the two keystore locations and share them. But I think both your security officer and your system admins would have conniptions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 11, 2010 6:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
| I suppose if you were feeling masochistic, you could use file system trickery to overlap the two keystore locations and share them. But I think both your security officer and your system admins would have conniptions. |
Not that I plan to, but couldn't you point both the Broker and the EG, or multiple EGs for that matter, all at the same keystore file? I know that's a dopey idea, but theoretically, is is feasible? Or would one of them put a lock on the key store or trust store file?
My #4 question should read:
"If there is a SOAP node that uses SSL, and you have configured the EG to use a key/trust store specific to that EG, it does not matter what you do to the store at the Broker level because that SOAP node will only ever consider the EG level store(s) and its SSL settings."
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 11, 2010 7:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| mqjeff wrote: |
| I suppose if you were feeling masochistic, you could use file system trickery to overlap the two keystore locations and share them. But I think both your security officer and your system admins would have conniptions. |
Not that I plan to, but couldn't you point both the Broker and the EG, or multiple EGs for that matter, all at the same keystore file? I know that's a dopey idea, but theoretically, is is feasible? Or would one of them put a lock on the key store or trust store file? |
It should work. They shouldn't put locks on the files. Or again if you don't set the EG to point to any keystore/trust store it will use the broker level one anyway. |
|
| Back to top |
|
|
| slonkoski |
| Posted: Thu Feb 11, 2010 10:33 am Post subject: |
|
|
Acolyte
Joined: 18 Mar 2005
Posts: 52
|
|
| Back to top |
|
|
| rahuldhanpal |
| Posted: Thu Feb 25, 2010 10:00 am Post subject: |
|
|
Voyager
Joined: 24 Jan 2009
Posts: 84
Location: Kenosha WI
|
Hi Guys,
The 4 parts mentioned are absolutely correct.
We have implemented the same in our current environment and we point the keystore and truststore for both http/https(httplistener process) and soap http/https ( DataFlowEngine process) to the same store, and it is working for us fine without any issues.
Cheers
RD |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 25, 2010 10:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
One important point: In the above discussions, "HTTP Nodes" applies to HTTP Input and Reply only. HTTP Request Nodes act just like SOAP nodes when it comes to SSL behaviour.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| paranoid221 |
| Posted: Mon Sep 27, 2010 9:52 pm Post subject: |
|
|
Centurion
Joined: 03 Apr 2006
Posts: 101
Location: USA
|
From the infocenter page at :
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac56170_.htm
| Quote: |
"Using port numbers when deploying a SOAPInput node to an execution group
Each execution group that contains a SOAPInput node has one listener and two ports, an HTTP port and an HTTPS port. The default SOAP node port numbers are 7800 for HTTP and 7843 for HTTPS. If you deploy the flow to multiple execution groups, the port number is incremented by one for each successive deployment. The message flow that is deployed to the first execution group receives requests on port 7800 (by default), the next one uses port 7801, and so on, up to the specified limit of 7842. In this scenario, you typically use an intermediary router that listens on one port, then distributes the requests across the range of ports that you are using." |
I find that to be oddly weird. I have been on 3 client engagements so far where they deploy their flows to 2 different execution groups on each broker to achieve local load-balancing. They do the same on the other load-balanced brokers. The above infocenter comment means that if there is a flow that uses a SOAPInput node and clients call
| Code: |
| http://someMBserver:7800/contextRoot/contextPath |
, the call is always picked up by the flow that was deployed first thereby rendering the second deployed flow absolutely useless.
The advice about an intermediary router is seemingly a band-aid fix. For every flow that you build using SOAP nodes, you have to have a router? No thanks
_________________
LIFE is a series of complex calculations, somewhere multiplied by ZERO. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 28, 2010 1:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| paranoid221 wrote: |
From the infocenter page at :
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ac56170_.htm
| Quote: |
"Using port numbers when deploying a SOAPInput node to an execution group
Each execution group that contains a SOAPInput node has one listener and two ports, an HTTP port and an HTTPS port. The default SOAP node port numbers are 7800 for HTTP and 7843 for HTTPS. If you deploy the flow to multiple execution groups, the port number is incremented by one for each successive deployment. The message flow that is deployed to the first execution group receives requests on port 7800 (by default), the next one uses port 7801, and so on, up to the specified limit of 7842. In this scenario, you typically use an intermediary router that listens on one port, then distributes the requests across the range of ports that you are using." |
I find that to be oddly weird. I have been on 3 client engagements so far where they deploy their flows to 2 different execution groups on each broker to achieve local load-balancing. They do the same on the other load-balanced brokers. The above infocenter comment means that if there is a flow that uses a SOAPInput node and clients call
| Code: |
| http://someMBserver:7800/contextRoot/contextPath |
, the call is always picked up by the flow that was deployed first thereby rendering the second deployed flow absolutely useless.
The advice about an intermediary router is seemingly a band-aid fix. For every flow that you build using SOAP nodes, you have to have a router? No thanks |
There is some further discussion of this topic here
And let's remember as well that this isn't significantly different than the situation that occurs with WAS based services. Every WAS server instance has it's own unique ip/port number combination. And so you can only access one instance of a deployed app at a single ip/port.
WAS comes with tools to make it easier to hide this behind a single HTTP server/balancer (the WAS plugin)... and so does Broker in the HTTP Proxy Servlet. |
|
| Back to top |
|
|
| paranoid221 |
| Posted: Tue Sep 28, 2010 8:52 am Post subject: |
|
|
Centurion
Joined: 03 Apr 2006
Posts: 101
Location: USA
|
How about the case where you deploy the same flow onto 2 different brokers and on the first broker you get a port of 7800 for your flow and on the second broker you get say 7802?
In this case instead of providing ur clients with a load-balanced vip in the URL, you are forced to have a specific server in the end-point URL. 
However you can always manually set the port number with one of those fun mqsi commands  or so the documentation says. I haven't tried it yet.
_________________
LIFE is a series of complex calculations, somewhere multiplied by ZERO. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 28, 2010 8:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| paranoid221 wrote: |
How about the case where you deploy the same flow onto 2 different brokers and on the first broker you get a port of 7800 for your flow and on the second broker you get say 7802?
In this case instead of providing ur clients with a load-balanced vip in the URL, you are forced to have a specific server in the end-point URL.
However you can always manually set the port number with one of those fun mqsi commands or so the documentation says. I haven't tried it yet. |
Yes. Or again, the HTTP Proxy Servlet that ships with the Broker Product and can be deployed into any JEE container, including an open source and cost free one that can be run on the same machine as the Brokers or on it's own set of loadbalanced hardware listening to a proper load-balanced VIP...
 |
|
| Back to top |
|
|
|
|
