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).
Related
What is the use of a server conn in Websphere MQ and why do we go for it.
What is the difference between client conn and server conn.
In some respects these are two opposite things, but they need to match to make a client connection to a queue manager. Its quite a generic topic but fortunately there is lots of useful documentation about this in google / IBM knowledgebase e.g. https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.con.doc/q016480_.htm
As a queue manager, if you are going to let clients connect into you, you need to be able to provide some configuration details (heartbeat intervals, max message sizes, user exits) - these are configured on a SVRCONN channel
As an application, if you want to connect into a queue manager via the client bindings (usually to go to another machine), you need some information about the configuration to use and these are configured on a CLNTCONN channel.
The application 'provides' a CLNTCONN channel, and once the connection is made, an equivalent SVRCONN channel is looked up, and the configuration values are negotiated and the connection made.
An application can 'provide' a CLNTCONN channel at least 3 common ways...
- As part of an MQSERVER environment variable
- Via a client channel table (MQCHLLIB/MQCHLTAB environment variables)
- During an MQCONNX call it can provide the channel details
More details here:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q027440_.htm
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
(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 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.
Now I use the websphere MQ client connect to remote MQ Server(7.0 version) using c#, and occurs a problem of authority,Which is the user running the MQ client application have insufficient authority to access qmgr.Then I use the 'setmqaut' command to grand the user sufficient authority and it works.
I think it's not very convenient and must be a better way.May via adding user's IP in MQ Server? But I have no idea how to do it.
Any suggestions would be greatly appreciated.
Thanks
WebSphere MQ does not perform any authentication. Local applications are authenticated by the operating system and so their ID can be trusted. (By definition, if you cannot trust the local OS authentication then the entire server is compromised.) Just as with local connections, WMQ trusts that the ID connecting remotely is genuine. It is up to the WMQ administrator to determine what level of authentication to employ. In WMQ v7 there are two choices - authenticate with SSL/TLS channels, or use a channel exit to authenticate.
In either case, it is the channel's MCAUSER value that decides what ID is used for authorization. If the MCAUSER is left blank then the channel will use the user ID that the client sends. In your case you received a 2035 error because the client sent an ID that was not in the administrative (mqm) group. Had your client sent the ID 'mqm' (or on Windows 'MUSR_MQADMIN'), the connection would have succeeded. If your program is Java or JMS, the ability to select the ID presented is part of the API. Just tell the QMgr who you want to be.
If you are willing to allow remote connections to execute OS commands on the server, then just put the administrative ID in the channel's MCAUSER. (For example, MCAUSER('mqm') on UNIX/Linux or typically MCAUSER('MUSR_MQADMIN') for Windows.) However, be aware that remote users with admin rights can remotely execute arbitrary OS command-line code using the QMgr. This is a feature of WMQ and not a bug, hence we NEVER recommend this in Production. In fact, I personally recommend that development environments enable security. Waiting until Production to figure out how to authenticate connections and what authorizations are needed often leads to unnecessary deployment delays.
If you want to use IP filtering to mitigate that threat, you can either move to WMQ v7.1 which includes this feature natively, or use an exit such as BlockIP2. Either of these solutions will allow you to create rules that filter incoming connection requests by IP address, user ID, etc.
Note that on a v7.0 QMgr all the channels are unprotected by default. So even if you filter incoming requests on one channel, if the others are left in their default state, anyone can still connect and execute commands as the administrator. For a comprehensive review of all this, please take a look at the Hardening WebSphere MQ presentation at t-rob.net. Scroll down to the v7.0 presentations.