[jcifs] Alternative to jcifs.http.NtlmHttpFilter

[Allen, Michael B (RSCH)]

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