Instalación y administración de Apache Tomcat

Instalación y Administración de
Apache Tomcat 6
Iván Párraga García – ivan.parraga.garcia@gmail.com

Instalación y Administración de Apache Tomcat
Nº 2
Módulo 1
Introducción
Objetivos
 Introducción al proyecto Apache & Jakarta
 Entender la tecnología J2EE

Nº 3
El proyecto Apache
 Rob McCool en el NCSA de la Universidad de Illinois,

creó uno de los primeros servidores web (conocido
como NCSA)
 El autor dejó el NCSA y un grupo de desarrolladores
lanzaron una nueva versión corregida conocida como

Apache Server (A PAtCHy Web Server)
 Apache fue ganando popularidad al mismo ritmo que
NCSA la perdía (dejó de soportarse en 1999)
 Hoy día está disponible en cualquier plataforma y se
considera un plataforma de producción de alta calidad
y que tiene una cuota de mercado del 60%
Nº 4
 Organización sin ánimo de lucro fundada en
1999 cuyo objetivo es facilitar el desarrollo de
proyecto s de software libre
 Tomcat se ha desarrollado en el marco de la
ASF
 Proyectos de la ASF:
 Servidor Web Apache
 Xerces: parser XML Java/C++
 Ant: el sistema de construcción estándar de
facto en Java
 Jakarta
Nº 5
Jakarta y Tomcat
 Tomcat era un subproyecto bajo el proyecto

Apache Jakarta
 Apache Jakarta aglutina diversos proyectos
Java
 JMeter
 Log4j
 Struts
 Hoy día Tomcat es un proyecto de alto nivel
Nº 6
La licencia Apache
 Tomcat es código libre, gratis y que puede distribuirse

libremente. Se rige bajo la licencia de Apache cuyos
puntos:
 La Apache License debe incluirse con cualquier
redistribución
 Cualquier documentación incluida con la redistribución

debe ser validad por la ASF
 Los términos “Tomcat”, “Projecto Jakarta”, “Apache” o
“ASF” no pueden utilizarse sin permiso de la ASF
 Tomcat no aporta garantías de ningún tipo
 Tomcat puede ser utilizado por cualquier tipo de entidad
 Si se modifica el código, no es obligatorio entregar el
código fuente de las modificaciones con la
redistribución
 Las modificaciones no tienen que ser donadas a la ASF
Nº 7
Las diferentes tecnologías Java
Java para dispositivos

móviles
Java para
aplicaciones de
escritorio
JME
JSE
JEE
Nº 8
Java Enterprise Edition (JEE)
 Es un conjunto de especificaciones que definen unas

APIs para la creación de aplicaciones empresariales
 Se construye encima de la JSE

 NO ES UN SOFTWARE. Las especificaciones son

implementadas por diferentes proveedores (el propio
SUN, IBM, Oracle, etc.)
 SUN controla estas (y otras) especificaciones a través

del Java Community Process, que es un proceso
formalizado el cual permite a las partes interesadas
involucrarse en la definición de futuras versiones de
características de la plataforma Java
Nº 9
Arquitectura multicapa (I)
 Sistemas especializados por tareas en los servidores
 Los usuarios acceden mediante un navegador web estándar

Presentación
Persistencia
Nº 10 Lógica de Negocio
Arquitectura multicapa (II)
 Ventajas
 Mantenible
 Sistemas separados por responsabilidades
 Fácil añadir / modificar funcionalidades
 Escalable: los diferentes subsistemas pueden

dimensionarse independientemente
 Mayor reusabilidad
 Fácil gestión de las máquinas clientes de los usuarios
Nº 11
Arquitectura multicapa de la JEE
Cliente / Usuario Presentación Lógica de Negocio Persistencia
HTTP Contenedor RMI Contenedor SQL

Web EJB SGBD
Límites de la tecnología Java
Nº 12
Los contenedores JEE (I)
 Un contenedor es un componente software que

implementa parte de las especificaciones JEE
 Proporciona servicios al programador que son

comunes y habituales a todas las aplicaciones

liberándole de tener que codificarlos cada vez y
permitiéndole centrarse en la lógica de negocio
olvidándose de tareas tediosas y repetitivas
Nº 13
Los contenedores JEE (II)
 Las especificaciones definen dos contenedores
 Contenedor web: especializado en gestionar la capa de

presentación con tecnologías web (JSPs, servlets, etc.)
 Contenedor de Enterprise Java Beans (EJBs):

especializado en gestionar la capa de lógica de negocio
e interactuar con el sistema de persistencia (el SGBD)
Nº 14
Ventajas del uso de contendores
Construyendo desde cero
Tareas del desarrollador
 Lógica de Negocio
 Persistencia
 Gestión de transacciones
 Multi-threading
 Seguridad
 Red
 Publicación de servicios
Utilizando contenedores Tareas del desarrollador

 Lógica de Negocio
Proporcionado por el contenedor

 Persistencia
 Gestión de transacciones
 Multi-threading
 Seguridad
 Red
 Publicación de servicios
Nº 15
Servidores de aplicaciones (I)
 Es un software que implementa las especificaciones y

contenedores JEE
 Sun proporciona el sello “JEE compliant server” sólo si

superan unos estrictos juegos de pruebas que
garantizan que se satisface la especificación
 Diferentes proveedores ofrecen diferentes productos,

pero está garantizada la compatibilidad entre todos
ellos, así pues una aplicación desarrollada en JEE
podrá desplegarse en cualquier servidor de
aplicaciones
Nº 16
Nº 17
Servidores de aplicaciones (II)
¿Y Tomcat?
 Tomcat es un producto muy popular, pero no es un

servidor de aplicaciones porque sólo (entre otras
cosas) implementa el contenedor web
 Es adecuado para aplicaciones web con arquitectura

de dos capas, donde el propio contenedor web incluye
la lógica de negocio sin requerir el contenedor de EJB
 Tomcat es más fácil de administrar y requiere menos

recursos para funcionar que servidores de aplicaciones
completos
Nº 18
¿Qué hemos visto?
 El servidor web Apache está en el origen de la ASF

 La ASF es una organización que promociona el
desarrollo de software libre
 Tomcat es un proyecto auspiciado por la ASF
 La tecnología Java J2EE se basa en la arquitectura en

tres capas
 La capa de presentación web se implementa con un
contenedor web
 Tomcat es un servidor y un contenedor web y es
adecuado para algunas tipologías de aplicaciones por
su facilidad de uso y su ligereza en cuanto a recursos
Nº 19
Nº 20
Módulo 2
Instalación de Tomcat
Objetivos
 Instalar la Java Virtual Machine (JVM)
 Instalar Tomcat
 Comprender la estructura de directorios de

Tomcat
 Resolver problemas típicos
 Instalar Ant
Nº 21
Instalar la JVM
 Tomcat es una aplicación Java y por tanto

requiere la JVM
 Tomcat 6 requiere la versión Java SE 5.0 o
superior
 Desde la versión 6 de Tomcat no se necesita

el JDK (es suficiente con el JRE)
Nº 22
Instalación de la JVM en Windows (I)
 Descargarla de http://java.sun.com
 Establecer la variable de entorno

JAVA_HOME en la ruta a la raíz de la JRE
 Añadir a la variable de entorno PATH la ruta a

la subcarpeta bin de la JRE
Nº 23
Nº 24
Instalación de la JVM en Windows (II)
Descargar Tomcat
 Conectarse a http://tomcat.apache.org
 Ir a la zona de descargas y elegir la versión
correspondiente:
 Core: versión base disponible en diferentes

