|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
single server connection channel for multiple client user id |
« View previous topic :: View next topic » |
Author |
Message
|
PeterPotkay |
Posted: Tue Nov 11, 2014 2:56 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
It all gets down to what you consider an app versus what I consider is the definition of app versus the next guy.
If the connections might need to be stopped / started separately, give the apps / components / thingies their own SVRCONN channels.
If the connections might need unique MQ authority, give the apps / components / thingies their own SVRCONN channels.
If you want to track statistics like bytes sent separately, separate channels.
Its as much art as it is science, similar to trying to decide if you need 10 queues for the app or 12 queues. You could probably run a lot of "things" thru one queue and one SVRCONN channel especially with the advent of CHLAUTH, or go the other way and make 1000 queues and then multiply by seven so you have one for each day of the week. The right answer lies somewhere in between, but I tend to err on the side of more queues / client channels rather than less. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
hklbj |
Posted: Wed Nov 19, 2014 12:29 am Post subject: |
|
|
 Apprentice
Joined: 20 Jun 2007 Posts: 34 Location: HK
|
I agreed with Peter that no universal rule for configuring the security in all cases and finally the ChlAuth can provide me the flexibility on my case and I am satisfied with this feature for controlling the MQ objects security.
I have another questions with my case about the channel enabled with SSL. I can enable the channel using SSL with server authentication (1-way) only.
I created a self-signed cert and distribute the public key to my clients. Once an unknown client create the key store and import that public key from elsewhere, the client can connect my server accordingly. It seems to me that it is not as secure as I thought, i.e. it only encrypt the data but cannot deny any unknown clients from connecting my server.
Of course we can enable SSL with (server & client authentication) but my MQ server need to import client's public key to perform 2-way authentication. Can anyone advise what scenario should 1-way authentication to be used? thanks.  |
|
Back to top |
|
 |
hughson |
Posted: Wed Nov 19, 2014 2:15 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
hklbj wrote: |
Of course we can enable SSL with (server & client authentication) but my MQ server need to import client's public key to perform 2-way authentication. |
Just to be accurate, you do not need to import the client's public key if you use CA-signed certificates, then you only need the CA certificate imported into the MQ server to authenticate all the different clients with certificates signed by that CA.
hklbj wrote: |
Can anyone advise what scenario should 1-way authentication to be used? |
1-way authentication can be useful if you have a situation where it is important that the clients can verify they are communicating to a valid server, but the server doesn't care who the clients are. Alternatively it can also be useful if you have some other method of authentication, and then you want to use SSL/TLS just for the encryption, i.e. using User ID & Password authentication in combination with 1-way SSL/TLS authentication.
Cheers
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
hklbj |
Posted: Wed Nov 19, 2014 2:26 am Post subject: |
|
|
 Apprentice
Joined: 20 Jun 2007 Posts: 34 Location: HK
|
Thanks Morag, but a CA-signed cert. is not likely will be used by our clients.  |
|
Back to top |
|
 |
JosephGramig |
Posted: Wed Nov 19, 2014 8:33 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
Or you can create an Internal CA, which is nothing more than a self-signed certificate used to sign Certificate Signing Requests (CSR) from Qmgrs and clients alike.
Then everybody can add the public certificate of the Internal CA and mutual authentication is no big deal. Fine for internal use but not for external partners.
Think about it. |
|
Back to top |
|
 |
hklbj |
Posted: Wed Nov 19, 2014 9:09 am Post subject: |
|
|
 Apprentice
Joined: 20 Jun 2007 Posts: 34 Location: HK
|
JosephGramig wrote: |
Or you can create an Internal CA, which is nothing more than a self-signed certificate used to sign Certificate Signing Requests (CSR) from Qmgrs and clients alike.
Then everybody can add the public certificate of the Internal CA and mutual authentication is no big deal. Fine for internal use but not for external partners.
Think about it. |
Thanks Joseph, will think about this.  |
|
Back to top |
|
 |
|
|
|
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
|
|
|
|