[jcifs] RFE's for NTLM HTTP Authentication

Tue Feb 18 06:40:41 EST 2003

>>>RFE
>>>when SmbSession.logon throws an Exception because of invalid credentials,
>> the exception is not catched and an Authentication fails without giving
the
>> Browser/user giving a chance to provide other credentials.
>> Better would be in such case to catch the exception and to send another
>> "WWW-Authenticate", "NTLM"  header.
>>
> This was done in 0.7.3.
I see. This is true for NtlmHttpFilter but not for NtlmServlet which I used
and meant.

Eric wrote:
>   >>Also useful would be an interface which gives the application the
> >>possibility
> >>to reject the credentials and to demand others even if they are valid
for
> >>the DC.
> >>For example they maybe  not valid for the application.
> >>
> >
> > This is very application specific behavior that I don't quite understand
and sould
> > be done by writing your own Filter with the NtlmSsp class.
> >
>
> I'm guessing he is talking about authorization rather than
> authentication (i.e. isUserInRole()).
Yes I would have such functionality for Authorization.
But indeed this is application specific. I only want to have an interface to
the
NTLM HTTP Authentication function within jCIFS to indicate that the
application is not "satisfied" with
the authenticated user (credentials). the purpose is to REINITIATE  NTLM
HTTP handshake
(by sending another ...setHeader("WWW-Authenticate", "NTLM"); ..).. and so
giving the user/browser
the chance to provide other credentials.

This would enable thus functionality which  MS IIS has (which demands
new/other NTLM credentials from IE) when there is an
access to a webpage for an unauthorized user.

> >
> >>2. RFE
> >>sometimes NTLM HTTP Authentication is failing or is suppressed for some
> >>reason.
> >>(for example some proxys are disrupting NTLM HTTP Authentication)
> >>this would leave a blank page in the IE window, because the jCIFS
> >>WWW-Authenticate
> >>response sends an empty body.
> >>Better would be an possibility/interface/responsebuffer for the
application
> >>to provide
> >>a html body and/or additional response headers which could deal with
such an
> >>incident.
> >>(For example a timed redirect to a fallback url or webpage which gives
the
> >>user a hint)
> >>
> >
> > The bodies aren't empty but they are sent in a different packet. It's
not clear to
> > me why this should be a real problem because they just contain error
message
> > junk. I don't recall exactly why the body is in a separate packet. I
believe it was
> > necessary to keep the connection open during the 3 message dialog. This
NTLM
> > over HTTP thing is non standard so maintaining state accross the
negotiate
> > presented some problems. To pursue this further we would need to see a
packet
> > trace of the errant dialog.
> >
>
> I think he's talking about providing a custom error body; so instead of
> just doing:
>
> resp.setHeader("WWW-Authenticate", "NTLM");
> resp.setHeader("Connection", "close");
> resp.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
> resp.flushBuffer();
> return;
>
> he wants to do:
>
> resp.setHeader("WWW-Authenticate", "NTLM");
> resp.setHeader("Connection", "close");
> resp.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
> resp.setContentType("text/html");
> resp.getWriter().println("<html><body>No access, pal.</body></html>");
> resp.flushBuffer();
> return;
>
Yes indeed thats it is what I meant.
furthermore I would provide in the body automatic/manual means for an
alternative access to the application (links, javascript , timed redirect
urls....)

That means the body is application specific and should be provided by the
application.

To make it clear the body is also needed for the case that the handshake
does not take place
for some reason.
But if the handshake is functional, the body does not bother (see below)

> This is possible (and is often done to provide "pretty" access denied
> messages).  I'm not sure how it would affect NTLM authentication,
> though; as Mike indicates, NTLM is strange in that it has fairly
> stringent connection requirements.  Testing would have to be done.

I have recently already tested this successfully  (with IE 5.5 and without
jCIFS, handshake only).
the body does not interfere with the NTLM HTTP handshake
Even a META HTTP-EQUIV="REFRESH" CONTENT=5;URL=http:...
could be sent without interfering the handshake
the only special requirement I know is that the connection must not be
closed
during the handshake.
(This could be the reason why I cannot test/use NTLM HTTP Auth with Visual
Age for Java)

Charly