formatos (nos descargaremos el instalador)
 Deployer: herramientas de despliegue
 Admin Webapp (no disponible todavía para la
versión 6)
 Embedded: para embeber el servidor en otras
aplicaciones
Nº 25
Instalar mediante el asistente
Instalar servicio de Windows
Instalar librerías nativas APR
Puerto en el que aceptará peticiones

Instalar ejemplos de servlets y JSPs
Usuario y password de las

herramientas administrativas
Nº 26
Establecer las variables de entorno
 Añadir la variable de entorno

CATALINA_HOME que apunte a la raíz de la
instalación
Nº 27
Probar la instalación
 Iniciar el servidor manualmente

 <TOMCAT_HOME>\bin\tomcat6.exe
 Iniciar el servidor como un servicio
Nº 28
Nº 29
Comprobar la instalación
La jerarquía de directorios de Tomcat
 bin: scripts y ficheros de arranque

 conf: ficheros de configuración del
servidor y de usuarios entre otras
cosas
 logs: contiene los ficheros de log

 lib: incluye todos los jars que el
servidor requiera
 webapps: contiene todas las
aplicaciones web
 work: archivos temporales requeridos
por Tomcat
Nº 30
Problemas típicos (I)
 Problema: error de versión de clase

 Descripción: aparece la siguiente excepción:
java.lang.UnsupportedClassVersionError
 Solución: instalar una JRE 1.5 o superior y asegurar
que JAVA_HOME le apunta
 Problema: puerto en uso

 Descripción: aparece la excepción:
java.net.BindException: Address already in use
 Solución: asegurarse que no hay otro servicio en ese
puerto (otro servidor web por ejemplo). Se puede
monitorizar el puerto mediante el comando netstat -ao
Nº 31
Problemas típicos (II)
 Problema: ejecutar varias instancias

 Solución: asegurarse que al intentar arrancar Tomcat
no hay otra en ejecución (comprobar que no esté
activo el servicio de Tomcat)
 Problema: un proxy bloquea el acceso

 Descripción: se tiene un proxy establecido para todos
los servicios HTTP
 Solución: deshabilitar el proxy para las conexiones
locales. En la configuración del proxy del navegador
web permitir la IP 127.0.0.1
Nº 32
¿ Por qué Ant?
 Ant es una herramienta de construcción de

software que permite automatizar tareas
repetitivas en el proceso de compilación,
enlazado, despliegue, etc
 Se ha convertido en la herramienta de este

tipo estándar de facto para este tipo de tareas
 Tomcat define una serie de librerías que le

permiten automatizar tareas como el
despligue y repligue de apliaciones web
Nº 33
Instalar Ant y las bibliotecas de Tomcat
 Descargar Ant desde http://ant.apache.org

 Descomprimir el fichero
 Configurar las variables de entorno ANT_HOME
para que apunte a la raíz de la distribución

 Configurar la variable PATH para añadir la ruta
hasta el directorio <ANT_HOME>/bin
 Copiar el fichero <TOMCAT_HOME>/lib/catalina-
ant.jar en <ANT_HOME>/lib
Nº 34
¿Qué hemos visto?
 Tomcat es una aplicación Java que requiere la

JRE versión 1.5 o superior
 Hay diferentes versiones de Tomcat. En
general trabajaremos con la versión Core
 La instalación bajo Windows se hace de forma

sencilla bajo un asistente y la configuración de
la variable de entorno CATALINA_HOME
 Se han listado los errores y soluciones típicos
en la instalación de Tomcat
 Tomcat permite automatizar tareas mediante
Ant y por eso lo instalamos
Nº 35
Nº 36
Módulo 3
Aplicaciones web con Java

Objetivos
 Entender la tecnología de servlets
 Entender las JSP

 El framework Jakarta Struts
Nº 37
Web sites y aplicaciones web
 Un web site es una colecciones de recursos

estáticos como páginas HTML, imágenes
 Una aplicación web es un web site con

recursos dinámicos
 Una aplicación web ejecuta programas en el

lado del servidor y para ello tiene diferentes
tecnologías disponibles
Nº 38
Ejecución de CGI’s
Servidor
Petición Shell CGI Programa

CGI
Petición Shell CGI
Petición Shell CGI
Servidor
web
Nº 39
Ejecución de servlets
Servidor
Petición
Thread
Petición
Thread Servlet
Petición
Thread
Servidor
web Contenedor web
Nº 40
Ventajas de modelo de servlets
 Utilizan threads en vez de procesos que

requieren menos recursos de CPU y memoria
(es escalable)
 Las tecnologías Java permiten separar la capa

de lógica de negocio de la de presentación
 Java es un lenguaje robusto y OO
 Java es independiente de la plataforma
Nº 41
Fundamentos de los Servlets
 Es un tecnología de componentes que se

ejecuta en el lado del servidor
 Se encarga de lo siguiente:
 Procesa peticiones HTTP

 Genera respuestas HTTP dinámicas
 Un contenedor web es una Máquina Virtual

Java (JVM) que gestiona los servlets y un pool
de threads
Nº 42
Fundamentos de las JavaServer Pages
 Las JSP se traducen en clases de tipo servlet

que se compilan y ejecutan por el contenedor
web
 El objetivo principal de las JSP es centrarse
en la lógica de presentación y no en la lógica

de diseño
 Se puede embeber código Java dentro de una
JSP
 Usando la tecnología Java, las JSP se suelen
usar en conjunción con los servlets para
implementar el patrón M-V-C
Nº 43
Ventajas de la tecnología JSP
 Proporcionan alto rendimiento y escalabilidad

porque usan threads para responder a las
peticiones
 Son tecnología Java y por tanto independiente

de la plataforma
 Pueden utilizar todas las características de la

orientación a objetos y las API Java
Nº 44
Inconvenientes de la tecnología JSP
 Usadas de manera aislada, incluyendo la

lógica de negocio, pueden ser crípticas y
además son más difíciles de debuggar
 Hay que tener en cuenta temas de

concurrencia (hay que comprender el proceso
mediante el que se convierten en servlets para
evitar problemas potenciales)
Nº 45
El patrón MVC (modelo-vista-controlador)
Nº 46
Struts
 Implementa un patrón de diseño de

contrastada utilidad en la gestión de interfaces
MVC (modelo-vista-controlador)
 El framework proporciona
 Un componente que actúa de controlador
 Clases de conveniencia
 Archivos de configuración
Nº 47
¿Por qué vale la pena usar Struts?
 Proporciona una infraestructura flexible y extensible

para implementar MVC
 Permite al desarrollador centrarse en lo que aporta
valor añadido a la aplicación:
 Controladores
 Componentes que constituyen el modelo
 Vistas
 Facilita
 Definir el flujo de navegación
 Verificar y procesar la entrada de datos del usuario
 La gestión de errores
Nº 48
Estructura de una aplicación web (I)
 La estructura de una aplicación web (jerarquía

de directorios y ficheros) está definida en la
API
 Cualquier contenedor web es capaz de

trabajar con dicha estructura
 Los diferentes contenedores suelen tener un

directorio de despliegue donde se instalan las
aplicaciones web
Ejercicio M3E1
Nº 49
Estructura de una aplicación web (II)
Recursos estáticos y JSPs

Descriptor de contexto (context.xml)
Descriptor de despliegue (web.xml)

Servlets y clases compiladas jars necesarios por la aplicación web
Nº 50
¿Qué hemos visto?
 Los servlets son una tecnología más eficiente

que otras soluciones para dar dinamismo a las
aplicaciones web
 Los JSP se centran en la presentación
 La tecnología Java hace uso del patrón M-V-C

