jespa (jcifs) does not works in Tomcat but works in single app

[Ignacio Ocampo]

Hi all!

I've a simple app (A) that uses JESPA (and JCIFS), it works perfectly when I run this isolated. This app, has a functionA that call a URL with NTLM authentication and I use JESPA to authenticate.

I have another app (B) that uses app (A) as library with TOMCAT, but, when I call the functionA it doesn't work.

In both cases, I'm sure of:

1) I register java protocol handler with: System.setProperty("java.protocol.handler.pkgs", "jespa") at the start of the program (I tried with JAVA_OPTS too).
2) I've jespa-1.1.20.jar and jcifs-1.3.18.jar in /opt/tomcat/lib/ and /opt/tomcat/webapps/ROOT/WEB-INF/lib

Using CLASSPATH: /root/apache-tomcat-7.0.57/bin/bootstrap.jar:/root/apache-tomcat-7.0.57/bin/tomcat-juli.jar:/root/apache-tomcat-7.0.57/lib/jespa.jar:/root/apache-tomcat-7.0.57/lib/jcifs.jar

Can you help me?

[Tim Holloway]

¡Welcome to the JavaRanch, Ignacio!

I'm out of practice on the various cifs mechanisms for Java, but I can try.

First, NEVER put a jar both in the TOMCAT_HOME/lib and WEB-INF/lib directories. Put it one place or the other (assuming it's safe for TOMCAT_HOME/lib), but never both or you risk having bizarre classpath problems.

The best place to set a JVM-level property in Tomcat is via its JAVA_OPTS, which you can set in the setenv.bat or setenv.sh file you add to TOMCAT_HOME/bin. However, I'm not sure if this particular setting is appropriate at the JVM level or not. As a general rule, you should avoid JVM-level properties, since they're inherited by all components and applications in the Tomcat server (although sometimes they should be!)

The jespa system is an authentication system. The preferred way to authenticate in J2EE is to let the container (Tomcat) manage it, using a plugin-in Security Realm. There should be a jespa Realm module available somewhere and that would almost certainly eliminate the confusion about configuration, not to mention being more secure than using user-written security code.

As far as jespa's interaction with CIFS in such a situation, I'm not certain, although as a general rule I don't like putting system-specific file references in web applications anyway. It limits their flexibility. My preference would be to use an NTLM share drive and treat it like an ordinary file/directory.


Incidentally, it's considered polite to inform us when you post the same question in other forums. Things can get confusing otherwise.

[Rainer Schmidt]

Hi

I have the same problem as Ignacio, but I don't see the solution here.
I wanted to use jespa for authenticate a soap web service (client role) to another system. The other system is running on windows and requires NTLM-auth. My tomcat 7 with the main application is running on linux with an own authentication.

Was there a solution found (some times ago?)

[Tim Holloway]

Linux has the SAMBA CIFS client/server filesystem. It allows you to mount a Windows share as though it was part of the local filesystem. That's what I used to use.

The jespa software is good for temporary connections and stuff where you are looking for dynamic connections to CIFS (NTLM), but I recommend Samba for more persistent linkages.

In either case, you'd be logging into the Windows LAN with a Windows userid and password passed as parameters to jespa or configured into Samba.

[Rainer Schmidt]

I found a solution for me:
1. Add jespa.jar and jcifs.jar to the classpath-entries of tomcat. It is not enough in the classpath of the application. It must be loaded togehter with bootstrap.jar and tomcat-juli.jar.
2. start tomcat with -Djava.protocol.handler.pkgs=jespa
I did it in eclipse (in the run configurations dialog). It works well.

[Tim Holloway]

Hmmm. Probably OK, but as a general rule I wouldn't be doing that, and I'm pretty sure that the last webapp I saw using jespa (which was a long time ago) didn't have to.

I still recommend a permanent mount via Samba over putting jcifs code in Tomcat or the webapp unless dynamic share connections are essential.

Incidentally, when running in production, Eclipse and its server settings are (I HOPE!!!) not going to be there. The way to get your environment configured in stand-alone tomcat is to create a TOMCAT_HOME/bin/setenv.sh file and put the following line in it:

JAVA_OPTS="-Djava.protocol.handler.pkgs=jespa"

Windows servers would do the same, but the name of the file would be "setenv.bat".

[Rainer Schmidt]

I'am not sure, whether we talk about the same problem.
I have to do a SOAP call from my application in tocmat to another 3rd party system, which ask for NTLM authentication.
It's not possible to mount something with SAMBA on the machine where the tomcat runs.

Further we use a complex framework with apache-cxf, spring* and many custom classes. I didn't found a solution, where I can integrate this NTLM-authenticated SOAP web service in our application easily.

[Tim Holloway]

cifs is the Common Internet File System, Samba handles it quite well (since that's its primary purposes), the Samba packages are easy to install and there's not a whole lot of good reason not to have them installed on a Unix/Linus/MacOS server in a Windows shop. I do recommend it for "permanent" Windows file mounts.

Based on what I found doing a quick Google, however, people have attempted to use it also as a kludge to NTLM-authenticate a machine for non-file purposes such as SOAP. Which sounds like what you are looking to do.

That sounds like a less than ideal solution, and I'd recommend checking to see if Apache HttpClient can handle NTLM authentication. At the time the people who came up in my Google Search were looking at things, it wasn't working, but one of the problems with the Internet is that old, bad information lives on even long after it's no longer true, so the only real authority on whether HttpClient can now do what you want is the current Apache HttpClient documentation itself.

[Rainer Schmidt]

Your are right. Jespa is not necessary any more.
SOAP with the cxf framework works good, can handle NTLM.

[Tim Holloway]