| Author |
Message
|
| jcv |
 Posted: Tue May 21, 2013 10:56 am Post subject: Password validation |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
1. Why don't you develop an option for MQ to have user repository of its own in qmgr queues, that is the ability not to depend on OS for that purpose
2. When MQ already depends on OS for authorization purposes, I think it is natural that authentication against the very same OS is built in feature in MQ, and if OS allows users maintained in repository other than files, that is in LDAP, Active Directory, or elsewhere, that should be supported too
3. Why don't you implement validation of passwords stored hashed and salted in qmgr queues? That could be useful even without implementing 1. If you implement 1., it would be good that passwords can be validated against LDAP and AD too (besides natural choice of queue for password storage) for MQ users which are not defined in OS
4. This type of authentication shouldn't be restricted only to svrconn channels, the same should be implemented for all chl types and for direct connection to qmgr without channels (binding shared memory protocol), that it is for all connections, be that from applications or from other qmgrs
5. It would be good that all of this is fully supported native functionality, as well as few other useful features that don't add to MQ security but to its traceability, and are at the moment only available as support packs
Last edited by jcv on Sun May 26, 2013 4:05 pm; edited 3 times in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue May 21, 2013 11:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, you know that you can indeed add comments directly to the RFE?
Otherwise, best of luck with the discussion here. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue May 21, 2013 4:14 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
It sounds like you are describing MQ Authenticate User Security Exit (MQAUSX)
Although, MQAUSX can authenticate an incoming UserID & Password against many more target systems:
- Server's native OS
- LDAP server
- Microsoft's Active Directory
- Quest Authentication Services
- Centrify's DirectControl
- Encrypted MQAUSX FBA file
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Jul 19, 2013 9:43 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
In anticipation of that RFE, I would like to comment on several other related topics.
Here I discussed SSL based security http://www.mqseries.net/phpBB2/viewtopic.php?t=57649. The fact that client's SSL Key Repository can be placed on a removable drive and/or that password stash file doesn't have to be permanently stored there, it can be created on demand by, for example, Ikeyman, and deleted immediately after it is read by MO71, which in turn satisfies that 1 password requirement in that case, doesn't change the fact that mo71 is slightly inferior to mq explorer with respect to preventing threats of unauthorized access to mq admin's workstation. Firstly, because it is slightly less convenient since MQ Explorer accepts password input directly interactively, and secondly because it is slightly less secure since stashed passwords are present on the system, for at least a certain period of time.
With respect to any other aspect, I prefer using MO71 to using MQ Explorer. Is MO71 still developed by IBM or MQGem?
It occurred to me that when adding SSL features to multiple qmgrs, it would be useful to have an option for easy creating and adding ssl key repository store to adequate qmgr folder from a certain central administration point. For example a wizzard that accepts input about CA root key repository location and its password, which is neccessary to sign a cert request and from which certificate needs to be added to signer certificates section, and all other neccessary input like for example password for newly created kdb. It must be followed by refresh security type(ssl) command, so that could be integrated to the same wizzard. Is there already such an option, some mq explorer plugin or something like that?
Let's get back to the original topic. It is clear that in order to satisfy requirement of both automatic and interactive channel starts, it should be possible to store passwords so that initiating channel agents can use it. Maybe in definitions of sender, cluster sender, requester and client connection channels. Hence, if there is no password stored in them, only interactive start is possible. That's completely analogous to the condition when password stash file is not present in SSL security schema. I thought this should be explained especially when I extended the RFE to the scope of qmgr to qmgr connections.
It also occurred to me that certain features of mq, like for example custom developing of authorization module, as well as custom developing security exits for authentication requires system programming on site that barely any end user will ever do. That's why I think that IBM should take different approach in marketing this product, and offer one version for strict end users, and another for third party developers which utilize such advanced features. Because it is totaly unusual that you can develop your own let's say OAM, but you don't have password validation out of the box in the basic product. Not from the version 8, but from version 1. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Jul 20, 2013 2:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MO71 was never developed by IBM. It was always developed by Paul Clarke and supported by Paul Clarke and released by IBM through the SupportPac processes.
Whether or not Paul Clarke wishs to discuss future business plans of MQGem in the area of providing a standalone GUI console for administering WebSphere MQ is a matter of choice for him.
I'd be glad to see any third party vendor do the same, provided it ran on more than just Windows, ideally a variety of mobile devices, and was actually easier to use than MQExplorer. |
|
| Back to top |
|
|
| jcv |
| Posted: Mon Jul 22, 2013 1:18 pm Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I guess I could have described more concisely that ssl setup wizard I was looking for, as a built in mo04. Natural places for calling such a wizard would be from creating new or editing properties of existing qmgr wizard in MQ Explorer, file transfer between qmgr host, CA host and central administration point host could be performed by scp, sftp, mqft, whatever. Apart from being not integrated into software product which is used for software integration, mo04 looks quite OK and comprehensive. After a shorter reconsideration, I think for its full integration, CA host and central administration point should be the same host. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 23, 2013 12:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are security implications of doing certificate management from a central host, rather than using scripting to do certificate management locally on each host.
Granted, it's from the 'every move of a certificate is a security leak' school of thought, but. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Jul 23, 2013 12:38 am Post subject: Re: Password validation |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| jcv wrote: |
1. Why don't you develop an option for MQ to have user repository of its own in qmgr queues, that is the ability not to depend on OS for that purpose
etc etc |
Who are you talking to in this first post? or which other topic is this related to?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Jul 23, 2013 1:09 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Sorry, that was addressed at IBM.
With respect to security implications of certificate management from a central host vs locally on each host, I guess that should be addressed with some more secure and better integrated procedure/protocol of transfering files, wich leaves no sensitive files at wrong places. I'm aware of that there are probably challenges, but this somehow looks unfinished. After qmgr is created, and there is connection to it, somehow it looks like one should be able to utilize it to do that too. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jul 23, 2013 4:09 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| jcv wrote: |
| Sorry, that was addressed at IBM. |
IBMers might read this forum, but don't expect them to comment here on your ideas for new features. IBM RFE or IBM Service Request might be a better conduit.
_________________
Glenn |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jul 25, 2013 2:19 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| gbaddeley wrote: |
| jcv wrote: |
| Sorry, that was addressed at IBM. |
IBMers might read this forum, but don't expect them to comment here on your ideas for new features. IBM RFE or IBM Service Request might be a better conduit. |
I would replace the word "might" with "is".
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 25, 2013 2:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| hughson wrote: |
| gbaddeley wrote: |
| jcv wrote: |
| Sorry, that was addressed at IBM. |
IBMers might read this forum, but don't expect them to comment here on your ideas for new features. IBM RFE or IBM Service Request might be a better conduit. |
I would replace the word "might" with "is". |
Cardinality error. "IBMers *is* read this forum" doesn't parse. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Jul 25, 2013 2:55 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| mqjeff wrote: |
| hughson wrote: |
| gbaddeley wrote: |
| jcv wrote: |
| Sorry, that was addressed at IBM. |
IBMers might read this forum, but don't expect them to comment here on your ideas for new features. IBM RFE or IBM Service Request might be a better conduit. |
I would replace the word "might" with "is". |
Cardinality error. "IBMers *is* read this forum" doesn't parse. |
IBM RFE or IBM Service Request is a better conduit.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jul 25, 2013 2:56 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| hughson wrote: |
| mqjeff wrote: |
| hughson wrote: |
| gbaddeley wrote: |
| jcv wrote: |
| Sorry, that was addressed at IBM. |
IBMers might read this forum, but don't expect them to comment here on your ideas for new features. IBM RFE or IBM Service Request might be a better conduit. |
I would replace the word "might" with "is". |
Cardinality error. "IBMers *is* read this forum" doesn't parse. |
IBM RFE or IBM Service Request is a better conduit. |
Briljant! 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jul 25, 2013 3:56 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
touché
_________________
Glenn |
|
| Back to top |
|
|
|
|
