| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Password validation |
View previous topic :: View next topic |
| Author |
Message
|
| jcv |
 Posted: Wed Sep 04, 2013 3:08 pm Post subject: |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| One can argue that if mq admin host is compromised to that extent that presence of .sth file for a short period of time may become an issue, one can easily suppose that such a host may be not secure from keylogging and that interactive password input does not neccessary mean any protection. Besides that, keeping just .kdb without .sth on a disk, removable or fixed, would not offer much more protection, since if stolen, .kdb can be opened by brute force, the prevention of which leads to the usage of crypto hardware. Although MO71 configuration with SSL client setup without PKCS #11 compliant devices, with .sth file permanently in place gives direct access to connections to qmgrs, while with MQ Explorer potential attacker must figure out additional password when already broke into the system, possibility to actually configure client to use PKCS #11 hardware means that MO71 and MQ Explorer have about the same potential to be secure in that setup. I plan to investigate that. So far I have managed to check that device that I own can be used for that purpose, since I managed to store there certificates by using Ikeyman PKCS11Direct Key database type. |
|
| Back to top |
|
 |
| jcv |
| Posted: Mon Nov 18, 2013 11:06 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| While waiting for the original RFE, I have submitted another, closely related with security configuration and documentation. I have studied a bit MO71's option View Network..., what I'm missing there, is that besides qmgrs as elements of mq topology/architecture/infrastructure, other elements are modestly visualized. For example only those chl types that connect qmgrs are represented in aggregate fashion by lines with symbols that depict their aggregate status, while applications are not visible, neither client nor server. Although great job was done in many ways, for example with automatically discovering foreign qmgr locations, I think connections could have been utilized in the same way to discover applications. And once discovered, their usage of queues/topics could have been visualized also. I know one can argue this is not needed since applications are more volatile and not actually part of mq infrastructure, but it would be nice if we could visualize qmgr hosts in the same diagram with hosts where applications are deployed with their hostnames/ipaddr displayed, appltags and how they connect through channels or directly, ssl or not, user ids, chlauth rules etc..., all as the output from the very same tool that we use for mq administration. Another (definitely) element of mq topology/architecture/infrastructure, not sufficiently visible there is qmgr clusters. I apologize if there is already some MQ Explorer plugin that implements such functionality, is there something like that? |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Nov 18, 2013 11:38 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I am sorry you find the Network View lacking in certain features. There are undoubtedly things I could do to improve it and the next version of MO71 does have some minor improvements suggested by a few customers. The bottom line is that MO71 has, until now, been developed entirely in my own spare time and made available entirely freely to the MQ community, for almost 20 years!. My hope is that a few people will consider it worth supporting and buy a few licences. That will allow me to spend more time enhancing the program.
As always, if anyone has suggestions for improvements they are welcome to mail me at support@mqgem.com
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| jcv |
| Posted: Mon Nov 18, 2013 11:18 pm Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Paul, once again, let me express my sincere admiration for Your work. Out of these 20 years I'm using it for at least 10. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Nov 20, 2013 10:11 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| It would be great if Network View was served via http, because when producing documentation, if several different views are needed, those could be at disposal by dynamic queries, ie by pointing documentation server to MO71 web application. You could improve usability of that web application by enhancing navigation with one additional menu. When certain qmgr is in focus, menu for accessing lists of objects for that qmgr (those options accessible from main page under each qmgr) could be placed in a header of such pages. Also, link to the main page where focus can be switched to another qmgr could be displayed as first option of that menu. I don't know if this is customizable/configurable at the moment (by editing files in html folder), and I don't think it should be. Adding page elements for specifying the values of the dialog fields, which are currently submittable only as query string parameters, would be also nice to have. |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Dec 10, 2013 9:48 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I want to set mq authorization for one user for several qmgrs hosted by several different unix machines, and I want to add that user just once to user repository, let's say AD, and I don't want to force unix admins to configure usage of that AD within OS on all these hosts. It does not matter if they already did that anyway. If I were able to hold mq users only on that AD (meaning that OS doesn't know about them and mq does), that would automatically give me independence from OS administration in any sense, configuring OS to use that AD or adding user locally (obviously it would not give me independence from AD administration). This dependence is sometimes seen as beneficial. Besides that, for large number of qmgrs one central user repository is a benefit in comparison with adding same users locally on each host. Not every piece of sw should necessarily maintain their own users, if one global user repository for all services can be established. But that repository should be usable without restrictions to OS seeing and using that repository, I mean just because some OS hosts some service, it does not mean service is available only from that host. And more importantly, some user using services hosted by that OS should not necessarily use anything on OS level from that host. So are there such restrictions? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Dec 10, 2013 4:43 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| jcv wrote: |
| I want to set mq authorization for one user for several qmgrs hosted by several different unix machines, and I want to add that user just once to user repository, let's say AD, and I don't want to force unix admins to configure usage of that AD within OS on all these hosts. It does not matter if they already did that anyway. If I were able to hold mq users only on that AD (meaning that OS doesn't know about them and mq does), that would automatically give me independence from OS administration in any sense, configuring OS to use that AD or adding user locally (obviously it would not give me independence from AD administration). This dependence is sometimes seen as beneficial. Besides that, for large number of qmgrs one central user repository is a benefit in comparison with adding same users locally on each host. Not every piece of sw should necessarily maintain their own users, if one global user repository for all services can be established. But that repository should be usable without restrictions to OS seeing and using that repository, I mean just because some OS hosts some service, it does not mean service is available only from that host. And more importantly, some user using services hosted by that OS should not necessarily use anything on OS level from that host. So are there such restrictions? |
As far as I know, there is no such product. I have fooled around with OAM exits and even thought about completely replacing the OAM but it would be an incredible amount of work and there is limited interest out there (or at least that's not something people email me about).
About 8 or 9 years ago, a Wily employee gave me a PDF (to review) for an OAM addon or replacement product that did pretty much what you have described. I have no idea what ever happened to the product.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Dec 11, 2013 4:05 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
|
| Back to top |
|
|
| jcv |
| Posted: Wed Dec 11, 2013 10:17 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Perhaps you should have anticipated that request 10 years ago? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 11, 2013 10:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jcv wrote: |
| Perhaps you should have anticipated that request 10 years ago? |
Perhaps they did, and in the pre-RFE world it never made it to the top of the priority list?
Vote now! Vote For Change!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Dec 11, 2013 10:47 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Perhaps I won't, because I can't vote twice for the same RFE? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 11, 2013 10:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jcv wrote: |
| Perhaps I won't, because I can't vote twice for the same RFE? |
Good reason. 
But I do think the RFE system offers we the downtrodden customer a really good way of influencing the development process.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Jan 10, 2014 1:25 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
To all of you who recently celebrated New Year, or are just about to, I wish happy 2014, and to all other people as well.
So, they are smart enough to understand each and every shortage of their product, but they are even more smart to count on customer community inertia and downtroddenness and do nothing about some of them for 10 years? I don't know how exactly is this supposed to comfort me, but I'll take your word for it.
Actually, I'm not that enthusiastic about that conduit of yours. I recently opened an RFE, wanted to discuss such things:
>>Why don't you use as a storage for keys & certificates a qmgr queue instead of files? Wouldn't that add an additional layer of isolation between an attacker and sensitive data? More importantly, it would remove the effort of taking care of where sensitive data should be stored, and how it should be protected on OS level. Why don't you add CMP (Certificate Management Protocol) support for WMQ, or develop your own brand new TCP based protocol for PKI purposes for secure communication between qmgr and CA server? Qmgr knows its own name, and based on that knowledge, and other input, according to predefined rules, why qmgr cannot ask for itself a certificate if MQ admin simply tells it to? Qmgr would create a new pair of keys and ask CA server to deliver certificate for its new public key, and when it receives it, it would store all that to wherever it wants, along with CA cert. Qmgr should also take care of cert expiration automatically, of course. The only duty of mq admin should be to configure qmgr for communication with CA server, hopefully in a manner easily reproducible among qmgrs. Another option would be that qmgr can issue to itself its own certificate too, if people find self issued certificates useful for test environments. Besides qmgrs, standard admin client sw components, like WMQ Explorer should also be upgraded so that they can act like CMP clients.<<
before I could actually ask such questions, I was cut off from further discussion with setting the RFE status to “Delivered”, and an explanation to use support pack MO04.
There is no password validation (yet), then I expect them to make SSL setup more administrator friendly. That's why I opened new RFE, with pretty much same intention.
I also opened an RFE about removing incompatibility between ETC (offers XA capabilities) and CCDT (offers connections to multiple qmgrs) about a year ago, and I remember how satisfied I was when I noticed that its status went from initial to “Under Consideration”, and not from there to “Rejected” on the same day. I was less satisfied when I realized that it will stay there for more than a year, although I read that they declare it cannot stay in that status for more than 3 months or something, without been asked for more information or some other comment, but nothing like that happened. This has nothing to do with the two general's problem, I think they are just reluctant to touch that code.
Another example of odd behaviour is that I unintentionally submitted an RFE about JMS and segmentation support, which is exactly duplicate of some previously rejected RFE, because I found nothing relevant when separating key words (JMS & segmentation) with blank, instead of with comma, during the search. Although, the reasons why they rejected it are not that clear to me, so it's actually good that I submitted it, it is still under consideration.
Because of that, I'm also not 100% sure that somebody didn't already ask for CMP support, I tried with keywords CMP, certificate, found nothing, but I believe I didn't produce duplicate.
I'm also not sure about that with respect to such RFE, that I also submitted:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=43485 |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Jan 29, 2014 11:43 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
There are some beneficial consequences of my writing. Immediately after my previous post, RFE about JMS and segmentation changed status to "Duplicate" with an explanation to see the original why it was rejected. Now everything is OK with respect to JMS and segmentation.
How exactly RFE comments are treated? If someone opens new RFE, and someone else writes comments which substantially change the subject, and noone refutes comments, do they count? I think I should have opened new RFE with amendments to the original "Password validation" RFE, and just place there a reference to the original as a note that it is related to it.
I've been thinking lately about certain things, namely design decisions from the early stage of MQ development. For example the ability to define multiple svrconn channels, in the context of “Single access point” security design pattern, which seems to be not envisioned as important. Obviously, noone forces you to define more than you can consistently defend, but when one understands how powerful these abstractions (patterns) are, that practically every significant piece of sw of various kind more or less conforms to them, one starts wondering about this. There is a wonderful picture worth a thousand words, taken from one of these books about security patterns:
I was so impressed with this picture, I thought I should share it with you.
Another thing is exposing exits as a mean to extend queue manager facilities. Usability of this option is low, plus if implemented by wrong people, it creates problems to L* support teams. Last thing is the ability to develop custom OAM, mainly because of a hypothesis that if certain product is overdeveloped in an unuseful manner, it must be underdeveloped in a useful manner, for example Password validation comes in mind. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Jan 29, 2014 4:56 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| jcv wrote: |
| Another thing is exposing exits as a mean to extend queue manager facilities. Usability of this option is low, plus if implemented by wrong people, it creates problems to L* support teams. |
IBM created many different kinds of exits (i.e. channel, API, OAM, etc..) for MQ, so that users or vendors can extend the products to do interesting/cool things or to add some extra features. Coding any exit for MQ or any product should ONLY be done by an experienced programmer with strong knowledge of the product they are extending.
| jcv wrote: |
| Last thing is the ability to develop custom OAM, mainly because of a hypothesis that if certain product is overdeveloped in an unuseful manner, it must be underdeveloped in a useful manner, for example Password validation comes in mind. |
What in the world are you talking about? What is underdeveloped and/or overdeveloped? Are you talking about MQ itself or are you talking about 3rd party exits or are you talking about some code you have written? You seem to be all over the place with your comments.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
