[jcifs] Alternative to jcifs.http.NtlmHttpFilter

[eglass1 at attbi.com]

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
> >>> 
> >>> 
> >> 
> > 
> > 
>