servidores de aplicaciones - ua · • jboss (redhat) • glassfish (sun) • websphere (ibm) se...

Servidores de aplicaciones

Índice

1 Introducción a los servidores de aplicaciones y a Glassfish........................................ 3

1.1 ¿Qué es un servidor de aplicaciones?...................................................................... 3

1.2 Características de Glassfish..................................................................................... 6

1.3 Dominios..................................................................................................................7

1.4 Despliegue de aplicaciones web.............................................................................. 9

1.5 Referencias.............................................................................................................12

2 Ejercicios de instalación y administración de GlassFish............................................13

2.1 Instalación de Glassfifsh+NetBeans...................................................................... 13

2.2 Desplegando la primera aplicación web................................................................ 16

2.3 Desplegando la aplicación sin NetBeans............................................................... 18

2.4 Empaquetando una aplicación EAR...................................................................... 20

2.5 CVS........................................................................................................................25

2.6 Backup del dominio............................................................................................... 25

2.7 Entrega................................................................................................................... 26

3 Clustering con GlassFish............................................................................................27

3.1 Conceptos básicos..................................................................................................27

3.2 Creación de un cluster............................................................................................31

4 Ejercicios de clustering.............................................................................................. 35

4.1 Creación de un nuevo dominio.............................................................................. 35

4.2 Creación de instancias de servidor en el cluster.................................................... 36

4.3 Despliegue de aplicaciones en el cluster................................................................37

4.4 Entrega................................................................................................................... 39

5 Gestión de recursos.................................................................................................... 40

5.1 JNDI: búsqueda de objetos mediante su nombre lógico........................................40

5.2 Acceso a recursos y bases de datos........................................................................42

6 Ejercicios de acceso a base de datos.......................................................................... 48

Copyright © 2009-2010 Depto. CCIA All rights reserved.

6.1 Creación de la base de datos.................................................................................. 48

6.2 Configuración de la fuente de datos en GlassFish................................................. 48

6.3 Acceso a la fuente de datos usando JNDI..............................................................48

6.4 Acceso a la fuente de datos con inyección de dependencias................................. 48

7 Seguridad de aplicaciones en Glassfish......................................................................50

7.1 Conceptos de seguridad......................................................................................... 50

7.2 Realms en Glassfish...............................................................................................50

7.3 Realm JDBC.......................................................................................................... 52

7.4 Uso de certificados.................................................................................................54

8 Ejercicios de seguridad de aplicaciones con Glassfish.............................................. 62

8.1 Prueba de realm......................................................................................................62

8.2 Configuración de un realm con uso de certificados...............................................65

8.3 Configuración de un realm JDBC (OPTATIVO).................................................. 70

9 Apéndice: Servidor de aplicaciones JBoss.................................................................71

9.1 JBoss: instalación, configuración y administración. Gestión de recursos............. 71

9.2 Ejercicios de instalación y administración de JBoss..............................................77

9.3 Seguridad en JBoss................................................................................................ 81

9.4 Ejercicios de seguridad de aplicaciones en JBoss..................................................89


2Copyright © 2009-2010 Depto. CCIA All rights reserved.

1. Introducción a los servidores de aplicaciones y a Glassfish

1.1. ¿Qué es un servidor de aplicaciones?

Un servidor de aplicaciones Java EE es una plataforma que da soporte a los serviciosdefinidos en la especificación, desde aplicaciones web con servlets y JSP, hastaaplicaciones distribuidas con soporte transaccional utilizando Enterprise JavaBeans (EJB)o servicios web.

Hasta ahora hemos estado trabajando con Apache Tomcat. ¿Es un servidor deaplicaciones? Sólo en parte, porque no implementa completamente el estándar Java EE.Hemos visto que sólo implementa un contenedor Web en el que se pueden instalarservlets y páginas JSP. Pero no implementa toda la parte de procesamiento transaccionaldistribuido definido por el contenedor de EJBs.

La siguiente figura muestra los distintos componentes del servidor de aplicacionesGlassfish.

Arquitectura J2EE.

La primera capa de la figura define los dos contenedores más importantes definidos en unservidor de aplicaciones. El contenedor web que gestiona el ciclo de vida de servlets y elcontenedor EJB que gestiona el ciclo de vida de los beans de negocio. El primero se basaen el servidor web Apache Tomcat y el segundo en una tecnología ORB (Object RequestBroker), una tecnología que permite realizar llamadas distribuidas entre objetos Java. Unadiferencia fundamental en ambos casos es el protocolo utilizado por ambas tecnologías.El servidor web permite comunicación distribuida entre los clientes y el servidorutilizando un protocolo HTTP o HTTPs. El ORB que soporta la tecnología EJB utiliza los



protocolos IIOP y IIOP/SSL (IIOP con comunicación segura SSL) que permiten serializarobjetos Java y gestionar llamadas síncronas a objetos remotos.

Bajo esta capa aparece en la figura una tercera capa que muestra servicios proporcionadospor el servidor de aplicaciones. Estos servicios son accesibles tanto desde el servidor webcomo desde el contenedor EJB. Iremos conociendo algunos de estos servicios conformeavancemos en los distintos módulos de esta segunda parte del especialista.

• Servicio de nombres: un servicio de nombres liga (binds) objetos java a nombreslógicos. Estos nombres pueden ser utilizados por las aplicaciones para obtener accesoa los objetos. El servicio que permite realizar este proceso se denomina JNDI (JavaNaming and Directory Interface).

• Seguridad: La tecnología de seguridad definida por el estándar Java EE es ladenominada JACC (Java Authorization Contract for Containers). Dependiendo de laidentidad del cliente, se permite el acceso a los distintos recursos de los contenedoresy de los servicios.

• Gestión de transacciones: el servicio JTA (Java Transaction API) da soporte a lautilización de transacciones distribuidas que pueden englobar distintas bases de datosgestionadas por distintos servidores de aplicaciones.

Junto con estos servicios, el servidor de aplicaciones proporciona tecnologías quepermiten el acceso a un conjunto de recursos externos:

• JDBC: proporciona acceso a bases de datos relacionales SQL. El servidor deaplicaciones Glassfish incluye por defecto la base de datos Java DB (Derby).

• Mensajes: la tecnología JMS permite la comunicación asíncrona entre aplicaciones yobjetos Java.

• Conectores: la tecnología de conectores permite la integración entre aplicacionesJava y aplicaciones EIS (Enterprise Information System) ya existentes. Una aplicaciónJava accede a un EIS mediante un componente portable llamado conector o adaptadorde recurso (resource adapter).

• JavaMail: con el API JavaMail las aplicaciones pueden conectarse con un servidorSMTP para enviar y recibir correo.

• Administración del servidor: La parte inferior derecha de la figura muestra unconjunto de tareas realizadas por el administrador del servidor de aplicaciones. Elservidor de aplicaciones proporciona herramientas que permiten la realización deestas tareas.

Frente a la tradicional estructura en dos capas de un servidor web (ver siguiente figura) unservidor de aplicaciones proporciona una estructura en tres capas que permite estructurarnuestro sistema de forma más eficiente. Un concepto que debe quedar claro desde elprincipio es que no todas las aplicaciones de empresa necesitan un servidor deaplicaciones para funcionar. Una pequeña aplicación que acceda a una base de datos nomuy compleja y que no sea distribuida probablemente no necesitará un servidor deaplicaciones, tan solo con un servidor web (usando servlets y jsp) sea suficiente.



Arquitectura en dos capas frente a tres capas utilizando el servidor de aplicaciones.

Como hemos comentado, un servidor de aplicaciones es una implementación de laespecificación J2EE. Existen diversas implementaciones, cada una con sus propiascaracterísticas que la pueden hacer más atractiva en el desarrollo de un determinadosistema. Algunas de las implementaciones más utilizadas son las siguientes:

• BEA WebLogic (Oracle)• JBoss (RedHat)• Glassfish (Sun)• Websphere (IBM)

Se puede consultar en esta página de la wikipedia una lista completa de servidores deaplicaciones compatibles con Java EE.

Nosotros vamos a utilizar el servidor Glassfish de Sun. La principal ventaja de Glassfishes que proporciona la implementación de referencia de la especificación Java EE. Se tratatambién de un servidor de aplicaciones rápido, ligero y fácil de administrar. Es tambiénmultiplataforma, pudiéndose instalar en Linux, Windows o Mac Os X.

Otros conceptos que aparecerán a lo largo de este módulo:

• Servidor proxy: Centraliza peticiones de los clientes y las reenvía hacia otrasmáquinas. Puede servir como nivel de indirección y seguridad. También puede serusado para realizar balanceo de carga.

• Cortafuegos (firewall): Proporciona servicios de filtrado, autorización yautentificación. Puede actuar como proxy y ayuda a manejar los ataques de loshackers.

• Máquina: Representa una unidad física donde reside un servidor. Una máquina sedefine como tipo Unix o no Unix (Windows NT, etc.).

• Servidor: Un servidor es una instancia de la clase Server ejecutándose dentro de una



http://en.wikipedia.org/wiki/Comparison_of_application_servers#Java_EE

máquina virtual de Java. Un servidor está alojado en una máquina, pero una máquinapuede contener varios servidores.

• Dominio: Un dominio es una unidad administrativa. Sirve para declarar variosservidores, aplicaciones, etc. y que todos ellos estén asociados mediante el nombre deldominio.

• Clustering (asociación): Los clusters permiten asociar maquinas y servidores paraque actúen de forma conjunta como una única instancia. La creación de un cluster vaa permitir el balanceo de carga y la recuperación frente a fallos.

• Balanceo de carga: Es una técnica utilizada para distribuir las peticiones entre variosservidores de tal forma que todos los servidores respondan al mismo número depeticiones.

• Recuperación ante fallos (failover): Permite evitar la caída de un sistema cuando unamáquina deja de funcionar o funciona incorrectamente.

• Puerto de escucha: Un servidor tiene varios puertos por los que puede "escuchar" laspeticiones. Existen puertos ya asignados a aplicaciones concretas, como por ejemploel puerto de http que suele ser el 80. Los puertos permiten que varias aplicacionespuedan atender distintas peticiones en la misma máquina. Un puerto en una direcciónse especifica de la siguiente manera: http://localhost:7001/direc . Con :7001indicamos el puerto que estamos atacando. Los puertos del 0 al 1023 son reservadospor el sistema. Podemos disponer de los puertos del 1024 al 65536. Hay que tener encuenta que dos servicios no pueden estar escuchando en el mismo puerto.

1.2. Características de Glassfish

Glassfish es el servidor de aplicaciones de Sun y está preparado para trabajar con Java EE5. El Sun Application Server 9.1 es exactamente igual al Glassfish v2, salvo que esteúltimo es software libre. Algunas de las tecnologías que incorpora son: EJB 3.0, JavaPersistence, JSF 1.2, JSP 2.1, JSTL 1.2, Java Servlet 2.5., soporte de replicación enmemoria, balanceo de carga, soporte para cluster, etc. Incorpora una BD propia llamada



Derby.

Los requerimientos necesarios para hacer funcionar Glassfish son:

• Memoria: 1Gb• Espacio en disco: 500MB

GlassFish proporciona una completa consola de administración (aplicación web) desde laque controlar y configurar el servidor de aplicaciones. La siguiente imagen muestra todaslas opciones disponibles:

A lo largo de este módulo iremos estudiando distintas funcionalidades de esta consola deadministración.

1.3. Dominios

Un dominio define un conjunto de propiedades, recursos e instancias de servidores deaplicaciones. La definición de dominios permite flexibilizar y organizar la instalación deservidores de aplicaciones, ya que es posible asignar distintos dominios dentro de unmismo host a distintas organizaciones y administradores. Las aplicaciones y recursosinstaladas en un dominio son independientes de los otros dominios. Para permitir que



distintos dominios puedan estar en marcha al mismo tiempo, cada dominio utilizadistintos puertos de servicio y administración.

El instalador de Glassfish crea un dominio por defecto llamado domain1 y en él crea unservidor llamado server. Veremos en la siguiente sesión que un dominio puede definirmás de un servidor. El puerto en el que escucha el servidor de administración del dominiopor defecto es el 4848.

Cuando se crea un dominio y se pone en marcha, se inicializa el Domain AdministrationServer (DAS) del dominio, una aplicación que está a la escucha y que permite configuralas características del dominio. La consola de administración se comunica con el DASpara enviarle peticiones. El DAS se comunica con los servidores del dominio para querealicen las peticiones. En la documentación de Sun, a veces se refieren al DAS como elservidor de administración o el servidor por defecto. El DAS es simplemente unainstancia de servidor con capacidades adicionales de administración. Cada sesión de laconsola de administración nos permite configurar y gestionar un único dominio.

Toda la configuración del dominio se guarda en el fichero domain.xml situado en eldirectorio domains/_dominio_/config. En el fichero se encuentran todos los detallessobre los distintos elementos definidos en el dominio (como servidores, agentes de nodo,aplicaciones desplegadas, recursos, servicios, etc.) así como características de laconfiguración básica (puertos y hosts en los que se ejecutan los distintos servicios,ficheros de contraseñas, etc.)

Por último, la definición de dominios nos da la posibilidad de realizar copias de seguridady de mover instalaciones de un host a otro. Para que funcionen correctamente las copiasde seguridad el servidor de aplicaciones debe estar instalado exactamente en la mismaruta en ambas máquinas.

1.3.1. Comandos

El comando para crear un dominio es asadmin create-domain. Por ejemplo:

• $ asadmin create-domain --adminport 5000 dominio2: crea un dominio conperfil de desarrollador con el nombre dominio2 administrado en el puerto 5000.

• $ asadmin crate-domain --adminport 5000 --profile cluster

cluster-domain: crea un dominio llamado cluster-domain con perfil de cluster yadministrado en el puerto 5000.

En ambos comando el script solicitará el login de administrador y la contraseña paraacceder posteriormente a la consola de administración del dominio.

El comando para borrar un dominio es asadmin delete-domain nombre-dominio. Eldominio no debe tener ningún servidor en marcha. Por ejemplo:

$ asadmin delete-domain domain1

Para hacer una copia de seguridad del dominio se utiliza el comando asadmin



backup-domain dominio. Por ejemplo:

$ asadmin backup-domain domain1

El comando crea un fichero ZIP que contiene toda la información del dominio en eldirectorio domain1/backups.

Podemos restaurar el dominio con el comando asadmin restore-domain dominio. Elfichero de backup debe encontrarse en el directorio backups del dominio. Por ejemplo:

$ asadmin retore-domain domain1

También es posible restaurar un dominio que se ha borrado completamente del directoriode dominios (o copiar un dominio en otra instalación del servidor de aplicaciones). Paraello hay que indicar el fichero ZIP con el domino comprimido y el nombre del dominio.Supongamos que hemos copiado en el escritorio el fichero de backup del dominio y quehemos borrado completamente el dominio del directorio de dominios. Se restauraría conla instrucción:

$ asadmin restore-domain --filename~/Escritorio/sjsas_backup_v00001.zip domain1

Nota:Para más detalles sobre parámetros adicionales de los comandos, consultar el manual dereferencia del servidor de aplicaciones Sun.

1.4. Despliegue de aplicaciones web

Existen básicamente dos formas de desplegar una aplicación web en un dominio,desplegando directamente en un directorio o bien mediante la consola de administración.En ambos casos es necesario tener la aplicación empaquetada en un fichero WAR.

1.4.1. Despliegue en un directorio

Basta copiar el fichero WAR de la aplicación a desplegar en el directorio autodeploy deldominio. El servidor detecta la aplicación (hay que esperar un poco) y la pone en marcha.Cuando haga esto veremos que se ha creado en el directorio el ficheroapplication.war_deployed.

1.4.2. Consola de administración

Para instalar una aplicación desde la consola de administración del dominio hay queseleccionar la opción Web Applications y escoger la opción Implementar... (la traduccióna castellano de Deploy). Tenemos dos formas de indicar la aplicación, o indicando unaruta accesible desde el servidor en la que se encuentra la aplicación o proporcionándoleun fichero WAR que se copia en el servidor.



http://docs.sun.com/app/docs/doc/820-4046


En el primer caso el servidor trabaja directamente con el fichero (lo que es interesante siestamos en modo de desarrollo, probando y cambiando funcionalidades) y en el segundocopia el fichero al directorio del dominio donde se encuentran las aplicaciones instaladas.En la misma pantalla de despliegue de aplicaciones web aparece la información de la rutafinal en la que queda instalada la aplicación.

1.4.3. Archivos EAR: empaquetamiento de aplicaciones enterprise

Hasta ahora hemos utilizado dos tipos de ficheros para empaquetar aplicaciones Java:ficheros JAR y ficheros WAR. Vamos a repasar algunos conceptos fundamentales, antesde explicar el nuevo tipo de fichero que introduciremos en esta sesión, el fichero EAR.

Los ficheros JAR empaquetan clases Java. Un fichero JAR contiene clases Javacompiladas (ficheros .class) junto con un descriptor de la aplicación.

Cuando un fichero JAR se añade al claspath de una JVM (Máquina Virtual Java) lasclases incluidas en él se ponen a disposición de cualquier aplicación Java que ejecute laJVM. De la misma forma, cuando un fichero JAR se define en el classpath del



compilador Java, las clases incluidas en él pueden utilizarse en las clases que estamoscompilando.

