Transcript Jakarta/Tomcat

Running Jakarta/Tomcat
CIT304/CSE301
University of Sunderland
Harry R. Erwin, PhD
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.