aspose file tools*
The moose likes Tomcat and the fly likes Can I override all web applications with global web.xml settings? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Can I override all web applications with global web.xml settings?" Watch "Can I override all web applications with global web.xml settings?" New topic
Author

Can I override all web applications with global web.xml settings?

Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi Rangers,

just out of curiosity, is it possible to override parts of the web application specific XML descriptors of deployed web applications with global settings in Tomcat? In particular I tried to secure my whole Tomcat instance with a HTTP basic authentication. This machine is just for testing purposes and I want to connect it to the internet, but I don't want every script kiddie to mess around with the applications on it. So I thought of simply putting a security layer over all web applications deployed on this box. Unfortunately I couldn't find a way how this could be done globally without modifying each web.xml descriptor of each web app.

Any ideas? Thanks in advance!

Marco
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12779
    
    5
The default web.xml works the other way around - application web.xml settings will override the default.

Bill
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi Bill,

thanks for your answer. Unfortunately this is what I already knew

No chance to do this the other way around?

Marco
Kees Jan Koster
JavaMonitor Support
Rancher

Joined: Mar 31, 2009
Posts: 251
    
    5
Dear Marco,

Why not just use your firewall to limit access to this machine from only your dev machines?


Java-monitor, JVM monitoring made easy <- right here on Java Ranch
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi!

Good question - simple answer: I want to make the box general available on the internet and for this firewall rules which match based on IP will be difficult. Of course there are other solutions like VPNs, but I'd prefer a simpler solution from a client's point of view.

I can hardly believe that there's no way to configure the security aspects of a whole Tomcat instance like you can configure other "global" parameters as well via server.xml etc. Or perhaps anyone has a different idea how to easily "secure" Tomcat without configuring each application deployed on it?!?

Marco
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16054
    
  21

Interesting that you should ask. One of the things that has become more and more annoying to me over the years is the pitiful state of Java webapp security.

Almost every webapp I've encountered has had a Do-It-Yourself security system. Done very badly. They almost inevitably have major holes in them. And every app has its own security implementation. Usually badly-documented, if it's even documented at all.

J2EE comes with a security framework. It's simple and it's powerful and almost nobody uses it. I have, and one thing I've noticed is that it's especially well-suited for enterprise-level security. Not only is it a well-documented standard, but its nature is such that it encourages using shared, centralized authentication and authorization facilities, making for a "one-stop-shopping" solution.

And yes, it's configured in large part in the web.xml file, in conjunction with external security realm configuration.

If you do have a typical DIY security system, you can configure it with JNDI. In Tomcat, you can define JNDI-registered entities in web.xml, but Tomcat can be instructed to override these definitions (or not). I've used it to retarget resources so that the same WAR could be deployed to both test and production environments without code changes.

Of course, there are also situations where subtlety is pointless. Sometimes it's better just to run 2 Tomcat servers, one public and one private, configure them appropriately, and then deploy as needed.


Customer surveys are for companies who didn't pay proper attention to begin with.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi Tim,

I'm glad to hear that I'm not the only one concerned about this topic

As I said I don't have a problem with a specific web application. But the fact that I'm looking for a "server side" solution shows that I've made the same experiences like you regarding different or insufficient security implementations in different web apps.

In my opinion Java based web applications in general have enormous advantages over PHP for example because they can rely on a stable and good specification/platform and servlet containers which provide a lot of infrastructure out-of-the-box. Unfortuantely for lot of developers simply don't care (or know) too much about security.

That said I'm really surprised that there's obviously really no solution for my problem. I have a lot of experience with PHP or Perl based web apps running on Apache and it was always nice that you can configure everything directly in the server configs and allow applications to override only specific config settings as necessary. That way it's easy to enforce security like it's common for firewalls where you first close everything and then only open up what's really needed. It would be nice to have something similar in Tomact (or other servlet containers).

Though I'm still not convinced that it's definitely not possible to have such configuration scenarios. What about web hosters? Are they running a distinct Tomcat instance for each customer? How do they restrict global security concerns?

Marco
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16054
    
  21

I wouldn't say that it's not possible, but there are different solutions depending on what you want done.

I have a list of about a dozen reasons why most webapps shouldn't use DIY security. If you're interested, you can find them on my blog at mousetech.com. But the one of the biggest problems with DIY security is that it suffers from the same "Git 'R Dun" approach that far too many computer apps today exhibit. It starts off with an "All You Have to Do Is..." concept, comes under an unrealistic timeline, is farmed out to whomever promises the solution cheapest/fastest, and since security is just an annoying add-on that doesn't promize a glitzy exciting UI or even help in the business functionality, it's just an afterthought.

Small wonder that the profession doesn't get any respect or that massive data leaks are an almost daily occurrence, even though relatively few of those are due to sloppy app security, since there are even sloppier business processes and attitudes in effect that mean that you don't need to go to the effort to actually crack a lot of systems.

As I mentioned, there are several things you can configure in web.xml that can help. PHP is no shining example - it has virtually no built-in security infrastructure, and in fact, has been subject to several major security problems in the past.

