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 https://myserver.advocacyinc.org:8443 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
filter.
- 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
connection.
- 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 www.ioplex.com) 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 waffle.codeplex.com, 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
