hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject RE: NTLM authorization header
Date Tue, 29 Mar 2005 10:44:20 GMT
Hi Richard,

it is all too clear what you intend :-)
The problem is that you will hardly be able
to do it without deploying custom code on
the browser. HTTP authentication is meant
to authenticate the client, and not some
computer somewhere else that claims to
be the client.

cheers,
  Roland





"Zhu Li Qiang" <ZhuLiQiang@bcsis.com> 
29.03.2005 11:57
Please respond to
"HttpClient User Discussion"


To
"HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
cc

Subject
RE: NTLM authorization header






Hi Roland,

Thanks for your prompt reply.

My SSO servlet is running in the same domain as the application.

The authorization header seems remaining the same for the whole session, 
by looking into the HttpTracer logs of an interactive session. Maybe BASIC 
scheme is used instead of NTLM.

The SSO servlet implements some secure way to authenticate the user across 
all the supported applications, which may not be covered by the windows 
authentication. And I try to avoid the dialog box since the SSO servlet 
has already authenticated the user.

Hope this makes it clearer.

Thanks,
Richard

-----Original Message-----
From: Roland Weber [mailto:ROLWEBER@de.ibm.com]
Sent: Tuesday, March 29, 2005 17:29
To: HttpClient User Discussion
Subject: RE: NTLM authorization header


Hello Richard,

unless your servlet and the application are running in
the same domain, your servlet will not be able to set
a cookie that would be sent to the application.

With NTLM, the authorization header is not the same
for each request. No matter what authorization scheme,
the browser will generate authorization headers only if
requested by the server it is targetting, and the browser
needs to know the user ID and password for that.
Which means that a dialog box will show up.

You can have IE perform SSO with "trusted" hosts,
based on the user ID and password of the windows
desktop. But then there would be no point in having
an SSO servlet.

cheers,
  Roland





"Zhu Li Qiang" <ZhuLiQiang@bcsis.com> 
29.03.2005 11:17
Please respond to
"HttpClient User Discussion"


To
"HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
cc

Subject
RE: NTLM authorization header






Hi Roland,

Thanks for your help.

I agree that it is very tedious and error-prone to do reverse proxying 
like that. So I try to find other ways.

For the session hand-over, I am wondering whether cookie could play a part 

or not. Currently the web application I am trying to connect to will 
return a cookie identified as "session-id" in its response after 
authentication. The servlet can pass this cookie back to the browser. But 
the problem is the web application expects the browser to include an 
identical "Authorization: XXX" header in every requests. This header was 
generated by the servlet and inserted into the request during its 
authentication with the web application. It is this header I don't know 
how to pass back to the browser so the browser can include it in every 
request to the web application, just like the cookie. I am not familiar 
with the browser behavior, are there any commands, (Java)Script can tell 
the browser to include this header in the next (and then every) requests?

If it is really not possible, then another choice may be to upgrade that 
web application to support Forms-Based Authentication, but that takes a 
long process.

Thanks,
Richard Zhu

-----Original Message-----
From: Roland Weber [mailto:ROLWEBER@de.ibm.com]
Sent: Tuesday, March 29, 2005 16:29
To: HttpClient User Discussion
Subject: Re: NTLM authorization header


Hello Richard,

> When an user's browser hits the servlet, the servlet will use HttpClient 


to:
> 
> 1) logon on to another web application via NTLM authentication
> 
> 2) request the first content page of that application 
> 
> 3) put the response from that application into the servlet's 
> response outputstream, which will redirect the browser to that 
> application directly onwards.
> 
> I have a problem here. Since the httpclient has been authenticated 
> by that application, how can the servlet passes the "authorization 
> headers" and "response headers" down to the browser so the 
> application will not authenticate the browser user again.

It can't. The authentication that took place is for the session
between the servlet and the application. It is not possible to
substitute a different client, or to hand the session over to a
standard web browser.
You could turn your servlet into a reverse proxy and make the client
send all followup requests to the servlet again, which forwards them
to the application. But then you would have to parse all pages sent
by the application, find the links in those pages, and replace them
with links to your servlet. It is no fun at all to do that.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message