| Author |
Message
|
| gfrench |
 Posted: Tue Aug 06, 2013 7:25 am Post subject: mqsisetdbparms and External SSO |
 |
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
Currently we have a fully automated deploy of our code. The deployment script, bar files and some mqsc files are all sent to the node and then the script does its magic.
It all works very nicely. However the script creates a small in memory database using a hardcode account/password and then performs an mqsisetdbparms with the said account/password. We could randomly generate them and bin them, but that wouldn't be very helpful if we want to investigate issues later.
The database concerned is solidDB which supports the X/Open SSO external authentication mechanism. I cant work out how/if the mqsisetdbparms would work with that. Has anyone done any work in this area that might help?
Thanks for any help |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Aug 06, 2013 7:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You lost me in the middle there where you said your build and deploy process created a new database each time, that was in memory.
mqsisetdbparms is never responsible for creating user accounts and passwords on the external systems it connects to. It's only responsible for providing them to broker in way that they can be stored in an obfuscated manner.
To be slightly more clear - Broker should never be the system of record for passwords.
I'm otherwise really confused about what you are trying to accomplish, and what solidDB has to do with what you are trying to accomplish.
Oh, and, it's a bad idea to store all of your passwords in a homebuilt repository that is accessed by a webservice, too. Or at least, it's only as good an idea as the guy writing it is experienced in creating hardened security systems. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Aug 06, 2013 7:34 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Its not a good thing at the moment due to vulnerabilities in the implementation.
IBM CVEs: CVE-2012-2131, CVE-2012-2110, CVE-2012-0884, CVE-2011-4108, CVE-2011-4576, CVE-2011-4577, CVE-2011-4619, CVE-2011-0014, CVE-2010-3864, CVE-2010-0742, CVE-2013-0169, and CVE-2013-0166
Home-grown way may be more secure. You can set a token in the Bar File Override which is a key to look-up account info in your own Web Service.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 06, 2013 7:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| Home-grown way may be more secure. |
Only if the person building it has significant long term experience building secure data stores.
Otherwise it's almost certainly going to be MUCH LESS secure.
I realize this continues to be a thing you believe is a great idea.
But it's a very hard problem to do right, and very very very easy to do in a way that LOOKS right, but has significant vulnerabilities.
Not to mention that postit note on the secretary's desk with the ceo's login on it. |
|
| Back to top |
|
|
| gfrench |
| Posted: Tue Aug 06, 2013 7:50 am Post subject: |
|
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
Some clarity:-
The database is used as an in memory store for the message flows. I guess that's not really relevant except to say it is only access by the local message flow and nothing else. Currently the script creates the database, providing a very standard clearly readable hard coded account/password.
We obviously don't want to store the account/password in a script, so we have two choices:-
1/randomly create the account/password pair, create the database, do the mqsisetdbparms, then store them in an external password repository for emergency use. I guess we could use a secure webservice to another safe disk bound database.
2/ I don't like the list of vulnerabilities, but we are on a secured trusted network, so we could have a local X/Open SSO server to use as an external security provider, but I don't know how mqsisetdbparms or broker would access its database using external account. Does anyone know if this is possible? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 06, 2013 7:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ok, that makes more sense now.
In terms of debugging, I guess I would create an additional flow that used the same DSN, that would let you examine the contents of the db.
Then you could indeed generate the id/pw randomly, send them to mqsisetdbparms and then discard them. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Aug 06, 2013 8:24 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 06, 2013 8:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| gfrench wrote: |
| we are on a secured trusted network |
There is no such animal. |
There is if you define "secure and trusted" as "signed off by the internal audit, internal security & corporate risk management".
The only way to make any server totally secure from network intrusion is to pull the CAT 5 out of the card. Everything else is a trade off between security & usability.
And as my most worthy associate points out, no form of technological security is proof against the Post-It note.
And as he also says, many methods offer the illusion of security rather than the fact.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Aug 06, 2013 8:58 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| gfrench wrote: |
| we are on a secured trusted network |
There is no such animal. |
There is if you define "secure and trusted" as "signed off by the internal audit, internal security & corporate risk management".
The only way to make any server totally secure from network intrusion is to pull the CAT 5 out of the card. Everything else is a trade off between security & usability.
And as my most worthy associate points out, no form of technological security is proof against the Post-It note.
And as he also says, many methods offer the illusion of security rather than the fact. |
Then why even bother with SSL or encryption? If the network is so secure, there is no need for that added complexity or performance hit.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 06, 2013 9:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Then why even bother with SSL or encryption? |
Because those are things you use to make a network trusted and secure. There's more to network security than a big wide DMZ as I'm sure you'll agree.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gfrench |
| Posted: Wed Aug 07, 2013 6:24 am Post subject: |
|
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
| Slightly off point, so back to my original question, is there any way to use mqsisetdbparms with an external security provider like x/open sso? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 07, 2013 6:33 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| gfrench wrote: |
| Slightly off point, so back to my original question, is there any way to use mqsisetdbparms with an external security provider like x/open sso? |
We answered this already. Yes. However, there are significant unpatched vulnerabilities. See CVE list above.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Last edited by lancelotlinc on Wed Aug 07, 2013 6:34 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 07, 2013 6:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| gfrench wrote: |
| Slightly off point, so back to my original question, is there any way to use mqsisetdbparms with an external security provider like x/open sso? |
Do you mean "How can I get an external security provider to provide user credentials as input to mqsisetdbparms?"
Or do you mean "How can I get broker to replace the credential store behind mqsisetdbparms with an external security provider?"
The answer to the first question is "script it, using whatever means the external security provider allows".
The answer to the second question is "Open an RFE". |
|
| Back to top |
|
|
| gfrench |
| Posted: Wed Aug 07, 2013 7:45 am Post subject: |
|
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
| I mean the second question, so RFE, (Request For Enhancement?) would imply it isn't supported currently. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 07, 2013 7:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