y de la arquitectura en 3 capas
 Struts implementa M-V-C
 Las aplicaciones web tienen un estructura
definida por la API que cualquier contenedor
web entiende
Nº 51
Nº 52
Módulo 4
Configurar Tomcat
Objetivos
 Entender la arquitectura de Tomcat
 Entender la configuración básica de Tomcat

 Entender los principales ficheros de

configuración
 Gestionar el control de acceso
Nº 53
Arquitectura de Tomcat (I)
 Tomcat se constituye como una jerarquía anidada de

componentes
 Un mismo tipo de componente puede aparecer en

diversos puntos de la jerarquía
 Es importante entender esta jerarquía a la hora de

configurar y administrar el servidor
 En la siguiente transparencia se muestra una

configuración típica
Nº 54
Arquitectura de Tomcat (II)
Servidor
Servicio
Motor
Conector
Logger Válvula Realm
Host
Logger Válvula Realm
Contexto
Válvula
Realm Encapsulador
Nº 55
Componentes de Tomcat (I)
 Servidor: el contenedor de más alto nivel

ofrece un puerto que permite para el servidor.
Sólo uno por JVM
 Servicio: contenedor de alto nivel que

engloba un motor y un conjunto de conectores
 Motor: componente que procesa peticiones,

examinándolas para redirigirlas al host o
context correspondiente. Motor por defecto:
Catalina
Nº 56
Componentes de Tomcat (II)
 Realm: gestiona la autenticación y

autorización de usuario
 Válvula: son filtros transparentes a las

aplicaciones que permiten interceptar las
peticiones y preprocesarlas
 Conector: ofrecen los puertos por los cuales

los clientes se conectan a las aplicaciones
Nº 57
Componentes de Tomcat (III)
 Logger: informan sobre el estado interno de

un componente y permiten registrar esa
información
 Host: nos permite tener variaso servidores
virtuales en la misma máquina y diferenciarlos

por dirección IP o por nombre
 Contexto: representa la aplicación web (son
términos sinónimos) y se considera a la vez
un contenedor de componentes servlet y JSP
(entre otros)
Nº 58
Configuración por arquitectura
 Comprendiendo las relaciones padre-hijo de

los componentes, la administración de Tomcat
es sencilla
 El fichero de configuración más importante es

<TOMCAT_HOME>/conf/server.xml que
representa dichas relaciones mediante
anidamiento de etiquetas XML
 Los scripts de arranque leen este fichero para

crear y configurar los componentes
Nº 59
El server.xml por defecto
<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">

<Service name="Catalina">
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
</Host>
</Engine>
</Service>
</Server>
Nº 60
Ficheros de configuración básicos (I)
 Residen en <TOMCAT_HOME>/conf
 server.xml: fichero de configuración principal,

que se lee al arrancar el servidor. Afecta a la
instancia completa de Tomcat. No debería

contener configuración de contexto
(aplicación)
 tomcat-users.xml: contiene autenticación de

usuario e información de roles. Las
aplicaciones de gestión utilizan esta
información
Nº 61
Ficheros de configuración básicos (II)
 context.xml: configuración de contexto por

defecto de las aplicaciones web (configura
componentes como gestores de persistencia
de sesión, realms, conexiones JDBC, etc)
 web.xml: constituye el descriptor de

despliegue por defecto de las aplicaciones
web
 catalina.policy: fichero de configuración del

modelo de seguridad de Java SE
Nº 62
Ficheros de configuración básicos (III)
 catalina.properties: propiedades que aportan

accesos a paquetes internos y control de
contenidos sobre los cargadores de clases
 logging.properties: Tomcat utiliza por

defecto la API de Java SE para escribir los
ficheros de log (no log4J) y este es el archivo
de configuración
Nº 63
server.xml: Componente Server
Ejercicio M4E1
Nº 64
Nº 65
server.xml: Subelementos de Server
Nº 66
server.xml: Componente Service
Los modos de operaciones de Tomcat
 Servidor de aplicaciones
 Tomcat requiere un servidor web que actúe de frontend
(Apache, IIS u otro)
 El contenido estático es servido por el frontend
 Las peticiones a servlets y JSPs son redirigidas a

Tomcat por el servidor web
 Recibe peticiones en protocolos específicos como AJP
que son enviados por el frontend
 Standalone
 No hay un servidor web que actúe de frontend
 Todos los contenidos son servidos por Tomcat
 Recibe peticiones HTTP
Nº 67
server.xml: Connector
 Veremos los conectores y los posibles modos de

operación de Tomcat en más detalle en capítulos
subsiguientes
Nº 68
Nº 69
server.xml: Componente Engine
Componente Realm
 Implementan la seguridad declarativa
 Establecen un mapeo entre usuarios,

contraseñas y roles de teareas que pueden

llevar a cabo
 Lo veremos en más detalles en un módulo

posterior
Nº 70
Componente Host
 Es un contenedor que representa un host

virtual
 Un solo servidor Tomcat 6 puede contener
muchos hosts virtuales
Servidor Servicio Motor
Host Virtual 1 Host Virtual 2 Host Virtual 2

(www.host1.com) (www.host2.org) (host1.es)
Web App 1 Web App 2 Web App 1 Web App 2 Web App 1 Web App 2
Nº 71
server.xml: Componente Host
Ejercicio M4E2
Nº 72
context.xml
 Ya hemos visto que los contextos establecen una

serie de configuraciones para cada aplicación web
(los veremos en más detalle)
 Se alojan en
<CATALINA_HOME>/conf/<nombre_motor>/<nombre_host>
 Las aplicaciones web pueden definir su propio

context.xml en su carpeta META-INF
 Si no se define ningún context.xml se aplica por

defecto <CATALINA_HOME>/conf/context.xml
Nº 73
Descriptor de despliegue: web.xml
 Toda aplicación web, por especificación, está obligada

a aportar un descriptor de despliegue en WEB-
INF/web.xml
 El descriptor <TOMCAT_HOME>/conf/web.xml es un
descriptor por defecto que se procesa siempre antes

que el descriptor propio de cada aplicación web
 Sólo debería contener información general y no

específica de aplicación
 Permite activar/desactivar/configurar numerosas

opciones como el compilador de JSPs, CGI, SSI,
mapeos MIME…
Ejercicio M4E3
Nº 74
¿Qué hemos visto?
 La arquitectura de Tomcat se basa en

componentes organizados jerárquicamente en
relaciones padre-hijo
 El fichero de configuración principal es

server.xml que mapea esta jerarquía
 Hay otros ficheros de configuración que

aplican valores por defecto sobre las
aplicaciones desplegadas
Nº 75
Nº 76
Módulo 5
Gestionar aplicaciones web

Objetivos
 Gestión mediante el Tomcat Manager
 Integración de gestión mediante Ant

 Gestión mediante peticiones HTTP
Nº 77
Desplegar una aplicación manualmente
 Añadir una entrada <Context> en el server.xml,

lo que permite colocar la aplicación web en
una localización diferente a
<CATALINA_HOME>/webapps
 Copiar el directorio de aplicación completo en

el directorio <CATALINA_HOME>/webapps
 Copiar el fichero WAR en

<CATALINA_HOME>/webapps
Nº 78
Tomcat Manager
 Herramienta web que permite llevar a cabo

tareas de administración:
 Desplegar aplicación web
 Listar aplicaciones desplegadas y sesiones
activas
 Listar recursos JNDI
 Elaborar roles de seguridad
 Iniciar una aplicación detenida
 Detener una aplicación
 Replegar una aplicación
 Mostrar estadísticas de sesión
Nº 79
Permitir el acceso al manager
 Por defecto y por motivos de seguridad está

