In my application, I am sending message out to a Websphere MQ queue. Here in the application, users have the flexibility to set the user id in the message. However my problem is, since the parameter is configurable in my application, if users does not set it, from where the value will be taken?
I have gone through the below links, but got little idea about what value will be set for user id if it is not set at application level.
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqzaw.doc/jm41030_.htm
How to set MQMD ApplicationID field via JMS API?
Any help is appreciated.
The MQMD.UserIdentifier field is set by the queue manager to the user ID associated with the connection (hConn) that put the message. You can see what this user ID is by looking at DISPLAY CONN or the Applications... display in MQ Explorer.
If your application is running using local bindings, that is, it is on the same machine as the queue manager and it chose not to use a socket, then the user ID that the queue manager will discover is the user ID that the application process is running with.
If your application is running using client bindings, that is, it is using a network conncetion to the queue manager, then the user ID that the queue manager will use is the one assigned to the MCAUSER of the channel connection which can be set by CHLAUTH rules, or security exits, or flowed from the client etc.
If your application is going to set the user ID in the MQMD of the message then the application must tell the queue manager it is going to do this, or whatever is in the MQMD.UserIdentifier field will be over-written with the above. To tell the queue manager it wants to do this, the application must use an additional option when it opens the queue, MQOO_SET_IDENTITY_CONTEXT and when it puts the message, MQPMO_SET_IDENTITY_CONTEXT. The open option also requires you to have the authorization to be allowed to do so, +setid when using setmqaut
Further reading:
Message Context
Controlling context information
Related
We are using BizTalk 2016 and MQSC adapter to send message to IBM MQ. We wanted to set MQMD_PutApplName property which we passed the value via Orchestration/Pipeline Component and we could see BizTalk is sending the value for MQMD_PutApplName property as shown below.
When we checked in MQ side it takes the default value as shown below and not taking the value BizTalk is sending.
Looks there is issue with BizTalk 2016 MQSC adapter so could anyone suggest on this issue and how to get the put app name value in MQ in BizTalk 2016
In order to set the values of context fields in the MQMD header, you need to be granted a particular authority or the queue manager will ignore, and over-write, what you wrote in there. You also need to explicitly ask to do this.
In MQ API parlance, asking to set the values in these context fields is done by using the Open Option MQOO_SET_ALL_CONTEXT
I don't know BizTalk configuration, it is there any setting that sounds like "Set Context"? Also, the user ID that you are running this program with, is it in the mqm group? If not, what authorities does it have granted on the queue manager?
Try issuing this MQSC command to learn the answer to that.
DISPLAY AUTHREC OBJTYPE(QMGR)
Further Reading
Message context
I have a local MQ which my IIB connects to in client mode (i.e. not as a trusted application). I've set check client connection security on in the QM and now the IIB can't connect because it doesn't send a password and it's sending the wrong username (by default it uses the user that the process starts with). I've seen lots of documentation around setting dbparms mq::*. I could be wrong that but that only seems to affect the MQ Input and Output nodes ? Not the actual broker and it's config manager connections to MQ?
However, I've tried setting those values so that all client connection to my QMGR get a user/passwd but it still comes across as failing and I can see in the MQ logs that it's trying to connect using the userid that the IIB process was started with (and presumably without a password).
So, how do I get IIB to ALWAYS send a user/passwd to MQ when connecting the node/config mgr to the QM using client connections??
Clarification:
I have set mq::MQ -u -p and still the node attempts to connect to the QMGR using the ID that the MQSI process is started with and not the -u param. I have no execution groups and (of course) no flows in my broker so this can only be a core IIB component that's attempting the connection.
According to the IBM Integration Bus v10.0.0.10 Knowledge Center page "Connecting to a secured WebSphere MQ queue manager" you can set this in three ways:
On each MQ Node by specifying a Security identity property.
For all MQ connections to a named queue manager
For all MQ connections.
The order of which ID will be used is the same as above, so if you have a ID setup for all queue managers, you can override it for a specific queue manager or a specific MQ Node.
If you have a queue manager you are already connecting to called for example IIBQM, you could specify the following command so that all connections to that queue manager would use the specified username and password.
mqsisetdbparms integrationNodeName -n mq::QMGR::IIBQM -u username -p password
The KC page tells how to set it all three ways. If you have any specific questions please update your question by clicking edit and add more details and I can update my answer.
Hurrah - I've worked this out !
Although, I had not enabled chcklocal or chckclnt MQ, the fact that I had a idpwldap authinfo set meant that MQ was going to LDAP to find out who the user was that I was logging in with (presumably so that it could check what group permissions it had). So, I had to put my local user into LDAP and set its group.
This got my broker working (with no execution groups or flows). Once I deployed my simple mqinput and MQ output node flow it failed due to authorisations using the same ID. I could then see that it was binding locally and not as a client (which i had first considered). Phew - all done. So, to review: the answer was to put the user id that the mqsi bip/bipbroker process runs under into LDAP. Then give various MQ permissions so that the broker NODE and it's MQ flow NODES could connect to MQ correctly and put/get etc.
thanks for your help - and maybe this will help someone else in the future when someone puts on MQ security and they have a local QM with IIB.
(First of all, sorry for my poor English)
I've got MQ client (v6.0 or higher). I use mqic32.dll to connect to MQ server. I call MQCONNX to connect to the Queue Manager. MCAUser is not specified for this manager. So, I authenticated at server as a current Windows user.
Well, my program option's window has a 'Test' button and 'Login' Edit. When 'Test' pressed, I call MQCONNX - MQOPEN - MQCLOSE - MQDISQ functions sequence to test the connection/queue opening. There are 2 types of users who starts my application - admin & operator. Admin sets options and performs connection tests, simple users sends and recieves MQ messages. They shoul log in Windows as different Windows users.
And my question is:
I call MQCONNX() being logged as Admin. What parameters (among MQCD struct [sub]fields) should i set for MQ server authenticate me as Operator.
Yes, I can start new process (CreateProcessWithLogonW) as an Operator. But is there a decision keeping me in single process?
I know, using client java- libs I can specify user. So, I think, there should be equivalent ability for mqic32.dll, am I right?
I authenticated at server as a current Windows user.
The queue manager does not authenticate an incoming connection. It will use the UserID to check if the user can do those particular actions i.e. MQCONN, MQOPEN, MQPUT, etc.. But that is not authentication.
If you have not implemented an MQ security solution then anyone can connect with any UserID they want.
I call MQCONNX() being logged as Admin. What parameters (among MQCD struct [sub]fields) should i set for MQ server authenticate me as Operator.
You need to create a client-side security exit and use MQCSP structure but it will not do you any good if you do not have a server-side security exit to read it.
Note: You cannot protect your queue manager from a client-side point of view because anyone can simply download one of the free MQ SupportPacs or one of the many free MQ applications and use it to connect to your queue manager. You need an MQ security solution that is implemented at the queue manager.
I have a qmgr QM1 and local queues Q1 and Q2. There is a SVRCONN channel with MCA set to mqm.
There are multiple application connect to my QMGR for example APP1 and App2.
I want App1 only have PUT authority which means ONLY PUT message to Q1 or Q2 and App2 only have GET authority to ONLY GET message from Q1 or Q2.
Is there any advice.
Each unique set of authorizations needs to be attached to a group. Then when the app connects it needs to do so as a user ID in the appropriate group. (Remember that access requests always resolve to a specific principal, but authorizations are attached to groups.)
In this case, App1 and App2 each need their own group and at least one ID that is in each group. Once you have groups for app1 and app2, then you need to arrange that the MCAUSER of the running channel is a user ID in the appropriate group. You can do this by having different channels with hard-coded MCAUSER in each, or dynamically set the MCAUSER based on CHLAUTH rules. If you have been using channel security exits such as BlockIP2 or MQAUSX then you can configure those to dynamically set the MCAUSER at connect time as well.
Remember that the channels with MCAUSER('mqm') set must be configured to deny access to App1 and App2, or any other non-admin connection. It is much more common and better from a security standpoint to set MCAUSER('*NOACCESS') in all inbound channels and then override that with exits or CHLAUTH rules. That way if the channel configuration fails, it fails to a secure state rather than an insecure state.
There is a SVRCONN channel with MCA set to mqm.
No wonder setmqaut doesn't work. Every client connection UserID will be overwritten with mqm UserID.
Remove the UserID from MCAUSER field of the channel, so that your security setup will start working. Secondly, you will need to look up how to protect your queue manager from client applications using the wrong UserID (intentionally or not).
I need to share a QM and its listener between multiple clients in order to utilize system resources.
my concern is security - access control.
as all clients will have access to the listener port i can't use firewall to manage access rights.
how can i make sure a client can only access his specific queues under the shared QM?
i know i can assign MCAUSER to client level channels, but still, what makes a client being able to only connect to a specific channel?
i have assigned an MCAUSER to a channel and set permissions.
now, from the client java JMS API, how do I connect to that specific channel, and what forbids other clients from connecting to this specific channel?
You are on the right track. I would recommend reading the security presentations from the IBM conference as background. Go to this page and scroll down a bit.
Remember that the client can specify any channel name other than the one you provisioned for them so in addition to setting MCAUSER on the one channel, you need to have set it on all channels. Channels named SYSTEM.DEF.* and SYSTEM.AUTO.* should be disabled with an MCAUSER that cannot be used as a valis user ID. We are currently recommending MCAUSER('*NOACCESS') since *NOACCESS is a reserved word in WMQ V7.1 and later.
Now that you've blocked the unused channels, you need to arrange to map the client connections to their respective user IDs. The way you do this is different depending on which version of WMQ QMgr that you have. In V7.0 and earlier it requires an exit. The BlockIP2 exit at MrMQ.dk is one that the community has contributed to over the years and is owned and maintained by an IBMer. In V7.1 and later the functions in BlockIP2 have been implemented natively in WMQ as CHLAUTH rules.
Specifically, the exit or in V7.1 the CHLAUTH rules allow you to map the connecting client's asserted ID, IP address or SSL Distinguished Name to a user ID to place into MCAUSER when the channel connection is made.
If you need to validate user ID and password, then you would need to write or purchase an exit to do that. Neither WMQ nor BlockIP2 validate ID and password at this time. However, business partners such as Capitalware sell exits which do just that. If you wished to write such an exit, the BlockIP2 source code is a good place to start.