savoym wrote:
The issue is that we do not currently use web.xml to set the particulars for
JCIFS. A wrapper was built by our former team lead who has now left the
company and Michael Allen had stated that we had to use the settings as he
has it in his doc in order for JESPA to work. As I stated previously, we
cannot rip out the security code that is currently there and just replace it
with the JESPA instructions because there is a lot more that the security
package does than just wrap JCIFS it has built-in security components for a
second layer of security against our legacy system.
Ok, that's more understandable then.
(And believe it or not, I am not a Jespa salesman ;-) )
I Rainer Jung is around, he may tell us if my assumptions are correct,
that IIS+redirector also sends the IIS user-id to Tomcat, if there is any.
If not, then tonight I might be able to send you a servlet filter to
dump the HTTP headers of the requests sent by IIS to Tomcat, to see if
there is a user-id in there somewhere. Unless you have already checked
that ?
Thanks again.
awarnier wrote:
Hi.
I am a bit busy right now, and I'll have more time tonight to answer.
But in short, if you are using jCIFS until now, then Jespa is really a
drop-in replacement. You get the user-id via getRemoteUser() just the
same way. Only web.xml changes, the application does not, as far as I
know.
But we'll look at the other possibilities later.
For now, maybe make sure that IIS is /really/ authenticating the URLs
that go to Tomcat. You may need to tell IIS something, for it to do that.
savoym wrote:
My understanding is that IIS+ jk redirector is suppose to give us windows
authentication what I cannot find either on the IIS website or the Apache
Tomcat Connector website is HOW one gets to the authentication
properties.
I've read the HOW to get it setup but that is as far as it goes on the
Apache Tomcat Connector website.
I am hoping that this is still a viable solution. We did look at Jespa
and
talked to Michael Allen extensively. Unfortunately, we have a security
paradigm that is underlying our entire web app. I have no time to
re-write
my app. Our app currently uses JCIFS but some of our users are using
Windows 7/IE 8 and because JCIFS does not work with NTLMv2 the web app no
longer comes up on Windows 7 that does not use NTLMv1.
There in lies my dilemma. I appreciate again all the help. Hopefully
someone who has made this work will reply.
Regards.
awarnier wrote:
savoym wrote:
Thanks again for the reply.
I do already have the tomcatAuthentication="false" setting as you
stated
below and I had tried the getRemoteUse() from the HttpRequestServlet
but
that unfortunately did not work unless I did something wrong.
I will try again but I do not think that is working. Again, I
appreciate
the time and help.
No problem, that's why we're here.
As mentioned earlier, I'm not too sure that this works with IIS and the
mod_jk redirector for IIS.
I am working on the assumption that it does the same thing as
Apache/mod_jk : if Apache already has a user-id, then mod_jk forwards it
to Tomcat.
When in Tomcat the tomcatAuthentication="false" is set, Tomcat accepts
this user-id from Apache/mod_jk instead of trying to get its own.
Maybe IIS+ jk redirector does the same, maybe not.
If not, there is another possibility : if IIS authenticates the user, it
/might/ automatically add a HTTP header to the request, before even
forwarding it to Tomcat through the redirector.
If so, a servlet filter at the Tomcat level might be able to pick up
this header, extract the user-id, and pass it to your webapp in a way it
can use it.
If all of that is negative, then you need something like the Jespa
filter from ioplex.
That filter /will/ authenticate the call on the base of the user's
domain user-id, and set it in Tomcat, allowing your webapp to pick it up
via getRemoteUser(). This is a certainty, not a guess. I use this
often.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
