Morag,
I have both the qmgr and the web server configured to use LDAP. The qmgr has been configured to use LDAP for some time and authentication/authorization is working fine with the other clients. Starting this week I updated the install to also install the MQ Web Server and configure the MQ Console MQ Messaging API components (previously, these were excluded). MQ (both qmgr and web server) is running on Debian Linux.
I verified I can log into the MQ Console using an admin account I have configured. I can add messages to a queue using this admin account, going through the MQ Console UI. I'm not sure how the console communicates with the qmgr, but this seems to be working as expected. The admin account is configured to have full privileges to the qmgr resources.
My goal is to use the MQ Messaging API to add, browse and receive messages from a queue. Access to each of our queues is controlled by one or more LDAP groups. We typically have a "send" group and a "receive" group, for PUTting and GETting, respectively. My assumption is that accessing a queue through the REST API is a two-step process as far as the authentication/authorization is concerned. First, you have to authenticate with the web server. I've configured this to use LDAP in the mqwebuser.xml before I run 'strmqweb'. Second step is for the qmgr to authenticate the user and verify they are authorized to perform whatever action is being requested.
I believe authentication with the web server is working. For example, if I use Postman with basic authorization I can invoke GET /ibmmq/rest/v2/login and see the ID along with the web server role returned.
{
"user": [
{
"name": "mqdevsnd",
"role": [
"MQWebUser"
]
}
]
}
If I intentionally enter an incorrect password, the same endpoint fails with a 401 (MQWB0105E).
Next, I tried the POST /ibmmq/rest/v1/messaging/qmgr/QS90/queue/MQDEV.QUEUE.V1/message with the body JSON as the message to add. I'm using the same credentials that were successful on the login endpoint. This returns the 403 error:
{
"error": [
{
"action": "Obtain the necessary authorization to perform the operation and resubmit the request.",
"completionCode": 2,
"explanation": "The authenticated principal is not authorized to perform the requested REST API operation.",
"message": "MQWB0103E: Not authorized to put to 'MQDEV.QUEUE.V1'.",
"msgId": "MQWB0103E",
"reasonCode": 2035,
"type": "rest"
}
]
}
and the message I reported in the original post in the qmgr log:
mqdev-server-simple | 06/22/22 12:14:58 - Process(214.17) User(mqm) Program(amqzlaa0)
mqdev-server-simple | Host(mqserver-simple-0) Installation(Installation1)
mqdev-server-simple | VRMF(9.2.0.4) QMgr(QS90)
mqdev-server-simple | Time(2022-06-22T12:14:58.562Z)
mqdev-server-simple | CommentInsert1(IBM MQ REST API)
mqdev-server-simple |
mqdev-server-simple | AMQ5540E: Application 'IBM MQ REST API' did not supply a user ID and password
mqdev-server-simple |
mqdev-server-simple | EXPLANATION:
mqdev-server-simple | The queue manager is configured to require a user ID and password, but none was
mqdev-server-simple | supplied.
mqdev-server-simple | ACTION:
mqdev-server-simple | Ensure that the application provides a valid user ID and password, or change
mqdev-server-simple | the value of CHCKCLNT to OPTIONAL on the AUTHINFO object specified by the
mqdev-server-simple | CONNAUTH attribute on the queue manager. For the change to take effect, you
mqdev-server-simple | must refresh the connection authentication configuration of the queue manager.
mqdev-server-simple | ----- amqzfuca.c : 5089 -------------------------------------------------------
The curl looks like this:
curl --location --request POST 'https://localhost:7443/ibmmq/rest/v1/messaging/qmgr/QS90/queue/MQDEV.QUEUE.V1/message' \
--header 'ibm-mq-rest-csrf-token: blank' \
--header 'Content-Type: text/plain;charset=utf-8' \
--header 'Authorization: Basic bXFkZXZzbmQ6cGFzc3dvcmQ=' \
--data-raw '{
"msg": "Hello!"
}'
Hopefully, I've answered your questions. Thanks for taking a look at this. Based on the behavior and the messages I'm seeing my best guess is that the REST API is not forwarding the user ID and password on to the qmgr at the time it tries to connect. I'm likely missing some configuration that tells the web server to do this, or I need to pass the credentials differently. My goal is that whatever LDAP ID is used to authenticate with the web server, the same ID is passed to the qmgr for performing the requested action.
Regards,
Jim
------------------------------
Jim Creasman
------------------------------
Original Message:
Sent: Wed June 22, 2022 01:52 AM
From: Morag Hughson
Subject: Configuring MQ Messaging REST API (mqweb) with LDAP
Hi Jim,
Are you trying to run the whole queue manager using LDAP authentication and LDAP authorization, or just the MQ web server using LDAP security? The reason I ask is because you have started your post by showing us a CONNAUTH error message, suggesting that you have CHCKLOCL(REQUIRED) set on your CONNAUTH settings, but you have not mentioned them further.
You say "I have the server installed and can successfully authenticate (using LDAP) with the web server." - what do you mean by "server" when you say you "have the server installed" - do you mean the web server, or the queue manager (many many people call a queue manager the "MQ server" so I have to ask!). And what action are you doing to prove you "can successfully authentication with the web server"?
Does the "password missing" error message occur at the time you attempt to use the REST API to put to a queue? Or does it occur at MQ Web Server startup?
Can you show us the full REST command you supply (obviously xxx-ing out or changing the password to something banal when you show us it. Are you sending the user id and password with each request, or are you using cookies?
It is odd that you get message "MQWB0103E: Not authorized to put to '{queue-name}'" as that does suggest that the password did go through. If you had failed password authentication, I would have expected you to get message "MQWB0104E: The REST API request to '{queue-name-url}' is not authenticated."
Are there any interesting messages in the servers/mqweb/logs/messages.log?
Given that you say the Web Console is working - I assume it is using the same MQ Web Server with the same security settings? Isn't there a simple put a message to a queue operation that you can do in the web console? Does that work?
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
------------------------------