[jcifs] Alternative to jcifs.http.NtlmHttpFilter

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Eric Glass [SMTP:eglass1 at attbi.com]
> Sent:	Tuesday, October 22, 2002 7:57 PM
> To:	Allen, Michael B (RSCH)
> Cc:	'Michael Piscatello'; jcifs at lists.samba.org
> Subject:	RE: [jcifs] Alternative to jcifs.http.NtlmHttpFilter
> 
> 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.
> 
	Right.

> > 	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
> 
	Good. Yes, I think this is finally taking shape.