[jcifs] NTLM authentication performance

[Mark Orciuch]

Eric and Mike,

Thanks for all your help with this issue.
>
> Attached is a simple web app which uses the JSP stuff.  You will have to
> edit the jcifs.http.domainController init-param to point to an SMB box;
> also, make sure the jCIFS jar is available (this was tested under 0.7.6,
> but should work at least a few revisions back).
>
> You should then be able to go to http://somebox/test/index.jsp, and
> click around.  index.jsp itself doesn't use the class, but the target of
> the POST (test.jsp) does.
>
> Note that use of the extends attribute for JSP pages is generally
> considered poor practice; many servlet containers make assumptions about
> the page implementation which don't hold when you provide a different
> implementation.  This could be the issue you're seeing, although without
> access to a WebSphere container I couldn't tell for sure.  The
> <jsp:forward> might also be causing flukes (I haven't tested that).
>

I don't think this will work in my case because I think it assumes that the
user will always access the portal through the FrontPage. That's not how it
works with Jetspeed - the user could bookmark almost anything and expect to
be automatically authenticated. It's a nifty trick to know though.

> As I'm looking at this more closely, I think I see the issue -- there is
> a bug in NtlmServlet.  You're using jcifs.http.domainController =
> "ngsmobile"; is that a domain?  The reason I'm asking is that I just
> noticed NtlmServlet does
>
> UniAddress.getByName(value);
>
> instead of
>
> UniAddress.getByName(value, true);
>
> The difference is that the second will allow for the possibility that
> "value" is a domain/workgroup (rather than a hostname).  This needs to
> be fixed; in the meantime, see if it works by changing the
> jcifs.http.domainController to an IP address.

It's a workstation name. This explains why the code I pulled out of the
filter worked with both a real domain name and/or workstation.

> The problem is that POSTs will fail (since they will be expecting the
> server to re-negotiate NTLM before they send the data).
>
> Unfortunately, I wasn't able to figure out a way around this.  At first,
> I tried sending a "Connection: close" header from the front page
> (thinking that if I terminated the connection, IE would "forget" that
> NTLM was negotiated).  It still kept sending the Type 1 with an empty
> POST, however.  I also tried closing the connection and redirecting to
> another page (thinking that the redirect might make it forget about
> NTLM); this didn't work either.  Apparently, once NTLM has been
> negotiated to a server, there doesn't seem to be any way to stop this
> behavior.  This is probably a security "feature" (to prevent someone
> from hijacking the connection and sniffing the POST data).  You could
> possibly redirect to another *server*, and then back again, but that is
> just plain kludgy.
>

I even tried to switch to BASIC authentication after NTLM has been
authenticated but I couldn't get it to work quite right.

> I'll keep looking at this -- this is interesting behavior, and deserves
> some scrutiny.  In the meantime, unfortunately, you will probably have
> to use NTLM on all your POST pages.

It's a real shame it works this way. I have a situation where Jetspeed is
competing against commercial portal (IBM WebSphere Portal) and I wanted to
offer robust NTLM authentication because they don't have this feature (not
out of the box, at least). My plan B is to just provide a login screen first
time through and save the user name and domain in the cookie (and store
encrypted password in the user profile) for automatic logins. The user won't
be bothered for password until it expires or is changed.

Best regards,

Mark Orciuch - morciuch at apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/