As for web hosters, yes, Tomcat is lightweight and easy to set up, so it's generally less trouble to give everyone their own Tomcat - in fact, often their own VM -- OS and all. Hosters generally don't worry about your security much; they figure that's your job. Mostly they're worried about their own infrastructure.

There are 2 different areas where you might choose to have access controls. One is on an absolute networking basis, where the content of the communications doesn't matter. Mostly this is handled by the firewall, although additional mechanisms may fine-tune it, such as proxying rules in Apache or custom valves in Tomcat.

The other area is context/content-sensitive. The outer layer of J2EE standard security relates to the context, and that's determined in Tomcat by the selected security realm implementation and by the web.xml definitions. They mostly guard the gates, preventing abusive traffic from even reaching the application. The URL is frequently used as a selector as to what rules to apply. The inner layer of the J2EE standard security consists of what little security code is actually part of the application itself. Most of this consists of role-checking to limit access to resources and functions. This is supported both by Java code and by many view management frameworks. Struts, for example has role attributes. IIRC, so does JSTL. JSF generally doesn't, although some of the MyFaces Tomahawk tags do.
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

Is it possible to set ssl to true for the environment using the setenv.sh|bat file?
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

@Tim Holloway: Thanks for your information, I'm definitely going to have a look at your blog ;-) I know exactly what you mean (not only regarding software security) and this is exactly my opinion, too! I'm surely no expert on any area in computer science but at least I try to think about any aspects of a software and find the best solution I can come up with. This may vary depending on constraints like the available time but that's another story. Anyway, I think the main reason for the bad habits of some (or many?) so called developers is, that you can't really see the end result of their work. No one would by a car with only three wheels but with software products it's very likely that customer won't even notice the missing wheel, if you know what I mean :-) Security is even harder to see and value for an average user or customer, usually until it's to late. Probably there are many, many more security breaches every day than showing up in any reports because most users won't even notice...

Anyway, thanks for sharing your ideas regarding my question. Actually network level security is no deal as I would consider myself almost an expert on this topic The only problem in this typical scenario is, that I simply want to access this tomcat box in my home network from the internet. Because of dynamic IPs I can't really block anything with the firefall. And I can't imagine very useful rules to do firewalling on the application level. Furthermore it would be very strange to use the firewall to manage HTTP specific things because the web server/servlet container doesn't support this. More complex scenarios like VPN access are definitely overkill because this is simply a small, ordinary HOME network with no production use. I just want to experiment a little bit with arbitrary web apps etc. Because I don't trust the security implementations of all possible web apps (reasons above ;-)), I wanted to protect ALL APPLICATIONS by globally activating HTTP authentication for Tomcat. Of course it's a completely different thing for production use when you what applications are deployed and how to secure them! On the other hand I don't want to invite every script kiddie to hack my home network even there isn't much of value to find ;-)

One good and flexible solution I can imagine is to put an Apache proxy in front of Tomcat, if it can't be done with Tomcat alone. But honestly this is more effort, than I would expect for such a stupid little configuration issue. I thought it can't be to hard to secure an entire server instance or at least entire application contexts from within the global server config, but obviously it is. Maybe the problem is, that even the global web.xml of Tomcat isn't part of the specification like most configuration aspects of servlet containers and application servers.

@Tim McGuire: What exactly do you mean? Tomat 6 doesn't even provide this script, if I know it correctly. Do you want to enable SSL or setup SSL? Enable - maybe. To setup there are definitely more things to do like generating a key store / X.509 certificate.

Marco
Tim McGuire
Ranch Hand

Joined: Apr 30, 2003
Posts: 820

Marco Ehrentreich wrote:

@Tim McGuire: What exactly do you mean? Tomat 6 doesn't even provide this script, if I know it correctly. Do you want to enable SSL or setup SSL? Enable - maybe. To setup there are definitely more things to do like generating a key store / X.509 certificate.

Marco


yes, there are other steps. setenv.sh is not present by default, but if it is present, it is read on startup and can set all kinds of environment variables. I was just wondering if "ssl ON" can be one of the settings.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Without having used the "setenv" script yet, I'd say that SSL is to complex to be simply switched on or off. It's a configuration for a separate connector of Tomcat which is somewhat "bigger" than some system properties or simple parameters. But that's just a guess...

Marco
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16054
    
  21

If you simply want to SSL-protect all webapp access, set the transport mechanism in web.xml. I normally have "public" URLs and private ones, since I like to have my app's home page visible to all, but then again, I'm soliciting public access. You can set the URL pattern to "*" and require all URLs for that app to be secure.

For extra paranoia, you can probably remove the non-SSL connector from Tomcat's server.conf file. Tomcat serves up a number of ports and a number of protocols. Server.xml defines what and where, but as I understand it, the webapp definition (web.xml) determines what protocols are bound to what URLs and not the container. You cannot override this part of web.xml like you can with JNDI, but it's easy to replace the offending web.xml with one more to your liking.