Una idea fundamental relacionada con el empaquetamiento de clases es que el compiladorJava y la máquina virtual Java tienen distintos classpath, esto es, buscan las clasesauxiliares en distintos directorios. Cuando estamos desarrollando una aplicación con unIDE, debemos decirle al IDE (que a su vez se lo dice a su compilador Java) dónde seencuentran los ficheros JAR con las clases auxiliares que estamos utilizando. Porejemplo, si nuestra aplicación utiliza log4j debemos indicarle al IDE que las clases delAPI se encuentran, por ejemplo, en el fichero log4j-1.2.13.jar (e indicar su path). Asu vez, cuando ejecutamos la aplicación, la JVM debe contener en su classpath un ficheroque contenga esas clases. Podría ser incluso un fichero distinto, por ejemplolog4j-1.2.15.jar. Lo único necesario es que contenga las mismas clases (mismosnombres e interfaces) que las usadas en la compilación.

Las aplicaciones web empaquetadas en ficheros WAR son aun más complicadas. Unaaplicación web debe desplegarse en un contenedor que está siendo ejecutado por unaJVM. Parece el juego de las muñecas chinas. ¿Qué sucede aquí con los classpath?.¿Cómo indicar dónde se encuentran el API log4j, por ejemplo? Ya lo sabemos. Lo máshabitual es incluir el fichero JAR en el directorio WEB-INF/lib del fichero WAR. Elestándar de Java que define el comportamiento de los ficheros WAR indica que esedirectorio se incluirá en el classpath del contenedor para las clases de la aplicación webdesplegada. Esto es, basta con incluir en ese directorio todas las librerías que usa nuestraaplicación web para que estén disponibles en tiempo de ejecución (y también en tiempode compilación, ya que el IDE también lo reconoce). ¿Existen otras opciones? ¿Quésucede si queremos desplegar más de una aplicación web en el contenedor y todas utilizanlas mismas librerías? ¿Debemos incluir estas librerías de forma repetida en todos losWAR? La respuesta es que no. Hay dos formas de evitarlo.

Una posible opción para que distintas aplicaciones web (cada una desplegada en unWAR) puedan usar las mismas clases auxiliares es instalar el fichero JAR con las clasesen el propio servidor web (en un path definido por el servidor). Los contenedores websuelen tener un directorio estándar en el que colocar ficheros JAR, y suelen revisar deforma dinámica ese directorio y poner todos sus JAR en el classpath de las aplicacionesweb que tienen desplegadas. De esta forma, por ejemplo, colocando en ese directorio elfichero log4j-1.2.15.jar cualquier aplicación web puede usar el API sin estar incluidoen su fichero WAR.



La otra opción nos lleva directamente a los fichero EAR. Los ficheros EAR (EnterpriseArchive) son la forma estándar de empaquetar en un único fichero distintas aplicacionesweb (ficheros WAR) y distintos ficheros JAR con clases Java. Los ficheros JAR que seincluyan en el EAR se ponen a disposición de cualquier aplicación WAR incluida en elEAR. Esto es, cuando un fichero EAR con un conjunto de ficheros JAR y ficheros WARse despliega en el servidor web (o servidor de aplicaciones) todos sus JAR se incluyen deforma automática en el classpath de cada WAR. De esta forma, siguiendo con el ejemploanterior, incluyendo en el EAR el fichero log4j-1.2.15.jar, cualquier aplicación WARincluida en el EAR puede usar el API log4j sin tener que contener el fichero físicamenteen su directorio WEB-INF/lib. Un fichero EAR representa una aplicación enterpriseformada por distintos módulos (aplicaciones web y ficheros JAR). Los ficheros JARpueden ser Enterprise JavaBeans (EJB) usados por las aplicaciones web. Tambiénpueden ser aplicaciones cliente que usan los EJB desplegados en el EAR y que seejecutan en un contenedor de aplicaciones clientes en máquinas cliente. Veremos másadelante estos módulos.

Físicamente, un fichero EAR es un fichero comprimido con el mismo formato que losficheros JAR. Todos los comandos que se pueden utilizar con los ficheros JAR (jar-tvf mi-fichero.jar, etc.) sirven para los ficheros EAR. Los ficheros EAR llevan laextensión .ear. La estructura de un fichero EAR es muy sencilla, contiene un conjunto deficheros WAR, un conjunto de ficheros JAR y el directorio META-INF, en el que seencuentra los distintos ficheros de configuración necesarios. Como mínimo debe contenerel descriptor de despliegue application.xml en el que se identifican los módulos que seincluyen en él.

1.5. Referencias

• Documentos de referencia de GlassFish 2.1• GlassFish 2.1 Quick Start Guide• GlassFish 2.1 Administration Guide• GlassFish 2.1 Reference Manual



http://docs.sun.com/app/docs/coll/1343.6




2. Ejercicios de instalación y administración de GlassFish

2.1. Instalación de Glassfifsh+NetBeans

Vamos a trabajar con la versión 6.5 de NetBeans, que incluye el servidor de aplicacionesGlassfish V2. Existe una versión más reciente tanto del entorno de desarrollo como delservidor de aplicaciones, pero todavía se encuentra en versión beta.

1. En primer lugar debemos descargar el servidor de aplicaciones desde la página desoftware del especialista o desde la web de NetBeans. En el caso de utilizar esta últimaURL, debemos pinchar el enlace 'Archivo' en la esquina superior derecha y seleccionar laversión 6.5.1. Debemos descargar la versión 'All' que ocupa 238 MB. Se descargará en elescritorio el fichero netbeans-6.5-ml-java-linux.sh

2. Una vez descargado el fichero abrimos una terminal y lo ejecutamos:

$ cd Escritorio$ chmmod +x netbeans-6.5-ml-java-linux.sh$ ./netbeans-6.5-ml-java-linux.sh

3. El script examinará el sistema buscando el entorno de ejecución Java y lanzará unaaplicación de instalación con la que podremos configurar determinadas características.

En primer lugar seleccionamos la opción 'Customize...' para configurar los componentesque vamos a instalar. Ahorramos algo de espacio si quitamos la selección de 'GlassfishV3 Prelude' y de 'Java ME'. No vamos a utilizar estos módulos.

Aceptamos el directorio de instalación de NetBeans por defecto:



http://www.jtech.ua.es/j2ee/restringido/software.html

http://www.jtech.ua.es/j2ee/restringido/software.html

http://www.netbeans.org/downloads/index.html

Y aceptamos las características de la instalación de Glassfish:

• Directorio de instalación: /home/especialista/glassfish-v2.1• Login de administrador: admin• Contraseña de administrador: admin• Puerto de servicio de HTTP: 8080• Puerto de servicio de HTTPS: 8181• Puerto de la consola de administración: 4848

Continuamos aceptando todas las opciones hasta el final. Antes de terminar la instalaciónaparece un formulario para enviar a Sun un registro de las aplicaciones instaladas. Puedescancelarlo, o rellenar los datos si te interesa realizar el registro.

4. Para comprobar que la instalación ha sido correcta lanza Netbeans haciendo un dobleclick en el icono que se ha creado en el escritorio o ejecutando .netbeans en el directorio~/netbeans-6.5/bin/netbeans.

Es posible lanzar el servidor Glassfish desde Netbeans. Pulsamos en la pestaña 'Services'y desplegamos 'Servers' para ver los servidores registrados en NetBeans. Por defectoestará el que acabamos de instalar, 'Glassfish V2'. Para ponerlo en marcha, pulsamos elbotón derecho sobre él y seleccionamos la opción 'Start':



Probamos que se puede acceder a la consola de administracción, pulsando con el botónderecho la opción 'View Admin Console'. Esto abrirá en el navegador la direcciónhttp://localhost:4848 en la que se accede al administrador. Entramos con el login admin yla contraseña adminadmin.

Podemos comprobar que se ha puesto en marcha el dominio por defecto 'domain1' que seha configura en la instalación:

5. Vamos ahora a arrancar el servidor de aplicaciones desde la línea de comandos.Detenemos el servidor pulsando la opción 'Stop' en el menún contextual del servidor en laventana de Netbeans. Ejecutamos los comandos desde un terminal:

$ cd /home/especialista/glassfish-v2.1/bin$ ./asadmin start-domain domain1

Probamos a conectarnos de nuevo con la consola de administración; debe funcionar igualque antes. Comprobamos también que en el IDE no se refleja correctamente el estado del



servidor de aplicaciones. Al haberlo arrancado desde fuera del entorno, NetBeans no seda cuenta de que se encuentra arrancado.

Por último, detenemos glassfish con la instrucción:

./asadmin stop-domain domain1

2.2. Desplegando la primera aplicación web

Vamos a crear una primera aplicación web en NetBeans y a desplegarla en el servidor deaplicaciones. Vamos a probar distintas formas de desplegar la aplicación.

1. En primer lugar, creamos una aplicación web ejemplo. En NetBeans pulsamos lapestaña 'Projects' y pulsamos con el botón derecho en el panel y escogemos la opción'New Project...'. También podemos realizar la misma acción con el menú 'File > NewProject...'.

Escoge la opción 'Samples > Java Web > Servlet Examples':

Acepta las opciones por defecto para el nombre y la localización del proyecto y apareceráel proyecto en el panel de projectos. Pulsa la opción 'Build' en el menú contextual delproyecto.

2. Vamos a comprobar las dos vistas del proyecto, la que nos ofrece el panel 'Projects' y ladel panel 'Files'.

En el panel de projectos tenemos una visión lógica del proyecto web: las páginas web,



los ficheros de configuración, los recursos del servidor (vacío), los paquetes de fuentesque contienen el código fuente del proyecto y las librerías que contienen los ficheros Jarutilizados en el proyecto.

En el panel de ficheros, tenemos la visión física de los ficheros que forman parte delproyecto web. Vemos que es bastante distinta a la que estábamos acostumbrados conEclipse.

• Carpeta 'build': aquí se guarda la versión compilada del proyecto con la estructuraestándar de una aplicación web.

• Carpeta 'dist': fichero War con toda la aplicación web, listo para desplegarse en elservidor de aplicaciones.

• Carpeta 'nbproject': carpeta de netbeans con los ficheros ant del proyecto y otrosficheros de configuración (dependencias entre proyectos, librerías, etc.).

• Carpeta 'src': paquetes Java con el código fuente del proyecto.• Carpeta 'web': páginas HTML y JSP del proyecto y ficheros de configuración del

proyecto web (WEB-INF/web.xml y WEB-INF/sun-web.xml)

Exploramos las distintas carpetas para comprobar qué tipo de ficheros hay en cada una.

3. Vamos a desplegar y ejecutar la aplicación web desde NetBeans. Para ello activamos elpanel de proyectos y pulsamos la opción 'Run' sobre el menú contextual del proyecto'ServletExamples'. En el panel inferior vemos que aparece una pestaña 'ServletExamples(run)' en la que se muestra la salida de la tarea Ant que realiza el despliegue en el servidorque tenemos en marcha. Una vez compilado, el proyecto se despliega en el servidor deaplicaciones y se lanza un navegador con su página principal.

4. Comprobamos en el panel de servicios que el proyecto se encuentra desplegado en elservidor:

Con el botón derecho podríamos eliminarlo (undeploy) del servidor. Pero vamos a hacerlodesde la consola de administración.

5. Abrimos con el navegador la dirección http://localhost:4848 y nos autentificamoscomo usuario administrador. Pinchamos en el panel izquierdo la opción 'AplicacionesWeb' y aparecerá la aplicación la lista de aplicaciones web desplegadas en el panelprincipal. En este caso sólo será ServletExamples:



Seleccionamos la aplicación y pulsamos en el botón 'Anular implementación' (nota: lapalabra 'implementación' de la versión en castellano significa 'deployment'). Se elimina laaplicación del servidor. En el IDE, debemos pulsar el botón derecho sobre el servidor yseleccionar la opción para refrescar su estado. Veremos que también desaparece laaplicación.

2.3. Desplegando la aplicación sin NetBeans

Vamos a ver cómo desplegar aplicaciones web directamente en el servidor deaplicaciones, sin utilizar NetBeans. Debemos tener el fichero WAR con la aplicación webempaquetada correctamente.

1. Generamos el fichero WAR de la aplicación en NetBeans. Para ello, compilamos laaplicación web escogiendo 'Build' con el botón derecho. Otra forma de generar el ficheroWAR es activando la pestaña de ficheros y haciendo un doble click en el fichero antbuild.xml. En el panel inferior izquierdo aparecerá la lista de tareas ant disponibles en elproyect:

Pulsamos con el botón derecho sobre la tarea 'dist' y seleccionamos la opción 'RunTarget'.

2. Con cualquiera de estas dos acciones, la aplicación web se compila y se empaqueta enun fichero WAR en el directorio dist. En este caso la aplicación se llamaTomcatServletExample.war. Copia este fichero al escritorio. Los proyectos deNetBeans se encuentran en el directorio /home/especialista/NetBeansProjects.Copiamos el fichero war en el escritorio:

$ cd ~/Escritorio



$ cp~/NetBeansProjects/ServletExamples/dist/TomcatServletExample.war .

Existen dos formas de desplegar el fichero WAR en el servidor Glassfish, utilizando laconsola de administración o copiándolo al directorio de despliegue del dominio. Vamos aempezar por esta última forma.

2.3.1. Despliegue en el directorio autodeploy

3. Una forma de desplegar la aplicación es copiando el fichero WAR en el directorioautodeploy del dominio:

$ cd /home/especialista/glassfish-v2.1/domains/domain1/autodeploy$ cp /home/especialista/Escritorio/TomcatServletExample.war .

