CFHTTP Authentification problem

[Guest]

My company is moving to single sign-on and it's giving my application problems. Crossed fingers that someone has a solution, and here's the background.
My application is accessed from a portal that prior to this change had its own User ID and Password. Now, the users will be authenticated when they go to the beginning portal page, and according to the people making the change this will be done using Windows Integrated Security. The problem occurs when another application tries to call my app using CFHTTP. In the past this worked fine, but now a 401 - Unauthorized error is occurring. According to the people working the change, this is because the server that the HTTP call is going to doesn’t allow anonymous access and it’s the CF Server, and not the User, that is making the call. I floated the idea of passing the userid and password in the CFHTTP, but that was shot down. Has anybody experienced a similar problem? Maybe something in the admin program that can pass along the User’s information in the call? I’ve attached the pertinent section of my code in case it would be helpful.
Regards,
Mike

[Newsgroup_User]

> this is because the server that the HTTP call is going to
doesn?t allow anonymous access and it?s the CF Server

unless you are running your app on the built-in cf web server, which i
doubt you do, cf is only an APPLICATION server - it does NOT accept
requests from the browser. the WEB SERVER accepts browser requests, and
passes them on to CF.

i would think the problem you see is because the request comes NOT from
IE browser, which is the only browser that supports MS integrated
authentication.

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[tclaremont]

Make sure the account that CF uses has rights and is authenticated on the network. I suspect this is your issue.

[Newsgroup_User]

Azadi wrote:
>
> i would think the problem you see is because the request comes NOT from
> IE browser

Yes, this is the problem. When you use the <CFHTTP...> the ColdFusion
server is the User and the internal 'browser' that CF uses to make the
request can not process the response headers required to use Microsoft
Integrated Security.

I'm sorry, I know of no solution to allow this to work, but you can set
headers with <cfhttpparam ...> tags. So I guess there is a slight
chance that if one *REALLY* knew the Microsoft Integrated Security
protocol and knew what had to be in those headers and could generate
that then it could be done.

But I am not that person, I have never heard of it being done and it may
well not be possible.

[tclaremont]

But if the service that CF runs under utilizes a username and password that is authenticated on the domain, wouldn't it just pass that username and password, thus allowing it to work?

Or are you saying that the CF Browser does not even pass that information at all?

I find this interesting because I believe I have performed exactly what is described here. It could very well be a different set of security on the remote server, though.

[ilssac]

tclaremont wrote:

But if the service that CF runs under utilizes a username and password that is authenticated on the domain, wouldn't it just pass that username and password, thus allowing it to work?

Or are you saying that the CF Browser does not even pass that information at all?

I find this interesting because I believe I have performed exactly what is described here. It could very well be a different set of security on the remote server, though.

Yes that is what I am saying.

For most things, the user name that the CF service runs under can be used for authentication purposes.  I.E. UNC access to network resources, <cfexecute...>, <cfldap...> ectera.

But with the Windows Integrated Security that allows a Windows Browser on a Windows Client to pass the users Windows Domain credentials to a Windows Server running a Windows Web server to be authenticated behind the scenes.  This is done by custom, proprietary requests and response between the Windows Client and the Windows Web server.

With non-windows clients, like Firefox for example, when one access a HTTP resource that is protected by Windows Integrated Security the custom propietary requests and responses fail and the human user is presented with a login dialog box that allows for the authentication to proceed.  The CF engine can not respond to this login request.

The same thing happens for Scheduled Tasks that try to access HTTP resourcs that are protected by Windows Inetgrated Security as the schedule task uses the same internal browser to make and receive the request and responses.

[Guest]

Thanks to each of you for your responses. I'm currently checking on the question that tclaremont asked about the service's username and password being authenticated on the domain. One other possible solution that was raised (by one of our people) is to do a http call using an AJAX function that does the call instead of CFHTTP. I'll update the discussion with where we end up on these issues for the benefit of the rest of the community as I learn more.

Thanks again,

Mike

[Guest]

Just a quick update. I spoke to the individuals that are working on our sign-on change and according to them, the account/password that this used in the cfhttp call is validated on the domain. Despite this fact, the CFHTTP is of course not working.

Regards,

Mike