desactivado
 Hay que configurar un Realm que permita el
acceso
 Por defecto se controla mediante un Realm

que lee los contenidos del fichero
<CATALINA_HOME>/conf/tomcat-users-xml
 Hay que activar un usuario con su password
correspodiente y el rol manager
Ejercicio M5E1
Nº 80
Nº 81
La pantalla principal del manager
Ajustar la configuración del Manager
 Se trata de una aplicación web como cualquier

otra y por tanto tiene un descriptor de
despliegue propio
 En su web.xml se pueden modificar los

criterios de seguridad
 Operaciones permitidas y roles administrativos
 Tipo de autenticación (veremos los diferentes
tipos en un módulo posterior)
Nº 82
Nº 83
Manager: mostrar el estado del servidor
Nº 84
Manager: gestionar aplicaciones (I)
Manager: gestionar aplicaciones (II)
 Trayectoria: ruta de la aplicación web

 Nombre a mostrar: el <display-name> del DD
 Ejecutándose: true o false según sea
 Sesiones: número de sesiones activas.

Haciendo click sobre el número se obtiene
más información estadística
 Comandos: arrancar, parar, recargar,
replegar
Nº 85
Manager: desplegar aplicaciones
Ejercicio M5E2
Nº 86
Controlar aplicaciones mediante Ant
 Instalar Ant y las librerías de Tomcat (ver

módulo 2)
 Añadir al script build.xml los elementos

<taskdef> para llamar a los comandos
 Añadir, si no existiera, un usuario con el rol

manager
Nº 87
Importar los tasks mediante taskdef
 Los tasks de Tomcat no son estándar de Ant y

por tanto hay que importarlos en el fichero
build.xml que los utilice
build.xml
<project name="M3E1" default="default" basedir=".">

../..
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/>
<taskdef name="undeploy" classname="org.apache.catalina.ant.UndeployTask"/>
../..
</project>
Nº 88
Importar los tasks mediante un properties
tomcat-tasks.properties
deploy=org.apache.catalina.ant.DeployTask
list=org.apache.catalina.ant.ListTask
status=org.apache.catalina.ant.JKStatusUpdateTask
reload=org.apache.catalina.ant.ReloadTask
remove=org.apache.catalina.ant.RemoveTask
resources=org.apache.catalina.ant.ResourcesTask
start=org.apache.catalina.ant.StartTask
stop=org.apache.catalina.ant.StopTask
undeploy=org.apache.catalina.ant.UndeployTask
../..
build.xml
../..
<path id=“tomcat.classpath”>
<fileset dir=“${tomcat.home}/lib”>
<include name=“*.jar”/>
</fileset>
</path>
<taskdef file=“tomcat-tasks.properties” classpathref=“tomcat.classpath”/>
../..
Nº 89
Importar los tasks desde el script
predefinido
 Desde la versión de Tomcat 5.5 existe un
script que hace todo lo necesario
build.xml
<project name="M3E1" default="default" basedir=".">

../..
<import file=“${tomcat.home}”/bin/catalina-tasks.xml”/>
../..
</project>
Nº 90
Usar los tasks (I)
 Una vez hemos importado los tasks ya los

podemos utilizar en nuestros targets para
llevar a cabo las diferentes tareas
administrativas
 Para ver el detalle de uso de cada task,

consultar la documentación on-line para el
paquete org.apache.catalina.ant
Nº 91
Usar los tasks (II)
<target name="deploy">
<deploy url="${tomcat.manager.url}" username="${tomcat.username}"
password="${tomcat.password}" path="${context.path}"
war="${war.file}" update="true"/>
</target>
<target name="reload">
<reload url="${tomcat.manager.url}" username="${tomcat.username}"
password="${tomcat.password}" path="${context.path}"/>
</target>
<target name="start">
<start url="${tomcat.manager.url}" username="${tomcat.username}"
</target>
<target name="stop">
<stop url="${tomcat.manager.url}" username="${tomcat.username}"
</target>
Ejercicio M5E3
Nº 92
Gestión mediante peticiones HTTP (I)
 Los comandos se lanzan con peticiones HTTP

desde un navegador
 El formato general de la petición es: http//

{nombre_host}:{puerto}/manager/{comando}?{params}
 comando: list, sessions, start, stop, install, remove,

deploy, undeploy, reload, serverinfo, roles, resources,
status, jxmget, jxmset y jxmproxy
 params: depende del tipo de comando
 Las respuestas son en texto plano (no HTML)
Nº 93
Gestión mediante peticiones HTTP (II)
 Un navegador web sólo puede enviar

peticiones GET
 Algunas operaciones requieren peticiones

POST o PUT y por tanto requerirán de un
cliente más sofisticado que un navegador
 Para ver un listado de las diferentes

operaciones y sus parámetros ver el capítulo 8
del libro
Nº 94
Petición HTTP: listar aplicaciones
desplegadas
Nº 95
¿Qué hemos visto?
 Hay diferentes manera de gestionar las

aplicaciones web
 Mediante el Tomcat Manager que es una

aplicación web que requiere activación previa
 Mediante tareas Ant que permite automatizar

los procesos
 Mediante peticiones HTTP
Nº 96
Nº 97
Módulo 6
Características avanzadas
Objetivos
 Entender las sesiones persistentes
 Configurar recursos JNDI

 Configurar una sesión JavaMail
Nº 98
¿Por qué sesiones persistentes?
 Por defecto, las sesiones de Tomcat están

configuradas para sobrevivir a reinicios del servidor,
pero si queremos más control deberemos configurarlo
 Sesiones inactivas (pero no caducadas) se pueden

configurar para que se copien a disco liberando los

recursos de memoria asociados
 Al parar Tomcat todas las sesiones se vuelcan a disco

por lo que al arrancarlo de nuevo se podrán restaurar
 Las sesiones que tengan un tiempo de vida que

supere cierto límite se copian a disco
automáticamente evitando posibles death-locks
Nº 99
Configurar las sesiones persistentes
 Se gestiona mediante el elemento <Manager>

como un subelemento de <Context>
 Podemos definirlo de manera global si lo

situamos en el <TOMCAT_HOME>/conf/context.xml
 Podemos definirlo de manera local a una

aplicación web si lo ponemos en su fichero
META-INF/context.xml
Nº 100
Nº 101
El elemento Manager
Ejemplo de configuración
<Context>
<Manager className="org.apache.catalina.session.PersistentManager"
saveOnRestart="true"
maxActiveSession="3"
minIdleSwap="0"
maxIdleSwap="60"
maxIdleBackup="0">
<Store className="org.apache.catalina.session.FileStore"/>
</Manager>
</Context>
Ejercicio M6E1
Nº 102
¿Qué es JNDI?
 JNDI = Java Naming and Directory Interface

 Es una API Java que da una abstracción para
acceder de igual forma a diferentes servicios
de directorio (LDAP, MS ADS, otros)
Aplicación Java Aplicación Java Aplicación Java Aplicación Java
JNDI
Driver Driver Otros

LDAP ADS drivers
Nº 103
¿Qué recursos se ofrece JNDI?
 Autenticación (nombre de usuario y

contraseña)
 Políticas de control de acceso
 Directorios de la organización
 Servidores
 Impresoras
 Otros objetos o recursos
Nº 104
Tomcat y JNDI (I)
 Los recursos se preconfiguran global o

localmente (server.xml o context.xml) en el
servidor
 Las aplicaciones web acceden a estos
recursos preconfigurados
Nº 105
Tomcat y JNDI (II)
Búsqueda JNDI
Aplicación Web
Recurso devuelto
Leer y emular
Recurso JNDI funcionalidad JNDI
Servidor
preconfigurado Aplicación Web
Tomcat
en server.xml
Aplicación Web
Nº 106
Ámbito de config. de recursos JNDI
 A nivel global de servidor, disponible para

