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

Transcripción

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

2 Módulo 1 Introducción Nº 2

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

4 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

5 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

6 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

7 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

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

9 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

10 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

11 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

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

13 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

14 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

15 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

16 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

17 Servidores de aplicaciones (II) Nº 17

18 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

19 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

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

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

22 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

23 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

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

25 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

26 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

27 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

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

29 Comprobar la instalación Nº 29

30 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

31 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

32 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

33 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

34 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

35 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

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

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

38 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

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

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

41 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

42 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

43 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

44 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

45 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

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

47 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

48 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

49 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

50 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 Nº 50 jars necesarios por la aplicación web

51 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

52 Módulo 4 Configurar Tomcat Nº 52

53 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

54 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

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

56 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

57 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

58 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

59 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

60 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

61 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

62 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

63 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

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

65 server.xml: Subelementos de Server Nº 65

66 server.xml: Componente Service Nº 66

67 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

68 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

69 server.xml: Componente Engine Nº 69

70 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

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

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

73 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

74 Descriptor de despliegue: web.xml Toda aplicación web, por especificación, está obligada a aportar un descriptor de despliegue en WEBINF/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

75 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

76 Módulo 5 Gestionar aplicaciones web Nº 76

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

78 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

79 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

80 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

81 La pantalla principal del manager Nº 81

82 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

83 Manager: mostrar el estado del servidor Nº 83

84 Manager: gestionar aplicaciones (I) Nº 84

85 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

86 Manager: desplegar aplicaciones Ejercicio M5E2 Nº 86

87 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

88 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

89 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

90 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

91 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

92 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> Ejercicio M5E3 Nº 92

93 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

94 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

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

96 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

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

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

99 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

100 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

101 El elemento Manager Nº 101

102 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

103 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 LDAP Nº 103 Driver ADS Otros drivers

104 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

105 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

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

107 Á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

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

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

110 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

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

112 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

113 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

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

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

116 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

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

118 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

119 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

120 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

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

122 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

123 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

124 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

125 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

126 Módulo 8 Conectores Nº 126

127 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

128 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

129 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

130 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

131 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

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

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

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

135 Atributos HTTP/1.1 relacionados con SSL Nº 135

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

137 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

138 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

139 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

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

141 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

142 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

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

144 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

145 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

146 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 de la 2.2) Sí Nº 146

147 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

148 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

149 mod_jk:el fichero workers.properties (II) workers.properties 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 = Nº 149

150 mod_jk: Propiedades de los workers Nº 150

151 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

152 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

153 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

154 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

155 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

156 Módulo 9 Seguridad Nº 156

157 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

158 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

159 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

160 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

161 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

162 Gestor de servicios Nº 162

163 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

164 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

165 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

166 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

167 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

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

169 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

170 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

171 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

172 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

173 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> <role-name>administrador</role-name> </security-role>. Nº 173

174 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

175 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

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

177 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

178 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

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

180 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

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

182 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

183 Módulo 10 Alojamiento Compartido Nº 183

184 Objetivos Entender las nociones de alojamiento compartido Nº 184

185 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

186 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