At a higher level, maybe a custom valve could be persuaded to meddle with the transport by doing URL rewriting, but it would be easier to stick a proxy (like Apache) in front of the whole thing.

At the same time think maybe you underestimate what you can do with a firewall, however. While a firewall cannot override protocols, chances are, any requests coming from a DHCP-assigned source are going through NAT, so the source IP address(es) for that particular network are likely to be limited. Hence you can set up a range to filter on, instead of allowing all comers. I used to do this so that I could dial in SSH from work. Granted, if anyone else on campus was so inclined, they'd also have access, but I wouldn't have to worry about random attackers from all over the world.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi Tim,

thanks a lot for your detailed answer!
If you simply want to SSL-protect all webapp access, set the transport mechanism in web.xml. I normally have "public" URLs and private ones, since I like to have my app's home page visible to all, but then again, I'm soliciting public access. You can set the URL pattern to "*" and require all URLs for that app to be secure.

My main concern would be to use authentication for all webapps. SSL would be OK, but I mainly want to keep off scrip kiddies and bots from my server. So a simple HTTP authentication would do. As this is both "security-constraints" in the servlet language, I guess I could configure both in the same way. But if I understand you correctly here, that would still mean to edit each web.xml descriptor of each deployed application?!? Do you know how things get merged if I define <security-constraints> in Tomcat's web.xml and any web app overrides <security-constraints> in its own web.xml? Is the security information merged or completely overridden?
Server.xml defines what and where, but as I understand it, the webapp definition (web.xml) determines what protocols are bound to what URLs and not the container.

For my understanding this applies only to "confidential" transport. In the server.xml you define which connectors are "secure" and a webapp may define with it's <security-constraints> to use a "secure" protocol based on a URL pattern...
chances are, any requests coming from a DHCP-assigned source are going through NAT, so the source IP address(es) for that particular network are likely to be limited.

I'm well aware of that fact, but I suppose this won't work in my case. Tomcat is running inside my home network where I am the only member of. So no access problems here^^ And now I want to make Tomcat also accessible from anywhere in the internet but without opening everything up for the whole world.

Anyway with all your valuable input I see only two practical solutions at the moment:

1.) Modifying each web.xml descriptor for any webapp I want to be globally authenticated.
2.) Put an Apache in front of Tomcat and let it do the authentication work.

Marco
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16054
    
  21

Tomcat's web.xml is the default webapp's web.xml, so it doesn't apply to user-supplied apps.

ALL port definitions and protocols are defined in server.xml, using <connector> definitions. That includes HTTP (default 8080) and HTTPS (default 8443).

It definitely sounds like you should be fronting external access with Apache HTTPS ( or maybe squid) and firewalling port 8080. That way you don't have to change anything in Tomcat or the webapps. It's about the simplest way to get things done.

If you want to be really paranoid, yet allow yourself dialin from anywhere in the world, try a port-knocking setup. It will allow to to send a "secret message" that will open up the firewall for whatever source IP you're coming from.

It's fairly trivial to setup an Apache proxy on Linux. I haven't run Apache on Windows in a while, so I don't know how easy it is these days.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Tomcat's web.xml is the default webapp's web.xml, so it doesn't apply to user-supplied apps.

Well, THAT was a complete misunderstanding for my part. I never really cared about it, because I was always pretty sure that this is a default descriptor which CAN be overridden as needed by webapps you deploy. Don't ask me why I never looked it up in the documentations. Good to know now!
It definitely sounds like you should be fronting external access with Apache HTTPS ( or maybe squid) and firewalling port 8080. That way you don't have to change anything in Tomcat or the webapps. It's about the simplest way to get things done.

This is my opinion, too. In particular because Apache runs on almost any box I have installed
If you want to be really paranoid, yet allow yourself dialin from anywhere in the world, try a port-knocking setup. It will allow to to send a "secret message" that will open up the firewall for whatever source IP you're coming from.

No, thanks! I already used port-knocking and other cool things, but this one should work without any special tool or client. As I said, it's just to keep out script kiddies or bots etc. It doesn't have to be as secure as a production network.
I haven't run Apache on Windows in a while, so I don't know how easy it is these days.

I wouldn't discuss about networks and servers without running a real OS! Of course I'm a penguin, too I've set up far more than 100 production servers with Apache, so this is indeed the easy part. I just thought this whole thing should be possible with Tomcat alone.

Anyway, thanks a lot for taking the time!

Marco
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Just in case anyone else has a similar question:

I've solved my "problem" by using Apache (2.2.x) as a proxy in front of Tomcat as I already posted. Until then I haven't used Apache extensively for a few months and I haven't even realized that there was a new module to help connecting Apache to Tomcat: "mod_proxy_ajp"! With mod_proxy_ajp it's even easier than with mod_jk. There's almost no configuration work to do other than a few lines which are similar to that of the ordinary mod_proxy module. Really nice

Marco
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Can I override all web applications with global web.xml settings?