[jcifs] Alternative to jcifs.http.NtlmHttpFilter

[Michael Piscatello]

Eric, Mike,

I tested the servlet against unauthenticated clients and the pop-up
appeared, took the credentials, and authenticated the user! This testing was
done in a WAS 4.0.2 environment with both PC and Mac clients using IE.

Mike

On 10/22/02 7:57 PM, "Eric Glass" <eglass1 at attbi.com> wrote:

> On Tue, 2002-10-22 at 19:17, Allen, Michael B (RSCH) wrote:
>> 
>> 
>>> -----Original Message-----
>>> From:    eglass1 at attbi.com [SMTP:eglass1 at attbi.com]
>>> Sent:    Tuesday, October 22, 2002 3:30 AM
>>> To:    Allen, Michael B (RSCH)
>>> Cc:    'Michael Piscatello'; jcifs at lists.samba.org
>>> Subject:    RE: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
>>> 
>>> I thought about this as well -- one thing that might be
>>> useful would be to include the HttpServletRequestWrapper
>>> in the filter (to provide getPrincipal(), getRemoteUser
>>> (), etc.),
>>> 
>> Not sure what you mean by this. Do you mean include the
>> HttpServletRequestWrapper class with the jCIFS package?
>> 
> 
> I just meant a wrapper subclass to provide the principal -- I see this
> made it into 0.7.0b5 as "NtlmHttpServletRequest".
> 
>>>  but then set the "NtlmHttpFilter" session
>>> flag to the principal name (i.e., 'DOMAIN\user') instead
>>> of just the string "1".  That way, it provides a quick
>>> and dirty means of obtaining that information under 2.2-.
>>> 
>> Actually I did change the attribute name to NtlmHttpAuth
>> and I put the NtlmPasswordAuthentication object in the
>> session instead of "1". I realize this was the sort of thing
>> that got me in trouble the last time but take a look. I think
>> you'll agree it should work just fine.
> 
> Yes, I think that most of the issues stemmed from having the negotiation
> rely on the session; with the new stuff, the worst case (if the client
> can't accept the session) is just that the authentication gets
> renegotiated each time.  This shouldn't be an issue, since no state is
> maintained during the authentication.
> 
>> retrive that. It now implements java.security.Principal so I
>> need to put that in the session so I can pass it to the
>> NtlmHttpServletRequest (a.k.a your NtlmRequest). Doing
>> this avoids performing NTLM SSP with each and every
>> request which is noticably slower and provides the
>> getRemoteUser functionality at the same time.
>> 
> 
> I liked your take on having NtlmPasswordAuthentication implement
> Principal, by the way -- I thought that was clever.  I haven't had a
> chance to do any real testing yet, but from what I've seen so far it
> looks great.
> 
> Eric
> 
>