tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Single Sign-On problems (SSO not the cause)
Date Mon, 16 Aug 2010 20:07:51 GMT
Carlton Whitmore wrote:
> I just verified that the issue is not with SSO. I tested this by accessing the URL until
I got "Page cannot be displayed" then I tried accessing
and got the same thing. 
> We're not doing any redirects from IIS. Could JCifs be tying up the system?
> Any ideas? 
With respect, I think that you are getting quite a few things mixed up.

There are threee different things altogether :
- User Authentication, here achieved (or not) at the Tomcat level by the jCIFS NtlmHttp 
- SSO, meaning Single-Sign-On, which means that the user needs to authenticate to the 
application (or system) only once, and can subsequently call one or more applications 
without having to login again.
Here, SSO is achieved indirectly by the jCIFS authentication, but that is only because 
this kind of authentication is implicitly carried over to the entire browser/server 
- and then there is SSL, which is implicated when you use the HTTPS protocol (which is 
really a HTTP conversation, but carried over an encrypted SSL link).  That implies that 
the data circulating between the browser and the server (and vice-versa) is encrypted. 
But in this case it has nothing to do with Authentication or SSO.

The 3 above things do "exist" in your case, but they do not really have much to do with 
one another.

And what you tried above does not "prove" anything.

Considering what you have told us so far, I believe that IIS has nothing to do with the 
problem, and neither does SSL/HTTPS.
I believe that your problem is at the jCIFS/NTLM Authentication level, but at this point 
this is more a hunch than a certainty.

To your question "Could JCifs be tying up the system?", my answer would be "yes, it could,

very easily".

And the entire thing seems quite off-topic for this Tomcat users list (because the problem

does not seem at this point to be linked to any Tomcat code, but more to the 
authentication side, which is code coming from somwhere else).
Unfortunately, I don't really know where to send you, because the jCIFS HTTP filter is no

longer developed nor supported, and has not been for quite a few years.

I believe that the people which you should first contact on this are the vendor of your 
application, since after all your setup is their recommendation.
Maybe you should point out to them that they are recommending a solution which is by now 
outdated and no longer technically working; and ask them for an alternative recommendation.

Additional info :

Jespa (see is the closest relative to the jCIFS filter.  It is also a 
servlet filter, which works (from the Tomcat point of view) much like the jCIFS filter.
You can download and test it for free.
But setting it up is not necessarily easy if you do not have some background knowledge of

how NTLM authentication works in the first place.

I not tried Waffle myself.  But Melinda who has, seems to have gotten her system to work 
with it in .. a short time, after spending many hours trying to do NTLM authentication in

other ways.  From what I checked just now at, they even propose a 
servlet filter, which should make it all the easier for you to replace jCIFS.

 From what I know (first-hand for Jespa, hearsay for Waffle) both will work will all 
versions of NTLM and all kinds of Windows workstations (including XP, Vista and W7).

Otherwise, try what I mentioned before : increase the log level of the jCIFS filter, and 
look in its logfile what it has to say about the failed authentications.
But this exercise may turn out to be quite pointless, as you should no longer be using 
this filter anyway.  Even if you fix your current issue, new ones are bound to appear as 
your workstations or servers get updated.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message