| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Connauth using LDAP without password |
« View previous topic :: View next topic » |
| Author |
Message
|
| saurabh25281 |
 Posted: Fri Oct 07, 2016 12:13 pm Post subject: Connauth using LDAP without password |
 |
|
Centurion
Joined: 05 Nov 2006
Posts: 107
Location: Bangalore
|
Hi All,
I am using MQ v 8.0.0.5 and I am using LDAP for conn auth. The application that needs to connect to the MQ server is being developed by a 3rd party, but our organisation does not want to part with the LDAP credential to the developers. The application would be hosted in our organisation. My idea was to use MQCSP and passon the userid & password from the application to MQ for authentication.
So my question is, is it possible to run the application under the LDAP user, without the application needed to pass both userid & password and still be authenticated by the LDAP server.
We don't want to bypass LDAP authentication.
We don't want to pass password from the app.
If this is possible, what option should be configured at MQ Server or/and MQ Client app.
Regards
Saurabh |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Oct 07, 2016 2:10 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why don't they develop it using a test LDAP? The only changes you'll be making then is to the credentials you'll pass in because surely the developers aren't going to hard code it?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| saurabh25281 |
| Posted: Sat Oct 08, 2016 3:21 am Post subject: |
|
|
Centurion
Joined: 05 Nov 2006
Posts: 107
Location: Bangalore
|
Hi,
Even if they develop it in a test LDAP at some point they will have to test in our organisation network where they will have to be provided the credentials.
Even if they are not hard coding it, the credential will be present in a file or DB table. What I want, is to run the application under the organisation LDAP id and since it will already have to be authenticated with credentials before running the application, it does not further need to pass on the credential.
My question is, is this possible with the current version of MQ. |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Oct 08, 2016 2:54 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| saurabh25281 wrote: |
| Even if they develop it in a test LDAP at some point they will have to test in our organisation network where they will have to be provided the credentials... |
Why? Why would a Third-Party be testing an application in your Production environment? Why will your organisation not be testing it below that level? Surely you will test and approve in a Pre-Production environment first?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Oct 09, 2016 12:14 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1916
Location: Bay of Plenty, New Zealand
|
The checking of the password is deferred to the LDAP server. If LDAP is configured to say the user id in question has no password then providing the user id and no password will pass the check. If the LDAP server expects there to be a password for that user, then providing the user without the password will not pass the check.
If you were able to do what you require in order to let this application be tested against your production system, it would mean your production system was insecurable. You would not wish for that.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Oct 09, 2016 4:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| saurabh25281 wrote: |
We don't want to bypass LDAP authentication.
We don't want to pass password from the app.
|
What is the business requirement to "trust" a 3rd-party client app such that it requires no password for authentication?
Is the value of the data it accesses insignificant or publicly available? If so, why even require a username?
Is the inbound SVRCONN channel secured with SSL and/or CHLAUTH records?
Has this solution been approved by internal- or external auditors? (I doubt this solution would pass audit.)
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| saurabh25281 |
| Posted: Sun Oct 09, 2016 8:42 am Post subject: |
|
|
Centurion
Joined: 05 Nov 2006
Posts: 107
Location: Bangalore
|
| exerk wrote: |
| saurabh25281 wrote: |
| Even if they develop it in a test LDAP at some point they will have to test in our organisation network where they will have to be provided the credentials... |
Why? Why would a Third-Party be testing an application in your Production environment? Why will your organisation not be testing it below that level? Surely you will test and approve in a Pre-Production environment first? |
We are not talking about Production right now. Our organisation does not want to provide even non-production credentials to 3rd party developers.
| hughson wrote: |
| If the LDAP server expects there to be a password for that user, then providing the user without the password will not pass the check. |
Yes, the LDAP server expects a password for the userid.
| bruce2359 wrote: |
| saurabh25281 wrote: |
We don't want to bypass LDAP authentication.
We don't want to pass password from the app.
|
What is the business requirement to "trust" a 3rd-party client app such that it requires no password for authentication?
Is the value of the data it accesses insignificant or publicly available? If so, why even require a username?
Is the inbound SVRCONN channel secured with SSL and/or CHLAUTH records?
Has this solution been approved by internal- or external auditors? (I doubt this solution would pass audit.) |
1. There is no requirement to "trust" a 3rd party. Infact that is the reason our org doesn't want to provide the developers credentials, to pass the credentials using application to the MQ server.
2. The SVRCONN is not secured with SSL, as its an internal app.
3. Our internal security team has not approved the current solution. They are still assessing the various options we present them.
Maybe i have to convince our internal team to allow sharing credentials until testing completes in lower environment. Once testing completes, we can either,
1. Reset the password for the LDAP user, if we decide to go with the same user in Production, or,
2. Create a new LDAP user for Production. |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Oct 09, 2016 9:15 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| saurabh25281 wrote: |
| Even if they develop it in a test LDAP at some point they will have to test in our organisation network where they will have to be provided the credentials... |
No, they don't have to test it within your organisation at all - they can test the LDAP element against their own test infrastructure...
| saurabh25281 wrote: |
| We are not talking about Production right now. Our organisation does not want to provide even non-production credentials to 3rd party developers. |
See above...
| saurabh25281 wrote: |
| 2. The SVRCONN is not secured with SSL, as its an internal app. |
So what? It's a SVRCONN, so internal or not, all possible security mechanisms should be utilised to protect it...
| saurabh25281 wrote: |
| 3. Our internal security team has not approved the current solution. They are still assessing the various options we present them. |
Good for them! At least they're doing their job properly...
| saurabh25281 wrote: |
| Maybe i have to convince our internal team to allow sharing credentials until testing completes in lower environment. |
No, you don't. The Third-Party are developing an app for MQ, an app that will require LDAP, so they must provide the necessary testing infrastructure to ensure it works - that's what your organisation is paying them for!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Oct 09, 2016 10:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
An 3rd-party app that effectively requires no credentials, on an unsecured channel, violates best-practice. As such, it should not be allowed on test, pre-prod or production within your organization.
Once allowed in test, with no "apparent" exposures, you will be pressured to eventually percolate it production.
IMHO, all security facilities should be developed and implemented in test, and percolated to prod along with the applications that security facilities protect. Your job, again in my opinion, is to protect your organization from preventable security exposures.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| saurabh25281 |
| Posted: Sun Oct 09, 2016 12:09 pm Post subject: |
|
|
Centurion
Joined: 05 Nov 2006
Posts: 107
Location: Bangalore
|
| exerk wrote: |
No, they don't have to test it within your organisation at all - they can test the LDAP element against their own test infrastructure...
So what? It's a SVRCONN, so internal or not, all possible security mechanisms should be utilised to protect it...
Good for them! At least they're doing their job properly...
No, you don't. The Third-Party are developing an app for MQ, an app that will require LDAP, so they must provide the necessary testing infrastructure to ensure it works - that's what your organisation is paying them for! |
1. They would have to test it within our org, because, except for the Dev, our org have agreed to provide Test/UAT infrastructure.
2. Our org doesn't enforce us to use SSL for all internal apps, so SSL is ruled out. For any apps that communicates outside the current org, SSL is a must.
3. Yeah I agree we have a good security team.
4. Like I mentioned in 1. above, our org have agreed to provide Test/UAT environment, hence, we have to provide them credentials to test out connection to MQ server, which uses LDAP authentication. |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Oct 09, 2016 12:43 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| saurabh25281 wrote: |
| 1. They would have to test it within our org, because, except for the Dev, our org have agreed to provide Test/UAT infrastructure. |
So use a crash-and-burn LDAP user...
| saurabh25281 wrote: |
| 2. Our org doesn't enforce us to use SSL for all internal apps, so SSL is ruled out... |
Trusting bunch aren't they?
| saurabh25281 wrote: |
| ...For any apps that communicates outside the current org, SSL is a must. |
At least they got that right...
| saurabh25281 wrote: |
| 3. Yeah I agree we have a good security team. |
...sort of 
| saurabh25281 wrote: |
| 4. Like I mentioned in 1. above, our org have agreed to provide Test/UAT environment, hence, we have to provide them credentials to test out connection to MQ server, which uses LDAP authentication. |
See 1. above...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 11, 2016 4:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| saurabh25281 wrote: |
| 2. Our org doesn't enforce us to use SSL for all internal apps, so SSL is ruled out. |
How does that follow? Because they don't insist on SSL for internal apps, you can't ever use SSL for internal apps? Why about their lack of enforcement prevents you from using SSL?
| saurabh25281 wrote: |
| 4. Like I mentioned in 1. above, our org have agreed to provide Test/UAT environment, hence, we have to provide them credentials to test out connection to MQ server, which uses LDAP authentication. |
You've agreed to provide a Test/UAT environment. That doesn't mean it has to be the Test/UAT environment. Set up a new crash & burn LDAP for them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