todos los servicios y motores. En el elemento
<GlobalNamingResources> del server.xml
 A nivel de host virtual. En el elemento

<DefaultContext> del server.xml
 A nivel de <Context>, asociado a una

aplicación web (seguramente en el META-INF/
context.xml)
Nº 107
Subelementos JNDI soportados
 Son elementos hijos de <Context> o <DefaultContext>

Nº 108
Atributos del elemento Environment
<Environment name=“monedaPorDefecto” type=“java.lang.String” value=“euro” />
Ejercicio M6E2
Nº 109
JavaMail y JNDI
 JavaMail es una API utilizada para crear y

enviar correo electrónico
 Tomcat soporta la configuración JNDI de una

sesión JavaMail
Nº 110
Instalar JavaMail
 Descargar mail.jar de
http://java.sun.com/products/javamail/downloads/index.html
 Descargar activation.jar de
http://java.sun.com/products/javabeans/jaf/index.jsp
 Copiar los jars a <TOMCAT_HOME>/lib/
Nº 111
Configurar JNDI para JavaMail
 Al igual que los elementos Environment,

podemos definirlo en los diferentes ámbitos
<Context>
<Resource name="mail/Session" auth="Container“
type="javax.mail.Session" />
<ResourceParams name="mail/Session">
<parameter>
<name>mail.smtp.host</name>
<value>localhost</value>
</parameter>
<parameter>
<name>mail.smtp.port</name>
<value>25</value>
</parameter>
</ResourceParams>
</Context>
Ejercicio M6E3
Nº 112
¿Qué hemos visto?
 Para gestionar sesiones persistentes tenemos

