Running Jakarta/Tomcat

1. Running Jakarta/Tomcat CIT304/CSE301 University of Sunderland Harry R. Erwin, PhD

2. Resources • Brittain and Darwin, 2003, Tomcat: the Definitive Guide, O’Reilly. • Kurniawan and Deck, 2004, How Tomcat Works, BrainySoftware.com. • Knuckles and Yuen, 2005, Web Applications: Concepts and Real World Design, Wiley. • Nakhimovsky and Myers, 2004, Google, Amazon and Beyond, Apress.

3. Introduction • The purpose of this lecture is to discuss how to set up and run a web application using Jakarta Tomcat. • Getting started • Configuring Tomcat • Deploying web applications • Integrating with Apache • Tomcat security • Configuration files • If you manage web application development, this is what your programmers will be doing.

4. How Servlet Containers Work • Servlet containers handle requests for service by… • Creating a request object and populating it with appropriate information. • Creating a response object that can be used to produce the response to the requester. • Calling a service method to translate the request object data to the response object.

5. Tomcat and Catalina • Tomcat is the web server • catalina is the servlet container in Tomcat • catalina has two main modules: • A connector to connect the request to the container. It constructs the request object and the response object. • A container, which actually services the request.

6. Getting Started with Tomcat • Installing • Download and run the compiled binary (you will need Java). Don’t compile Tomcat from source. • Starting, stopping, and restarting • There are nine scripts, but you can get by with startup.sh (.bat) and shutdown.sh (.bat). Restarting is flaky, because you may have unhalted Java processes around. Run them to ground and gun them before you start up again.

7. Configuring Tomcat • Using Apache • Tomcat can run standalone or with Apache. Both are common and appropriate in various situations. • Managing web application security • You have two alternatives: • Container-managed security • Application-managed security • Users, passwords, and roles are managed by realm in container-managed security. • Your application has to handle login, etc., in application-managed security.

8. Configuration Options • Controlling sessions • A session is a single browser instance • Sessions can persist through a server shutdown • Accessing resources • JNDI and JDBC are available • Using CGI • Yes, you can use CGI with Tomcat • Tomcat admin application • A web-based application that automates most of this.

9. Deploying A Web Application • Layout of an application • This is standardized—see the next slide • Manual or automatic deployment • Web applications directories can be anywhere, but usually inside the Tomcat tree. You tell Tomcat about the new application using the manager application. • You can also deploy a web application automagically. • The manager application automates all this. • Jakarta ant can also be used.

10. Web Application Layout • sample_webapp/ • xxx.html • yyy.jsp • zzz.other resources • WEB-INF/ • web.xml • classes/ • Java class files • lib/ • jars and zips of class files

11. Integrating with Apache • Sometimes you already have Apache running and you don’t want to change things. • Why you might do this: • Tomcat is less mature and less known. • Fewer web server features in Tomcat • Tomcat is slower than Apache httpd • Why you might not: • It’s easier to set Tomcat up standalone. • Security is better standalone. • Migration is easier. • Upgrading is easier.

12. Tomcat Security • Security is important and Tomcat supports good security. Remember—good enough security, not perfect security. • Securing the system • Multiple security models • The chroot jail • Filtering bad input • SSL

13. Securing the System • First, harden the operating system! • Block private and internal ports: • Control port: 8005 • Connector port: 8009 • Anything else you don’t need. • Tomcat usually runs on 8080, so leave it open. If you have Apache running, you’ll need port 80 open, as well.

14. Multiple Security Models • Watch for interactions between the Apache/IIS and Tomcat server models. They’re different. Use a connector module and isolate your Tomcat applications from Apache and IIS. • You will need to edit httpd.conf and web.xml to do this. • Unless you need it, disable the invoker servlet. • Use Java security. It gives you fine-grained control over security policies.

15. The chroot Jail • Unix-like operating systems can limit process access to a restricted subtree of the full directory tree. This is the chroot command. Use it! • This jail is not escape-proof, but it’s pretty good. • Some unix systems allow you switch the root user to some other user when you chroot. This is also good. • Even if you’re using Tomcat’s built-in security features, use the chroot jail. Belt and suspenders.

16. Filtering Bad Input • There are applications-level exploits that Tomcat generally can’t protect against. So… • Never trust what users feed you. Possible exploits: • Cross-site scripting/HTTP session hijacking when unfiltered HTML input is echoed back to the user. • HTML injection • SQL injection/insertion • Command injection • Most of these are controlled by input filtering, but SQL PreparedStatements help with SQL injection.

17. SSL • Tomcat has native support for SSL, but you don’t need SSL if you’re running Tomcat behind Apache. • The process of generating a server certificate is not complicated, but you will need a Certificate Authority to sign it if you don’t self-sign it. (Good browsers warn on self-signed certificates.) • You will need to set up a SSL connector so Tomcat knows about the certificate.

18. Configuration Files • server.xml • The main configuration file. • web.xml • Configures servlets and web applications • tomcat-users.xml • Roles, users, and passwords • catalina.policy • The security policy file.

19. Conclusions • This isn’t enough to even start to become a web applications designer—you have to read further for that. • But this is enough to give insight into what the designer’s manager is responsible for.