[jcifs] Alternative to jcifs.http.NtlmHttpFilter

[Michael Piscatello]

Eric,

I'll try it and let you know.

Mike

On 10/24/02 10:09 AM, "eglass1 at attbi.com" <eglass1 at attbi.com> wrote:

> Hmmm... there are a couple of possibilities I could
> think of.
> 
> First, try retrieving "ntlmdomain" and "ntlmuser" from
> the session.  If these two are there, but NtlmHttpAuth
> isn't, then the issue may be the fact that
> NtlmPasswordAuthentication is not Serializable;
> according to the servlet spec, a session is only
> REQUIRED to accept Serializable objects.  It MAY accept
> other objects, and although it MAY throw an
> IllegalArgumentException for unsupported entries, it
> isn't required -- it is conceivable that your container
> is simply ignoring the attribute (although technically
> it IS supposed to throw an exception if it is incapable
> of migrating the object between VMs).  You should be
> able to test this by simply adding Serializable to the
> implements list of NtlmPasswordAuthentication and seeing
> if it works.  For maximum compatibility, this should
> probably be added anyways.
> 
> If NONE of the attributes are showing up, it may be that
> the service method of HttpServlet is removing them
> (during the call to super.service) or otherwise
> monkeying around with the session (although I don't
> believe it is supposed to do anything except dispatch
> the method-specific calls).  The solution in this case
> would be to remove the call to super.service and
> manually dispatch the doXXX methods, instead of relying
> on HttpServlet to do so, like:
> 
>   if (request.getMethod().equalsIgnoreCase("GET")) {
>       doGet(request, response);
>   }
> 
> and so on for each of the doXXX methods.
> 
> Or it could be something else completely.  In any case,
> let me know what you find... I don't have access to a
> testing environment readily available right now, but
> when I get a chance I will tool around with it and see
> what I can determine.
> 
> Eric
>> When using the 
>> 
>>  NtlmPasswordAuthentication ntlm =
>>>   (NtlmPasswordAuthentication)req.getSession().getAttribute( "NtlmHttpAuth"
>>> );
>>> 
>> 
>> I am getting a null when I look for NtlmHttpAuth  in the session. Where can
>> I look to see what is happening?
>> 
>> Thanx
>> 
>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>