[jcifs] RFE's for NTLM HTTP Authentication

Mon Feb 17 23:13:38 EST 2003

  >>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()).  Doing actual group-based 
authorization against NT groups would require DCE/RPC (I believe). 
There are basically 2 ways to handle this:

a) inside your application code, just maintain a list of "valid" users; 
and manually check membership; i.e.:

if (!userlist.contains(request.getRemoteUser())) {
     response.sendError(HttpServletResponse.SC_UNAUTHORIZED,
             "Bad user.");
     return;
}

b) if you want to get a bit more clever, you could subclass/alter 
NtlmHttpServletRequest and override isUserInRole() to check role 
membership for you.  Then your application code would be able to do:

if (!request.isUserInRole("admin")) {
     response.sendError(HttpServletResponse.SC_UNAUTHORIZED,
         "Bad user.");
     return;
}

this would require a bit more work though; you would have to change 
NtlmHttpFilter (or create a new filter) to use your request class 
instead of the NtlmHttpServletRequest class.

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

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.

Eric

> 
>>Hope this is also useful for others.
>>
>>
>> Charly
>>
>>
>>appended class NtlmServlet
>>
> 
> 	What is this supposed to show us?
> 
> 
> 