| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ-Client different authenticate methods on multiple SVRCONN |
« View previous topic :: View next topic » |
| Author |
Message
|
| pnusch |
 Posted: Mon Aug 17, 2020 2:21 am Post subject: MQ-Client different authenticate methods on multiple SVRCONN |
 |
|
Newbie
Joined: 17 Aug 2020
Posts: 5
|
Hello,
I working with IBM MQ for z/OS a couple of years and one of my task is to secure our MQ enviroment.
We have version 9.1.
I'm on point that I haven't really an easy solution in my head for the topic.
What I did until yet?
I developed little Java MQ client for testing the TCP/IP connects in combination with CONNAUTH at QMgr.
Test with password and with passphrases (yeah MQCSP).
It works and I give some developer of the inhouse applications possible solutions for extends their application for User + Password / Passphrase authentication.
Now we have third party application them can send client certificate and haven't implement user + password authentication.
So I trying got my MQ client to send an own client certificate, after weeks of despair it works.
My problem was, the CA of the client certificate wasn't in the QMgr keyring and I thought, okay the client can send the certificate and the QMgr would say, no, I didn't trust the certificate.
But without the CA in the QMgr keyring, the client say, I haven't client certificate in my client keystore with match with the sended CAs of the QMgr 
After talking with my RACF admins them created certificate name filter (CNF) in RACF with the DN of my client certificate to my user.
Current intermediate result is, when I connecting with my MQ client in the channelstatus of the SVRCONN stay my user as SSLCERTU.
Back to my intention to write this thread:
We have multiple SVRCONNs for different application on our QMgrs. Want to have SVRCONN A and B, A should authenticate via User + Pass* by CONNAUTH/RACF and B should authenticate via clientcertificate and CNF in RACF.
The "not easy solution" is in my eyes to set CONNAUTH and the AUTHINFO set CHCKCLNT to OPTIONAL,
so the SVRCONN B have then set SSLAUTH to required and for A a CHLAUTH with set CHCKCLNT to REQUIRED.
The big question is now, how I get the SVRCONN B to use the SSLCERTU as user for Connect and access to objects?
Because if I look on our MQ Receiver I see the Sender QMgr user as SSLCERTU but the Receiver QMgr user as MCAUSER?
I don't think that I'm the only with this case so I hope someone can help me or confirm my "not easy solution" to the solution for this case.
Thank you in advance for your answers 
PS: sorry for much text and only two questions at the end  |
|
| Back to top |
|
 |
| hughson |
| Posted: Tue Aug 18, 2020 12:58 am Post subject: Re: MQ-Client different authenticate methods on multiple SVR |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| pnusch wrote: |
My problem was, the CA of the client certificate wasn't in the QMgr keyring and I thought, okay the client can send the certificate and the QMgr would say, no, I didn't trust the certificate.
But without the CA in the QMgr keyring, the client say, I haven't client certificate in my client keystore with match with the sended CAs of the QMgr |
Just so you are aware, this is specifically behaviour from the Java Client - the 'C' client will simply send the certificate with the label you tell it to use.
| pnusch wrote: |
We have multiple SVRCONNs for different application on our QMgrs. Want to have SVRCONN A and B, A should authenticate via User + Pass* by CONNAUTH/RACF and B should authenticate via clientcertificate and CNF in RACF.
The "not easy solution" is in my eyes to set CONNAUTH and the AUTHINFO set CHCKCLNT to OPTIONAL,
so the SVRCONN B have then set SSLAUTH to required and for A a CHLAUTH with set CHCKCLNT to REQUIRED. |
Yes - good, this is exactly the intention of CHLAUTH rule specific CHCKCLNT.
| pnusch wrote: |
The big question is now, how I get the SVRCONN B to use the SSLCERTU as user for Connect and access to objects?
Because if I look on our MQ Receiver I see the Sender QMgr user as SSLCERTU but the Receiver QMgr user as MCAUSER? |
Be aware that MCAUSER is not the same thing as SSLCERTU. SSLCERTU is used as the second user ID checked for the channel. This means that you must have RESLEVEL set so that the channel is doing two user ID checking. Then it will check both MCAUSER and SSLCERTU against the authorisation profiles.
Is your RESLEVEL profile set up for two-user id checking?
Or are you asking how to copy SSLCERTU into MCAUSER? Directly this is not easy, but you could set up an CHLAUTH SSLPEER rule INSTEAD of the RACF CNF MAP to achieve the same result and then you would be setting your user id into MCAUSER.
Happy to provide more information on any of this as required.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| pnusch |
| Posted: Mon Sep 21, 2020 3:40 am Post subject: |
|
|
Newbie
Joined: 17 Aug 2020
Posts: 5
|
First, I apologize me for wrote this answer late.
| hughson wrote: |
| pnusch wrote: |
My problem was, the CA of the client certificate wasn't in the QMgr keyring and I thought, okay the client can send the certificate and the QMgr would say, no, I didn't trust the certificate.
But without the CA in the QMgr keyring, the client say, I haven't client certificate in my client keystore with match with the sended CAs of the QMgr |
Just so you are aware, this is specifically behaviour from the Java Client - the 'C' client will simply send the certificate with the label you tell it to use. |
That explain why I thought it, because in another MQ environment one client sent the certificate without we had the CA in our keyring
| hughson wrote: |
| pnusch wrote: |
We have multiple SVRCONNs for different application on our QMgrs. Want to have SVRCONN A and B, A should authenticate via User + Pass* by CONNAUTH/RACF and B should authenticate via clientcertificate and CNF in RACF.
The "not easy solution" is in my eyes to set CONNAUTH and the AUTHINFO set CHCKCLNT to OPTIONAL,
so the SVRCONN B have then set SSLAUTH to required and for A a CHLAUTH with set CHCKCLNT to REQUIRED. |
Yes - good, this is exactly the intention of CHLAUTH rule specific CHCKCLNT. |
Ok, then I'm on the right way with my thoughts
| hughson wrote: |
| pnusch wrote: |
The big question is now, how I get the SVRCONN B to use the SSLCERTU as user for Connect and access to objects?
Because if I look on our MQ Receiver I see the Sender QMgr user as SSLCERTU but the Receiver QMgr user as MCAUSER? |
Be aware that MCAUSER is not the same thing as SSLCERTU. SSLCERTU is used as the second user ID checked for the channel. This means that you must have RESLEVEL set so that the channel is doing two user ID checking. Then it will check both MCAUSER and SSLCERTU against the authorisation profiles.
Is your RESLEVEL profile set up for two-user id checking?
Or are you asking how to copy SSLCERTU into MCAUSER? Directly this is not easy, but you could set up an CHLAUTH SSLPEER rule INSTEAD of the RACF CNF MAP to achieve the same result and then you would be setting your user id into MCAUSER.
Happy to provide more information on any of this as required. |
Until I read your post, RESLEVEl wasn't in my eyes but looks like the answer for me.
But I notice, I need tests with active security to get more experience.
Until yet is the plan like "if all clients change the connect to sends authinformation then I can turn security on".
I think, I'm on the point where I cann't continue testing without all security on. Until yet in the system test enviroment was only Connection Security on and not Queue-Security and similar
Thanks for your help and information. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