el elemento Manager que se configura a nivel
de contexto (global o local a una webapp
 JNDI es una API que nos permite acceder a

diferentes servicios de directorio de manera
independiente
 JNDI nos permite configurar en el servidor

recursos (como JavaMail) que luego podrán
ser accedidos desde las aplicaciones
Nº 113
Nº 114
Módulo 7
Conexión con bases de datos

Objetivos
 Entender JDBC
 Configurar una DataSource a través de JNDI

 Interactuar con MySQL
Nº 115
¿Qué es JDBC?
 La mayoría de bases de datos comerciales de

hoy día son bases de datos relacionales
 JDBC es una API Java que se abstrae del

proveedor de bases de datos relacional
haciendo transparentes las diferencias entre
ambas
 JDBC proporciona una interfaz SQL y de

conexión contra los diferentes SGBDs
Nº 116
Diagrama básico de JDBC
Aplicación Java
Llamadas JDBC
Librería JDBC
Independiente del SGBD
Dependiente del SGBD

Peticiones SQL nativas
Driver JDBC SGBD

Respuestas SQL nativas
Nº 117
Misión de las operaciones JDBC
 Recibir las llamadas de la API JDBC y

transformarlas en una consulta SQL
 Enviar esa consulta al SGBD
 Recuperar el conjuntos de resultados y

transformarlo en una estructura de datos Java
Nº 118
Etapas en la programación JDBC
 Obtener una conexión a un servidor de bases

de datos remoto
 Generar y preparar una sentencia SQL

 Ejecutar la sentencia SQL
 Obtener el conjunto resultado y trabajar con él
 Desconectarse de la base de datos remota
Nº 119
Pool de conexiones
 Los procesos de conexión y desconexión de una base

de datos son costosos en recursos y tiempo
 Un pool es un componente que almacena conexiones

físicas pre-establecidas contra el SGBD y que las

proporciona a los componentes que las requieran bajo
demanda
 Cuando un componente ha terminado de utilizar una

conexión al cerrarla, en realidad la está devolviendo al
pool pero la conexión física permanece abierta y
disponible para un nuevo “usuario”
Nº 120
Funcionamiento de un pool
4.- Conexión física

devuelta al pool
1.- Solicita conexión
Aplicación 2.- Recibir conexión lógica
Web SGBD
3.- Cerrar conexión lógica
Nº 121
Emulación JNDI y los pool en Tomcat 6
 Tomcat ofrece
 Acceder a las fuentes de datos JDBC mediante
una búsqueda JNDI
 Utilizar el pool propio de Tomcat (DBCP
JakartaComons)
Nº 122
Configurar una conexión JNDI
 Añadir una etiqueta <Resource> en el

elemento <Context> (META-INF/context.xml)
o en el elemento <DefaultContext> (en
server.xml)
 Confirmar que se ha definido un elemento

<resource-ref> en el DD que se corresponderá
con el elemento <Resource> del paso anterior
 Utilizar llamadas JNDI en el código de la
aplicación para buscar la fuente de datos
JDBC
Nº 123
La etiqueta Resource
<Resource name="jdbc/oficina” auth="Container"

type="javax.sql.DataSource"
maxActive="20" maxIdle="30" maxWait="10000"
username="user" password="pass"
url="jdbc:mysql://localhost:3306/oficina"
driverClassName="com.mysql.jdbc.Driver" />
Ejercicio M7E1
Nº 124
¿Qué hemos visto?
 Java ofrece la API JDBC para conectarnos de

manera independiente a diferentes SGBDs
 Un pool es un componente que permite

gestionar las conexiones obteniendo un mayor
rendimiento
 Tomcat permite acceder a fuentes de datos

mediante JNDI y tiene un pool integrado
Nº 125
Nº 126
Conectores
Módulo 8
Objetivos
 Entender los diferentes conectores HTTP
 Entender la configuración con un servidor web

actuando de front-end
 Configurar Apache y Tomcat para que se

comuniquen
Nº 127
Los modos de operaciones de Tomcat
 Servidor de aplicaciones
 Tomcat requiere un servidor web que actúe de frontend
(Apache, IIS u otro)
 El contenido estático es servido por el frontend
 Las peticiones a servlets y JSPs son redirigidas a

Tomcat por el servidor web
 Recibe peticiones en protocolos específicos como AJP
que son enviados por el frontend
 Standalone
 No hay un servidor web que actúe de frontend
 Todos los contenidos son servidos por Tomcat
 Recibe peticiones HTTP
Nº 128
¿Qué son los conectores?
 Son los componentes que proporcionan la

interfaz externa al servidor
 Existen conectores para diferentes protocolos

(HTTP, AJP…)
 El conector HTTP/1.1 basado en Coyote es el

conector por defecto
Nº 129
Conectores HTTP disponibles
 Conector HTTP/1.1 basado en Java (Coyote)
 Conector HTTP de alta eficiencia NIO basado

en Java
 Conector HTTP APR optimizado con código

nativo
Nº 130
Conector HTTP/1.1
 Como hemos visto, los conectores se definen

en el <TOMCAT_HOME>/conf/server.xml
 El único atributo obligatorio es el port

<Conector port=“8080”
protocol=“HTTP/1.1”
maxThreads=“150”
connectionTimeout=“2000”
redirectPort=“8443” />
Nº 131
Nº 132
Atributos del conector HTTP/1.1 (I)
Nº 133
Atributos del conector HTTP/1.1 (II)
Conector HTTP/1.1 con SSL
 Utiliza los mismos atributos que el conector

HTTP/1.1 (adicionalmente veremos otros más)
 Debería tener el atributo secure a true y el
scheme a https
protocol=“HTTP/1.1”
scheme=“https”
secure=“true”
clientAuth=“false”
sslProtocol=“TLS” />
Nº 134
Atributos HTTP/1.1 relacionados con SSL
Nº 135
El conector NIO
 Es un conector escrito en Java que utiliza las

nuevas librerías NIO de Java 5
 Proporcionar operaciones sin bloqueo
 Soporta Comet (técnica de programación

similar a Ajax que permite enviar información
al cliente sin que la haya solicitado)
protocol=“org.apache.coyote.http11.Http11NioProtocol”
Nº 136
¿Qué es APR?
 APR (Apache Portable Runtime) es una

librería de código nativo escrita en C/C++
dependiente de la plataforma
 Existen versiones para Windows, Linux y Unix
 No es estrictamente un conector, pero cuando

se activa el conector estándar delega la
mayoría de sus operaciones en él
 Al utilizar código nativo incrementa la
eficiencia y escalabilidad
Nº 137
¿Por qué es más eficiente y escalable?
 Utiliza una llamada sendFile() en modo núcleo

para enviar grandes ficheros estáticos
directamente desde el sistema de ficheros
nativo
 Usa un solo consultor de persistencia de

código nativo para implementar conexiones
persistentes para un gran número de
conexiones
 Utiliza código nativo de OpenSSL, el cual
tiene capacidad de acelerar la implementación
del controlador SSL (mediante hardware)
Nº 138
Activar APR (I)
 Instalar las librerías nativas

 Descargar la librería
 En los sistemas Unix / Linux suele estar incluida
de serie
 Para Windows puede descargarse de:

http://tomcat.heanet.ie/native
 Configurar la librería
 En Unix / Linux incluirla en LD_LIBRARY_PATH
 En Windows incluirla en el PATH
Nº 139
Activar APR (II)
 Modifica el conector para que use APR
protocol=“org.apache.coyote.http11.Http11AprProtocol”
Ejercicio M8E1
Nº 140
¿Standalone o sevidor de front-end?
 La eficiencia del código nativo APR y las JVM

modernas hace que la elección no sea trivial
considerando sólo la eficiencia
 Una configuración clúster con balanceo de
carga obliga a tener un front-end

 El soporte de seguridad de Apache e IIS es
significativamente mejor que el de Tomcat
 Si la estrategia web incluye otros mecanismos
dinámicos (PHP, Perl, Python, ASP…)
requeriremos un servidor de front-end
especializado
Nº 141
Configuración front-end con Apache
 Para implementar la comunicación se

requieren módulos especializados en ambos
extremos
 Estos módulos se comunican con el protocolo
AJP
 En el lado de Apache son módulos escritos en
C/C++
 En el lado Tomcat son conectores AJP
escritos en Java
Nº 142
Arquitectura de la integración
Petición de recursos estáticos Apache Tomcat

Protocolo Protocolo
HTTP AJP
Módulo Conector AJP

Petición de recursos dinámicos:
servlets,JSPs
Nº 143
Características de AJP1.3
 Eficiencia optimizada en redes rápidas (como

ethernet gigabit)
 Compresión para optimizar el ancho de banda
 Soporte para SSL, cifrado y certificados de

cliente
 Soporte de clústeres
Nº 144
Módulos disponibles para Apache (I)
 Dos opciones
 mod_jk: el módulo “tradicional”
 mod_proxy: módulo estándar de Apache que
en sus últimas versiones soporta AJP
 ¿Cuál es la mejor opción? mod_proxy

 El esfuerzo de desarrollo se ha centrado en
este módulo
 Es estándar de Apache (lo tendremos
disponibles sin tener que construirlo)
 Es más fácil (estándar) de configurar
Nº 145
Módulos disponibles para Apache (II)
Versión de Apache
1.3.x 2.0.x 2.2.x

mod_jk Sí Sí Sí
mod_proxy No Sí (necesita código Sí

de la 2.2)
Nº 146
mod_jk: Concepto de worker
 Representa una instancia de Tomcat en

ejecución
 Cuando tenemos un cluster tenemos más de

un worker
 Cada worker se identifica por un nombre de

host (máquina donde está la instancia
Tomcat) único o una combinación de dirección
IP y número de puerto (puerto donde escucha
el protocolo AJP)
Nº 147
mod_jk: El fichero workers.properties (I)
 Es un fichero que se situa en

<APACHE_HOME>/conf
 Es leído por el módulo de Apache que se

encargará de enviar las peticiones AJP contra

las diferentes instancias de Tomcat
 Contiene
 Descripción de la lista de workers
 Descripción de cada instancia de worker de la
lista anterior
Nº 148
mod_jk:El fichero workers.properties (II)
workers.properties
worker.list = testworker1, tesworker2

worker.testworker1.type = ajp13
worker.testworker1.host = 192.168.1.128
worker.testworker1.port = 9009
worker.testworker1.connection_pool_size = 5
worker.testworker1.connection_pool_timeout = 300
worker.testworker2.type = …
…
Nº 149
Nº 150
mod_jk: Propiedades de los workers
mod_jk: Tipos de worker
 ajp13: representa una instancia en ejecución

de Tomcat
 lb: se emplea para equilibrio de cargas. Este
worker no procesa peticiones sino que las
redirige a otros worker de tipo ajp13 en

función de su carga
 status: se utiliza para mostrar información útil
de carga
 jni: es un protocolo que permite enviar
peticiones entre Apache y Tomcat a través de
memoria porque comparten el mismo proceso
Nº 151
mod_jk: Configuración de Apache
 Construir el módulo mod_jk y copiarlo en

<APACHE_HOME>/modules
 Añadir la directiva correspondiente en httpd.conf

LoadModule jk_module modules/mod_jk.so
 Configurar el wokers.properties
Nº 152
mod_proxy: Configuración de Apache
 Añadir la directiva correspondiente en httpd.conf

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
 Editar la configuración de proxy en http.conf, p.e.:

ProxyRequests Off
ProxyPreserveHost On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /examples/jsp ajp://localhost:8009/examples/jsp
ProxyPassReverse /examples/jsp ajp://localhost:8009/examples/jsp
<Location /examples/jsp>
Order allow,deny
Allow from all
</Location>
Nº 153
Tomcat: config. del conector AJP
 En el lado de Tomcat, las peticiones AJP se

reciben en un conector AJP independiente del
módulo que esté usando Apache
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
Ejercicio M8E2
Nº 154
¿Qué hemos visto?
 Tomcat proporciona conectores HTTP eficientes que

lo convierten en una opción válida para una
configuración standalone
 La configuración con un servidor web actuando de

front-end puede seguir teniendo sentido (para montar
un cluster, por ejemplo)
 La comunicación entre un servidor web y Tomcat se

hace mediante un protocolo eficiente llamado AJP que
implica la inclusión de módulos en el servidor web y la
activación de un conector AJP en Tomcat
Nº 155
Nº 156
Seguridad
Módulo 9
Objetivos
 Asegurar la instalación de Tomcat
 Entender el soporte de autenticación para las

aplicaciones Web
 Configurar el soporte para cifrado SSL
Nº 157
Verificar la integridad de la descarga
 Es importante asegurarnos que el código que

nos descargamos no ha sido modificado por
una fuente maliciosa
 Para verificarlo disponemos de dos opciones

 Funciones de hash MD5
 claves PGP
 En Windows hay diferentes herramientas que

calculan las funciones de hash
Nº 158
Eliminar las aplicaciones por defecto
 ROOT, tomcat-docs y examples

 No aportan funcionalidad en producción
 Riesgo mínimo pero potencialmente podría haber un
exploit
 manager y host-manager
 Por su funcionalidad (tareas administrativas) presentan
el mayor riesgo
 Deberían ser eliminadas por completo
 Si fueran necesarias:
 Cambiar el mecanismo de autenticación de BASIC a un
tipo más seguro
 Permitir sólo el acceso de direcciones específicas
 Elegir un usuario y password difícil de adivinar
Nº 159
Cambiar el comando de SHUTDOWN
 Ya hemos visto que el componente Server

permite configurar un puerto y un comando de
apagado del servidor
 Se debería cambiar el puerto y la palabra

clave por defecto
<Server port=“8123” shutdown=“byebye” />
 También es una buena idea bloquear el

acceso al puerto mediante un firewall
Nº 160
Ejecutar Tomcat con una cuenta restringida
 Si un atacante se hace con el control de

Tomcat es importante que el usuario que lo
ejecuta no tenga privilegios para dañar el
sistema
 El Unix / Linux crear un usuario cuyos únicos

privilegios sea ejecutar Tomcat
 En Windows crear un usuario no
administrativos y utilizar la utlidad Servicios de
las carpeta Herramientas administrativas para
establecer el usuario
Nº 161
Nº 162
Gestor de servicios
Asegurar el sistema de ficheros (I)
 En Windows
 sólo podremos restringir acceso a ficheros si
con NTFS (con FAT32 no hay nada que hacer)
 NTFS se basa en listas de control de acceso:
se puede establecer qué usuarios acceden a

un recurso
 Deberíamos denegar el acceso a todos los
ficheros de todas las particiones
 En Unix / Linux los permisos se establecen
explícitamente mediante usuarios y grupos
Nº 163
Asegurar el sistema de ficheros (II)
 Conceder permisos de lectura y ejecución

sobre los ficheros de la JRE
 Conceder permisos de lectura sobre
 <TOMCAT_HOME>/bin
 <TOMCAT_HOME>/lib
 <TOMCAT_HOME>/webapps (aunque esto inhabilita el
uso del manager como herramienta para desplegar
nuevas webapps)
 Conceder permisos de lectura y escritura
sobre <TOMCAT_HOME>/conf
Nº 164
Utilizar el gestor de seguridad de Java
 La arquitectura de seguridad de Java está

basada en permisos
 Una vez activado (no lo está por defecto), las
aplicaciones deberán tener permiso explícito
para realizar ciertas tareas

 Los permisos se conceden mediante ficheros
de políticas
 El fichero de políticas de Tomcat es
<TOMCAT_HOME>/conf/cataina.policy
 Para activar el gestor:
<TOMCAT_HOME>/bin/catalina start -security
Nº 165
Proteger aplicaciones web
 Hasta ahora hemos visto como proteger

Tomcat y la plataforma
 Las seguridad a nivel de aplicación puede

categorizarse en;
 Autenticación y Realm
 Cifrado
 Restricción de Host
Nº 166
Autenticación y Realm
 Autenticar es el proceso de determinar y validar la

identidad de un cliente
 J2EE proporciona la API JAAS (Java Autentication

and Authorization Service) como mecanismo estándar
de autenticación
 El uso de JAAS garantiza la portabilidad del

mecanismo de autenticación entre diferentes
servidores
 El mecanismo de Realm de Tomcat es una

implementación de JAAS
Nº 167
Mecanismos de autenticación
 BASIC
 DIGEST
 Formularios
 Certificado de cliente HTTP
Nº 168
Mecanismo BASIC
 Es una aproximación simplista
 El navegador envía credenciales (user y

password) cifradas en base64 al servidor que
descifrará y utilizará para autentificar
 Problemas
 base64 no es un mecanismo de cifrado seguro
 Los navegadores guardan en caché las
credenciales
Nº 169
Mecanismo DIGEST
 Es similar a BASIC con la diferencia que la contraseña

se transmite de forma segura
 El cliente aplica una función de hash sobre la
contraseña y transmite el resultado al servidor. Éste
realiza la misma operación sobre el password que tiene
almacenado y compara los resultados
 Problemas
 La contraseña original debe almacenarse en algún lugar
(habrá que proteger adecuadamente este recurso)
 El navegador guarda en caché las credenciales
 Java soporta los hash MD5 y SHA
Nº 170
Mecanismo de formularios
 El navegador no coopera y es la aplicación

web la que tiene que crear un formulario que
permita enviar las credenciales
 La transmisión de los datos se puede hacer

sobre HTTPS garantizando el cifrado de datos
 Problema
 Sigue habiendo dependencia de usuarios y
credenciales que pueden obtenerse por fuerza
bruta o ingeniería social
Nº 171
Mecanismo de certificados digitales
 Se utilizan certificados digitales de manera simétrica

 El cliente puede estar seguro que se conecta al servidor
que pretendía (como certifica una entidad externa como
VeriSign) mediante la clave pública
 El servidor recibe un certificado del cliente que le

permite autenticarlo
 Es un sistema muy seguro aunque generalmente se

usan mecanismos más sencillos como la
autenticación a través de formularios sobre HTTPS
Nº 172
Configurar la aplicación web
web.xml
…
<security-constraint>
<display-name>todo</display-name>
<web-resource-collection>
<web-resource-name>TodaLaAplicacion</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>administrador</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>MiRealm</realm-name>
</login-config>
<security-role>
</security-role>
….
Nº 173
Configurar los Realm en Tomcat
 El modelo se construye sobre los conceptos de

usuarios y roles
 La aplicación declara en su descriptor qué roles

pueden acceder a qué recursos y los usuarios que
dispongan de ese rol tendrán acceso
 Los Realm, se configuran en Tomcat (no en la

aplicación) y así se pueden añadir y borrar usuarios
dinámicamente
 Existen diferentes implementaciones: JDBCRealm,

DataSourceRealm, JNDIRealm, MemoryRealm,
JAASRealm
Nº 174
MemoryRealm
 Los usuarios y roles se almacenan en un

fichero de texto editable (p.e. XML) que se
carga en memoria
mis-usuarios.xml
<tomcat-users>
<role rolename="administrador"/>
<user username="admin" password="admin2" roles="administrador"/>
</tomcat-users>
context.xml
<Context path="/M3E1">
<Realm
className="org.apache.catalina.realm.MemoryRealm"
pathname="conf/mis-usuarios.xml" />
</Context>
Ejercicio M9E1
Nº 175
JDBCRealm
 Almacena las credenciales en una base de datos
user_roles
users
PK,FK1 login
PK login
PK role
password
<Realm className=“org.apache.catalina.realm.JDBCRealm”
driverName=“com.mysql.jdbc.Driver”
connectionURL=“jdbc:mysql://localhost/autoridad”
connectionName=“tomcat”
connectionPassword=“tomcat”
userTable=“users”
userNameCol=“login” userCredCol=“password”
userRoleTable=“user_roles”
roleNameCol=“role”
digest=“md5”/>
Ejercicio M9E2
Nº 176
Cifrado SSL
 Protocolo que permite una conexión segura

entre clientes y servidores en una red
 Tiene protocolos de clave pública/privada y de

clave simétrica
 HTTPS utiliza HTTP sobre SSL para ofrecer

encriptación y autenticación fiable
Nº 177
Añadir soporte SSL a Tomcat
 Descargar e instalar una implementación SSL

(podemos usar la librería JSSE estándar de Java o la
implementación nativa APR)
 Crear un almacén de claves de certificado al que

añadiremos un certificado que firmaremos nosotros
 Obtener un certificado de una agencia de certificación

externa como VeriSign para que los usuarios puedan
confiar en nuestro certificado (en desarrollo podemos
obviar este paso)
 Configurar Tomcat para SSL
Nº 178
Preparar el almacén de claves
 Lo hacemos mediante la herramienta

<TOMCAT_HOME>/bin/keytool
Nº 179
Configuración de Tomcat
 Situamos el almacén de claves y

configuramos el conector
Conector Java
<Connector
port=“8443” scheme=“https” secure=“true” SSLEnabled=“true”
keystoreFile=“store” sslProtocol=“TLS”
keystorePass=“clave-segura” />
Conector Nativo APR
<Connector
protocol=“org.apache.coyote.http11.HttpAprProtocol”
port=“8443” scheme=“https” secure=“true” SSLEnabled=“true”
SSLCertificateFile=“/mycertdir/server.crt”
SSLCertificateKeyFile=“/mycertdir/ssl/server.pem” />
Nº 180
Configurar la webapp para que use SSL
 Hay que editar el descriptor de despliegue para añadir

una user-data-constraint especificando protocolo
CONFIDENTIAL
web.xml
<security-constraint>
<display-name>todo</display-name>
<web-resource-collection>
<web-resource-name>TodaLaAplicacion</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Ejercicio M9E3
Nº 181
¿Qué hemos visto?
 Hay que personalizar la configuración por

defecto de Tomcat cuando esté en entorno de
producción para garantizar la seguridad
 J2EE define un estándar de autentificación

para la aplicaciones web que se basa en
Realms que Tomcat implementa
 Tomcat tiene conectores que proporcionan

SSL
Nº 182
Nº 183
Módulo 10
Alojamiento Compartido
Objetivos
 Entender las nociones de alojamiento

compartido
Nº 184
¿Qué es el alojamiento compartido?
 Pequeñas organizaciones es posible que no

puedan permitirse tener su propio Tomcat
(máquinas, ingenieros, etc.)
 Se puede subcontratar el servidor a un

proveedor de servicios
 Estos proveedores suelen proporcionar

soluciones en las que se comparten recursos:
bases de datos, servidores de correo, firewall,
servidores web y servidores de aplicaciones
Nº 185
Alojamiento virtual
 El alojamiento virtual se refiere a que una

misma máquina física proporciona más de un
servidor web (o de aplicaciones)
 Tipos
 Basado en IP: cada dominio web necesita
tener una dirección IP diferente que es lo que
usa el servidor para diferenciar peticiones
 Basado en nombres: los dominios pueden
compartir IP y las peticiones se diferencian por
nombre
Nº 186
Alojamiento virtual basado en IP
 Necesitamos que la máquina tenga más de

una IP válida
 Funciona con todos los clientes HTTP

(aunque usen la versión 1.0)
 El número de hosts virtuales máximo está

limitado y la administración asociada a la
gestión de muchas IPs puede ser tediosa
Nº 187
Alojamiento virtual basado en nombres
 La máquina no necesita más de una dirección

IP
 Para poder funcionar se basa en la cabecera

Host que es una característica de HTTP 1.1
por lo que es posible que no todos los clientes
puedan conectarse
 La administración es más sencilla
Nº 188
Configurar Tomcat para alojamiento virtual
basado en nombres
 Está disponible desde las primeras versiones
 Consiste en añadir nuevas entradas Host a
nivel de Engine
server.xml
<Engine name=“Catalina” defaultHost=“dominio1.com” debug=“0”>

…
<Host name=“dominio1.com” debug=“0”
autoDeploy=“true” unpackWar=“true”
appBase=“/websites/dominio/webapps” />

</Engine>
Nº 189
Configurar Tomcat para alojamiento virtual
basado en IP
 Es una característica nueva desde la 5.5
 La configuración es prácticamente la misma excepto en que
activamos un atributo a nivel de conector que fuerza a ignorar la
cabecera Host de HTTP/1.1 con lo que sólo se usará la IP
server.xml
<Connector port=“8080” protocol=“HTTP/1.1” redirectPort=“8443”
useIPVHosts=“true”>
…
<Engine name=“Catalina” defaultHost=“dominio1.com” debug=“0”>
…

</Engine>
Nº 190
Configuración con front-end y alojamiento
virtual
 Apache también se puede configurar para
trabajar con los dos modos de alojamiento
virtual
 Tomcat también soporta el modo de

alojamiento virtual teniendo un front-end
Apache
Nº 191
Arquitectura en modo front-end
Apache Tomcat
Gestor Host Virtual 1

Cliente
de
Web
peticiones
Host Virtual 2
…
Módulo de Host Virtual
Host Virtual N
mod_jk Conector AJP
Nº 192
¿Qué hemos visto?
 El alojamiento virtual tiene sentido cuando se

quiere compartir el mismo servidor entre
diferentes usuarios
 Existe alojamiento virtual por IP o por nombre
 Tomcat 6 en modo standalone soporta ambos
 También se puede configurar con un front-end
Nº 193

Instalación y administración de Apache Tomcat

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Instalación y administración de Apache Tomcat

Hochgeladen von

Copyright:

Verfügbare Formate

Instalación y Administración de

Iván Párraga García – ivan.parraga.garcia@gmail.com

 Introducción al proyecto Apache & Jakarta

 Entender la tecnología J2EE

 Rob McCool en el NCSA de la Universidad de Illinois,

lanzaron una nueva versión corregida conocida como

 Tomcat era un subproyecto bajo el proyecto

 Tomcat es código libre, gratis y que puede distribuirse

 Cualquier documentación incluida con la redistribución

Java para dispositivos

 Es un conjunto de especificaciones que definen unas

 Se construye encima de la JSE

 NO ES UN SOFTWARE. Las especificaciones son

 SUN controla estas (y otras) especificaciones a través

 Sistemas especializados por tareas en los servidores

 Los usuarios acceden mediante un navegador web estándar

 Escalable: los diferentes subsistemas pueden

Cliente / Usuario Presentación Lógica de Negocio Persistencia

HTTP Contenedor RMI Contenedor SQL

Límites de la tecnología Java

 Un contenedor es un componente software que

 Proporciona servicios al programador que son

comunes y habituales a todas las aplicaciones

 Las especificaciones definen dos contenedores

 Contenedor web: especializado en gestionar la capa de

 Contenedor de Enterprise Java Beans (EJBs):

Utilizando contenedores Tareas del desarrollador

Proporcionado por el contenedor

 Es un software que implementa las especificaciones y

 Sun proporciona el sello “JEE compliant server” sólo si

garantizan que se satisface la especificación

 Diferentes proveedores ofrecen diferentes productos,

 Tomcat es un producto muy popular, pero no es un

 Es adecuado para aplicaciones web con arquitectura

 Tomcat es más fácil de administrar y requiere menos

 El servidor web Apache está en el origen de la ASF

 La tecnología Java J2EE se basa en la arquitectura en

 Instalar la Java Virtual Machine (JVM)

 Comprender la estructura de directorios de

 Resolver problemas típicos

 Tomcat es una aplicación Java y por tanto

 Desde la versión 6 de Tomcat no se necesita

 Establecer la variable de entorno

JAVA_HOME en la ruta a la raíz de la JRE

 Añadir a la variable de entorno PATH la ruta a

 Core: versión base disponible en diferentes

Instalar servicio de Windows

Instalar librerías nativas APR

Puerto en el que aceptará peticiones

Instalar ejemplos de servlets y JSPs

Usuario y password de las

 Añadir la variable de entorno

 Iniciar el servidor manualmente

 bin: scripts y ficheros de arranque

 logs: contiene los ficheros de log

 Problema: error de versión de clase

que JAVA_HOME le apunta

 Problema: puerto en uso

 Problema: ejecutar varias instancias

 Problema: un proxy bloquea el acceso

 Ant es una herramienta de construcción de

 Se ha convertido en la herramienta de este

 Tomcat define una serie de librerías que le