HELP - Question on Tomcat Connector ISAPI Filter for authentication on IIS

[Melinda Savoy]

I have been trying to get IIS-Tomcat integration setup. I was finally able to get IIS talking to Tomcat using the ISAPI filter after a lot of help from both the Tomcat users list and IIS engineers. The last leg of this, I think, it is finally get my HttpFilter class working with what the ISAPI Filter is passing into my application via the REQUEST.

In the ISAPI log the request shows the "user" value that shows domain\userID which is what I'm needing to authenticate the user within my SecurityFilter class.
IIS send the NTLM encrypted authenticated domain\userID as well.

However, when the Tomcat container initiates the HttpFilter class below in the doFilter() the req.getRemoteUser() returns a NULL value.:

public final void doFilter(final ServletRequest request, final ServletResponse response, final FilterChain chain) throws IOException, ServletException {
		final HttpServletRequest req = (HttpServletRequest) request;
		final HttpServletResponse resp = (HttpServletResponse) response;

                String userID = req.getRemoteUser(); // returns a NULL value.

		try {
			execute(req, resp);
		} catch (FilterInterruptException e) {
			return;
		} catch (Exception e) {
			log.severe(new HttpRequestDebugger(req).toString());
			throw new ServletException(e);
		}

		chain.doFilter(request, response);

		this.afterChain(req, resp);
	}

I am not knowing where the problem could be. If anyone has worked with the Tomcat connector for IIS please respond ASAP. If add'l info is required please let me know.

Also, while debugging in Eclipse I DO NOT SEE the remoteUser under the req variable name in the debugger. I see a lot of other properties but NOT remoteUser. Any suggestions here as well would be appreciated.

Thank you.

[Tim Holloway]

remoteUser (and userPrincipal) is set when the user logs in using J2EE standard container-based authentication. If you're not using the built-in security system - e.g., using a custom login system, they will remain null.

[Melinda Savoy]

Thanks for the reply. IIS is actually authenticating the user and it is my understanding that the ISAPI filter from Apache Tomcat can then decrypt the NTLM value from IIS, which it does per my ISAPI log, and then send it to Tomcat so that I can grab it and use it for authentication purposes using the getRemoteUser().

Thanks again.

[Tim Holloway]

Melinda Savoy wrote:Thanks for the reply. IIS is actually authenticating the user and it is my understanding that the ISAPI filter from Apache Tomcat can then decrypt the NTLM value from IIS, which it does per my ISAPI log, and then send it to Tomcat so that I can grab it and use it for authentication purposes using the getRemoteUser().

Thanks again.

You'd have to provide the user principals and roles via a Tomcat Realm in order for getRemoteUser to work. FIlters, IIS authenthicators - none of them setup the J2EE security context of which getUserPrincipal and getRemoteUser are parts.

Specifically, from the javadocs:

	getRemoteUser()
          Returns the login of the user making this request, if the user has been authenticated, or null if the user has not been authenticated.

Their definition of "authenticated" means using J2EE container-managed security (as configured by web.xml security elements), not an external add-on or application-internal security system.

[Melinda Savoy]

Thanks TIm. I actually just took the Tomcat Connector defaults on the realm setup. I never setup a custom Realm within the config of this ISAPI filter.

Have you done that before? I guess I'll start reading up on that as well. Thanks so much for the help. If it's ok I may ping you again for additional help on that.

[Tim Holloway]

I'm afraid that I'm not much up-to-date on Windows/Tomcat/IIS interactions. I don't have the time or a big enough bottle of antacids to manage Windows security, so all the Windows machines in my environment are desktops barricaded behind several layers of firewalls and not servers.

J2EE security realms are configured as part of the Tomcat server configuration and are actually run as Tomcat code, not as part of the webapp the way filters are. They reference data defined in web.xml to determine what security context a URL demands, and what roles have access to it. Beyond that, the only other point of contact is that incoming HttpServletRequest objects are provisioned with user credentials and constructed from classes that hook back to the Tomcat user and role-checking code. Which is useful, since you can use a completely different (and simpler) security system for development then pick a more appropriate security system for production.

If the primary level of security is external (IIS), then you'd need to configure the Tomcat server to use a Realm module that could communicate with that service. For example, the CAS implementation from Yale University is a Single Signon (SSO) Realm implementation, which if my memory isn't too far gone can hook into the user's Windows Logon system. Meaning that simply by being logged into windows, the user is considered to be logged into the webapp.

All that is part of the basic J2EE security framework, however, and doesn't require (or use) servlet filters.

[Melinda Savoy]

Thanks, Tim. There is a lot there to decipher and I can't say that I blame you regarding Windows security. That is why we were using JCIFS. But unfortunately, JCIFS does NOT support NTLMv2 and therein lies the issues. Because IIS does support NTLMv2 and from what I understood from the guys on the Tomcat list server, without any realm configuration then I could get the "user" value directly from the ISAPI filter just by using the getRemoteUser() in my java code. Which now turns out to be untrue. Its definitely been a learning experience. It has literally taken me 2 months just to get the ISAPI filter configured properly and IIS configured properly to talk to each other. The instructions looked very simplistic but it turned out to be more complex. When I finally got that done then I thought I could just use the getRemoteUser() and be on my way. ARGGGH...

[Tim Holloway]

I think they meant you can get the remote user HTTP header from the HttpServletRequest. I doubt they're familiar with J2EE internals so they wouldn't realize that the API call isn't quite the same thing. You probably CAN get the header value, but you'll have to read the header itself for that.

[Melinda Savoy]

That is exactly what they meant but I could only get the encrypted AUTHORIZATION NTLM value and not the decrypted value that the ISAPI log provided. I understood that the ISAPI filter would provide the decrypted NTLM value which I saw in the ISAPI log but I could not get to via the HttpServletRequest getRemoteUser() which is what I was being told should work but it did NOT.

Now I'm in the middle of going through the process of getting the NTLM decoded using Sun's Base64Decoder.

Hope that makes sense.

[Tim Holloway]

Melinda Savoy wrote:

Now I'm in the middle of going through the process of getting the NTLM decoded using Sun's Base64Decoder.

Whoops! Don't do that! The com.sun.decoders will cause compilers and IDEs to whine. You should only use com.sun classes if you work for Sun. Er, Oracle. Whatever. Or you're using a commercial package from them.

For Base64 decoding, use the Apache commons decoder instead. Same results, no complaining from the development system.

[Melinda Savoy]

Thanks Tim. I've already encountered NPE on a valid NTLM value so I was not sure and started down another weeds path.

I'll use the Apache Commons decoder and hopefully have better luck.

Again, appreciate the help.