Can I use on premise MQ explorer to connect to MQ On Cloud? Will it be using the API Key as password for connection? Or any other setup is needed?

Yes. In fact you have to - there is no cloud based MQ Explorer. If you need full admin capabilities (MQ Console doesn't yet provide everything) then you must use an on premise tool.

And yes, the API Key is the password you use when connecting.

The instructions for using MQ Explorer are here.

Other MQ admin tools can also be used with MQ on Cloud. Read more here.

Cheers,
Morag

To expand on Morag's excellent answer, a little thought will bring you to the conclusion that there is no corresponding OS, AD, or LDAP to validate your credentials with a pure Cloud deployment.  Two button clicks, a few minutes wait, and "Poof" you have a Queue Manager.  It is the creation of the secret (API Key) within the Cloud that provides a replacement for a password contained in OS/AD/LDAP.  That's why you need to use the API Key with your MQExplorer client.  

Keep in mind that the password (secret/API Key) is being  *** See Morag's post below *** may be transmitted in clear text. so you probably want to use an SSL encrypted SvrConn channel.    

Regards,

Glen Brumbaugh

It's not true that your API key is being transmitted in clear text. So long as your on-premise MQ installation where the admin tool (such as MQ Explorer) is running is at least at MQ V8, then your API Key will not be sent in clear text.

Certainly, it will be more secure if you use a fully encrypted channel, but it is not as bad a being sent in the clear if you do not.

One question, can you use SSL/TLS channels to the cloud yet? I haven't researched that myself yet.

Cheers,
Morag

Morag,

Thanks for the correction!  Did this behavior change from v7.5 to 8.x?  My Queue Manager is up to date (v9.x) but my Explorer isn't.  I had to back level it a while back to add back in the Message Broker Explorer plug-in for come client testing.  I guess I'll have to run another test with upgraded MQ client software.  

I'll correct my preceding post so that no one picks up inaccurate information.

It looks as if all of the expected SSL settings are there, but you would have to log directly onto the server to perform any necessary keystore processing.  At least I haven't yet found a way to do it through the MQ console.    

Regards,

Glen Brumbaugh

MQ didn't have built-in user ID and password functionality prior to V8. If you use MQCSP to deliver your user ID and password to the queue manager to check (which is what the API key in MQ on Cloud uses) and both ends of the client-server-connection channel are at V8 and above, then the password will not be sent in the clear.

See page 14 of MQTC Presentation: MQ Connection Authentication

If you're running MQ Explorer, be aware that to use MQCSP to deliver the user id and password you must ensure that compatibility mode is OFF.

See Pages 11-12 in the above presentation.

I believe in the most recent versions of MQ Explorer the default has now flipped away from compatibility mode.

Morag, I attended Francois van der Merwe's Webcast on connecting On-Prem MQ to MQ on Cloud on April 10 and while the demo did NOT use SSL channels, the question was asked if secure channels could be used and Francois said SSL/TLS could be used.
Another interesting question was whether outbound (from MQ on Cloud) channel flows were supported and Francois said yes but Server/Requester channels had to be used.
The other question I found interested was whether Pub/Sub was supported by MQ on Cloud and Francois thought that it should be but I am not certain how this squares with the Server/Requester channel point above.

Thanks Dermot. - I knew they were thinking about SSL/TLS, but hadn't had a chance to look into whether it had been done yet or not.

Server-Requester channels don't have to be used, they are just recommended because then you don't need an external static IP address for your on-premise end. If you have an IP address then a Sender-Receiver can also be used successfully.

Not sure how Pub/Sub relates to Server/Requester, but since that is not a hard requirement, I guess no issue.

Cheers,
Morag

>> >> Francois said SSL/TLS could be used.

>> From Hursley. They are aware of that custom certificates are essential for this functionality to be taken seriously by customers. They are also aware of that customers would expect IBM to be a third party having access to possible customer confidential messages on the Cloud queue manager.

I think that's where it was in Beta. So I guess it hasn't yet moved on to real SSL/TLS support.

Cheers,
Morag

Hi everyone,

I can confirm that there is not yet support in the MQ on Cloud service to manage TLS certificates, but it is something that we're aware is important and are considering for inclusion in a future update (subject to the usual disclaimers about forward-looking statements).

Similarly, protecting the content of individual messages is another important topic we talk regularly about with customers for which we are investigating a number of potential options as part of our future roadmap.

Regards,

Matt
(Architect, IBM MQ on Cloud service)

Matt,

Thank you very much for adding you knowledge and presenting the Hursley Park lab point of view (subject to the usual constraints, etc.).  A quick question for you and the lab.  The MQ on the Cloud software Queue Manager shows the location of the keyring.  My assumption is that if access to the server could be provided, that the keyring could then be modified and that the Queue Manager would be able to use the updated x.509 certificates after security was refreshed.  

Is this case?  Is the stumbling block giving a Cloud user access to the server?  Is this a possible work around until full Web interface tools could be made available?  

Regards,

Glen Brumbaugh

Hi Glen, sure - always happy to answer questions!

You are correct that the stumbling block to the approach you suggested is in giving the user access to the operating system of the instance on which the queue manager is running. The queue managers in the cloud service run on shared infrastructure so for security reasons we don't provide direct access to the operating system itself, as that exposes a large surface area for potential security attack, and also increases the chances that a user might accidentally make changes that affect the availability of the queue manager (for which IBM is responsible).

Instead the approach we take is to expose a structured mechanism by which users can carry out the necessary configuration of permitted settings - an example of which you can see already in the ability that we provide to download logs and diagnostic information for the queue manager.

Regards,

Matt