| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Propagating NTLM authentication to back-end service |
« View previous topic :: View next topic » |
| Author |
Message
|
| Gralgrathor |
 Posted: Sat Apr 16, 2016 1:32 pm Post subject: Propagating NTLM authentication to back-end service |
 |
|
Master
Joined: 23 Jul 2009
Posts: 297
|
Yes, I'm still a n00b.
I'm investigating how to integrate IIB 10.0.0.3/4 into an existing service landscape running mostly on Windows platforms where consumers authenticate with providers using IWA/NTLM.
The setup for my PoC is simple:
Flow 1: SoapIn -> stuff -> SoapRequest (to Flow 2)-> stuff -> SoapReply
Flow 2 (acting as a stub for the back end): SoapIn -> SoapRequest (to a SoapUI mock service without authentication) -> SoapReply
I've configured both flows with the Default Propagation profile and done the necessary work to make sure the flows authenticate using IWA. Both Flow 1 and 2 work as expected when provided with requests using NTLM authentication headers.
The problem is in sending requests from Flow 1 to Flow 2: the username token propagated into the flow (obviously) lacks credentials, so the request from Flow 1 to Flow 2 will fail.
I've produced a workaround by retrieving the password from a directory server using a Java Compute node, but this workaround requires that passwords be stored in the directory server in an unencrypted form.
After about a week of reading through the IBM knowledge base and whatnot, I've been unable to find a solution that works with IWA/NTLM and that does not require the retrieval of unencrypted credentials.
Yet I cannot imagine this is such an uncommon problem. Certainly there must be other environments using simple NTLM authentication where the ESB is tasked with propagating the necessary authentication data to back-end services? What am I missing? (I'm assuming that I'm missing a lot, since I've little experience with this authentication mechanism.)
Are there any common patterns or preferred solutions with the above specifications?
Any answers greatly appreciated. Thanks.
Gr,
Gr.
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Apr 18, 2016 4:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If all of the information you have in the incoming request (the security token) doesn't contain enough information about how to authenticate to the back side service, then how do other applications in this infrastructure solve the problem?
Also, you dont't need to store passwords in an external database. You should be able to use mqsisetdbparms (or whatever it's hopefully been renamed to by now) to store the password securely on the broker and reference that id from inside the flow. If only by setting it directly on the SoapRequest node to cause every request sent out by the flow to be authenticated as the same user.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Gralgrathor |
| Posted: Sat Apr 23, 2016 2:15 am Post subject: |
|
|
Master
Joined: 23 Jul 2009
Posts: 297
|
Hi mqjeff, thanks for responding.
| mqjeff wrote: |
| If all of the information you have in the incoming request (the security token) doesn't contain enough information about how to authenticate to the back side service, then how do other applications in this infrastructure solve the problem? |
This is precisely my question. Shouldn't it be possible to propagate *a* valid token to the backend provider (eg. by simply using the same NTLM handshake tokens in the socketconnector) in such a way that it doesn't allow or require access to authentication data other than the identity propagated into the flow? I realize that this is probably closer to an RFE than a support question. Clients I've worked for so far have relied on other mechanisms for security and authentication than their ESB so that a simple authentication against a WSS password token usually sufficed; this is a learning experience for me.
| mqjeff wrote: |
| You should be able to use mqsisetdbparms to store the password securely on the broker and reference that id from inside the flow. |
Propagating a static identity to the back end is one way, but it does mean the back end application can no longer do any authorization on the identity used by the client. It suffices for a simple PoC, but I can imagine there are scenarios in which it doesn't.
| mqjeff wrote: |
| (or whatever it's hopefully been renamed to by now) |
Neh. And I'm calling integration servers execution groups until IBM changes all of their documentation as well 
_________________
A measure of wheat for a penny, and three measures of barley for a penny; and see thou hurt not the oil and the wine. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 25, 2016 3:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Gralgrathor wrote: |
Hi mqjeff, thanks for responding.
| mqjeff wrote: |
| If all of the information you have in the incoming request (the security token) doesn't contain enough information about how to authenticate to the back side service, then how do other applications in this infrastructure solve the problem? |
This is precisely my question. Shouldn't it be possible to propagate *a* valid token to the backend provider (eg. by simply using the same NTLM handshake tokens in the socketconnector) in such a way that it doesn't allow or require access to authentication data other than the identity propagated into the flow? |
That doesn't sound like exactly my point.
You are trying to add Application N (for a very generic sense of 'application').
Existing Applications A,B, C, etc, already have a solution to this problem.
What is it? How does it work?
If A,B,C don't have a solution, then why does yours need one? How does the back end team suggest you solve this problem?
If the message data itself contains information about the client app, then maybe a static id works.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Apr 25, 2016 6:22 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1638
|
NTLM specifically is not a "forwardable" protocol, so you cannot send the inbound credentials onto a backend service. This is not specific to IIB, rather it is a feature on NTLM itself. The usual pattern for NTLM use is for the "mid-tier" app (IIB in this case) to use a single trusted credential for connecting to back end services and in this case this would probably be the IIB service user ID, so all inbound requests connect to the backend as a the single trusted ID. However, you can of course connect outbound with a specific ID instead (mapped from the inbound ID) using a DB for example, but you need to store passwords in the clear somewhere (in the DB?) for this to work.
It is also worth noting that IWA when used with SPNEGO to negotiate the use of Kerberos credentials (rather than NTLM) is "forwardable" using Kerberos delegation, but currently (@10.0.0.4) IIB does not support Kerberos credential delegation - so it would be worth raising an RFE if you really need this behaviour.
I hope this helps...
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| ksrocks9 |
| Posted: Mon Apr 25, 2016 1:07 pm Post subject: |
|
|
Apprentice
Joined: 11 Mar 2015
Posts: 35
|
|
| 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
|
|
|
|
