I'm trying to configure IIS6, Tomcat 6, and isapi_redirect 1.2.31.
I have a web application running on tomcat that has several different components. The main servlet is to be accessible to all of the users in a domain group maintained by our network admins. Selected pages, in addition, are password-protected within the web application using the tomcat-users.xml file and form-based authentication. In addition, the Tomcat manager application has its default tomcat authentication, which I think is Basic authentication.
I have installed the isapi connector, and as long as I set the web site in IIS to allow anonymous access, everything works fine. The single html page in the IIS site redirects to an index page in the web application, the appropriate URLs get forwarded to the isapi connector, and tomcat prompts for the tomcat username and password when it is needed.
However, when I set the IIS web site to Integrated Windows authentication, I get the following: 1. The html page on the IIS web site still works. 2. When I type in a URL that should get forwarded to Tomcat, I get a domain login prompt. When I put in my domain credentials (which should have been picked up by the integrated authentication anyway), they apparently do not match and I get a 401 unauthorized error.
I've tried setting the jakarta virtual directory in IIS identically to the site root; I've tried setting the jakarta virtual directory to allow anonymous access (then it just fails authentication without prompting me). Everything is on a single machine and I'm testing everything out while logged in as a member of the Administrators group, so there shouldn't be any problem with directory or other permissions.
Someone in another forum with a related (but not the same) problem mentioned his issue being due to a problem with the application pool's "Identity," but did not elaborate. My application pool is running with the deault identity of Network Service.
Does anyone have any suggestions? I have the feeling I'm overlooking something monumentally stupid.
There are basically 2 ways to integrate Tomcat security with Windows/IIS security. One is by tapping into the same security provider that IIS is using (and I'm not an expert on that), and the other is to tap into Active Directory and/or Windows Login authentication.
When you create a Tomcat app using the J2EE security framework, the security functions are handled by Tomcat. In order to maximize flexibility, Tomcat allows you to select from a set of plug-in security modules known as Realms. Realms are fairly simple little modules whose main function in life is to authenticate and to authorize, and the different flavors reflect the different ways to validate userid/password and to test for security roles. The Realm processors don't care about basic or form-based authentication, only about credentials and roles, so one app can be form-based and another (such as the Tomcat Manager app) can be basic, and both can be using the same JDBC Realm, for example. You can define Realms on a per-application basis, if you prefer.
One of the simplest ways of coordinating Tomcat app security with Windows security is to use the LDAP realm, where the LDAP provider is Active Directory. It's fairly easy to setup, but has the downside that each app in the Realm has to have the user log in separately, which can be a pain for simple apps, and a nightmare for portlet apps (where you'd have to log into each portlet on a portal page). There are also Single-Signon realms, that alleviate that problem by allowing any app to accept a login request which then serves to authenticate to all other apps sharing that SSO service.
Another variant of this is the Realm that allows you to share your Windows login, so that the act of logging into Windows automatically authenticates you (under your Windows user ID) to the Realm. This one's a little tricky, because users also have to enable a security feature in their browser to support this (a rare case where Microsoft was secure by default).
I listed the above just to indicate some options and describe how the Realm concept works. What it actually sounds like you're attempting to do is setup a system where Tomcat taps into the security manager that IIS itself is configured for using a connector service. And from the sound of it, you don't have your Realm definition set up the way it needs to be.
So the next step in solving the problem needs more input from you. Can you show us how you configured the cross-server Realm? If you don't know, or didn't do that, then the problem is probably because you didn't understand the Realm concept, and I hope I've managed to make that a little clearer.
An IDE is no substitute for an Intelligent Developer.
Joined: Mar 17, 2011
Thanks for replying.
I've never really done anything with the Security Realms in Tomcat, except to use the built-in Default Security Realm (that they say not to use), which is a MemoryRealm that uses tomcat-users.xml in the conf folder, with usernames and passwords in plain text.
I work in a large corporation with a large corporate IT department that I am not part of. My boss is looking for ways to limit what we ask of them, whiile at the same time limiting what we have to implement ourselves. I have a server that I have been given admin rights to to set up with IIS, Tomcat, and associated scripts and applications. When the application goes live, I do not know exactly what rights I will still have, although I've recently been told I will still own Tomcat and IIS on that server.
We have three categories of users for this application:
1. Customers, who log into a corporate web server and will use the web application pages that access our database.
2. Select employees, who are logged into our corporate network and are members of a domain group. They will use the web application pages that do not access the database ("standalone" application).
3. Administrators (for now, that would be me). If I still have Remote Desktop access after we go live, then I can log into the server itself. Otherwise, I will be in a domain group also. I will use the log4j configuration pages and the test pages.
I am presuming that the corporate web servers are running IIS, and I will provide them with isapi-redirect configuration files to map customers to my Tomcat server. The web application pages they need do not have user-constraints defined in web.xml, and should not be a problem.
Employees will access the web application through IIS on the Tomcat server machine. I need to configure IIS to use Integrated Windows Authentication for the domain group to be used to limit access to the selected employees. However, I do not want those users to be able to access the config pages, while I do still want admins like myself to be able to to do so. And so, I currently have user-constraints in web.xml for both types of pages. This is evidently causing a conflict, as both IIS and Tomcat are trying to authenticate the user, and this was the question I originally asked.
IIS evidently has the capability to configure URL-based security, but it requires additional components to be installed and configured, I haven't ever done it, I don't know that I even have sufficient rights on this computer to add the requisite components, and I am quite sure my boss would object to my taking the time to try to figure it all out.
The more I think about it, the more I think what I need to do is simply remove the user-constraint for the standalone application, and let IIS completely handle employee access to the application based on the domain group. Then remove the mapping for the config pages, and if I still have Remote Desktop access, then access the config pages directly from Tomcat while logged into the server over RDP. If I lose Remote Desktop access, then the log4j configuration (and Tomcat manager application) will become the responsibility of someone who does.
Sounds like a reasonable idea. I wouldn't do it on an external site, but as long as the app is for internal use only, it's probably good enough. People could do unauthorized access to Tomcat resources by addressing it directly and bypassing IIS, but that's an internal affair. You could prevent that using a firewall, but only if IIS was tunnelling the request instead of redirecting it.
Er. Come to think of it once you're redirected, you pretty much are talking directly to Tomcat. So do take care to ensure that IIS doesn't drop out of your URLs!
Joined: Mar 17, 2011
Please explain. The main application *is* being served to the outside world, through a corporate web server.
My understanding of the way the isapi-redirect filter and extension works is:
Customer computer over the internet to corporate IIS server: "send me, over HTTPS, the resource at /MyApp/mypage"
Corporate IIS to customer: "Who are you?"
... further authentication exchange...
Customer computer to corporate IIS server: "Here are my valid credentials, now send me, over HTTPS, the resource at /MyApp/mypage"
Corporate IIS server through the intranet (tunnelled if necessary across the country) to internal tomcat server: "send me, over AJP1.3, the resource at /MyApp/mypage"
Internal tomcat server to corporate IIS server: "Here it is."
Corporate IIS server to external customer: "Here it is."
Employee computer over the intrAnet to internal IIS server: "send me, over HTTPS, the resource at /MyApp/mypage"
Internal IIS server to employee computer: "Who are you?"
... further authentication exchange...
Employee computer to internal IIS server: "Here are my valid credentials, now send me, over HTTPS, the resource at /MyApp/mypage"
Internal IIS server to internal tomcat server on localhost: "send me, over AJP1.3, the resource at /MyApp/mypage"
Internal tomcat server to internal IIS server: "Here it is."
Internal IIS server to employee: "Here it is."
Administrator logged on using Remote Desktop browser to localhost Tomcat server: "send me, over HTTPS on this alternate port, the resource at /MyApp/mypage"
Tomcat to Administrator browser: "Who are you?"
Administrator browser to administrator user: "Who are you?"
Administrator user to Administrator browser: "Here are my username and password"
Administrator browser to Tomcat: "Here are the username and password"
Tomcat to Administrator browser: "Here it is."
We would ask IT to firewall the ports with direct access to Tomcat.
Outsiders not on the corporate notwork are already firewalled from HTTP or HTTPS access to the internal IIS server.
Joined: Mar 17, 2011
In other words, even though the *name* of the Tomcat connector says "redirect", it's actually an IIS *filter* and an IIS *extension*. I've never seen anything to indicate that when using AJP worker threads, there is is any actual HTTP redirecting going on.
Am I completely wrong?
P.S. Wow, you sure had me scared for a minute there, but I just fired up Wireshark and checked. I currently have IIS configured to allow anonymous access, and Tomcat is doing the authentication. There are only four TCP packets exchanged:
The original GET request to the IIS server
A reply *from IIS* requesting authentication, stating that the authentication realm is "Tomcat Manager Application". It also includes a JSESSIONID cookie.
A second GET request to the IIS server that includes the JSESSIONID cookie and an authentication string.
A second reply from IIS, containing the tomcat manager page.
No HTTP redirects. Phew!
Rebeccah Quevedo-Prastein wrote:In other words, even though the *name* of the Tomcat connector says "redirect", it's actually an IIS *filter* and an IIS *extension*. I've never seen anything to indicate that when using AJP worker threads, there is is any actual HTTP redirecting going on.
Am I completely wrong?
I think you're happy with what you discovered, but yes, I'll confirm just so everyone knows. AJP is a proxy service, and manages routing of the requests and responses from the web host to Tomcat by encoding the incoming data in a binary data stream of its own, passed on to Tomcat. It neither redirects the original data, nor requires any direct outside-world contact with Tomcat.
AJP was developed for Apache to talk to Tomcat, but the impression that I've been getting is that your transport mechanism is an IIS implementation of an AJP service, so the same rules would presumably apply.
There's been an IIS How-To for ages. It just doesn't really cover authentication issues, since that's not really its job. The only mention I see, says "Once again, be aware that by allowing IIS to access the content of your Tomcat context directly, you are potentially bypassing Tomcat's protection of that content. You should thus make sure to protect this content at the IIS level if needed, by using the corresponding IIS management console functions. "
They mention that you may *potentially* be bypassing Tomcat's security and allowing access where it's not desired, but do not mention that depending on how you configure IIS's security, you may instead be *conflicting* with Tomcat's security and locking people out. I suppose if both IIS and Tomcat were using the same security realm to authenticate but using different criteria within the realm to allow access, then you'd get potential undesired access; whereas when, like me, you are authenticating with two different realms, you lock people out.
So now I use one realm for the publicly facing IIS server(s) (with no tomcat authentication), one realm for the internal IIS server (with no tomcat authentication), and one realm for the standalone tomcat server (no IIS authentication) for pages that aren't even mapped from any of the IIS servers.