Módulo 1. Introducción. Instalación y Administración de Apache Tomcat Nº 2

Transcripción

1 Módulo 1 Introducción Nº 2

2 Objetivos Introducción al proyecto Apache & Jakarta Entender la tecnología J2EE Nº 3

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

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

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

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

7 Las diferentes tecnologías Java Nº 8 Java para dispositivos móviles JME JSE Java para aplicaciones de escritorio JEE

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

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

10 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

11 Arquitectura multicapa de la JEE Cliente / Usuario Nº 12 Presentación Lógica de Negocio HTTP Contenedor Contenedor Web RMI EJB SQL Límites de la tecnología Java Persistencia SGBD

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

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.) Nº 14 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)

14 Ventajas del uso de contendores Construyendo desde cero Tareas del desarrollador Lógica de Negocio Persistencia Gestión de transacciones Multi-threading Seguridad Nº 15 Utilizando contenedores Red Publicación de servicios Tareas del desarrollador Lógica de Negocio Proporcionado por el contenedor Persistencia Gestión de transacciones Multi-threading Seguridad Red Publicación de servicios

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

16 Servidores de aplicaciones (II) Nº 17

17 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

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

19 Módulo 2 Instalación de Tomcat Nº 20

20 Objetivos Instalar la Java Virtual Machine (JVM) Instalar Tomcat Comprender la estructura de directorios de Tomcat Resolver problemas típicos Instalar Ant Nº 21

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

22 Instalación de la JVM en Windows (I) Descargarla de 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

23 Instalación de la JVM en Windows (II) Nº 24

24 Descargar Tomcat Conectarse a 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

25 Instalar mediante el asistente Instalar servicio de Windows Instalar librerías nativas APR Instalar ejemplos de servlets y JSPs Usuario y password de las herramientas administrativas Nº 26 Puerto en el que aceptará peticiones

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

27 Probar la instalación Iniciar el servidor manualmente <TOMCAT_HOME>\bin\tomcat6.exe Iniciar el servidor como un servicio Nº 28

28 Comprobar la instalación Nº 29

29 La jerarquía de directorios de Tomcat Nº 30 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

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

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 Nº 32

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

33 Instalar Ant y las bibliotecas de Tomcat Descargar Ant desde 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/catalinaant.jar en <ANT_HOME>/lib Nº 34

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

35 Módulo 3 Aplicaciones web con Java Nº 36

36 Objetivos Entender la tecnología de servlets Entender las JSP El framework Jakarta Struts Nº 37

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

38 Ejecución de CGI s Servidor Nº 39 Petición Petición Petición Servidor web Shell CGI Shell CGI Shell CGI Programa CGI

39 Ejecución de servlets Servidor Nº 40 Petición Petición Petición Servidor web Thread Thread Servlet Thread Contenedor web

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

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

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

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

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

45 El patrón MVC (modelo-vista-controlador) Nº 46

46 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

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

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 Nº 49 Ejercicio M3E1

49 Estructura de una aplicación web (II) Recursos estáticos y JSPs Descriptor de contexto (context.xml) Descriptor de despliegue (web.xml) Nº 50 Servlets y clases compiladas jars necesarios por la aplicación web

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

51 Módulo 4 Configurar Tomcat Nº 52

52 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

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

54 Arquitectura de Tomcat (II) Servidor Servicio Conector Motor Logger Válvula Realm Nº 55 Host Logger Contexto Realm Válvula Realm Válvula Encapsulador

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

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

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

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

59 El server.xml por defecto <?xml version='1.0' encoding='utf-8'?> Nº 60 <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>

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

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

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

63 server.xml: Componente Server Nº 64 Ejercicio M4E1

64 server.xml: Subelementos de Server Nº 65

65 server.xml: Componente Service Nº 66

66 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

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

68 server.xml: Componente Engine Nº 69

69 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

70 Componente Host Es un contenedor que representa un host virtual Un solo servidor Tomcat 6 puede contener muchos hosts virtuales Nº 71 Servidor Servicio Motor Host Virtual 1 ( Web App 1 Web App 2 Host Virtual 2 ( Web App 1 Web App 2 Host Virtual 2 (host1.es) Web App 1 Web App 2

71 server.xml: Componente Host Nº 72 Ejercicio M4E2

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

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 Nº 74 Ejercicio M4E3

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

75 Módulo 5 Gestionar aplicaciones web Nº 76

76 Objetivos Gestión mediante el Tomcat Manager Integración de gestión mediante Ant Gestión mediante peticiones HTTP Nº 77

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

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

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 Nº 80 Ejercicio M5E1

80 La pantalla principal del manager Nº 81

81 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

82 Manager: mostrar el estado del servidor Nº 83

83 Manager: gestionar aplicaciones (I) Nº 84

84 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

85 Manager: desplegar aplicaciones Nº 86 Ejercicio M5E2

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

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 Nº 88 <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>

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

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 Nº 90 <project name="m3e1" default="default" basedir=".">../.. <import file= ${tomcat.home} /bin/catalina-tasks.xml />../.. </project>

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

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}" password="${tomcat.password}" path="${context.path}"/> </target> <target name="stop"> <stop url="${tomcat.manager.url}" username="${tomcat.username}" password="${tomcat.password}" path="${context.path}"/> </target> Nº 92 Ejercicio M5E3

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} Nº 93 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)

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

94 Petición HTTP: listar aplicaciones desplegadas Nº 95

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

96 Módulo 6 Características avanzadas Nº 97

