How does the PCFMessageAgent with the following constructor gets authenticated. What are the user/configuration permissions required to be set. I connect to MQ of version 8.0.0.4.
public PCFMessageAgent(java.lang.String host,
int port,
java.lang.String channel)
throws MQException
You do not provide enough details to give an exact answer. That constructor does not allow for authentication, it connects to the host/port/channel specified but does not pass a username/password or allow for the use of a cetificate.
If the channel on the queue manager does not require CONNAUTH (ex: "CHKCLNT(OPTIONAL)") or TLS (ex: SSLCIPH/SSLPEER) and you are not blocked by CHLAUTH rules, you may be able to connect.
To determine what user MQ would use for authorization would depend on what user your java process is running under, the MCAUSER attribute of the channel, and any CHLAUTH rules that could map you to a different MCAUSER. Based on the final MCAUSER value, MQ would check if you have permission to the SYSTEM.ADMIN.COMMAND.QUEUE and the model queue used to create a temporary dynamic queue for replies.
If you want to provide a username and password or use certificates you would need to create a MQQueueManager and pass this instead of host/port/channel using this constructor:
PCFMessageAgent(MQQueueManager qmanager)
Initializes a new PCFMessageAgent with an existing queue manager connection.
Related
Im using an MQTTSN Gateway Version 1.2 from;
https://github.com/simon622/mqtt-sn
I notice that a when a client connection goes to sleep and then subsequently wakes up, its IP address may well have changed on the network. When the next PINGREQ message is sent by a client, the gateway is unable to establish its identity from the network address and so the session simply times out.
Is there anyway of updating the network address in this scenario to tie it back to the original session without having the overhead of a new CONNECT?
I tried issuing a new PINGREQ, but the gateway was unable to link the new network address to an existing gateway session.
You're correct in stating that a client may well recycle their IP address during a network event (ie. a network stack power down, or roaming between cells on a cellular network). These events typically require a completely new CONNECT to be issued in order to re-authenticate with a gateway, since typically in SN UDP implementations, the network address is used as part of the identification mechanism. You can CONNECT(clean=false) to maintain session state.
Allowing a client to re-establish (or bind to an existing) session using a PINGREQ alone (with the presence of a clientId) would be very insecure and would present an easy attack vector for session hijacking.
Hope this helps clarify things.
I am trying to connect to IBM MQ using JMS and client channel definition table (CCDT). I was able to connect successfully to the QueueManager when i specify the MQ properties individually.
But when i try to use CCDT file i get the below exception.
As client channel definition table (CCDT) is used to determine the channel definitions used by client applications to connect to the queue manager i didnt set QueueManager Name.
ERROR> com.ssc.ach.mq.JMSMQReceiver[main]: errorMQJMS2005: failed to create MQQueueManager for ''
javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for ''
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:586)
at com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2110)
at com.ibm.mq.jms.MQConnection.createQMNonXA(MQConnection.java:1532)
at com.ibm.mq.jms.MQQueueConnection.<init>(MQQueueConnection.java:150)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:174)
at com.ibm.mq.jms.MQQueueConnectionFactory.createConnection(MQQueueConnectionFactory.java:1066)
Iam using the .setCCDTURL(ccdt); method to set the CCDT URL.
private MQQueueConnectionFactory mqQueueConnectionFactory = new MQQueueConnectionFactory();
mqQueueConnectionFactory.setCCDTURL(ccdt);
queueConnection = mqQueueConnectionFactory.createConnection(username, pwd);
When i try to connect using below configuration instead of the CCDT file it connects to the MQ.
mqQueueConnectionFactory.setHostName(host);
mqQueueConnectionFactory.setChannel(channel);
mqQueueConnectionFactory.setPort(port);
mqQueueConnectionFactory.setQueueManager(qManager);
mqQueueConnectionFactory.setTransportType(1);
Do i need to set setQueueManager as well along with the CCDT file , as the exception says failed to create MQQueueManager for ''
The CCDT is not meant to be read in a text editor, it is a binary formatted file. One of the parameters in the CCDT for each CLNTCONN channel is QMNAME. Knowing what QMNAME is set to and how many CLNTCONN channels you have defined in the CCDT and what you want to accomplish will help figure out what value if any should be specified for with setQueueManager.
If there is only one CLNTCONN channel then you could specify the following and it will connect using the single channel no matter what the QMNAME property is set to:
setQueueManager("*");
If there is more than one CLNTCONN channel in the file each with a different QMNAME specified, assuming the name matches the actual queue manager name listening on the host and port associated with the channel you would pass the queue manager name:
setQueueManager("QMGRNAME");
If there is more than one CLNTCONN channels in the file each with the same QMNAME specified where this name is not meant to reflect a actual queue manager name listening on the host and port associated with each channel, this is known as a queue manager group, this would be intended where you want the client to connect to any number of different hosts and ports and you do not need to know which queue manager you are connecting to, in this case you would pass the queue manager group name prefixed with a *:
setQueueManager("*QMGRGROUPNAME");
Another variation of the above is if there is more than one CLNTCONN channels in the file each with an all blank (spaces) or NULL QMNAME specified, this is known as a queue manager group, this would be intended where you want the client to connect to any number of different hosts and ports and you do not need to know which queue manager you are connecting to, in this case you would pass the queue manager name as either a single space or nothing at all ``:
setQueueManager(" ");
//or
setQueueManager("");
The last use case above would likely work if you did not use setQueueManager at all.
If you want to view the contents of the CCDT, you can use the runmqsc command that comes as part of the MQ v8 and higher client or server install.
For Unix ksh/bash shells use the following:
export MQCHLLIB=PATH/OF/CCDT
export MQCHLTAB=NAME_OF_CCDT
runmqsc -n
For Windows use the following:
set MQCHLLIB=PATH/OF/CCDT
set MQCHLTAB=NAME_OF_CCDT
runmqsc -n
Once the runmqsc program has started and displayed Starting local MQSC for 'NAME_OF_CCDT'. you can run the following command to see the channel details:
DIS CHL(*)
Below is a more specific command to narrow the number of fields returned:
DIS CHL(*) QMNAME CONNAME
I haven't look at it in a while but I thought the correct format is:
MQQueueConnectionFactory qcf = new MQQueueConnectionFactory();
qcf.setQueueManager(qManager);
qcf.setCCDTURL(ccdt);
conn = qcf.createConnection(username, pwd);
I have installed Websphere MQ 8 server in my Windows 8,
using MQ Explorer :
I created a queue manager MAJID.QUEUE.MANAGER with port 1419.
I created a TCP listener on port 1419.
I tried one of the java programs that Tools from MQ8 installation, it runs like this :
PCF_ListQueueNames MAJID.QUEUE.MANAGER 10.196.67.99 1419
but I only got :
Completion Code '2', Reason '2035'.
UPDATE:
the log file says :
AMQ9777: Channel was blocked
EXPLANATION:
The inbound channel 'SYSTEM.DEF.SVRCONN' was blocked from address 'ITD- 968735
(192.168.56.1)' because the active values of the channel matched a record
configured with USERSRC(NOACCESS). The active values of the channel were
'CLNTUSER(alotfi) ADDRESS(ITD-968735)'.
ACTION:
Contact the systems administrator, who should examine the channel
authentication records to ensure that the correct settings have been
configured. The ALTER QMGR CHLAUTH switch is used to control whether channel
authentication records are used. The command DISPLAY CHLAUTH can be used to
query the channel authentication records.
----- cmqxrmsa.c : 1461 -------------------------------------------------------
1/13/2016 15:55:13 - Process(9988.27) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(ITD-968735) Installation(Installation1)
VRMF(8.0.0.4) QMgr(MAJID.QUEUE.MANAGER)
AMQ9999: Channel 'SYSTEM.DEF.SVRCONN' to host '192.168.56.1' ended abnormally.
EXPLANATION:
The channel program running under process ID 9988(8292) for channel
'SYSTEM.DEF.SVRCONN' ended abnormally. The host name is '192.168.56.1'; in some
cases the host name cannot be determined and so is shown as '????'.
There is a great MQ security blog article which describes how to configure MQ to let clients connect securely (i.e. without just turning the security features off).
However to address your specific question, the default channel authentication rules for new MQ 8 queue managers prevent client connections to the queue manager via SYSTEM.* channels. If you run DIS CHLAUTH(*) ALL on a new MQ 8 queue manager you'll see:
DIS CHLAUTH(*) ALL
2 : DIS CHLAUTH(*) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
DESCR(Default rule to allow MQ Explorer access)
CUSTOM( ) ADDRESS(*)
USERSRC(CHANNEL) CHCKCLNT(ASQMGR)
ALTDATE(2016-01-14) ALTTIME(16.15.20)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
DESCR(Default rule to disable all SYSTEM channels)
CUSTOM( ) ADDRESS(*)
USERSRC(NOACCESS) WARN(NO)
ALTDATE(2016-01-14) ALTTIME(16.15.20)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
DESCR(Default rule to disallow privileged users)
CUSTOM( ) USERLIST(*MQADMIN)
WARN(NO) ALTDATE(2016-01-14)
ALTTIME(16.15.20)
The second rule prevents all client connections to channels named SYSTEM.*. This applies to you because you are connecting to SYSTEM.DEF.SVRCONN.
You probably want to define a new SVRCONN channel for your application to connect to and use that instead of SYSTEM.DEF.SVRCONN.
When defining a new channel MQ security best practice is to set the MCAUSER field of the channel to a user that doesn't exist - for example 'nobody'. You can then define a new channel authentication rule that allows your Java application to adopt the user ID you have chosen instead of the default user 'nobody'. The rule could for example be an ADDRESSMAP rule that allows any clients connecting from a specific IP address to connect to the new channel and to adopt the user ID you have chosen.
In summary:
1) Choose a valid user that exists on your system (but that isn't in the 'mqm' group)
2) Define a new non-SYSTEM channel, with MCAUSER set to 'nobody', e.g.
DEFINE CHANNEL(MY.FIRST.CHANNEL) CHLTYPE(SVRCONN) MCAUSER('nobody')
3) Define a new channel auth rule that allows connections from the IP address of you client, and adopts the user you have defined, e.g.
SET CHLAUTH(MY.FIRST.CHANNEL) TYPE(ADDRESSMAP) ADDRESS('192.168.56.1') USERSRC(MAP) MCAUSER('validuser') ACTION(REPLACE)
You will have one further step to perform. You need to tell MQ that 'validuser' is allowed to connect, put, and/or get messages. You can use SET AUTHREC to define the authorities the client should have. See the KnowledgeCenter for the valid AUTHREC options.
The above is an example of how to configure MQ to let your client connect. You should use a combination of blog articles like the one I've linked to and the KnowledgeCenter to set up your security in the way want. For example you might want to use TLS certificates to authenticate your Java client which I haven't described above.
I have a server which allows RMI connections. It exposes a "Server" object on the registry for remote calls, which has a method "authenticate". That method, if successful, returns a "user" object. This user object can then be used by the client to get some data.
It looks like this:
RMIServer server = new RMIServer ();
Naming.rebind("rmi://"+ hostName +"/" + AUTH_OBJECT_BINDING, server);
RMIServer then has a method:
public InterfaceUser Authenticate(String username, String password);
This method checks the username/pw and returns a user object (actually the interface). The user object saves some string which contains the username, and a list of permissions. This can then be checked when calling other methods further down the line.
My question is this:
Someone wants to develop a (another) client for the server, to do this I would give them the interfaces required to interact with it (e.g, the InterfaceUser interface, as well as others). I would need to set up a fake "development" server somewhere to allow them to do this, which they can connect to. Is it possible for that developer to use the interfaces to allow it to get an instance of "InterfaceUser" from the real server without correctly authenticating? For example, Bob logs in to the real server, the server creates a User object which implements InteraceUser. Can Alice, with the interfaces, hijack that object or find it somehow on the registry? All other objects are exported on the same port (if this makes a difference).
Or, can Alice authenticate with the fake server, then somehow use that to access the real server? Let's assume that all usernames/passwords are different on the "real server" and the "development server"
Thanks, any help is appreciated.
Alice can't get any user object unless she can login to a server that provides it.
Any user object Alice does get is bound to the server that created it, and can't be used on another server. It doesn't even survive power cycling of the correct server.
Does that answer your question?
How can I check whether a queue exists on a JMS server using the Java API? I don't want to send or receive any data to the queue for now, just verify that the queue exists. Also, the queue may be empty.
Here is my code sample. I have removed the error handling for simplicity.
Connection connection = null;
Session session = null;
connection = factory.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
//I was hoping this next line would throw an exception if the queue does not exist
Queue queue = session.createQueue(queueName);
My JMS server is TIBCO EMS. I'm hoping for a solution that works on versions 5-7.
Solution
I followed the recommendation in the accepted answer but created a browser instead. The following line threw an exception as desired:
QueueBrowser browser = session.createBrowser(queue);
This is dependent on the provider, but you wont know in most cases until you create the session type, such as session.createConsumer. Simply creating a consumer this way will not consume any messages until you do a receive. And it is here the behavior may change from provider to provider and configuration of the server.
For example with ActiveMQ, assuming there are no permissions blocking the user you are connecting with, the queue is created automatically when you create the session type.
With WebSphere MQ, the queue has to be defined by an admin. If it does not exist, the queue manager will return an exception with a reason code of 2085 (UNKNOWN_OBJECT_NAME).
Outside of this, you'd need to see if the particular provider had a way to access a list of queues. Using the above examples, ActiveMQ you can get the list of queues using JMX, with WebSphere MQ, you can do this if you have permissions to send PCF commands to the queue manager.
Try creating a consumer or producer off the Session passing in the queue object you just created:
session.createConsumer(queue);
This should throw an InvalidDestinationException if the queue (or topic) does not exist.