ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » MQ-Client different authenticate methods on multiple SVRCONN

Post new topic  Reply to topic
 MQ-Client different authenticate methods on multiple SVRCONN « View previous topic :: View next topic » 
Author Message
pnusch
PostPosted: Mon Aug 17, 2020 2:21 am    Post subject: MQ-Client different authenticate methods on multiple SVRCONN Reply with quote

Newbie

Joined: 17 Aug 2020
Posts: 4

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
View user's profile Send private message
hughson
PostPosted: Tue Aug 18, 2020 12:58 am    Post subject: Re: MQ-Client different authenticate methods on multiple SVR Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
pnusch
PostPosted: Mon Sep 21, 2020 3:40 am    Post subject: Reply with quote

Newbie

Joined: 17 Aug 2020
Posts: 4

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Mainframe, CICS, TXSeries » MQ-Client different authenticate methods on multiple SVRCONN
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.