Al cabo de unos instantes aparecerá un fichero terminando en '_deployed', que indicaráque la aplicación ha sido desplegada. Lo podemos comprobar accediendo a la aplicacióncon el navegador (http://localhost:8080/servlets-examples/) o consultándolo enla consola de administración.

Entramos en la consola de administración y eliminamos la aplicación, para poderdesplegarla de la otra forma.

2.3.2. Despliegue de la aplicación con la consola de administración

4. En la consola de administración, selecciona en el panel izquierdo la opción'Aplicaciones > Aplicaciones Web' y pulsa en el panel principal derecho el botón'Implementar...' (que es la traducción del término inglés 'Deploy...'). Indicamos la rutadonde se encuentra el fichero WAR que glassfish copiará y cargará en el servidor.

Borra la ruta del contexto raíz para que Glassfish utilice la definida en el ficherosun-web.xml (/servlets-examples). Acepta los cambios y prueba que la aplicaciónestá en marcha.



La aplicación se habrá desplegado en el directorio~/glassfish-v2.1/domains/domain1/applications/j2ee-modules/.

Otra forma de desplegar la aplicación desde la consola de administración sería indicandoun directorio del disco duro accesible desde glassfish. En este caso el servidor no copia elfichero WAR a su directorio local, sino que utiliza el propio directorio indicado.

5. Una vez que hemos comprobado que la aplicación está funcionando correctamentevamos a cambiar la ruta del contexto raíz. Pulsa en el enlace con la aplicación en el panelprincipal para que aparezca una pantalla con la descripción de la aplicación web:

Modificamos la ruta, escribiendo por ejemplo servlets. Guardamos y probamos con elnavegador que (pasados unos instantes) la aplicación responde en la nueva ruta.

2.4. Empaquetando una aplicación EAR

Aviso:Vamos a utilizar como nombres de las aplicaciones que vamos a crear en este apartado lossiguientes: sapp-ear1, sapp-calculadora, sapp-web1 y sapp-web2 para continuar con el convenioutilizado hasta ahora y organizar correctamente el repositorio CVS.

Vamos a construir una sencilla aplicación EAR para demostrar las posibilidades de estetipo de configuraciones. Hasta ahora, los ficheros WAR nos permitían empaquetar unaaplicación web y un conjunto de ficheros JAR utilizados en la aplicación. Los ficherosJAR deben estar en el directorio WEB-INF/lib de la aplicación.

El problema de este enfoque es que la instalación de más de una aplicación en un mismoservidor de aplicaciones obliga a multiplicar las instalaciones de librerías en las distintasaplicaciones web. Cuando distintas aplicaciones utilizan las mismas librerías repetidas(por ejemplo, log4java o las apache commons), es necesario colocarlas en todas lasaplicaciones.



Los ficheros EAR solucionan este problema, ya que permiten empaquetar en un mismofichero un distintas aplicaciones web (ficheros WAR) y distintos ficheros JAR accesiblesdesde cualquier aplicación web. Veamos paso a paso cómo configurarlo en Netbeans.

1. Comenzamos creando un proyecto nuevo de tipo 'Java EE > Enterprise Application'.Le damos como nombre 'Ear1', lo asociamos al servidor 'GlassFish V2' y desactivamos lacreación por defecto de los módulos adicionales. Los crearemos de forma independiente ylos asociaremos a la aplicación enterprise.

2. Creamos la librería JAR y la incorporamos a la aplicación enterprise. Para ello creamosun proyecto nuevo de tipo 'Java > Java Class Library'. Le damos como nombre'calculadora'. Definimos una clase llamada Calculadora en el paquete es.ua.jtech enla que se definen dos funciones estáticas: suma y multiplica. El código fuente es elsiguiente:

package es.ua.jtech;

public class Calculadora {public static int suma(int a, int b) {

return a+b;}public static int multiplica(int a, int b) {

return a*b;}

}

Para generar el JAR pulsamos con el botón derecho en la opción 'Build' y el proyecto se



compila y se crea el fichero dist/calculadora.jar. Para añadir este fichero JAR alEAR, primero pulsamos con el botón derecho en el EAR y escogemos 'Properties >Libraries > Add Project' y seleccionamos calculadora. De esta forma estamosrelacionando ambos proyectos. Pero todavía no hemos configurado el fichero JAR paraque sea incluido en el EAR. Para ello, entramos en la opción 'Packaging' de la opción'Properties' del proyecto enterprise y pulsamos 'Add Project' y seleccionamos 'calculadora'para incluir el fichero 'dist/calculadora.jar' en el EAR.

3. Creamos un nuevo proyecto de tipo 'Java Web > Web Application' y le ponemos comonombre 'web1'. En la ventana de creación podemos ya incluirlo en el EAR 'Ear1'. Loasociamos al servidor 'GlassFish V2'. Para añadir la librería a su classpath y podercompilarlo correctamente debemos pulsar con el botón derecho sobre el proyecto yseleccionar 'Properties'. Escogemos la opción 'Libraries > Add Project...' y seleccionamos'calculadora'. Desactivamos la opción 'Package' para que no empaquete la librería en elproyecto web, ya que va a estar en el proyecto EAR:



4. Creamos un servlet llamado Suma en el paquete es.ua.jtech.servlet que incluya elsiguiente código en el que se llama a la librería creada:

out.println("<h2> 2+2 = " + Calculadora.suma(3,3) + "</h2>");out.println("</body>");

5. Compilamos el EAR y comprobamos el contenido del paquete con el navegador dearchivos de Ubuntu. Vemos que, efectivamente, contiene el JAR con la claseCalculadora y el WAR con la aplicación web:



Comprobamos en el servidor que el EAR se ha desplegado correctamente junto con laaplicación Web:

6. Desplegamos en el servidor pulsando el botón derecho sobre el EAR y seleccionado'Deploy' y ejecutamos el servlet en http://localhost:8080/web1/Suma y comprobamos quefunciona correctamente.



7. Hacemos lo mismo con una nueva aplicación ('web2') definiendo un servlet llamadoMultiplica. Comprobamos que puede acceder a la misma librería JAR en el EAR y quefunciona correctamente:

Para comprobar que la librería calculadora.jar está en el EAR y no en ninguno de losWAR, podemos explorar en la pestaña 'Files' la estructura del directorio build del EAR.

2.5. CVS

1. Botón derecho sobre el EAR y seleccionar 'Versioning > Import into CVSRepository...'. Escribimos los datos del repositorio CVS (los mismos que en Eclipse):

:ext:[email protected]:/opt/usr/local/cvs-especialista/domingo

Escribimos la contraseña y aceptamos. Aparece una ventana en la que debemos escribir elmensaje de commit y subimos la aplicación. Se suben sólo los directorios que estánfísicamente en el proyecto. En este caso, el código fuente de los servlets no se subiría,porque se encuentran en directorios que no están bajo el directorio ear. Una importantediferencia con Eclipse es que no hay ninguna indicación visual de que los proyectos seencuentran conectados a un repositorio CVS.

2.6. Backup del dominio

Terminamos haciendo una copia de seguridad del dominio.

1. Detener el dominio. En la línea de comandos, en el directorio glassfish-v2.1/bin

escribir el comando:

$ ./asadmin stop-domain domain1

2. Hacer una copia de seguridad del dominio con el comando:

$ ./asadmin backup-domain domain1

La copia de seguridad se encuentra en el directorio domains/domain1/backups y sellama sjsas_backup_v00001.zip. Vamos a probar a restaurarla.

3. Muevemos la copia de seguridad al escritorio:



$ mv ../domains/domain1/backups/sjsas*01.zip ~/Escritorio

4. Borramos el dominio y nos aseguramos que se ha eliminado el directorio completo:

$ ./asadmin delete-domain domain1$ ls ../domains/

5. Por último, restauramos el dominio y lo volvemos a arrancar:

$ ./asadmin restore-domain --filename~/Escritorio/sjsas_backup_v00001.zip domain1$ ./asadmin start-domain domain1

2.7. Entrega

Crea la carpeta entrega-usuario y guarda allí el backup del dominio.



3. Clustering con GlassFish

3.1. Conceptos básicos

En la sesión pasada hemos visto el concepto de dominio. Un dominio es una unidadadministrativa en la que podemos configurar distintas instancias de servidoresgestionados por agentes de nodo. Estas instancias de servidores se pueden agrupar enclusters. Vamos a ver cómo implementa GlassFish estos conceptos.

3.1.1. Domain Administration Server (DAS)

Antes de hablar de servidores, nodos y clusters debemos dejar claro el concepto de DAS(Domain Administration Server). Cuando se crea un dominio se crea por defecto unainstancia de servidor en el que se van a poder desplegar aplicaciones y que va a estar enfuncionamiento para administrar los servicios del dominio. La consola de administraciónse conecta con ese servidor y le envía las peticiones del administrador. Podemosconsiderar el DAS como una instancia de servidor con capacidades adicionales deadministración (crear otras instancias de servidores, clusters, etc.).

Cada nuevo dominio creado tiene su propio servidor de administración de dominio, al quese le asigna un puerto de acceso distinto para conectarse desde la consola deadministración.

3.1.2. Perfiles

El servidor de aplicaciones Glassfish define tres posibles perfiles de dominio. Cada perfiltiene distintas capacidades. Por ejemplo, el perfil de desarrollo no permite definir clusters.El perfil por defecto (si no indicamos nada) es el de desarrollo.

Los perfiles son los siguientes:

• Desarrollador: Se trata del perfil con capacidades más bajas. No incluye capacidadesdefinición de múltiples instancias de servidor, agente de nodo, clustering o balanceode carga. Se utiliza habitualmente como dominio de desarrollo en el que probar laaplicación antes de desplegarla.

• Cluster: Perfil usado para crear clusters con distintos servidores y balanceo de carga.No da contiene las características de bases de datos de alta disponibilidad (HADB) ola configuración de seguridad avanzada con un keystore NSS.

• Enterprise: Perfil que contiene todas las capacidades anteriores junto con la base de



datos de alta disponibilidad (HADB) y el keystore NSS. Estas capacidades debeninstalarse aparte.

3.1.3. Instancia de servidor

Una instancia de servidor es una instancia de una Máquina Virtual Java que contiene unservidor de aplicaciones compatible Java EE. Un dominio puede contener más de unainstancia de servidor, cada una con un nombre único. Las instancias de servidor contienenaplicaciones, servicios y recursos Java EE.

Cada instancia de servidor (exceptuando la de administración del dominio) es gestionadapor un agente de nodo (node agent) administrado por el dominio.

La siguiente figura muestra los elementos que constituyen una instancia de servidor ycómo son gestionados por el servidor de administración:

3.1.4. Agente de nodo

Asociado a cada instancia de servidor distinta del DAS hay que definir un agente de nodo



(node agent) que es un proceso nativo del sistema operativo que controla el ciclo de vidade la instancia. Su propósito principal es lanzar y parar la instancia de servidor a peticióndel DAS.

Un agente de nodo debe ser asociado a un dominio (que puede estar en otro host) cuyoDAS será el encargado de controlarlo. Por ejemplo, si queremos que un dominio en elhost1 pueda lanzar servidores en las máquinas host2 y host3 debemos crear un agente denodo en cada una de esas máquinas y conectarlos con la primera máquina.

El comando de glassfish para crear agentes de nodo es: asadmin create-node-agent --host<host-que-controla-el-nodo> --port <puerto-host-controlador> <nombre-nodo>.

3.1.5. Cluster

Un cluster es una colección de instancias de servidor que comparten el mismo conjuntode aplicaciones, recursos y configuración. Un cluster facilita el balanceo de carga entrelas instancias mediante la distribución de las peticiones entre las distintas instanciascontenidas en el cluster. La otra característica de un cluster es que facilita la altadisponibilidad, ya que si cualquiera de los servidores cae, los otros pueden continuarsirviendo recursos, sesiones y peticiones.

La configuración de un cluster implica que todas las instancias de servidores dentro delcluster tengan la misma configuración. Un administrador ve el cluster como una únicaentidad y usa la consola de administración de GlassFish para gestionar las instancias en elcluster.

Es posible añadir nuevas instancias de servidores a un cluster en marcha sin parar elservicio. Esto permite atender a picos de peticiones añadiendo servidores nuevos.Automáticamente las aplicaciones y recursos del cluster se instalan en el nuevo servidor.

La siguiente figura muestra cómo se relacionan el dominio, el administrador del dominio,el cluster y las instancias de servidor (cada una gestionada por un agente de nodo):



Una de las características de los clusters es que es posible configurarlos para replicarincluso las sesiones activas en memoria. Si se configuran de esta forma (denominada altadisponibilidad) la caída de un servidor no invalidaría una sesión en curso, porque otrainstancia de servidor mantendría una copia en memoria de esta sesión. Para conseguir laalta disponibilidad las distintas máquinas del cluster se organizan en forma de anillo, deforma que las sesiones de cada uno de los servidores se replican en el siguiente servidoren el anillo:

3.1.6. Balanceo de carga



Cada instancia de servidor del cluster recibe las peticiones HTTP en su propia direcciónIP. Para que esto sea transparente a los clientes de nuestra aplicación hay que incluir ennuestra arquitectura un balanceador de carga que reciba las peticiones en una dirección IPdeterminada y las distribuya a los distintos componentes del cluster. En las charlas dearquitectura de aplicaciones se han visto distintas configuraciones posibles. Para losclientes es una única máquina la que está respondiendo, pero realmente esa máquina seencarga del balanceo de carga y de la recuperación ante fallos de los servidores.

La siguiente imagen muestra un ejemplo de recuperación ante fallos en GlassFish. En lafigura izquierda el balanceador de carga realiza la petición a una máquina que contieneuna réplica de la sesión. En la figura derecha, la petición se realiza a una máquina que notiene replicada la sesión y ésta realiza una petición a todas las máquinas del cluster parasolicitar la sesión:

El balanceo de carga no está disponible por defecto en GlassFish. Hay que instalarlo deforma manual en un servidor web aparte (Sun Java System Webserver 6.1) (ver blog deArun Gupta).

3.2. Creación de un cluster

Sólo es posible crear un cluster en un dominio creado con el perfil cluster. Para crearlohay que usar la opción --profile cluster.

Si entramos a la consola, veremos que algunas opciones cambian. Por ejemplo, nosaparece Dominio donde antes teníamos Application Server. Los registros ahora se puedenvisualizar por servidor o de todo el cluster.



http://weblogs.java.net/blog/arungupta/archive/2009/02/totd_69_glassfi.html

http://weblogs.java.net/blog/arungupta/archive/2009/02/totd_69_glassfi.html

La información que antes teníamos del servidor, la tenemos un poco más abajo en el árbol(instancias independientes). Podemos ir viendo los datos específicos de ese servidor,como las aplicaciones que tiene desplegadas, sus recursos, su árbol JNDI, etc.

También podemos ir creando más servidores dentro del cluster. Para ello, tenemos quetener instalado el Agent Node. Para arrancarlo, tenemos que realizar los siguientes pasos:

• Crear el Node Agent. Tenemos que tener el dominio funcionando. Ejecutamosasadmin create-node-agent --port puerto nombre-agente

El puerto es el puerto de administración del dominio, y el nombre simplemente espara diferenciarlo de otros. Tenemos que crear un Node Agent por cada máquina en elsistema. Existen otros parámetros, como el nombre del host donde escucha eldominio.

• Arrancar el Node Agent. Ejecutamosasadmin start-node-agent --user usuario nombre-agente

El usuario es el administrador del dominio. Si no da error, podemos entrar en laconsola de administración e ir a la opción Agentes de nodo y ver los que se estánejecutando.



3.2.1. Configuración del cluster

Lo primero que tenemos que hacer es crear el cluster. Pinchamos en la opción Tareascomunes y luego en Crear cluster nuevo.

Le damos nombre al cluster y le indicamos los servidores que formarán parte del cluster.Podemos ir creando tantos servidores como nos haga falta. También podemos indicar aqué Node agent estará asociado el servidor. Pinchamos en Aceptar y se crea el cluster.

En la siguiente figura podemos ver la información disponible para el cluster. Podemos



monitorizar las aplicaciones desplegadas en el cluster, o visualizar las instancias(servidores) que forman el cluster.

Si tenemos arrancado el Node agent podemos arrancar los servidores desde la consola deadministración. Podemos ir a cada servidor y arrancarlos por separado o bien ir al cluste yarrancar todos los servidores a la vez.



4. Ejercicios de clustering

4.1. Creación de un nuevo dominio

Comenzamos creando un nuevo dominio con el perfil de cluster y probando que funcionacorrectamente.

1. Creamos un nuevo dominio llamado cluster1 administrado con base en el puerto9000. Lo creamos con el perfil cluster para poder crear en él distintos servidores yconfiguar un cluster.

Para ello lanzamos el comando:

$ ./asadmin create-domain --portbase 9000 --profile clustercluster1

Introducimos como usuario y contraseña de administrador el mismo que antes (admin yadminadmin):

Introduzca el nombre de usuario de administración>adminIntroduzca la contraseña de administración>Introduzca de nuevo la contraseña de administración>Introduzca la contraseña maestra [Pulse Intro para aceptar lapredeterminada]:>Introduzca la contraseña maestra otra vez [Pulse Intro para aceptarla predeterminada]:>Utilizando el puerto 9048 para Admin.Utilizando el puerto 9080 para HTTP Instance.Utilizando el puerto 9076 para JMS.Utilizando el puerto 9037 para IIOP.Utilizando el puerto 9081 para HTTP_SSL.Utilizando el puerto 9038 para IIOP_SSL.Utilizando el puerto 9039 para IIOP_MUTUALAUTH.Utilizando el puerto 9086 para JMX_ADMIN.Se está creando el dominio con el perfil: cluster, talcomo se especifica en la línea de comandos o en el entorno.El archivo con la configuración regional especificada [es_ES]ubicado en:[/home/especialista/glassfish-v2ur2/lib/install/templates/locales/es_ES/index.html]no se pudo encontrar. En su lugar, se utilizará el archivoindex.html (en_US) predeterminado.Usos del almacén de seguridad: JKSSe creó el dominio cluster.

Recordamos los puertos 9048 (administración) y 9080 (HTTP)

2. Una vez creado el dominio, lo arrancamos, ejecutando:

$ ./asadmin start-domain cluster1

Comprobamos que el dominio está funcionando abriendo su consola de administración enla dirección http://localhost:9048. Comprobamos que en el menú de administración



aparece distintas opciones relacionadas con la configuración de clústers ('Clústeres','Instancias independientes', 'Equilibradores de carga HTTP' y 'Agentes de nodo'):

4.2. Creación de instancias de servidor en el cluster

1. Vamos a crear el cluster y sus instancias de servidores. Para ello debemos entrar en elmenú de administración y seleccionar la opción 'Clústeres' y pulsar en el botón 'Nuevo'.Le damos como nombre 'cluster1':

2. Todavía no podemos crear instancias de servidores dentro del cluster. Para ellotenemos que crear previamente un nodo que gestione a las instancias de servidor. Hay quecrear un nodo por cada máquina física en la que esté distribuida el cluster. Cada nodogestiona las instancias que corren en su máquina física. Vamos a utilizar una únicamáquina (la actual), por lo que creamos un único nodo. Lo llamamos 'nodo1' y lorelacionamos con el dominio 'cluster1' en el ordenador actual y en el puerto 9084. Unavez creado, lo ponemos en marcha:



asadmin create-node-agent --port 9084 nodo1asadmin start-node-agent nodo1

Nos aseguramos en la consola de administración del 'cluster1' de que el agente de nodo seestá ejecutando.

3. Una vez creado el nodo, ya podemos crear las instancias de servidores en el cluster.Para ello hay que pinchar en el botón 'Instancias' de la pantalla del cluster 'cluster1'.Creamos dos servidores y le damos como nombre 'server1' y 'server2'. Usamos el agentede nodo recién creado para que controle ambas instancias.:

4. Ponemos en marcha las dos instancias de servidor. Veremos que cada una sirve laspeticiones HTTP en un puerto distinto: 38080 y 38081. Ya tenemos configurado uncluster de dos máquinas. Prueba con el navegador a contectarte a las direccioneshttp://localhost:38080 y http://localhost:38081.

4.3. Despliegue de aplicaciones en el cluster

Vamos a desplegar la aplicación Ear1 en el cluster para comprobar que se despliega



automáticamente en ambas instancias de servidor.

1. Pinchamos el botón 'Aplicaciones' de la pantalla del 'cluster1' y el botón'Implementar...'.

2. Seleccionamos el archivo/home/especialista/NetBeansProjects/Ear1/dist/Ear1.ear y pulsamos 'Aceptar'.La aplicación se instalará en el clúster:

3. Comprobamos que la aplicación es servida por ambas instancias, conectándonos a lasURL: http://localhost:38080/web1/Suma y http://localhost:38081/web1/Suma.

4. Vamos a probar ahora cómo los servidores pueden compartir una misma sesión,proporcionando alta disponibilidad. Desplegamos la aplicación/home/especialista/glassfish-v2.1/samples/quickstart/clusterjsp/clusterjsp.ear

en el cluster. Pulsamos de nuevo en la pestaña 'Aplicaciones' y seleccionamos'Implementar'. Activamos 'Disponibilidad':

5. Consultamos que la aplicación está respondiendo en los dos servidores(http://localhost:38080/clusterjsp):



Añadimos valores al estado de la aplicación y comprobamos que ambos servidoresmantienen el mismo estado.

6. Por último, detenemos uno de los servidores a mitad de modificar la sesión ycomprobamos que en el otro servidor continúa la sesión activa.

4.4. Entrega

Guarda en la carpeta entrega-usuario el backup del dominio cluster1.



5. Gestión de recursos

5.1. JNDI: búsqueda de objetos mediante su nombre lógico

JNDI (Java Naming and Directory Interface) es un API para el acceso a diferentesservicios de nombres y directorios de una manera uniforme. Proporciona un mecanismopara enlazar programas Java con, por ejemplo, sistemas de ficheros, recursos de red,recursos de bases de datos o servicios de directorios (LDAP). El API de JNDI permiteencontrar objetos y datos registrados en estos servicios y así mismo registrar sus propiosobjetos y datos para que sean usados por otros usuarios.

JNDI suele ser utilizado para lo siguiente:

• Servicio de nombres: asocia nombres lógicos a recursos. Se detalla en la siguientesección. Este servicio es muy similar al servicio DNS de la web. Cuando solicitamosuna dirección web, el DNS se encarga de buscar la dirección IP asociada y ladevuelve.

• Servicio de directorio: haciendo uso de otro servicio (LDAP, sistema de ficheros, etc.)JNDI proporciona todas las funcionalidades que permiten estos servicios. JNDI puedeser visto como un driver JDBC en el sentido de que se encarga de "traducir" lasllamadas. En el momento de que un EJB, por ejemplo, pide un recurso a JNDI, éstepasa la petición al servicio correspondiente (LDAP, por ejemplo) y devuelve elrecurso. El servicio de directorio es muy parecido al servicio X.500.

Un servicio de nombres proporciona un método para mapear nombres lógicos (porejemplo, databd) con entidades u objetos (un recurso DataSource, un EJB, JMS, etc.). Deesta manera, no tenemos que buscar un determinado objeto, sino que buscaremos sunombre lógico. Pensad cuando trabajábamos con las bases de datos. Obteníamos unaconexión a partir de un driver y nos conectábamos a una base de datos en concreto, queestaba alojada en una determinada dirección. Si la base de datos cambiaba de nombre ocambiaba su dirección debíamos reflejar dichos cambios en nuestro código. Si utilizamosJNDI y asociamos un nombre lógico, por ejemplo databd, a un objeto DataSource, elobjeto DataSource es el que manejará los datos de la conexión con la base de datos.Nuestro código Java accede a JNDI y obtiene una referencia al objeto DataSourceasociado con el nombre lógico. Si cambian los parámetros de conexión, debemos cambiarel objeto DataSource, pero no nuestro código Java, puesto que el nombre lógico no hacambiado.

Vamos a definir un par de conceptos:

• Contexto: un contexto es similar a una conexión en JDBC. Cuando obtenemos uncontexto de JNDI tenemos un flujo de información entre nuestra aplicación y elservicio deseado (de nombres o directorios). Podemos entender un contexto como undirectorio del sistema operativo. Dentro de ese directorio podremos tener más



contextos u objetos, de la misma forma que en un directorio podemos tener másdirectorios u objetos (ficheros, enlaces, etc.) Cuando creemos un contexto en nuestrocódigo primero deberemos especificar una serie de propiedades.

• Enlace: un enlace es una asociación entre un nombre atómico y un objeto.

JNDI suele tener asociado un árbol. En la siguiente figura se muestra un posible árbolJNDI. Todo árbol tiene un contexto raíz, sin embargo el que se utiliza para trabajar es elcontexto inicial. A partir de este contexto podemos acceder a los objetos enlazados coneste contexto (representados con un triángulo) o descender a subcontextos (los contextosse representan mediante círculos). De esta forma podemos agrupar objetos y organizarlosa nuestra manera. Dentro de JNDI podemos hacer referencia a subcontextos utilizando el"." como delimitador.

5.1.1. Programar con JNDI

El siguiente código nos muestra cómo acceder al contexto inicial en un servicio LDAPgestionado por JNDI:

Hashtable env = new Hashtable();env.put(Context.INITIAL_CONTEXT_FACTORY,

"com.sun.jndi.ldap.LdapCtxFactory");env.put(Context.PROVIDER_URL, "ldap://ldap.wiz.com:389");env.put(Context.SECURITY_PRINCIPAL, "joeuser");env.put(Context.SECURITY_CREDENTIALS, "joepassword");env.put(Context.PROVIDER_URL,"ldap://localhost:389/o=JNDITutorial");Context micontexto = new InitialContext(env);

En todo código JNDI debemos capturar la excepción NamingException.

Cuando terminemos de utilizar el contexto debemos cerrarlo llamando al método close deContext.



Para asociar un objeto en el árbol utilizaremos el siguiente código:

Persona persona = new Persona();miContexto.bind ("objeto persona", persona);// miContexto.rebind ("objeto persona", persona);

Hemos creado un objeto cualquiera, en este caso el objeto persona. Utilizamos elcontexto para asociar (bind) el nombre "objeto persona" al objeto. Si utilizamos elmétodo bind y ya existe una asociación con este nombre en el árbol, se producirá unaexcepción. Por ello se puede utilizar la llamada al método rebind que, caso de existir,reemplaza la asociación anterior.

También podemos crear subcontextos para organizar mejor nuestra información. Paracrear un subcontexto podemos utilizar el siguiente código:

Context subcontexto = miContexto.createSubContext ("empleados");Persona persona = new Persona();subcontexto.bind ("contable", persona);

Hemos creado un subcontexto enlazado con el contexto inicial y dentro de esesubcontexto hemos asociado un objeto.

Por último, queda recuperar un objeto dentro de un contexto. El siguiente códigodevuelve el objeto introducido en el ejemplo anterior. Observad que es necesario realizaruna conversión al objeto que esperamos que se devuelva.

Persona pers = (Persona)miContexto.lookup ("empleados/contable");

5.2. Acceso a recursos y bases de datos

Glassfish dispone de un árbol JNDI. A través de él será como accedamos a las fuentes dedatos. Para configurar una nueva fuente de datos tenemos que seguir siempre tres pasos.Los comentamos en las siguientes secciones.

Recordemos (ya lo hemos visto en el módulo de servidores web) que un objetoDataSource puede ser usado como una factoría de conexiones a la base de datos asociadaa él, mediante el método getConnection().

5.2.1. Configuración del driver

El driver que gestiona la conexión con la base de datos tiene que estar disponible en elCLASSPATH del servidor. Lo más sencillo es copiar el fichero .jar del driver en eldirectorio domains/nombre_dominio/lib. Paramos el dominio (si estuviera funcionando) ylo arrancamos de nuevo. De esta forma, el dominio arranca ya con el nuevo driver en elclasspath



5.2.2. Configuración del conjunto de conexiones (Connection Pool)

Antes de configurar la fuente de datos, debemos dar de alta el conjunto de conexiones.Pinchamos en Recursos, JDBC y Conjunto de Conexiones. Aparecerá una lista de lasconexiones creadas y un botón para crear una nueva.

En la pantalla que nos aparece, introducimos el nombre del conjunto de conexiones, eltipo de recurso (tiene que ver con el nivel transaccional de la BD) y el tipo de base dedatos a usar. Pulsamos en Guardar.

En la siguiente pantalla se nos piden distintas opciones de la conexión, como el númerode conexiones que tenemos que crear, tiempos de espera, etc. Al final de esta pantalla nosencontramos con las propiedades adicionales de la BD. Como cada BD dispone decaracterísticas bien distintas, esta lista de propiedades es flexible para ir indicando laspropiedades de nuestra BD. Lo mejor es borrarlas todas (si no lo hacemos así es muyprobable que no funcione) e incluir las siguientes:

• password: la contraseña de la BD• URL: jdbc:mysql://host:3306/base_de_datos• user: usuario para acceder a la BD



Pinchamos en finalizar y ya tenemos configurado el conjunto de conexiones. Nos vuelvea la lista de conexiones. Si pinchamos en la recién creada, nos aparece un botón, Sondeo,que permite comprobar si la conexión es correcta. Al pulsarlo intenta conectar con la BDindicada y nos dice si la conexión es correcta o no.

5.2.3. Configuración de la fuente de datos

Procedemos a configurar la fuente de datos. Pinchamos en Recursos, JDBC, RecursosJDBC. Nos aparece la lista de recursos creados y podemos crear uno nuevo. Al pincharlonos aparece la siguiente pantalla:

Introducimos el nombre JNDI (por convención, se suele añadir jdbc/ antes del nombreque queramos darle), el conjunto de conexiones con el que está enlazado y nos permite



indicar si queremos que el recurso esté activo. Ya tenemos el recurso disponible y sepuede consultar en el árbol JNDI.

5.2.4. Uso de una fuente de datos en una aplicación que reside en el servidor

Una vez definida y configurada la fuente de datos en el servidor de aplicaciones, ya estádisponible para ser usada en cualquier aplicación web que resida en él. Para utilizar lafuente de datos debemos: (1) obtenerla a partir de su nombre (hacer un lookup) y (2)obtener una Connection a partir de ella.

La parte más complicada es la primera. Debemos obtener en nuestra aplicación unareferencia a la fuente de datos (objeto Java) creada en el servidor de aplicaciones. Vamosa ver que la forma de hacerlo es mediante su nombre JNDI.

La fuente de datos es un objeto de tipo DataSource que reside en el servidor deaplicaciones. Supongamos para el resto del apartado que el nombre JNDI que le hemosdado a la fuente de datos en el servidor de aplicaciones es jdbc/myDatabase

5.2.4.1. Acceso mediante llamada a JNDI

Podemos obtener el DataSource mediante una llamada explícita al servicio de JNDI delservidor de aplicaciones en el que está corriendo la aplicación web. Para ello:

• Debemos importar las clases para el manejo de las fuentes de datos y JNDI.import javax.sql.DataSource;import javax.naming.*;

• Para obtener el InitialContext del árbol JNDI basta con hacer un new de esta clase.Obtenemos el contexto inicial del árbol JNDI del servidor de aplicaciones en el que seestá ejecutando la aplicación web:Context ctx = new InitialContext();

• Por último, obtenemos el objeto DataSource usando el nombre JNDI que le hemosdado en el servidor de aplicaciones:DataSource ds = (DataSource) ctx.loockup("jdbc/myDatabase")

A partir de este momento ya podemos utilizar la fuente de datos como una factoría deconexiones:

Connection conn = ds.getConnection();

Nota:Obteniendo el acceso a la fuente de datos de esta forma no es necesario definir el recurso en elfichero web.xml.

5.2.4.2. Inyección de dependencias



La otra forma de obtener una referencia a la fuente de datos es mediante inyección dedependencias. Se utiliza la anotación Resource en la que se define el nombre JNDI de lafuente de datos y el servidor de aplicaciones se encarga de obtener e instanciar el objeto:

public class myServlet extends HTTPServlet {

@Resource(name="jdbc/myDatabase")DataSource ds;</source>

// métodos del servlet}

En los métodos del servlet ya se puede utilizar la fuente de datos:

protected void processRequest(HTTPServletRequest request,HTTPServletResponse response)throws ServletException, IOException {

//...Connection conn = ds.getConnection();//...

}

Sólo se pude utilizar inyección de dependencias en servlets o en componentes EJB. Larazón es que el servidor de aplicaciones debe inyectar el objeto referenciado en tiempo deejecución y para ello debe poder controlar el ciclo de vida del componente en el queinyecta la dependencia. Esto sucede con los servlets o los componentes EJB que viven enlos respectivos contenedores gestionados por el servidor de aplicaciones.

Un error muy común es colocar una anotación @Resource en una clase normal. Elcompilador no da ningún error, la clase se compila y la aplicación se despliega en elservidor de aplicaciones correctamente. Pero nadie inyecta la fuente de datos en lavariable de instancia.

¿Cómo podemos entonces combinar el patrón DAO con la inyección de dependencias?Recordemos que en el patrón DAO obtenemos una conexión a la base de datos a partir deuna clase FuenteDatosJDBC que contiene la fuente de datos. Lo hacíamos con elsiguiente código:

public class LibroJDBCDAO implements ILibroDAO {public Libro getLibro (String isbn) throws DAOException {

//...Connection conn =

FuenteDatosJDBC().getInstance().createConnection();//...

}}

Debemos modificar la clase FuenteDatosJDBC para que desde fuera podamos hacer unset del objeto dataSource. Para ello habría que cambiar el código y definir la clase comosigue:

public class FuenteDatosJDBC {



private static Log logger =LogFactory.getLog(FuenteDatosJDBC.class);

private static FuenteDatosJDBC me = new FuenteDatosJDBC();

private DataSource ds;

private FuenteDatosJDBC() {}

public static FuenteDatosJDBC getInstance() {return me;

}

public void setDataSource(DataSource ds) {this.ds = ds;

}

public Connection createConnection() {Connection conn = null;try {

return ds.getConnection;} catch (Exception e) {

logger.fatal("No se ha podido crear la conexion", e);}return conn;

}}

Con esto, basta con inicializar el singleton en el primer servlet que llame la aplicación. Apartir de ahí estará disponible para cualquier clase que lo utilice y que llame al métodocreateConnection()

public class myServlet extends HTTPServlet {

@Resource(name="jdbc/myDatabase")DataSource ds;</source>

//...

public void init() {FuenteDatosJDBC.getInstance().setDataSource(ds);

}}



6. Ejercicios de acceso a base de datos

En los ejercicios de esta sesión vamos a crear una base de datos, definir una fuente dedatos en el servidor de aplicaciones y acceder a la fuente de datos desde dos aplicacionesweb. En la primera utilizaremos un acceso con JNDI y en la segunda inyección dedependencias.

6.1. Creación de la base de datos

Crea la base de datos sapp que contenga una tabla Estudiante con los campos DNI(clave primaria) y Nombre.

Añade algunos registros en la base de datos para después poder comprobar la conexióndesde la aplicación web.

6.2. Configuración de la fuente de datos en GlassFish

Vamos a trabajar con el dominio domain1.

Instala el driver de la base de datos MySQL en el directorio domains/domain1/lib delservidor de aplicaciones.

Reinicia el dominio y configura la fuente de datos tal y como hemos visto en teoría. Ponleel nombre jdbc/sapp. Comprueba que funciona correctamente el pool de conexiones.

6.3. Acceso a la fuente de datos usando JNDI

Crea en NetBeans un proyecto web llamado sapp-database1 con los siguienteselementos:

• Una clase es.ua.jtech.DAO.FuenteDatosJDBC con un singleton que obtiene lafuente de datos jdbc/sapp accediendo al JNDI del servidor.

• Una clase es.ua.jtech.DAO.Estudiante en la que se define un bean Estudiante

con los atributos dni y nombre.• Una clase es.ua.jtech.DAO.EstudianteDAO con un único método

getEstudiante(String dni) que busca en la base de datos un estudiante ydevuelve un bean con sus datos.

• Un servlet Test desde el que se acceda al DAO para probar que la conexión estáfuncionando correctamente.

Despliega la aplicación y comprueba accediendo ahttp://localhost:8080/sapp-database1/Test que todo funciona correctamente.

6.4. Acceso a la fuente de datos con inyección de dependencias



Crea otro proyecto web llamado sapp-database2 copiando todas las clases anteriores ymodificando la clase FuenteDatosJDBC para que permita un set en su objeto fuente dedatos, tal y como hemos visto en la sesión de teoría.

Modifica el servlet para que obtenga la fuente de datos por inyección de dependencias yse la pase al singleton FuenteDatosJDBC.

Despliega la aplicación y comprueba accediendo ahttp://localhost:8080/sapp-database2/Test que todo funciona correctamente.



7. Seguridad de aplicaciones en Glassfish

En esta sesión veremos cómo configurar la seguridad de nuestras aplicaciones enGlassfish. Como ya hemos ido viendo a lo largo del curso, cuando usamos seguridaddeclarativa en una aplicación debemos configurarla en el servidor. En Glassfish, al igualque en Tomcat, la seguridad de las aplicaciones gira en torno a la idea de realms. Vamosa ver cómo se definen estos realms y qué tipos de realm soporta el servidor por defecto.

7.1. Conceptos de seguridad

La configuración de seguridad en Glassfish gira alrededor de una serie de elementosbásicos similares a los ya vistos en el módulo de servidores web.

• Usuarios: normalmente personas, aunque también pueden ser servicios ocomponentes software (EJB, por ejemplo).

• Grupos:: asociación de usuarios para que tengan un comportamiento similar. Losusuarios y grupos se definen a nivel de dominio, es decir, pueden compartirse entrevarias aplicaciones.

• Roles: El rol autoriza al que lo posea a realizar distintas tareas en una aplicación.Podríamos decir que es similar a un grupo de usuarios pero propio de una aplicaciónconcreta (se define en su web.xml). Distintos usuarios pueden tener el mismo rol y unusuario puede tener distintos roles.

• Realms: asociación entre usuarios y grupos y roles. Se denomina política deseguridad del dominio. Puede ser parte del servidor (mediante ficheros o certificados)o manejado por aplicaciones externas (como LDAP).

Realms y dominiosEn la traducción al castellano de la consola de administración se usa "dominio" como traducciónde "realm". Esto puede resultar un poco confuso, ya que recordemos que hasta ahora hemoshablado de un dominio (domain) como la "unidad" que estamos administrando en Glassfish(habitualmente un servidor, pero podría ser un cluster). Aquí usaremos siempre la palabra"realm" para referirnos a los dominios de seguridad

7.2. Realms en Glassfish

Glassfish ofrece diferentes implementaciones para los realms. Cada una de ellas almacenalos datos de usuarios y grupos usando un mecanismo distinto. Este puede ser tan simplecomo un fichero de texto o tan "sofisticado" como un servidor LDAP.

Los realms se pueden definir y configurar mediante la consola de administración. En elárbol desplegable de la izquierda elegir Configuración > Seguridad > Dominios.

Por defecto hay tres realms definidos. El primero de ellos, admin-realm, define los



usuarios de la propia consola de administración. Además de definirse en este realm, unusuario autorizado para la consola debe pertenecer al grupo asadmin (como puedecomprobarse examinando las propiedades del usuario de consola por defecto, admin)

Los otros dos realms ya definidos pueden considerarse como realms de ejemplo. Elprimero de ellos, file, usa una implementación que almacena los datos de usuarios ygrupos en un fichero de texto plano (aunque con password encriptado). Este dominio es elque usarán por defecto las aplicaciones desplegadas salvo que especifiquemos locontrario. El dominio certificate emplea certificados para autentificar al cliente. Esteúltimo lo veremos con todo detalle más adelante. Para el ejemplo inicial vamos a usarfile, que es mucho más sencillo. Vamos a configurar el realm y desplegar una aplicaciónque lo use.

El primer paso es configurar las propiedades del realm file (aunque no vamos amodificar ninguna). La primera de ellas es la clase que lo implementa, en este casocom.sun.enterprise.security.auth.realm.file.FileRealm. Como puede verse, esuna clase propia de Glassfish. Esta clase se ocupa de almacenar y gestionar los datos deusuarios y grupos, usándose para esta implementación un archivo de texto. En las"propiedades específicas de esta clase" se puede seleccionar el nombre del archivo. Pordefecto es el archivo config/keyfile dentro del directorio donde se define el dominio(para el dominio por defecto, dir_de_glassfish/domains/domain1).

El segundo paso es crear los usuarios dentro del realm. El interfaz de la consola deadministración es bastante autoexplicativo, así que no es nada complicado definirlosmediante el botón de "Administrar usuarios". Para cada usuario debemos definir login,password y grupo/s al/los que pertenece. Los nombres de grupo son nombres arbitrarios,luego veremos cómo enlazarlos con los roles usados en nuestra aplicación. Por ejemplo,supongamos que se define un usuario llamado "prueba", con password "prueba" yperteneciente al grupo "usuarios".

Finalmente, nos queda configurar la seguridad en la aplicación web. Ya vimos en elmódulo de servidores web cómo se configuraba la seguridad en el descriptor dedespliegue de la aplicación, el web.xml. Vamos a poner aquí un fragmento de ejemplo, enel que impedimos el acceso a cualquier página a los usuarios que no tengan rol"registrado". Nótese que en las aplicaciones especificamos roles, no grupos. En breveveremos cómo relacionar ambos.

<security-constraint><display-name>TodoElSitio</display-name><web-resource-collection>

<web-resource-name>Todo</web-resource-name><description/><url-pattern>/*</url-pattern>

</web-resource-collection><auth-constraint>

<description/><role-name>registrado</role-name>



</auth-constraint></security-constraint><login-config>

<auth-method>BASIC</auth-method><realm-name>file</realm-name>

</login-config><security-role>

<role-name>registrado</role-name></security-role>

En el descriptor anterior se usa autentificación BASIC. Ya vimos en el módulo deservidores web en qué consistía esta autentificación y las diferencias con FORM, por loque no repetiremos la discusión aquí. Nótese que con la etiqueta <realm-name> sereferencia el realm definido en glassfish.

El realm por defectoEn realidad la etiqueta <realm-name> es superflua en nuestro ejemplo, ya que file es elrealm por defecto en glassfish. Si no ponemos <realm-name> o ponemos un nombre de realmno existente se usa el realm por defecto. El realm por defecto se puede cambiar en la opciónConfiguración > seguridad de la consola de Glassfish.

Nos falta asociar el rol "registrado" con el grupo "usuarios". Esto se hace a través de undescriptor de despliegue adicional WEB-INF/sun-web.xml, específico de Glassfish:

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE sun-web-app PUBLIC"-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet2.5//EN""http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd"><sun-web-app><security-role-mapping><role-name>registrado</role-name><group-name>usuarios</group-name>

</security-role-mapping></sun-web-app>

7.3. Realm JDBC

Como en aplicaciones web lo habitual es guardar la información en una base de datosrelacional, es lógico usarla también para almacenar los datos de los usuarios. Esto sepuede conseguir en Glassfish a través de un realm JDBC.

Como este tipo de realm funciona con una conexión JNDI a la base de datos, hay queconfigurarla previamente para poder definirlo. Ya vimos cómo se hacía esto en sesionesanteriores, así que no lo repetiremos aquí. En la explicación que sigue, supondremos queya se ha definido un recurso JDBC llamado jdbc/seguridad con la conexión a la base



de datos que contiene la información de usuarios, passwords y grupos.

Para concretar un poco más el ejemplo, vamos a suponer que en la base de datos tenemoslas tablas que aparecen en la siguiente figura.

tablas de la BD con información de usuarios y grupos

En la definición del realm hay que especificar una serie de propiedades:

• Nombre de la clase: debe seleccionarsecom.sun.enterprise.security.auth.realm.jdbc.JDBCRealm.

• Contexto JAAS: ya aparecerá jdbcRealm. No cambiarlo.• JNDI: el nombre JNDI de la conexión a la base de datos. En nuestro caso,

jdbc/seguridad.• Tabla de usuario: tabla de la base de datos que contiene los logins de los usuarios.

En nuestro caso, usuarios.• Columna de nombre de usuario: nombre de la columna de la tabla anterior que

contiene el login. Este nombre debe ser el mismo en la tabla de grupos, ya que es laforma que usa glassfish de relacionar ambas tablas, para saber a qué grupos perteneceun usuario. En nuestro caso, login.

• Columna de contraseña: nombre de la columna de la tabla anterior que contiene elpassword. En nuestro caso, password.

• Tabla de grupo: tabla que contiene la relacion entre usuarios y grupos. En nuestrocaso, usuarios_grupos.

• Columna de nombre de grupo: nombre de la columna de la tabla anterior quecontiene el grupo. En nuestro caso, grupo.

• Algoritmo digest: algoritmo que se ha usado para encriptar el password en la base dedatos. Si ponemos none se supondrá almacenado en claro. Luego veremos ejemplosde encriptación.

El resto de propiedades del realm pueden dejarse en blanco.

En cuanto a los ficheros descriptores de la aplicación, (web.xml y sun-web.xml), no esnecesario hacer nada esencialmente distinto de lo que hacíamos en el apartado anterior.Por supuesto, habrá que referenciar con la etiqueta <realm-name> el nombre del realmdefinido: jdbc/seguridad.

7.3.1. Encriptación del password

Conservar los passwords en claro no es una buena práctica. Si se filtra parte de la BD alexterior, la seguridad de nuestros usuarios se verá comprometida. Por eso, es una práctica



común almacenar los passwords encriptados en la base de datos. Glassfish soportacualquier algoritmo de digest de los usados en java y soportados por JAAS (los mástípicos son MD2, MD5, SHA-1, SHA-256...). Cuando el usuario introduzca su passwordpara autentificarse (en la ventana del navegador, si se usa autentificación BASIC o en elformulario web si se emplea FORM) Glassfish calculará el digest y lo comprobará contrala columna de contraseña. Como ya hemos visto, en la propiedad "Algoritmo digest" delrealm debemos indicar qué método de digest se debe emplear. Lo que no nos proporcionaGlassfish es un mecanismo para, al dar de alta al usuario, calcular el digest de sucontraseña. No obstante, es algo relativamente sencillo de hacer con APIs estándar deJava, como muestra el siguiente fragmento de código de ejemplo:

public String encriptarPassword(String password, Stringalgoritmo)

throws NoSuchAlgorithmException {//Crea el "digester"MessageDigest md = MessageDigest.getInstance(algoritmo);md.reset();//Calcula el valor del digestbyte[] digest = md.digest(password.getBytes());//Convierte el digest a cadena hexadecimalStringBuilder sb = new StringBuilder();for(int i=0;i<digest.length;i++) {

String valHex = Integer.toHexString(digest[i] & 0xFF);if (valHex.length()==1)

sb.append("0");sb.append(valHex);

}return sb.toString();

}

El método anterior encripta un password, recibiendo además como parámetro el nombredel algoritmo a usar. Se usa la clase MessageDigest para hacer la encriptación y seconvierte a cadena hexadecimal porque es el formato esperado por Glassfish. El métodoanterior lo usaría el código de nuestra aplicación que da de alta un nuevo usuario y metesus datos en la BD.

Para completar la configuración deberíamos introducir el valor adecuado en la propiedad"algoritmo digest" del realm (por ejemplo "MD5") y probablemente cambiar el tipo dedatos de la columna de la BD donde almacenamos el password. Por ejemplo, los digestMD5 son siempre de 32 caracteres de largo, por lo que un CHAR(32) sería el tipoadecuado para la columna "password" de la tabla "usuarios"

7.4. Uso de certificados

Junto con los passwords, el mecanismo de autentificación más común en aplicacionesenterprise son los certificados. Comúnmente se emplean para autentificar al servidor, perotambién se pueden usar para el cliente, como se hace en la mayoría de organismosoficiales que ofrecen servicios a través de la red. Vamos a ver cómo configurar un



dominio de Glassfish que use certificados para autentificar al cliente.

7.4.1. Certificados digitales y criptografía de clave pública

En los siguientes apartados se habla extensamente de certificados digitales, clavespúblicas y otros conceptos que vamos a clarificar brevemente. Una discusión másprofunda de estos conceptos queda fuera del ámbito de estos apuntes, pero tampoco esnecesaria para comprender la autentificación basada en certificados.

En los sistemas de criptografía de clave pública las claves usadas para encriptar losmensajes van "por parejas". Lo que se encripta con una clave de la pareja solo se puededesencriptar con la otra. Este mecanismo se puede usar tanto para comunicacionessecretas como para autentificación. La idea consiste en que una de las claves de la parejase distribuye públicamente y se conoce como "clave pública" mientras que la otra solodebería ser conocida por su dueño y es la "clave privada". Si se encripta un mensaje conla clave privada del usuario solo se podrá desencriptar con su clave pública, y esto nosproporciona un mecanismo para comprobar la autoría del mensaje. De hecho, se puedeconsiderar que el documento encriptado con la clave privada ha sido "firmado" por elautor.

No obstante, el mecanismo anterior no nos asegura la identidad del autor del mensaje enel mundo real, solo que el autor posee determinada clave privada. Alguien podríaenviarnos por email o por cualquier otro canal una clave pública diciendo que es ciertapersona u organización y sin embargo no ser cierto. ¿Cómo saber entonces que alguien esquien dice ser?. Surge así el concepto de certificado. Un certificado es una clave públicade un usuario firmada digitalmente por alguien en quien confiamos. Esa firma "certifica"que ese alguien es quien dice ser. Existe un formato estándar para certificados, el X509,con el que se pueden almacenar, importar y exportar según nuestras necesidades.

Por supuesto esto plantea otra pregunta: ¿quién es este usuario o entidad en quienconfiamos y que firma digitalmente los certificados?. Este papel lo desempeñan lasautoridades de certificación o Certificate Authorities (CA). Hay autoridades decertificación privadas, compañías como Thawte o Verisign, y también públicas. EnEspaña la FNMT actúa como tal y muchas Comunidades Autónomas también tienen suCA .

Por tanto, necesitamos disponer de una lista de autoridades certificadoras en las queconfiar. Dicha lista será en realidad un almacén de certificados con las claves públicas delas autoridades certificadoras. Lo cual de nuevo nos plantea un problema que más bienparece destinado a una regresión infinita: ¿quién firma los certificados de las autoridadescertificadoras?. Para acabar con la regresión en algún punto, normalmente estoscertificados están auto-firmados, es decir, firmados por el propio titular del certificado.Evidentemente, estos certificados auto-firmados son un punto crítico en la seguridad delsistema y solo deben obtenerse de fuentes y métodos absolutamente fiables. Normalmentevienen ya instalados en los sistemas (servidores de aplicaciones o los propios



navegadores) o se obtienen vía métodos presenciales. Nótese que se establece una especiede "cadena de confianza" (chain of trust). Confiamos en el certificado de alguien porqueestá firmado por una autoridad en cuyo certificado confiamos. En el ejemplo, la cadenasolo tiene dos eslabones, pero podría tener más, con varios niveles de autoridades decertificación. El certificado auto-firmado, del final de la cadena, se conoce generalmentecomo "certificado raíz" o root certificate.

7.4.2. Creación del certificado

El primer paso es obtener el certificado para el cliente. Normalmente éste loproporcionará una autoridad de certificación, pero como los certificados tienen un costemonetario, para hacer pruebas en desarrollo se suelen usar certificados auto-firmados.Estos certificados no están firmados por ninguna autoridad de certificación reconocida,sino por el propio usuario. Por ello el navegador nos dará una serie de warnings, pero sonperfectamente usables para las pruebas.

Para trabajar con certificados es básico contar con alguna herramienta que nos permitacrearlos, editarlos y mostrar sus contenidos. Los certificados se guardan en archivosalmacenes de claves o keystores, a los que necesitaremos añadir nuestra nueva clave (hayuno en el cliente y otro en el servidor). El JDK tiene una herramienta en línea decomandos que nos permite realizar todas estas operaciones llamada keytool. Escribiendokeytool en línea de comandos obtendremos una breve ayuda sobre su uso, aunque aquíveremos paso a paso todas las operaciones necesarias.

Vamos pues a crear un certificado auto-firmado para autentificar al cliente. Tenemos queespecificar, entre otras cosas, el algoritmo empleado para la generación del certificado yel nombre del almacén de claves. Además, el certificado y el almacén están protegidospor un password. Esto se consigue con la siguiente orden:

keytool -genkeypair -v -alias autofirmada -keyalg RSA -storetypePKCS12

-keystore keystore_cliente.p12 -storepass secreto -keypasssecreto

Con el switch genkey especificamos que deseamos crear un nuevo certificado. El alias delcertificado es arbitrario, simplemente es un nombre para identificarlo dentro del almacén.Elegimos el tipo de almacén más común en navegadores, PKCS12. El nombre del archivode almacén es arbitrario pero al ser de este tipo debería tener extensión .p12. Por último,espeficicamos los passwords para acceder al almacén y al certificado.

Una vez tecleada la orden se nos irá solicitando la información necesaria para generar elcertificado.

¿Cuáles son su nombre y su apellido?[Unknown]: especialista

¿Cuál es el nombre de su unidad de organización?



[Unknown]: jtech¿Cuál es el nombre de su organización?[Unknown]: ua

¿Cuál es el nombre de su ciudad o localidad?[Unknown]: Alicante

¿Cuál es el nombre de su estado o provincia?[Unknown]: Alicante

¿Cuál es el código de país de dos letras de la unidad?[Unknown]: es

¿Es correcto CN=especialista, OU=jtech, O=ua, L=Alicante,ST=Alicante, C=es?[no]: si

Generando par de claves RSA de 1.024 bits para certificadoautofirmado (SHA1withRSA)con una validez de 90 días para: CN=especialista, OU=jtech,O=ua,L=Alicante, ST=Alicante, C=es[Almacenando keystore_cliente.p12]

(la generación de claves y el almacenamiento tardará unos segundos).

7.4.3. Importación en el cliente

Debemos importar el certificado a nuestro navegador habitual antes de poder usarlo. Estepaso es dependiente del navegador. Aquí veremos cómo hacerlo en Firefox.

Vamos a la opción de menú Editar > Preferencias. Los certificados se gestionandesde la solapa llamada Cifrado, Con el botón Ver certificados... haremos aparecerel cuadro de diálogo del Administrador de certificados, desde el que podemosimportar y borrar certificados.

Pulsamos sobre el botón Importar... y buscamos el fichero almacén de claves reciéncreado (keystore_cliente.p12). Se nos pedirá la contraseña con la que creamos el almacén(en nuestro ejemplo, "password"). Si todo va bien, aparecerá el certificado en eladministrador.



administrador de certificados de Firefox

7.4.4. Importación en el servidor

En nuestro caso, tenemos el problema de que el certificado que hemos generado no estáfirmado por ninguna autoridad de certificación reconocida por Glassfish. El servidorguarda en un almacén de claves las autoridades reconocidas (lo que se conoce en el"argot" habitual como un truststore). Dicho almacén está en el directorio del dominio (ennuestro caso domains/domain1 con el nombre cacerts.jks. Por tanto, debemosañadirnos a dicho almacén como nueva autoridad certificadora

Lo primero es exportar el certificado desde el almacén de claves en un formato apto paraser importado en glassfish. Esto podemos hacerlo con el switch exportcert. Loguardamos en un fichero con extensión .cer. El switch -rfc lo guarda en formatoimprimible (en caso contrario se guardaría en binario, y necesitamos que esté así parapoder importarlo a glassfish).

keytool -exportcert -alias autofirmada -keystorekeystore_cliente.p12-storetype PKCS12 -storepass secreto -rfc -file certificado.cer

Ahora ya podemos importarlo al truststore de Glassfish con la orden:

keytool -importcert -file certificado.cer -alias autofirmada-keystore[directorio_de_glassfish]/domains/domain1/config/cacerts.jks

Nos pedirá contraseña para el almacén de claves del dominio. Por defecto, en Glassfish seusa changeit. Además, como el certificado no está firmado por ninguna autoridad decertificación reconocida, se nos pedirá confirmación (¿Confiar en este certificado?). Unavez añadido el certificado al almacén, el servidor ya nos reconocerá como autoridad



certificadora. Tendremos que rearrancar el dominio para que los cambios tengan efecto.

7.4.5. Configuración del dominio y del descriptor de despliegue

Primero especificaremos la configuración del descriptor de despliegue estándar, web.xml.Debemos hacer un par de cambios con respecto a los realms que usábamos hasta elmomento.

• El primero es la forma de hacer login, especificada en la etiqueta <login-config/>.En este caso no se usa password, por lo que no tienen sentido la autentificaciónFORM ni BASIC. Se usa un valor especial que es CLIENT-CERT

• En segundo lugar, la autentificación mediante certificados debería venir asociada auna comunicación segura, por lo que activaremos el uso de SSL mediante la etiqueta<user-data-constraint/> con <transport-guarantee/> a CONFIDENTIAL.

El fragmento del web.xml que tiene que ver con la seguridad quedaría como sigue:

<security-constraint><display-name>TodoElSitio</display-name><web-resource-collection><web-resource-name>Todo</web-resource-name><description/><url-pattern>/*</url-pattern>

</web-resource-collection><auth-constraint><description/><role-name>registrado</role-name>

</auth-constraint><user-data-constraint><transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint></security-constraint><login-config><auth-method>CLIENT-CERT</auth-method><realm-name>certificate</realm-name>

</login-config><security-role><role-name>registrado</role-name>

</security-role>

Pero todavía nos queda especificar qué usuario/s pertenecen al rol "registrado". Como eshabitual, esto se hace con el descriptor de despliegue particular de Glassfish,sun-web.xml. Nótese que se asocia el usuario con el rol y con el grupo.

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE sun-web-app PUBLIC"-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet2.5//EN""http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd">



<sun-web-app error-url=""><security-role-mapping><role-name>registrado</role-name><principal-name>CN=especialista, OU=jtech, O=ua, L=Alicante,

ST=Alicante, C=es</principal-name><group-name>usuarios</group-name>

</security-role-mapping></sun-web-app>

El "principal-name" debe ser el "nombre completo" del titular del certificado. Si no lorecordamos, puede obtenerse mediante keytool. Por ejemplo, recordemos que habíamosexportado el certificado a un fichero "certificado.cer". Con:

keytool -printcert -file certificado.cert

Podemos ver todos los datos del certificado. Nos interesa la línea que aparece como"Emisor" ("Owner" en la versión en inglés de keytool).

¡Cuidado!El contenido de "principal-name" no debe tener espacios ni retornos de carro que no esténpresentes en el certificado original, de otro modo la autentificación no funcionará

7.4.6. Prueba del realm

Para probar el realm lo primero sería crearlo, no obstante podemos usar el que viene yapor defecto con Glassfish llamado certificate. Simplemente debemos editar lapropiedad "asignar grupo" para que los autentificados en este realm se consideren delgrupo "usuarios" (enlazando así con lo especificado en el fichero sun-web.xml).

Al intentar acceder a la aplicación lo más probable es que veamos un aviso de nuestronavegador indicando que no se confía en la identidad del servidor. Esto no tiene nada quever con la autentificación del cliente. El aviso aparece porque hemos activado lacomunicación con SSL y sin embargo en el servidor no tenemos un certificado firmadopor ninguna CA asegurando su identidad.

Certificado del servidorEl certificado del servidor se almacena en el directorio "config" del dominio dentro del archivo"keystore.jks". Con la herramienta keytool podemos ver su contenido (keytool -list -v -keystoredir_de_glassfish/domains/domain1/config/keystore.jks). Veremos un certificado auto-firmado yque ha sido generado cuando se creó el dominio. En un Glassfish en producción aquícolocaríamos el certificado firmado por alguna autoridad de certificación reconocida (es decir,reconocida por los navegadores que accedan al servidor).

Una vez superado este aviso (en las últimas versiones de Firefox hará falta seleccionar"añadir una excepción..." y confirmar la excepción de seguridad), el servidor nos



solicitará un certificado para autentificarnos. Nuestro navegador nos debería mostrar unalista con el certificado apropiado para la tarea (o una lista con varios, si hay más de unoválido).



8. Ejercicios de seguridad de aplicaciones con Glassfish

8.1. Prueba de realm

En este primer ejercicio vamos a probar la implementación más sencilla de realm deGlassfish: el que almacena los datos de usuarios en un fichero de texto plano.

8.1.1. Creación del realm

1. Arrancar el dominio por defecto de Glassfish. Suponiendo que Glassfish estáinstalado en el directorio especialista:

$ cd /home/especialista/glassfish-v2ur2/bin$ ./asadmin start-domain domain1

2. Abrir la consola de administración (http://localhost:4848). Recordad que eladministrador por defecto es admin con password adminadmin

3. Crear un nuevo realm: en el menú desplegable de la izquierda seleccionarConfiguración > Seguridad > Dominios. En la parte derecha de la pantallaaparecerá una lista con los dominios existentes. Pulsar sobre el botón Nuevo...

4. Especificar las propiedades del realm. Vamos a guardar los logins y passwords en elarchivo usuarios.txt del directorio config dentro del dominio domain1. El${com.sun.aas.instanceRoot} representa el directorio raíz del dominio actual. Unavez especificadas todas las propiedades, pulsar sobre el botón Guardar

propiedades del realm basado en archivo5. Añadir usuarios: en la pantalla con la lista de dominios, pulsar sobre el nombre del



dominio, testFileRealm, para editarlo. Mediante el botón Administrar usuarios

se pueden ir añadiendo usuarios. Añadir a pepe con password pepe, perteneciente algrupo usuarios.

6. Si se muestra el archivodir_de_glassfish/domains/domain1/config/usuarios.txt se verá que se haañadido el usuario pepe. Fijaos en que el password no está en claro, sino que se usaun digest.

8.1.2. Creación de la aplicación de prueba

Necesitamos una aplicación de prueba con seguridad declarativa. Iremos modificando laconfiguración para ir adaptándola a los distintos realms que vayamos probando.

1. Crear una nueva aplicación web en NetBeans llamada TestSeguridad. Comoservidor de destino elegir Glassfish. Vamos a proteger todas las URLs de laaplicación. En index.jsp pondremos simplemente un mensaje "Si ves esto es que tehas autentificado correctamente". No es necesario que tenga nada de código parahacer las pruebas.

2. Configurar el web.xml para proteger todas las URL a los usuarios con rol"registrado". Vamos a hacer uso de la autentificación BASIC por simplicidad. Podéishacer uso del editor "visual" del web.xml o bien escribir el código XML "a mano".Por defecto al hacer doble clic sobre el web.xml se abrirá el editor visual. Pulsar sobre"security" e introducir la información que aparece en la figura (si prefieres editarlomanualmente, pulsar sobre el último botón, "XML")



restricciones de seguridad en web.xml

En el editor visual, marcar también la casilla de "Enable authentication constraint" yañadir el rol "registrados" pulsando sobre el botón "Edit".

LogoutCon autentificación BASIC no hay "logout". Si consigues hacer login, ya no podrás cambiar deusuario. Si introduces usuario y contraseña erróneos varias veces, ya no te dejará acceder alrecurso solicitado . Puedes cerrar el navegador o bien (más fácil) borrar todas las cookies. EnFirefox ve a Herramientas > Limpiar datos privados y asegúrate de que marcas las cookies

3. Configurar el fichero descriptor sun-web.xml para asociar el rol "registrados" conel grupo "usuarios". Si hemos elegido Glassfish como servidor destino de la



aplicación, este archivo se habrá creado automáticamente junto al web.xml. Tambiéndispone de un editor "visual":

sun-web.xml4. Compilar, y desplegar la aplicación. Pulsar con el botón derecho sobre el proyecto y

seleccionar Build para generar el fichero .war dentro de la carpeta dist del proyecto.Recordad de los ejercicios de la semana pasada que había varias formas de desplegareste .war, podéis hacerlo por ejemplo desde la consola de administración enAplicaciones > Aplicaciones web y luego con el botón Implementar... subir el.war al servidor (equivalente a desplegar). Una vez desplegada por primera vez, si semodifica hay que recompilarla y pulsar sobre Reimplementar... para subir el nuevo.war

5. Probar la aplicación accediendo a http://localhost:8081/TestSeguridad.Debería aparecer una ventana del navegador solicitando login y password. Trasintroducir "pepe", "pepe", debería mostrarse el index.jsp

8.2. Configuración de un realm con uso de certificados

En este ejercicio vamos a configurar la aplicación TestSeguridad para que autentifiqueal cliente basándose en un certificado en lugar de login y password. Seguiremos estospasos:

1. Vamos a hacer un uso extensivo de la herramienta keytool incluida en el JDK. Si alejecutar keytool aparece un mensaje indicando "keytool: orden no encontrada" loañadiremos al PATH ejecutando

export PATH=$PATH:/opt/jdk1.6.0_16/bin



Si lo hacemos así los cambios solo tendrán efecto durante la sesión actual. Para quesean permanentes añadiremos la línea anterior al fichero .bashrc (en este caso habráque abrir una nueva terminal para que los cambios tengan efecto)

2. Creación del certificado del cliente. Usaremos un certificado auto-firmado. Teclear

keytool -genkeypair -alias autofirmado -keyalg RSA -storetypePKCS12-keystore keystore_cliente.p12

keytool nos preguntará varios datos necesarios para crear el certificado, entre ellos unpassword del que luego debemos acordarnos(!) . Podéis elegir por ejemplo,"password"

Escriba la contraseña del almacén de claves:Volver a escribir la contraseña nueva:¿Cuáles son su nombre y su apellido?[Unknown]: especialista

¿Cuál es el nombre de su unidad de organización?[Unknown]: jtech

¿Cuál es el nombre de su organización?[Unknown]: ua

¿Cuál es el nombre de su ciudad o localidad?[Unknown]: Alicante

¿Cuál es el nombre de su estado o provincia?[Unknown]: Alicante

¿Cuál es el código de país de dos letras de la unidad?[Unknown]: es

¿Es correcto CN=especialista, OU=jtech, O=ua, L=Alicante,ST=Alicante, C=es?[no]: si

Esto creará un almacén de claves con un único certificado, llamado "autofirmado".Podemos comprobar su existencia con

keytool -list -v -storetype PKCS12 -keystore keystore_cliente.p12

3. Importación del certificado en el cliente:. Incorporar el certificado autofirmado afirefox. Vamos a la opción de menú Editar > Preferencias. Los certificados segestionan desde la solapa llamada Cifrado, Con el botón Ver certificados...

haremos aparecer el cuadro de diálogo del Administrador de certificados, desdeel que podemos importar y borrar certificados. Pulsamos sobre el botón Importar...

y buscamos el fichero almacén de claves recién creado (keystore_cliente.p12). Se nospedirá la contraseña con la que creamos el almacén

4. Importación del certificado en el servidor:. Primero debemos exportar elcertificado en un formato apto para el servidor:

keytool -exportcert -alias autofirmado -keystorekeystore_cliente.p12



-storetype PKCS12 -rfc -file certificado.cer

Ahora ya podemos importarlo al almacén de certificados de confianza del servidor,que está en[directorio_de_glassfish]/domains/domain1/config/cacerts.jks. Recordadque la contraseña del almacén de certificados del servidor es changeit.

keytool -importcert -file certificado.cer -alias autofirmado-keystore

[directorio_de_glassfish]/domains/domain1/config/cacerts.jks

5. Cambiar la configuración del web.xml de la aplicación TestSeguridad. Para que nose pierda lo que habéis hecho hasta el momento de cara a la entrega de ejercicios,haced una copia del web.xml actual (el configurado para el realm de archivo de texto)como "web-file.xml"

web.xml para certificado,parte I



web.xml para certificado,parte II

Especificar el nombre del realmEn el editor visual del web.xml, cuando se activa la autentificación con certificadoautomáticamente se quita la posibilidad de especificar el "realm-name". No obstante, enGlassfish se debería especificar el nombre del realm para que el servidor pudiera asociarlo aladecuado. Esto solo se aplica en realidad si hay más de un realm basado en certificados. Enciertos casos por tanto, habría que editar el web.xml manualmente.

6. Cambiar la configuración del sun-web.xml. En el "Principal name" debéis poner elcampo "Emisor" del certificado (podéis visualizarlo del fichero .cer al que lo habéisexportado con keytool -printcert -file certificado.cer)Para que no sepierda lo que habéis hecho hasta el momento de cara a la entrega de ejercicios, haceduna copia del sun-web.xml actual (el configurado para el realm de archivo de texto)como "sun-web-file.xml"



sun-web.xml para certificado7. Probar la aplicación: cread de nuevo el .war (botón derecho > Build en NetBeans) y

desplegadla de nuevo (Reimplementar... en la consola de Glassfish). Al acceder ahttp://localhost:8081/TestSeguridad dará un aviso de seguridad indicando queel servidor se está autentificando con un certificado autofirmado (cuidado, esto notiene nada que ver con la autentificación del cliente, es porque hemos activado SSL).

error de seguridad en Firefox

Elegir "Añadir una excepción..." para que Firefox acepte la conexión con el servidor.



Una vez superado este paso, el servidor nos pedirá autentificación. Firefox mostrará elcertificado y nos permitirá usarlo para autentificarnos. Comprobar que podemosacceder a index.jsp correctamente.

8.3. Configuración de un realm JDBC (OPTATIVO)

Siguiendo las instrucciones de los apuntes, configurad un realm JDBC para la aplicaciónTestSeguridad. Podéis aprovechar algún Datasource que hayáis creado en la sesiónanterior, añadiendo las tablas de usuarios y grupos a la base de datos. Para añadir lastablas podéis ayudaros de la herramienta "MySQL query Browser".



9. Apéndice: Servidor de aplicaciones JBoss

9.1. JBoss: instalación, configuración y administración. Gestión de recursos

JBoss es uno de los servidores de aplicaciones más difundidos en el mundo JavaEE. En laactualidad, con la presencia de Glassfish, puede no resultar sorprendente la idea de unservidor de aplicaciones de código abierto, pero cuando surgió JBoss, a principios de2000, era el único de este carácter en un mercado copado por servidores propietarioscomo Websphere y Weblogic.

JBoss es por tanto uno de los servidores de aplicaciones más "maduros" del mercado.Además, siempre se ha distinguido por mantener una comunidad de desarrolladores y deproyectos software que crecen y se mantienen en torno al servidor de aplicacionespropiamente dicho.

Durante dos sesiones vamos a ver cómo configurar a nivel básico el servidor, desplegaraplicaciones y fuentes de datos y configurar la seguridad.

9.1.1. Configuración de JBoss

JBoss no es un servidor monolítico. Por el contrario, es lo que sus desarrolladores llamanun microcontenedor, en el que se definen los servicios de manera modular. De este modopodemos arrancar solo los servicios que vayamos a necesitar realmente, sin sobrecargar elsistema de modo innecesario.

9.1.1.1. Configuraciones del servidor

Podríamos hacer un paralelismo entre configuraciones en JBoss y dominios en Glassfish,aunque no son totalmente equivalentes. JBoss viene originalmente con tresconfiguraciones alternativas. En cada una de ellas el conjunto de servicios que se activanes distinto. Físicamente son subdirectorios dentro del directorio server de la distribución,que contienen ficheros de configuración y librerías para arrancar los servicioscorrespondientes. Las versiones anteriores de JBoss (4.x) venían con tres configuracionesdistintas: minimal, con el mínimo de servicios para que JBoss funcione, default, laconfiguración usada por defecto, con los servicios JavaEE más típicos, y all, que arrancatodos los servicios incluidos en la distribución. La versión 5 trae dos adicionales:standard: conjunto de servicios necesarios para la certificación JavaEE 5 y web, orientadoal "futuro" perfil de aplicaciones web de JavaEE 6.

Para poner en marcha una configuración determinada basta con pasar su nombre en elparámetro -c del script de arranque. Por ejemplo (en linux)

run.sh -c minimal



Como ya hemos dicho, las configuraciones iniciales se corresponden con lossubdirectorios existentes dentro del directorio server. Podríamos crear una configuraciónpropia copiando la estructura de directorios de una de las ya existentes y adaptando losarchivos de configuración a nuestras necesidades. De este modo se añaden o eliminanservicios o se cambia su configuración. Los subdirectorios que componen unaconfiguración de servidor son los siguientes:

• conf: contiene un fichero de configuración XML donde se definen los servicios"fijos" durante todo el ciclo de vida del servidor. Además de estos podemos añadirservicios sobre la marcha, como ya veremos.

• deploy: aquí es donde se despliegan las aplicaciones y los nuevos servicios.• deployers: contiene los servicios que se encargan del despliegue de aplicaciones.• lib: librerías comunes al servidor y a las aplicaciones. Por ejemplo, drivers JDBC.• La primera vez que se arranca una configuración, JBoss crea automáticamente una

serie de directorios auxiliares:• log: evidentemente, guarda los logs. JBoss usa log4j, que se configura en un

XML guardado en conf.• data: disponible para servicios que quieran almacenar datos de manera

permanente. JBoss lo utiliza para la base de datos que lleva integrada(hypersonic).

• tmp y work: son directorios de trabajo de JBoss, similares a los del mismo nombrede Tomcat

9.1.1.2. Cambiar la configuración

Configurar JBoss hasta el último detalle es una cuestión compleja, de modo que aquísimplemente daremos unas breves indicaciones. Se recomienda consultar la excelentedocumentación de referencia disponible en el sitio de JBoss.

El microcontenedor de JBoss está compuesto por un conjunto de objetos que colaboranpara implementar los diferentes servicios. Las clases a las que pertenecen dichos objetos ylas relaciones entre ellos se definen en diversos archivos XML dentro del directorio conf

de la configuración del servidor. Para modificar los servicios debemos modificar portanto estos archivos.

El microcontenedorEl microcontenedor de JBoss es un framework basado en inyección de dependencias. Si conocesotros frameworks java basados en la misma filosofía como Spring o Guice, probablemente tepuedas hacer una idea bastante aproximada de la lógica de los ficheros de configuración deJBoss. Si no, no te preocupes. No vamos a necesitar una configuración sofisticada de JBoss parael curso, y veremos en profundidad la idea de inyección de dependencias en los módulos de EJB3y Spring.

Veamos como ejemplo el archivo conf/jboss-service.xml. Si lo editamos veremosque en él se define un conjunto de MBeans (recordemos los conceptos de JMX



introducidos en apartados anteriores). El archivo está extensamente comentado, lo queunido a la documentación de referencia hace relativamente sencillo (aunque tedioso)cambiar la configuración manualmente. Por ejemplo, el siguiente MBean (tomado de laconfiguración minimal) define el servicio de gestión de logs.

<mbean code="org.jboss.logging.Log4jService"name="jboss.system:type=Log4jService,service=Logging"><attribute

name="ConfigurationURL">resource:jboss-log4j.xml</attribute></mbean>

Bastaría comentar la sección anterior para que no se pusiera en marcha el logging alarrancar JBoss, o cambiar el valor del atributo ConfigurationURL para usar otro ficherode configuración para log4j.

La configuración también se puede cambiar a través de la consola JMX, pero los cambiosno son permanentes y solamente se mantendrán mientras el servidor esté en marcha.

Finalmente, nótese que JBoss usa internamente Tomcat como servidor web, por lo quepodemos aplicar todo lo visto en la configuración de Tomcat a la parte web de JBoss.Tomcat está configurado como un servicio más de JBoss, dentro del directoriodeploy/jboss-web.deployer. Allí podemos encontrar por ejemplo el server.xml deTomcat.

9.1.2. La consola JMX

La versión de pago de JBoss incorpora una consola gráfica de administración, llamadaJBoss ON (Operations Network). Aunque se está desarrollando una versión de códigoabierto de JBoss ON, en el momento de escribir estas líneas todavía no está disponiblepara JBoss 5. No obstante, disponemos de otra herramienta de configuración: la consolaJMX.

JBoss implementa el estándar JMX para administración y monitorización de serviciosJavaEE. Este estándar permite interactuar con los servicios a través de componentesllamados MBeans.

Podemos acceder a la consola JMX en JBoss a través del enlace JMX Console. Apareceráuna lista con todos los MBeans disponibles, ordenados por categorías (dominios, enterminología JMX).



consola JMX

En el estándar JMX, el nombre de un MBean no es simplemente una cadena de textoplano,sino que se compone de dos partes diferenciadas: el dominio, similar al nombre depaquete en clases java y las propiedades clave, pares nombre=valor. No hay que dejarseconfundir aquí por el término "valor". Todo esto forma parte del nombre del MBean, node su contenido.

Podemos elegir por ejemplo el dominio jboss.system, que contiene información sobreel servidor propiamente dicho: en el cuadro de texto de la parte superior de la pantalla,teclear jboss.system: para filtrar los MBeans de este dominio.

Ahora podemos seleccionar por ejemplo el MBean jboss.system:type=Server, querepresenta al propio servidor. Como podrá verse, cada componente tiene una serie depropiedades, que podemos examinar, y operaciones, que podemos invocar desde laconsola JMX. Por ejemplo, pulsando sobre el "Invoke" de la operación shutdown()

podemos parar el servidor.

Problemas de la consolaLa consola JMX no es una herramienta realmente apropiada para trabajos de administración. Laorganización de la información no es muy conveniente desde el punto de vista del administrador,y además los cambios en la configuración no son permanentes. La única forma de hacer cambiospermanentes es editando los ficheros XML de configuración. No obstante, es una herramientavaliosa para el desarrollador en la fase de pruebas, ya que nos permite comprobar los nombresJNDI vinculados, las fuentes de datos desplegadas, etc.



9.1.3. Despliegue

9.1.3.1. Despliegue de aplicaciones

JBoss tiene un directorio en el que basta "dejar caer" las aplicaciones web para que sedesplieguen en el servidor. Se trata del directorio deploy. En él podemos dejar un .war obien un directorio con la aplicación web descomprimida. Recordemos que en Tomcat eldirectorio equivalente era webapps.

Para eliminar una aplicación basta con borrarla del directorio deploy.

Con Eclipse, la forma de trabajo será idéntica a la que empleábamos con Tomcat,únicamente necesitaremos definir el servidor JBoss y lo usaremos como runtime paranuestro proyecto web dinámico.

9.1.3.2. Despliegue de servicios

Una característica muy interesante de JBoss es la posibilidad de desplegar y eliminarservicios "en caliente", con el servidor en marcha. Estos servicios se despliegan en elmismo directorio que las aplicaciones, es decir, en deploy.

Los servicios se despliegan colocando un XML con su configuración en dicho directorio.Aquellos que requieran algún recurso adicional (librerías, otros archivos) se empaquetanen lo que JBoss llama ficheros SAR (Service Application Archive) que no son más queJARs con metainformación especial.

Al igual que con las aplicaciones, para eliminar un servicio basta con borrarlo deldirectorio deploy. Por ejemplo, JBoss ofrece un servicio de scheduling que podemos usarpara ejecutar una tarea a intervalos regulares. Si no necesitamos dicho servicio, podemoseliminarlo "en caliente" sin más que borrar el fichero scheduler-service.xml.

9.1.4. Fuentes de datos en JBoss

Como cualquier otro servidor de aplicaciones, JBoss puede gestionar los Datasources quenecesiten nuestras aplicaciones. Esto permite la gestión automática del pooling deconexiones y el cambio del recurso físico sin afectar a la aplicación. Veamos cómo seconfigura una fuente de datos en JBoss. En el ejemplo usaremos mysql, pero por supuestolos pasos son similares para cualquier otra base de datos.

Lo primero es dejar el driver java de la base de datos a disposición de JBoss. Ya hemosvisto que las librerías que deben estar accesibles durante todo el ciclo de vida se colocanen el directorio lib de JBoss. El driver no es más que un JAR con las clases que loimplementan.

Una vez colocado el driver en lib, tenemos que rearrancar el servidor. Podemos



comprobar que se ha cargado correctamente a través de la consola JMX. En la partesuperior de la pantalla aparecerá el dominio JMImplementation, que contiene 3 MBeans.Nos interesa el primero de ellos (LoaderRepository). En él podemos ver una lista de losJAR cargados por JBoss entre los que debería aparecer el de MySQL(mysql-connector-java...). También podemos invocar la operacióndisplayClassInfo() introduciendo el nombre de la clase que implementa el driver(com.mysql.jdbc.Driver), que mostrará si la clase está accesible o no.

Nos queda configurar las propiedades del DataSource. En JBoss un DataSource seconsidera un servicio desplegable "en caliente" y por tanto se configura a través de unfichero XML que se deja en el directorio deploy. La distribución de JBoss incluye en eldirectorio docs/examples/jca ficheros de configuración de ejemplo para distintas basesde datos. Nosotros tomaremos el de MySQL: mysql-ds.xml. Nótese que todos estosficheros siguen la convención de que su nombre acaba por -ds. El servidor busca losnuevos DataSources en los ficheros XML que sigan esta convención.

Aquí tenemos un ejemplo de una posible configuración para MySQL:

<?xml version="1.0" encoding="UTF-8"?><datasources><local-tx-datasource><jndi-name>PruebaDS</jndi-name>

<connection-url>jdbc:mysql://localhost:3306/prueba</connection-url><driver-class>com.mysql.jdbc.Driver</driver-class><user-name>prueba</user-name><password>prueba</password><exception-sorter-class-name>

org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter

</exception-sorter-class-name></local-tx-datasource>

</datasources>

Aunque el fichero de ejemplo original contiene más información, se ha eliminado la queno es estrictamente necesaria. Por desgracia, en la documentación de jboss 5 disponibleen el momento de escribir estas líneas no se detalla el formato del fichero deconfiguración. No obstante, en la "Guía de Administración y desarrollo" de la versión 4.2de JBoss sí se describe, y es el mismo formato. Además en el archivodocs/dtd/jboss-ds_5_0.dtd de la distribución se puede ver una descripción de todaslas etiquetas disponibles.

Veamos los elementos definidos en nuestro ejemplo:

• <local-tx-datasource>: define una fuente de datos que puede usartransaccionalidad distribuida sobre varias bases de datos, pero no sobre variosservidores de aplicaciones. Este es el valor apropiado, en general, si no vamos a hacerclustering.

• <jndi-name>: es el nombre JNDI, es decir, el nombre lógico que usaremos en nuestrocódigo Java.



http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/4/html/index.html

• <connection-url>: la URL de conexión con la BD, al igual que cuando abrimos laconexión manualmente.

• <driver-class>: clase que implementa el driver.• <user-name> y <password>: datos del usuario de la BD.

Al dejar el fichero en deploy aparecerá en la terminal donde está arrancado el servidor unmensaje indicando la incorporación de una nueva fuente de datos, algo como:

INFO [ConnectionFactoryBindingService] Bound ConnectionManager'jboss.jca:service=DataSourceBinding,name=PruebaDS'to JNDI name 'java:PruebaDS'

Nótese que el nombre JNDI en realidad es java:PruebaDS, como vemos también en elcódigo java de ejemplo para acceder a la fuente de datos:

//Obtener el contexto JNDIContext initCtx = new InitialContext();//Obtener el recurso con su nombre lógico (JNDI)DataSource ds = (DataSource) initCtx.lookup("java:PruebaDS");//A través del DataSource podemos obtener una conexión con la BDConnection conn = ds.getConnection();//A partir de aquí trabajaríamos como es habitual en JDBC...

Aunque una descripción más detallada del funcionamiento de JNDI está fuera del alcancede este tema, para nuestros propósitos basta saber que el servidor de aplicacionesmantiene un servidor JNDI. El acceso inicial al servidor JNDI se hace a través delInitialContext. Una vez obtenido el contexto, podemos obtener recursos (lookup) porsu nombre lógico.

9.2. Ejercicios de instalación y administración de JBoss

9.2.1. Instalación y arranque de JBoss

La instalación y ejecución con la configuración por defecto de JBoss es bastante sencilla.Basta con

• Bajarse la distribución de JBoss desde sourceforge) o desde la página de software delespecialista y descomprimirla en cualquier carpeta del sistema, por ejemplo en/home/especialista. Creará el directorio jboss-5.0.1.GA (versión actual en elmomento de escribir estas líneas)

• Definir la variable de entorno JBOSS_HOME para que apunte al directorio de instalaciónde JBoss. En el archivo .bashrc de nuestro directorio HOME(/home/especialista) colocaremos:

export JBOSS_HOME=/home/especialista/jboss-5.0.1.GAexport PATH=$PATH:$JBOSS_HOME/bin



http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=663566

http://www.jtech.ua.es/j2ee/2008-2009/restringido/software.html

http://www.jtech.ua.es/j2ee/2008-2009/restringido/software.html

La segunda línea solo es necesaria si deseamos poder arrancar el servidor llamando alscript de arranque desde cualquier directorio. Será necesario abrir una nueva terminalpara que los cambios tengan efecto

• Ejecutar el script de arranque, llamado run.sh y contenido en el subdirectorio bin deJBoss.

• En la terminal aparecerán mensajes a medida que van arrancando todos los servicios.Una vez completado el arranque, se mostrará el mensaje "Started in ..." con eltiempo que ha tardado JBoss en arrancar.

• Para verificar que todo es correcto, se puede abrir la consola de administración. En unnavegador, abrir la URL http://localhost:8080. Debe aparecer una página webcon el logo de JBoss y acceso a las diferentes consolas de administración ymonitorización.

• Parar el servidor: En desarrollo, es habitual tener disponible la consola desde dondehemos arrancado JBoss. En ese caso, para parar el servidor basta con pulsar Ctrl-C.Si estamos ejecutando JBoss como un servicio del sistema, o en un sistema remoto,podemos pararlo con el script shutdown.sh del directorio bin.

9.2.2. Creación de una configuración propia (dominio)

En JBoss, los dominios son los distintos subdirectorios que aparecen dentro del directorioserver. JBoss no tiene herramientas de creación/configuración de dominios, por lo que elproceso se debe hacer manualmente. Normalmente se parte de un dominio ya creado, quevamos modificando según nuestras necesidades. Podemos crear un nuevo dominiomoviéndonos hasta /home/especialista/jboss-5.0.1.GA/server y copiando laestructura de directorios del dominio default en el nuevo dominio que llamaremosespecialista

cp -r default especialista

Para ejecutar este dominio:

run.sh -c especialista

No cierres la terminal, así podrás ver los mensajes de log de JBoss a medida que se vanproduciendo (aunque también se guardan en el archivo server.log dentro del directoriolog del dominio.

9.2.3. La consola JMX

Si abrimos un navegador y accedemos a http://localhost:8080/jmx-console/

veremos la consola JMX. En la parte izquierda aparecen los dominios de los MBeans y enla derecha los propios MBean categorizados por dominio. Vamos a ver el MBean querepresenta al servidor y a pararlo.



1. En el cuadro de texto de la parte superior derecha de la pantalla, teclear el dominioque nos interesa, que es jboss.system

2. Examinar las propiedades y métodos del MBean type=Server, que es el querepresenta al propio servidor. Entre las operaciones aparecerá shutdown. Ejecutarlapulsando sobre el botón "invoke" correspondiente

3. En la terminal verás que aparecen mensajes indicando que JBoss se está parando.

9.2.4. Despliegue de una aplicación de prueba

Por desgracia, en el momento de escribir estas líneas la integración de JBoss 5 conNetbeans 6.5 deja un poco que desear. La versión de NetBeans que se descarga de la webno está preparada para JBoss 5, y no podremos añadir el servidor de la forma habitual enel IDE (Tools > Servers, botón "Add server..."). Si se actualiza Netbeans con los parchesdisponibles on-line, ya es posible añadirlo como servidor, pero no localizarácorrectamente todos los JARs incluídos en la distribución (en concreto, todos los decommon/lib, ya que en JBoss 4 estaban en lib). Continuamente saldrán mensajes deerror "echando en falta" ciertos JARs entre ellos el API de servlets.

Por el momento, y hasta que se arreglen estos problemas con el IDE, probablemente lomás operativo sea fijar como servidor destino otro que tengamos instalado (por ejemploGlassfish) y hacer el despliegue y ejecución de manera manual.

1. Crear un proyecto de NetBeans de tipo aplicación web llamado TestJBoss. Comoservidor destino, elegir uno cualquiera de los instalados (glassfish, por ejemplo).Modificar el index.jsp para que muestre un mensaje de "Hola JBoss!".

2. Crear el .war ejecutando Build sobre el proyecto. Como habéis visto en anterioressesiones, el war se habrá creado en el directorio dist (en este caso, en/home/especialista/NetBeansProjects/TestJBoss/dist).

3. Asegurándoos de que JBoss está arrancado (recordad: run.sh -c especialista),copiar el .war al directorio de deploy del dominio($JBOSS_HOME/server/especialista/deploy). En la terminal en que se estéejecutando el servidor aparecerá un mensaje indicando que se ha producido eldespliegue:

INFO [TomcatDeployment] deploy, ctxPath=/TestJBoss

4. Acceder a la url http://localhost:8080/TestJBoss para comprobar que laaplicación se ha desplegado correctamente.

5. Para replegar la aplicación, borrar el .war del directorio de deploy. Aparecerá unmensaje en la consola de JBoss

INFO [TomcatDeployment] undeploy, ctxPath=/TestJBoss

9.2.5. Despliegue de servicios

Los servicios en JBoss se tratan como aplicaciones, por lo que se despliegan en el



directorio "deploy". En realidad, en lugar de desplegar un nuevo servicio, vamos aeliminar uno innecesario para nosotros: el servicio de mail. Para ello bastará con borrar elfichero mail-service.xml. Si tenemos el servidor en marcha, en la consola debeaparecer un mensaje indicando el repliegue del servicio

INFO [MailService] Mail service 'java:/Mail' removed from JNDI

9.2.6. Despliegue de una fuente de datos

Vamos a desplegar una fuente de datos en el dominio y a hacer que la aplicaciónTestJBoss acceda a ella:

1. Copiar el driver de mysql al directorio lib del dominio "especialista". Es necesariorearrancar el servidor para que los cambios surtan efecto.

2. Crear un fichero biblioteca-ds.xml, con el contenido adecuado para acceder a labase de datos del proyecto de integración. Consultad los apuntes para ver el formatodel fichero

3. Copiar el biblioteca-ds.xml al directorio "deploy" del dominio "especialista". Si elservidor se está ejecutando debería aparecer en la consola la creación de la fuente dedatos y el nombre JNDI asignado

INFO [ConnectionFactoryBindingService] Bound ConnectionManager'jboss.jca:service=DataSourceBinding,name=BibliotecaDS' to JNDIname 'java:BibliotecaDS'

4. Copiar el contenido del siguiente JSP al index.jsp de la aplicación "TestJBoss".Observa que dicho JSP accede a la fuente de datos recién creada bajo el nombrejava:BibliotecaDS y muestra una lista de usuarios de la biblioteca. Desplegar denuevo la aplicación generando el .war y copiándolo en el directorio "deploy" deldominio "especialista" como ya has hecho antes. Comprueba que se muestracorrectamente la lista de usuarios.

<%@page import="javax.naming.*,javax.sql.*,java.sql.*"%><%

Context initCtx = new InitialContext();DataSource ds = (DataSource)

initCtx.lookup("java:BibliotecaDS");Connection con = ds.getConnection();Statement sql = con.createStatement();ResultSet rs = sql.executeQuery("select * from usuario");

%><%@page contentType="text/html" pageEncoding="UTF-8"%><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">

<html><head>

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">



<title>Lista de usuarios</title></head><body>

<h1>Usuarios de la biblioteca</h1><table border="0">

<tr><th>Nombre y apellidos</th><th>tipo</th>

</tr><% while (rs.next()) {%><tr><td>

<%=rs.getString("nombre")%><%=rs.getString("apellido1")%><%=rs.getString("apellido2")%>

</td><td>

<%=rs.getString("tipoUsuario")%></td></tr><%}%>

</table></body>

</html><%con.close();%>

9.3. Seguridad en JBoss

9.3.1. El modelo de seguridad de JBoss

La seguridad en JBoss se implementa en un módulo denominado JBoss SX (SecurityeXtension). Dicho módulo está construido sobre JAAS (Java Authentication andAuthorization Service), la tecnología estándar en Java EE para implementación deseguridad. JBoss SX incluye diversos mecanismos de autentificación y autorización quehacen que no sea necesario trabajar directamente con JAAS salvo que nuestrasnecesidades sean muy particulares.

El siguiente diagrama muestra los principales elementos de JBoss SX y las relaciones quehay entre ellos. Supongamos que desde el exterior se accede a un componente de una denuestras aplicaciones (sea un servlet, un EJB, un servicio web u otro) que requiere deautentificación y/o autorización. JBoss SX interceptará automáticamente la petición yentrará en acción el dominio de seguridad (security domain) asociado. El dominio deseguridad se basa en uno o más módulos de login (login modules), que autentifican y/oautorizan al usuario actual contra un determinado almacén (security datastore) quecontiene los passwords y/o roles de los usuarios. Dicho almacén puede ser tan simplecomo un fichero de texto o tan complejo como un directorio LDAP.



JBoss SX

Nótese que los dominios de seguridad son globales al servidor, es decir, pueden serusados por más de una aplicación. Por eso se enlazan con el árbol JNDI y la aplicación serefiere al dominio por su nombre JNDI.

9.3.1.1. Definición de un "security domain"

Los dominios de seguridad se crean por defecto en el fichero de configuraciónlogin-config.xml, en el directorio server/xxx/conf, donde xxx es el nombre de laconfiguración actual del servidor (recordemos que estaban default, all, minimal yotras).

El MBean XMLConfig controla la localización de este fichero. De este modo, a través dela consola JMX podemos ver información sobre la seguridad de las aplicaciones y porejemplo cambiar el nombre o localización física de login-config.xml. Nosotros, noobstante, usaremos la configuración por defecto.

Si abrimos el fichero, observaremos que en él se define un conjunto de<application-policy> que son precisamente los dominios de seguridad. Cada dominiotiene un nombre asociado, y un conjunto de <login-module>. Por ejemplo, al final delfichero de configuración login-config.xml podemos añadir un dominio de pruebacomo el siguiente:

<application-policy name="PruebaJBoss"><authentication>

<login-module



code="org.jboss.security.auth.spi.UsersRolesLoginModule"flag="required" />

</authentication></application-policy>

Este dominio usa como módulo de login el UsersRolesLoginModule, unaimplementación muy sencilla que toma los usuarios de un par de ficheros .properties,uno definiendo usuarios y passwords (users.properties) y otro usuarios y roles(roles.properties). Estos ficheros se pueden colocar en cualquier lugar delCLASSPATH de la aplicación, y permiten probar la autentificación de manera sencilla.

El flag="required" necesita de cierta explicación. JBoss implementa lo que denominauna pila de autentificación ("authentification stack"). La idea consiste en que podemosusar varios módulos de login de modo, por ejemplo, que si el usuario no se puedeautentificar a través de uno de ellos se intente con otro. En el ejemplo el atributoobligatorio flag tiene valor required, indicando que si falla la autentificación con estemódulo, el proceso de autentificación debe fallar. En este caso solo hay un móduloconfigurado, pero podríamos tener varios y por ejemplo marcarlos comoflag="sufficient". En este caso, con que la autentificación tenga éxito en uno de ellosbastaría. Veremos un ejemplo de esto posteriormente, aunque hay más modos defuncionamiento aparte de "required" y "sufficient". Se recomienda consultar la guía deconfiguración de JBoss para una información más detallada.

Si eres observador, te habrás dado cuenta de que en el login-config.xml original deJBoss viene un dominio muy similar al que hemos definido nosotros, con la únicadiferencia del nombre, que es other. Este es un nombre especial que en JBoss seconsidera como el dominio por defecto, que se emplea cuando una aplicación requiereseguridad JavaEE pero no tiene un dominio específico asociado (en el siguiente apartadoveremos cómo se hace esta asociación).

JBoss proporciona varias implementaciones alternativas de login module. Nosotrosveremos la autentificación/autorización contra base de datos y LDAP.

9.3.1.2. Enlace del "security domain" con la aplicación

Cada aplicación que use seguridad JavaEE debe configurarse a través de un descriptor dedespliegue XML adicional para referenciar uno de los dominios definidos.

Dicho descriptor se debe llamar jboss-web.xml y colocarse también en el WEB-INF de laaplicación, al igual que el web.xml estándar. En este archivo se especifica el nombreJNDI del dominio de seguridad. Los nombres JNDI asociados a la seguridad en JBossllevan el "prefijo" java:/jaas, seguido del nombre del dominio tal y como se definió enlogin-config.xml (recordemos que en nuestro ejemplo era PruebaJBoss).

<!DOCTYPE jboss-web PUBLIC"-//JBoss//DTD Web Application 2.4//EN"



"http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd"><jboss-web>

<security-domain>java:/jaas/PruebaJBoss</security-domain></jboss-web>

9.3.2. Autentificación contra una base de datos

La implementación que usa JBoss para esta tarea es DatabaseServerLoginModule. Lainformación de usuarios, passwords y roles puede estar en la base de datos de la formaque queramos, siempre que podamos extraerla mediante SQL en el formato que esperaJBoss.

JBoss usa dos consultas SQL para extraer la información:

• La que obtiene el password (PrincipalsQuery) nos debe devolver un registro con unúnico campo que será el password.

• La consulta de los roles (RolesQuery) debe devolver un conjunto de registros cadauno con dos campos. El primero debe ser el rol del usuario. Para permisos de usuarioconvencionales, el segundo campo debe ser el valor literal Roles. Este último valoren realidad depende de la configuración de JAAS, aunque habitualmente no esnecesario cambiarla.

Además de las consultas, para completar la configuración debemos referenciar la fuentede datos para conectar con la base de datos con la información de autentificación.

<application-policy name="seguridadBD"><authentication>

<login-modulecode="org.jboss.security.auth.spi.DatabaseServerLoginModule"

flag="required"><module-option

name="dsJndiName">java:/DefaultDS</module-option><module-option name="principalsQuery">

select password from USUARIOS where login=?</module-option><module-option name="rolesQuery">

select rol, 'Roles' from USU_ROLES where login=?</module-option>

</login-module></authentication>

</application-policy>

En el ejemplo anterior, usamos como fuente de datos una de nombre DefaultDS, que porsupuesto, suponemos definida en algún fichero ***-ds.xml tal y como vimos en lasesión anterior. Por otro lado, estamos suponiendo que la tabla USUARIOS contiene unregistro por usuario, incluyendo login y password y que la tabla USU_ROLES relacionalogin con rol.



9.3.3. LDAP

Muchas organizaciones mantienen los datos de sus usuarios en un directorio LDAP.JBoss nos da la posibilidad de autentificar los usuarios de nuestras aplicaciones contraeste servidor a través de un módulo de login predefinido.

Supongamos que tenemos la estructura LDAP mostrada en la figura. El nodo Personal,de tipo OrganizationalUnit contiene todos los empleados de la organización. Cadaempleado está en un nodo de tipo Person y uidObject que contiene todos sus datos:nombre, apellidos, etc, incluyendo login (atributo uid) y password (userpassword). Losroles están almacenados en un nodo aparte. Cada rol es un objeto groupOfNames

conteniendo una referencia a los usuarios que tienen ese rol (contiene su identificadorúnico, o DN).

árbol de LDAP ejemplo

árbol LDAP

Formato LDIF

dn: dc=example,dc=comobjectClass: domainobjectClass:

extensibleObjectobjectClass: topdc: example

dn:uid=pperez,ou=Personal,dc=example,dc=com

objectClass: personobjectClass: uidObjectobjectClass: topcn: Pedrosn::

UMOpcmV6IE1hcnTDrW4=uid: pperezuserpassword:: cGVyZXpw

dn:uid=acuenca,ou=Personal,dc=example,dc=com

objectClass: personobjectClass: uidObjectobjectClass: topcn: Alfonsosn: Cuenca Richardsonuid: acuencauserpassword::

Y3VlbmNhYQ==

dn:uid=elopez,ou=Personal,dc=example,dc=com

objectClass: personobjectClass: uidObjectobjectClass: topcn: Eduardosn::

TMOzcGV6IEZpZ3VlcmVz



uid: elopezuserpassword:: bG9wZXpl

dn:ou=roles,dc=example,dc=com

objectClass:organizationalUnit

objectClass: topou: roles

dn:cn=admin,ou=roles,dc=example,dc=com

objectClass:groupOfNames

objectClass: topcn: adminmember:

uid=acuenca,ou=Personal,dc=example,dc=commember:

uid=elopez,ou=Personal,dc=example,dc=com

dn:cn=usuario,ou=roles,dc=example,dc=com

objectClass:groupOfNames

objectClass: topcn: usuariomember:

uid=acuenca,ou=Personal,dc=example,dc=commember:

uid=elopez,ou=Personal,dc=example,dc=commember:

uid=pperez,ou=Personal,dc=example,dc=com

dn:ou=Personal,dc=example,dc=com

objectClass:organizationalUnit

objectClass: topou: Personal

Nota:En el ejemplo se usa terminología estándar de LDAP. Una explicación más detallada de LDAPestá fuera del alcance de este tema. No obstante, no es estrictamente necesaria para entender elfuncionamiento del módulo LDAP de JBoss.

En la configuración del módulo de login LDAP debemos especificar cómo podemosobtener el identificador completo del usuario (en argot LDAP el DN o distinguishedname, que se forma concatenando los identificadores de todos los nodos desde la raízhasta el objeto). En nuestro caso, cada usuario tiene un identificador del tipouid=su_login,ou=Personal,dc=example,dc=com. En JBoss este identificador se divideen tres partes: el prefijo(propiedad de configuración principalDNPrefix), el login del



usuario (que deberá introducir para autentificarse) y el sufijo (propiedadprincipalDNSuffix). En nuestro caso está claro que el prefijo será "uid=" y el sufijo",ou=Personal,dc=example,dc=com".

Por otro lado, hay que obtener los roles del usuario. Podemos buscar los rolesespecificando parte de su identificador (o DN). En este caso, todos los roles se agrupanbajo ou=roles,dc=example,dc=com. El nombre del rol lo define en nuestro caso elatributo cn (en JBoss roleAttributeID). Y finalmente, cada usuario dentro del rol seespecifica con el atributo member (en JBoss uidAttributeID). Nótese que incluimos elnombre completo de cada usuario (o sea, su DN), por lo que la propiedad matchOnUserDN

será true. La configuración de la búsqueda de roles LDAP puede ser compleja yrecomendamos consultar la documentación de JBoss.

La configuración en login-config.xml quedaría así:

...<application-policy name="seguridadLDAP">

<authentication><login-module

code="org.jboss.security.auth.spi.LdapLoginModule"flag="required">

<module-optionname="java.naming.factory.initial">

com.sun.jndi.ldap.LdapCtxFactory</module-option>



<module-option name="java.naming.provider.url">ldap://localhost:10389/

</module-option><module-option

name="java.naming.security.authentication">simple

</module-option>



<module-option name="principalDNPrefix">uid=

</module-option><module-option name="principalDNSuffix">

,ou=Personal,dc=example,dc=com</module-option>

<module-option name="rolesCtxDN">

ou=roles,dc=example,dc=com</module-option>



<module-optionname="uidAttributeID">member</module-option>

<module-option

name="matchOnUserDN">true</module-option>

<module-option

name="roleAttributeID">cn</module-option><module-option

name="roleAttributeIsDN">false</module-option></login-module>

</authentication></application-policy>...

En este ejemplo, la estructura LDAP es muy sencilla. Si la información contenida en elárbol LDAP de nuestra organización no se puede adaptar fácilmente a la forma de trabajarde este módulo de login, tendremos que escribir un módulo propio usando el API deJBoss.

9.3.4. Combinar varios módulos de login

Como el LDAP es algo externo a las aplicaciones web, es normal que los administradoresde LDAP se muestren reticentes a introducir en el directorio la información de roles.JBoss puede solucionar el problema combinando la autentificación en LDAP con laautorización (verificación de roles) basada en otro mecanismo, por ejemplo en base dedatos. Esto se denomina password stacking y es realmente sencillo de configurar en loscasos básicos. Basta con incluir dentro de la política de autentificación asociada a nuestraaplicación más de un módulo de login, especificando que queremos usar passwordstacking. JBoss intentará usar el primer módulo para autentificar (en nuestro caso LDAP)y si no consigue los roles pasará a usar el/los siguiente/s módulo/s.

<application-policy name="LDAPconBD"><authentication>

<login-modulecode="org.jboss.security.auth.spi.LdapLoginModule"

flag="required"><module-option name="java.naming.factory.initial">

com.sun.jndi.ldap.LdapCtxFactory</module-option><module-option name="java.naming.provider.url">

ldap://localhost:10389/</module-option><module-option

name="java.naming.security.authentication">simple

</module-option><module-option

name="principalDNPrefix">uid=</module-option><module-option name="principalDNSuffix">

,ou=Personal,dc=example,dc=com</module-option><module-option name="password-stacking">

useFirstPass</module-option>

</login-module><login-module

code="org.jboss.security.auth.spi.DatabaseServerLoginModule"flag="required"><module-option

name="dsJndiName">java:/PruebaDS</module-option><module-option name="principalsQuery">

select password from usuarios wherelogin=?

</module-option><module-option name="rolesQuery">

select rol, 'Roles' from usu_roles wherelogin=?

</module-option><module-option name="password-stacking">

useFirstPass</module-option></login-module>

</authentication></application-policy>

9.4. Ejercicios de seguridad de aplicaciones en JBoss

9.4.1. Autentificación contra una base de datos

Vamos a añadir seguridad declarativa a la aplicación de prueba de la sesión anterior,TestJBoss. Autentificaremos a los usuarios con la información de la base de datos de labiblioteca, del proyecto de integración.

1. Suponemos ya creada la fuente de datos BibliotecaDS de la sesión anterior. Si no lohiciste, haz el último ejercicio de la sesión anterior (evidentemente hace falta unafuente de datos para poder autentificarse contra una BD).

2. Cambia la configuración del web.xml de la aplicación para proteger todas las URLs.Solo deben tener acceso los usuarios con rol "bibliotecario". Ya viste cómo se hacíaesto en Tomcat y Glassfish, aquí es exactamente igual.

3. Añade un nuevo dominio de seguridad: un nuevo application-policy con nombreseguridadBD en el archivo login-config.xml. Fijate en el ejemplo de los apuntespara deducir los valores a poner. Necesitarás cambiar los datos de dsJndiName,principalsQuery y rolesQuery para que encajen con la base de datos de biblioteca(piénsate bien el SQL de las dos queries, no es nada difícil, pero no es igual que el delejemplo de los apuntes)

4. Crea el fichero descriptor de despliegue jboss-web.xml. Dada la falta de integraciónde NetBeans con JBoss 5, tendrás que crearlo tú y editarlo a mano. Puedes tomar elcontenido de los apuntes. Fijate que el nombre del dominio coincida con el que tieneel application-policy creado en el paso anterior (con la única diferencia del prefijojava:/jaas/)

5. Compila la aplicación (Build en NetBeans) y despliégala a JBoss (copiando el .war aldirectorio "deploy" del dominio.

6. Comprueba ahora que solo se puede ver el listado de usuarios si te autentificas como



bibliotecario (login:"b",password:"b" o "bibliotecario",bibliotecario")

9.4.2. Autentificación con LDAP

En las plantillas de la sesión se incluye un servidor LDAP llamado ApacheDS. Noobstante, el servidor carece de GUI, por lo que también se incluye un programa paraexplorar el árbol LDAP llamado JXExplorer-

Para instalar ApacheDS basta con descomprimirlo en cualquier carpeta. Para ponerlo enmarcha, ejecutar el archivo apacheds.sh. No cierres la terminal en la que se ejecuta elservidor para que éste no se pare.

Lo mismo ocurre con JXExplorer, simplemente descomprímelo en cualquier directorio.Para arrancarlo, ejecutar el archivo jxplorer.sh. Tenemos que configurar la conexióncon el servidor LDAP e insertar datos.

1. Elegimos la opción File > Connect

2. En el cuadro de diálogo introducir los valores de la figura. El password es "secret".

conexión con servidor LDAP en JXPlorer

3. Para insertar nuestros datos en LDAP elegimos la opción LDIF > Import File eimportamos el archivo ejemploLDAP.ldif de las plantillas de la sesión. Se creará elárbol LDAP que aparece en la figura (es el mismo que el de los apuntes, pero los rolesson "bibliotecario" y "socio" en lugar de "admin" y "registrado". Así podemos usarlodirectamente con nuestra aplicación "TestJBoss".



conexión con servidor LDAP en JXPlorer

4. Añadir el application-policy que usa LDAP de los apuntes, al ficherologin-config.xml del dominio especialista. Recordad que para que los cambios eneste archivo surtan efecto, hay que rearrancar el servidor.

5. En jboss-web.xml habrá que referenciar el seguridadLDAP recién creado.6. Comprobar que la autentificación LDAP funciona, entrando como "elopez" con

password "lopeze".



servidores de aplicaciones - ua · • jboss (redhat) • glassfish (sun) • websphere (ibm) se...

Documents