[jcifs] Alternative to jcifs.http.NtlmHttpFilter

Michael Piscatello mpiscatello at directvinternet.com
Wed Oct 23 10:59:50 EST 2002


Mike,

Yes, the pop-up appears on Macs at least. No modification. I don't have a
windows PC that does not not use microsoft networking. I will check the
authentication as you suggest.

Mike

On 10/22/02 8:17 PM, "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com>
wrote:

> The pop-up appeared? So you modified it to send the additional 401
> Unauthorized
> / WWW-Authenticate: NTLM? Make sure it's really authenticating OK by
> retrieving
> the NtlmPasswordAuthentication object like:
> 
> NtlmPasswordAuthentication ntlm =
>   (NtlmPasswordAuthentication)req.getSession().getAttribute( "NtlmHttpAuth" );
> 
> That will also give you access to the username and domain.
> 
>> -----Original Message-----
>> From:    Michael Piscatello [SMTP:mpiscatello at directvinternet.com]
>> Sent:    Tuesday, October 22, 2002 8:01 PM
>> To:    Eric Glass
>> Cc:    jcifs at lists.samba.org
>> Subject:    Re: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
>> 
>> 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
>>> 
>>> 
>> 
> 
> 




More information about the jcifs mailing list