hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34909] - Digest authentication problem with domain\user username format
Date Wed, 18 May 2005 11:42:32 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34909>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34909





------- Additional Comments From olegk@apache.org  2005-05-18 13:42 -------
(In reply to comment #9)
> It turned out not to be a digest problem.
> 
> I was reading the "Known Limitations and Problems" here:
> http://jakarta.apache.org/commons/httpclient/3.0/sslguide.html
> 
> Since I am using JDK 1.3, I figured I might be having a problem with stale
> connection checking--which it looks like is enabled by default in httpclient
> 2.0.2 and 3.0-rc2. I shut of stale connection checking and it started working in
> 3.0-rc2. 
> 
> At first, this made no sense because stale connection checking is also enabled
> in 2.0.2 by default. What is different is the way each version implements
> isStale(). The version 2.0.2 httpclient uses a PushbackInputStream, while
> version 3.0-rc2 uses a BufferedInputStream.
> 
> This may not be a problem in JDK 1.4 at all, but for 1.3 it took a little time
> to figure out. I'm still not entirely sure why this was causing the problem--my
> guess is that because the client thought the connection was stale, it re-opened
> a new one for which the nonce value the client had was no longer valid--hence
> the 401 status code.

This kind of explains it. I do not have good explanation as to why the stale
connection check produces different results with different version of
HttpClient, but at least this perfectly explains why Microsoft IIS fails the
authentication, as IIS traditionally implements its security context based on
the state of a persistent connection.

Anyway, out of this story I brought out three items I would like to follow upon

(1) We need to document this case in the "Known Limitations and Problems"
section of the SSL guide and provide a link in the authentication guide. I'll
accept the bug as an enhancement request shortly

(2) While working on this case I discovered the following document:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/717b450c-f4a0-4cc9-86f4-cc0633aae5f9.mspx

As always Microsoft is true to its embrace and extend strategy towards open
standards. Their implementation of Digest authentication while appears compliant
with RFC 2616 and RFC 2617 in fact represents a superset of the standard with
some additional Windows specific aspects. If you are interested in giving me a
helping hand (or even taking the lead), we could implement a Windows specific
version of DigestScheme

(3) DigestScheme code review made me realize the currently HttpClient does not
correctly handle escaped characters in HTTP elements. 

See an excerpt from Microsoft's "How Digest Authentication Works" document below:

<quote>
* RFC 2617-compliant Digest Authentication challenges and responses must also
comply with RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 quoted string
requirements. This requirement particularly affects the use of backslash (\) and
embedded double quotes. Both must be preceded (escaped) with a backslash.

* For example, domain\username according to RFC 2616 is read as domainusername.
This reading is important because if an application sends information in this
format rather than as domain\\username, authentication fails.

* However, because this is a known issue with domain\username , if
authenticating with backslash encoding fails, Digest SSP attempts to
authenticate the response and assumes that the backslash is part of the string.
This behavior can be turned off by setting the ServerCompat registry key.
</quote>

I'll file a bug report for this issue shortly

Oleg

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message