[jcifs] jCIFS NTLM HTTP Authentication Hangup

Tue Aug 6 17:39:26 EST 2002

On Tue, 6 Aug 2002 13:43:08 +1000
"Pugsley, Jason" <Jason.Pugsley at team.telstra.com> wrote:

> >> I  did  not use your code for reasons that will be obvious when you look at
> >> the attached source. Also, I don't see why it should be necessary to modify
> >> Tomcat.  This  code  should  not be specific to any container. Can you help
> >> enlighten  me  as  to  why you did it the way you did? Do you know what I'm
> >> doing wrong? 
> 
> Wrong? Well I'm not sure if you are. The NTLM authing protocol specifies a constant connection between the browser and web server for the entire time it takes to authenticate.
> 
> When you use a servlet to do the authentication, you might not be able to maintain a constant connection - this may or may not be web-server specific.
> 
> I note from your logs that the connection is HTTP/1.1, but the header string "Connection: close" is also present. You might start by trying a different version of tomcat or a different server altogether.

Err, this doesn't sound good Jason. I was hoping the code would be flexible
enough to work with just about any container. 

> 
> Are you using Tomcat standalone or with the apache httpd server? All my work has been with Tomcat in a standalone configuration (I'm after a pure Java environment which is why jCIFS was my saviour), I'm not sure if this impacts on anything though.

I used the standalone config. But I didn't use your modified Catalina which
is why I'm not getting the third message. 

> 
> As to why I did it the way I did. Well I wanted to make it easy for the end user (if this ever gets out to any). Take a look at this page from the servlet JavaDocs
> http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletRequest.html
> 
> You'll note "BASIC_AUTH", "CLIENT_CERT_AUTH", etc. already exist - I wanted to simply add "NTLM_AUTH" (though it may never be recognised in the standard it might be an extension people can use).
> The function getRemoteUser() would return your logon ID. Other functions like getUserPrincipal() and isUserInRole() would also work as normal. (Not to confuse you - isUserInRole relates to web server roles, not NT Groups).
> 
> Take a look at this document on the apache tomcat web site
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html
> 
> A realm is a way of limiting access to parts of your site by seeing if a user is in a particular role. By doing this, you manage access and authentication at the container level - not in your servlets. When you set up your web apps, you specify the realm and type of authentication (in our case NTLM) in the web.xml file.

Again, I'd rather not use features of a specific servlet engine.

> Download the servlet spec from Sun and read chapter 12 - Security.
> http://www.jcp.org/aboutJava/communityprocess/final/jsr053/
> You write all your sevlets as if they are open to the world, but tell the container to protect the ones you want secured. Your servlet can then do user specific things like:
> //
> // Silly Example
> //
> public void doGet( HttpServletRequest req,
> 			 HttpServletResponse resp ) throws IOException,
> 								ServletException {
> 	PrintWriter out = resp.getWriter();
> 
> 	String username = req.getRemoteUser();
> 
> 	resp.setContentType( "text/html" );
> 	out.println( "<HTML><HEAD><TITLE>Silly Example</TITLE></HEAD><BODY>" );
> 
> 	out.println( "<H1>Hello " + username + "</H1>");
> 
> 	out.println( "</BODY></HTML>" );
> }
> 
> Of course the username returned by getRemoteUser() is their LAN logon ID. You would normally use this as a key into a local database to retrieve their first and last names and any other details you might have relating to that person.
> 
> If you get the source to tomcat, then the most interesting parts can be found in
> org/apache/catalina/authenticator
> Other web servers have similar set-ups.
> 
> I was only able to present a simple end-user set-up by modifying the tomcat source. What is really needed of course is a standard way to extend the web servers to plug in other authentication modules. Who knows, this may happen in future.
> 
> I hope this explains why I chose the path I did. I've just noticed they've release version 4.1.8-beta of tomcat. I'll re-integrate into that version to make sure everything still works.

It's  clear that this MS extension does not integrate well with the Servlet
API because you cannot take over the socket momentarily to handle this sort
of  scenario. I had to modify the jCIFS code pretty seriously to expose the
8  byte challenge and hashes in a nice way. I posted a message to the Resin
list here: 

  http://www.caucho.com/support/resin-interest/0208/index.html

Perhaps you can chime in with your experiences and come up with a solution.
Otherwise  I  think  I  just  have  to  back off these changes and drop the
feature.

Sorry,
Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and more importantly to tasks that have not
yet been conceived. 