tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Savoy, Melinda" <>
Subject RE: How can I get the user value in the request forwarded to my Tomcat in my Java app?
Date Tue, 08 Jun 2010 23:38:33 GMT
Andre - thanks for the reply.
From: André Warnier []
Sent: Tuesday, June 08, 2010 16:37
To: Tomcat Users List
Subject: Re: How can I get the user value in the request forwarded to my Tomcat in my Java

Savoy, Melinda wrote:
> Andre,
> Without going into a lot of detail I was finally able to, via the help of an IIS engineer
at Microsoft via our TAM,
  force NTLM authentication via IIS.  What I learned is that by default
IIS is NOT setup to accept NTLM authentication
  but only Kerberos.  Consequently, I went thru some different commands
with the MS IIS engineer to get NTLM
  on IIS to authenticate and now I am getting in the request, per the
ISAPI log, the user info I was looking for (see below).
So all this time, the problem was between the browser and IIS, and
nothing to do with isapi_redirector or Tomcat.
That is basically what Rainer and I have been telling you since a long time.

As for the rest :

- the fact that you are getting something like TEXAS\user-id is normal.
The first part is the (short) domain name.  That is because your LAN
could consist of several domains, and a user-id might be repeated in
different domains (like TEXAS\jsmith and INDIANA\jsmith, being different
users).  Specialised Tomcat-level authentication modules like Jespa (and
I suppose Waffle) have parameters allowing you to have the domain part
stripped automatically if you so wish.  But since you are not using
these modules, you'll have to do that yourself.
But beware of what I say above : really find out with your network
admins if you do indeed have a single domain where a domain-stripped
user-id is really unique; or if your network has different "trusting"
domains inside of which domain-stripped user-id's may not be unique.

- reduce the log level of isapi_redirector now, please.  It is no fun
scanning through hundreds of log lines to find the significant bit.
The (only) significant bit in this case was the very first response,
which indicates a "server error 500" return code. The rest is all
retrieval of error page and links therein (images, css, etc).

- you should temporarily replace your entire webapp (including the
legacy filter) with a very simple one, which does /only/ a
getRemoteUser() and displays it as a response.
Then you will see if the fact that you do not get the user in your
webapp is an issue of your webapp, or maybe of your legacy filter
Then re-insert the legacy filter and try again.

It is possible that the legacy filter simply resets the user-id to null
when /it/ cannot authenticate the user (and that it never checks if the
request is already authenticated to begin with).

The easiest way to disable your legacy filter is probably to temporarily
set its <filter-mapping> (in web.xml) to something that never matches.

Here follows a very simple servlet which just echoes back the userid.
I do not know anything about JSP, but I suspect that doing this with a
JSP page is much simpler.  Christopher or someone ?

package scimisdev;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public final class DumpUser extends HttpServlet {
   public void doGet(HttpServletRequest request, HttpServletResponse
               throws IOException, ServletException {

   String userName = request.getRemoteUser();
   if (userName == null) {
     userName = "*null*";

   PrintWriter writer = response.getWriter();

In your web.xml, include the following:



and call it as http://servername/scimisdev/xxx.dumpuser

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

The information contained in this message and any attachments is intended only for the use
of the individual or entity to which it is addressed, and may contain information that is
PRIVILEGED, CONFIDENTIAL, and exempt from disclosure under applicable law.  If you are not
the intended recipient, you are prohibited from copying, distributing, or using the information.
 Please contact the sender immediately by return e-mail and delete the original message from
your system.

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

View raw message