97 Objetivos Entender las sesiones persistentes Configurar recursos JNDI Configurar una sesión JavaMail Nº 98

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

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

100 El elemento Manager Nº 101

101 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> Nº 102 Ejercicio M6E1

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) Nº 103 Aplicación Java Aplicación Java Aplicación Java Aplicación Java Driver LDAP JNDI Driver ADS Otros drivers

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

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

105 Tomcat y JNDI (II) Búsqueda JNDI Recurso devuelto Aplicación Web Recurso JNDI preconfigurado en server.xml Nº 106 Leer y emular funcionalidad JNDI Servidor Tomcat Aplicación Web Aplicación Web

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

107 Subelementos JNDI soportados Son elementos hijos de <Context> o <DefaultContext> Nº 108

108 Atributos del elemento Environment <Environment name= monedapordefecto type= java.lang.string value= euro /> Nº 109 Ejercicio M6E2

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

110 Instalar JavaMail Descargar mail.jar de Descargar activation.jar de Copiar los jars a <TOMCAT_HOME>/lib/ Nº 111

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> Nº 112 Ejercicio M6E3

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

113 Módulo 7 Conexión con bases de datos Nº 114

114 Objetivos Entender JDBC Configurar una DataSource a través de JNDI Interactuar con MySQL Nº 115

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

116 Diagrama básico de JDBC Aplicación Java Llamadas JDBC Nº 117 Librería JDBC Driver JDBC Peticiones SQL nativas Respuestas SQL nativas SGBD Independiente del SGBD Dependiente del SGBD

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

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

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

120 Funcionamiento de un pool Nº 121 Aplicación Web 1.- Solicita conexión 2.- Recibir conexión lógica 3.- Cerrar conexión lógica 4.- Conexión física devuelta al pool SGBD

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

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

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" /> Nº 124 Ejercicio M7E1

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

125 Módulo 8 Conectores Nº 126

126 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

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

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

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

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 Nº 131 <Conector port= 8080 protocol= HTTP/1.1 maxthreads= 150 connectiontimeout= 2000 redirectport= 8443 />

131 Atributos del conector HTTP/1.1 (I) Nº 132

132 Atributos del conector HTTP/1.1 (II) Nº 133

133 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 Nº 134 <Conector port= 8443 protocol= HTTP/1.1 maxthreads= 150 scheme= https secure= true clientauth= false sslprotocol= TLS />

134 Atributos HTTP/1.1 relacionados con SSL Nº 135

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) Nº 136 <Conector port= 8080 protocol= org.apache.coyote.http11.http11nioprotocol maxthreads= 150 connectiontimeout= redirectport= 8443 />

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

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

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: Configurar la librería En Unix / Linux incluirla en LD_LIBRARY_PATH En Windows incluirla en el PATH Nº 139

139 Activar APR (II) Modifica el conector para que use APR Nº 140 <Conector port= 8080 protocol= org.apache.coyote.http11.http11aprprotocol maxthreads= 150 connectiontimeout= redirectport= 8443 /> Ejercicio M8E1

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

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

142 Arquitectura de la integración Petición de recursos estáticos Apache Tomcat Nº 143 Protocolo HTTP Petición de recursos dinámicos: servlets,jsps Módulo Protocolo AJP Conector AJP

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

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

145 Módulos disponibles para Apache (II) Versión de Apache 1.3.x 2.0.x 2.2.x mod_jk mod_proxy Nº 146 Sí No Sí Sí (necesita código de la 2.2) Sí Sí

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

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

148 mod_jk:el fichero workers.properties (II) workers.properties Nº 149 worker.list = testworker1, tesworker2 worker.testworker1.type = ajp13 worker.testworker1.host = worker.testworker1.port = 9009 worker.testworker1.connection_pool_size = 5 worker.testworker1.connection_pool_timeout = 300 worker.testworker2.type =

149 mod_jk: Propiedades de los workers Nº 150

150 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

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 Configurar el wokers.properties Nº 152 LoadModule jk_module modules/mod_jk.so

152 mod_proxy: Configuración de Apache Añadir la directiva correspondiente en httpd.conf Editar la configuración de proxy en http.conf, p.e.: Nº 153 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 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>

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 Nº 154 <Connector port="8009" protocol="ajp/1.3" redirectport="8443" /> Ejercicio M8E2

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

155 Módulo 9 Seguridad Nº 156

156 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

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

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

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 También es una buena idea bloquear el acceso al puerto mediante un firewall Nº 160 <Server port= 8123 shutdown= byebye />

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

161 Gestor de servicios Nº 162

162 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

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

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

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

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

167 Mecanismos de autenticación BASIC DIGEST Formularios Certificado de cliente HTTP Nº 168

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

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

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

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

172 Configurar la aplicación web web.xml Nº 173 <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> <role-name>administrador</role-name> </security-role>.

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

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 Nº 175 <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

175 JDBCRealm Almacena las credenciales en una base de datos Nº 176 PK users login password user_roles PK,FK1 PK login role <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

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

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

178 Preparar el almacén de claves Lo hacemos mediante la herramienta <TOMCAT_HOME>/bin/keytool Nº 179

179 Configuración de Tomcat Situamos el almacén de claves y configuramos el conector Conector Java Nº 180 <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 />

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 Nº 181 <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> <user-data-constraint> <transport-guarantee>confidential</transport-guarantee> </user-data-constraint> </security-constraint> Ejercicio M9E3

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