Your SlideShare is downloading. ×
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Tema 7
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Tema 7

141

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
141
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. II Curso Online JAVA-J2EE TEMA 7 J2EE avanzadoAutor: PCYTA / Centro de Excelencia de Software Libre de Castilla-La ManchaVersión: 1.0Fecha: Revisado 07-02-2008 11:46Licencia: CC-by-sa 2.5
  • 2. 0 LicenciaUsted es libre de: Copiar, distribuir y comunicar públicamente la obra Hacer obras derivadasBajo las condiciones siguientes: Reconocimiento. Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan eluso que hace de su obra). Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. • Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. • Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor • Nada en esta licencia menoscaba o restringe los derechos morales del autor.Para ver la licencia visite:http://creativecommons.org/licenses/by-sa/2.5/es/legalcode.es6 de febrero de 2008 Tema 7 2
  • 3. UNIDAD VII. J2EE AVANZADO0 Licencia...........................................................................................................................................21 Seguridad en las aplicaciones Web...............................................................................................4 1.1 Introducción a la seguridad en las aplicaciones Web...............................................................4 1.2 Métodos de autenticación web.................................................................................................42 Patrones de diseño J2EE...............................................................................................................7 2.1 Introducción a los patrones J2EE.............................................................................................7 2.2 Resumen patrones J2EE...........................................................................................................93 Otros Web Frameworks..............................................................................................................11 3.1 JSF, Spring MVC, Stripes, Structs 2, Tapestry, Ticket...........................................................126 de febrero de 2008 Tema 7 3
  • 4. 1 Seguridad en las aplicaciones Web 1.1 Introducción a la seguridad en las aplicaciones WebCuando desarrollamos o desplegamos una aplicación en un entorno de producción es probable quetengamos que tener en cuenta ciertas cuestiones relativas a la seguridad.Primero, es posible que nuestra aplicación solicite al usuario que pruebe su identidad, esto sedenomina autenticación. Normalmente, se suele realizar mediante la introducción por parte delusuario de su identificador (usuario) y una clave asociada (contraseña). Mediante la autenticaciónnos aseguramos de que el usuario es quien dice ser.Una vez autenticado un usuario, el siguiente paso es la autorización. Mediante la autorizaciónnos vamos a asegurar de que un usuario determinado sólo tiene acceso a los recursos a los quese le quiera dar acceso. Normalmente, esto se consigue manteniendo unas tablas que nos indicanque acciones puede realizar un usuario determinado.Por último, tenemos que tener en cuenta la confidencialidad de los datos, es decir, que los datosúnicamente tendrían que ser accesibles por la persona/s adecuadas.Una vez definidos los conceptos de autenticación, autorización y confidencialidad de los datos,vamos a ver como podemos conseguir estos requisitos de seguridad en la capa web.En primer lugar necesitamos proporcionar un método para recoger la identidad de los usuarios o loque es lo mismo un mecanismo de login. La forma más famosa de login en las aplicaciones web esla utilización de la pareja usuario/contraseña, pero podrían utilizarse también certificados pararealizar la autenticación.Una vez que la información para autenticarse es aportada por el usuario necesitamos enviarla desdeel navegador al servidor. En este paso estamos hablando de confidencialidad, y la forma de realizarel transporte de forma segura es mediante SSL.Cuando el servidor reciba esta información (usuario/contraseña) necesita verificarla contra unrepositorio (base de datos, fichero plano, servidor LDAP, etc.). Este repositorio se denomina realm.Un realm se encarga de mantener la información relacionada con los usuarios, contraseñas yroles.Además, es recomendable que los servidores también mantengan la información relacionada con elcontrol de acceso a los recursos (autorización), deben permitir la definición de que tipo de usuarios(roles) pueden acceder a que recursos. 1.2 Métodos de autenticación webEn este apartado vamos a resumir los dos esquemas de seguridad web más importantes:Autenticación Básica (BASIC) y Autenticación basado en Formulario (FORM).La diferenciaentre estos dos métodos básicamente está en la forma en que el navegador recoge la identificacióndel usuario. En el método Basic el navegador utiliza una ventana de diálogo propia y en el métodoForm la pantalla de autenticación es un fichero (HTML o JSP) que tiene un formulario con unoscampos predefinidos.Autenticación Básica (BASIC).Los pasos para securizar una aplicación web con este método son los siguientes:6 de febrero de 2008 Tema 7 4
  • 5. 1. Definir los usuarios, contraseñas y roles (realms). La definición de los realms son específicos de cada servidor (Tomcat, Weblogic, etc) y pueden definirse realms en ficheros planos, bases de datos o servidores LDAP. Para Tomcat, el realm por defecto es un fichero que se denomina tomcat-users.xml y que se encuentra en el directorio conf. A continuación hay un ejemplo del contenido de este fichero: <?xml version="1.0" encoding="UTF-8"?> <tomcat-users> <role rolename="Administrador"/> <role rolename="Usuario"/> <user username="admin" password="admin" roles="Administrador,Usuario"/> <user username="juan" password="juan" roles="Usuario"/> </tomcat-users> 2. Especificar los recursos (URLs) que tienen restricciones de acceso. Los parámetros de securización en la aplicación web se definen dentro del fichero web.xml. Para establecer la autenticación Básica se utilizan las siguientes etiquetas: <security-constraint> <web-resource-collection> <web-resource-name>Admin</web-resource-name> <url-pattern>/HolaAdministrador</url-pattern> <http-method>POST</http-method> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>Administrador</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> La etiqueta <transport-guarantee> cuando tiene el valor CONFIDENTIAL sirve para definir que las URLs protegidas serán accesibles a través de SSL, con NONE se hace todo sin SSL. 3. Parametrizar la aplicación web para que utilice la autenticación Basica. Al igual que antes, esta definición se realiza también en el fichero web.xml: <web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>default</realm-name> </login-config> ... </web-app>6 de febrero de 2008 Tema 7 5
  • 6. Autenticación basada en Formulario (FORM).Los pasos 1 y 2 anteriores también se tienen que realizar para éste método, además tenemos querealizar: 1. Parametrizar la aplicación web para que utilice la autenticación basada en FORM. Los parámetros de securización en la aplicación web se definen dentro del fichero web.xml. Para establecer este método se utilizan las siguientes etiquetas: <web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name>default</realm-name> </login-config> ... </web-app> 2. Crear los ficheros necesarios para la página de login y la página de error. La página de login puede ser un fichero HTML o JSP que contiene el siguiente formulario: <FORM ACTION="j_security_check" METHOD="POST"> <INPUT TYPE="TEXT" NAME="j_username"> <INPUT TYPE="PASSWORD" NAME="j_password"> </FORM> La página de error también es un fichero HTML o JSP cuyo contenido no está prefijado.6 de febrero de 2008 Tema 7 6
  • 7. 2 Patrones de diseño J2EE 2.1 Introducción a los patrones J2EETal y como vimos en el Tema 1 un patrón de diseño define una forma de resolver un problemaque se presenta en un contexto determinado.En esta lección vamos a ver algunos de los patrones J2EE que se definen en el libro Core J2EEPatterns: Best Practices and Design Strategies escrito por arquitectos del Sun Java Center(http://java.sun.com/blueprints/corej2eepatterns/index.html).En este libro se realiza una clasificación de patrones atendiendo al modelo de arquitectura en capas,distinguiendo entre capa de presentación, capa de negocio y capa de integración. Se incluyen 15patrones en el catálogo que se agrupan de la siguiente forma: Capa de Presentación Intercepting Filter; Front Controller; View Helper; Composite View; Service to Worker; Dispatcher View. Capa de Negocio Business Delegate; Value Object; Session Facade; Composite Entity; Value Object Assembler, Value List Handler; Service Locator. Capa de Integración Data Access Object; Service ActivatorEn la capa de presentación se encuentran los patrones relacionados con la tecnología JSP/Servlets,la capa de negocio contiene los patrones relacionados con la tecnología EJB y en la capa deintegración contiene la tecnología relacionada con JDBC y JMS.En la siguiente imagen podemos ver como se interrelacionan los patrones J2EE:6 de febrero de 2008 Tema 7 7
  • 8. 6 de febrero de 2008 Tema 7 8
  • 9. 2.2 Resumen patrones J2EEEn este apartado simplemente os voy a hacer un pequeño resumen de los patrones J2EE queconsidero más importantes.Intercepting FilterSe utiliza para ‘interceptar’ peticiones (request) y respuestas (response) y aplicarles un filtrodeterminado, por ejemplo, añadir logging, trazas de depuración, etc. Estos filtros pueden serañadidos o eliminados de forma declarativa, pudiendo aplicarse más de un filtro de formacorrelativa a la declaración realizada.Front ControllerProporciona un control centralizado para gestionar las peticiones que se realizan en la capa depresentación. El controlador se encarga de recibir y gestionar las peticiones, centralizando lainvocación de los servicios de seguridad, delegando el procesamiento de la lógica de negocio,controlando la elección de una vista apropiada, el manejo de errores y el control de la selección deestrategias de creación del contenido de respuesta.View HelperÉste patrón enfatiza en la separación entre el código para la vista y el código de la lógica denegocio. Se sugiere utilizar Helper para encapsular la lógica relacionada con la recogida deparámetros, validaciones y adaptación de los datos enviados al modelo. Este componentenormalmente delega la lógica de negocio utilizando un patrón Business Delegate mientras que lavista puede encontrarse compuesta de múltiples subcomponentes.Composite ViewPropone utilizar vistas compuestas que se componen de varias subvistas atómicas. Cadacomponente de la plantilla se podría incluir dinámicamente dentro del total y la distribución de lapágina se maneja independientemente del contenido.Business DelegateReduce el acoplamiento entre capas y proporciona un punto de entrada único para acceder a losservicios que ofrece la capa de negocio. Este patrón podría también implementar el cacheo deconsultas comunes para mejorar el rendimiento. Un Business Delegate normalmente utiliza unpatrón Service Locator que se va a encargar de los objetos del servicio, como EJBS y JMS.Session FaçadeEste patrón recomienda usar un bean de sesión como una fachada (facade) para encapsular lacomplejidad de las interacciones entre los objetos de negocio participantes en un flujo de trabajo. ElSession Facade maneja los objetos de negocio y proporciona un servicio de acceso uniforme a losclientes.Value ObjectEl patrón Value Object proporciona las mejores técnicas y estrategias para intercambiar datos entrelas diferentes capas. Este patrón intenta reducir el número de llamadas remotas y evitar lasobrecarga asociada que produce obtener datos de la capa de negocio.Value List HandlerSe puede utilizar un Value List Handler para controlar las búsquedas, hacer un caché con los6 de febrero de 2008 Tema 7 9
  • 10. resultados, y proporcionar los resultados al cliente en una hoja de resultados cuyo tamaño ydesplazamiento cumpla los requerimientos del cliente.DAO (Data Access Object)Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente dedatos. El DAO maneja la conexión con la fuente de datos para obtener y almacenar datos. Para estudiar en detalle cada uno de ellos (contexto, problema, estrategias de solución y lasconsecuencias) podéis ir pinchando sobre el nombre de cada patrón en la siguiente imagenhttp://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html.La versión en castellano de dicha documentación la podéis encontrar en la página de Java encastellano(http://www.programacion.com/java/tutorial/patrones/ yhttp://www.programacion.com/java/tutorial/patrones2/).6 de febrero de 2008 Tema 7 10
  • 11. 3 Otros Web FrameworksLa cantidad de web frameworks para J2EE que nos podemos encontrar actualmente en el mercadoempieza a ser tan numerosa que podemos llegar a perdernos en el momento de tener que elegir cualdebemos utilizar.Como ejemplo, os envío el link de un post donde Matt Raible intenta dar su opinión sobre que webframework se debe utilizar a lo que recibe una serie de respuestas donde cada uno de losprogramadores expone que es mejor la que él utiliza(http://raibledesigns.com/rd/entry/re_what_web_application_framework).En este foro os puedo enumerar que se comentan los siguiente frameworks: 1. Struts, http://struts.apache.org/. 2. JSF, http://java.sun.com/javaee/javaserverfaces/. 3. Spring – Spring MVC, http://www.springframework.org/. 4. Shale, http://shale.apache.org/. 5. WebWork, http://sf.net/projects/opensymphony/. 6. Struts 2 (Struts/WebWork), http://struts.apache.org/2.0.9/index.html. 7. Tapestry, http://tapestry.apache.org/. 8. Click. http://click.sourceforge.net/. 9. Stripes, http://mc4j.org/confluence/display/stripes/Home. 10.Wicket, http://wicket.apache.org/. 11.Echo2, http://www.nextapp.com/platform/echo2/echo/. 12.Thinwire, http://www.thinwire.com/.Como podéis ver, son bastante como para dejarte en la duda de cual utilizar e, incluso, llegar adecidir continuar con el que ya tienes que al menos lo controlas.En el siguiente apartado, os voy a presentar las ventajas e inconvenientes de unos cuantos de éstosframeworks, información que he extraído de un documento de Matt Raible donde los compara(ComparingJavaWebFrameworks.pdf).6 de febrero de 2008 Tema 7 11
  • 12. 3.1 JSF, Spring MVC, Stripes, Structs 2, Tapestry, Ticket FRAMEWORK VENTAJAS INCONVENIENTES - Es parte del estándar J2EE. - Los JSPs terminan siendo una ‘sopa’ - Permite realizar desarrollos de forma de etiquetas. rápida y sencilla. - No funciona bien con restricciones deJSF - Existen multitud de librerías de seguridad. componentes desarrollados. - No existe una única implementación única. - Facilidades para realizar - Multitud de XML para realizar la validaciones, binding entre vista y configuración. modelo, etc. - Se diría que es incluso demasiado - Integración con múltiple vistas flexible.Spring MVC JSP/JSTL, Tiles, Velocity, etc. - No tiene soporte para Ajax - Mediante el patrón IoC (Inversion of predefinido. Control) que utiliza Spring se facilitan las pruebas. - No utiliza XML para la configuración - La comunidad ‘stripe’ es pequeña. sino un convenio para el nombrado de - Este framework no tiene un desarrollo clases. tan activo como otros.Stripes - Existe buena documentación. - Las direcciones URLs se encuentran - Una comunidad de desarrollo ‘hard-coded’ en los ActionBeans, es entusiasta. decir, directamente escritas dentro del código de los ActionBeans. - Arquitectura sencilla y fácilmente - La documentación se encuentra mal extensible. organizada. - La librería de etiquetas se pueden - Se tiene una concentración excesivaStruts 2 personalizar con FreeMarker o en la nuevas funcionalidades. Velocity. - Las búsquedas de documentación te - Se puede definir la navegación remiten a la versión 1.x. basada en Controladores o basada en páginas. - Es un framework muy productivo una - La documentación es más conceptual vez que se aprende. que pragmática. - Las plantillas son HTML, lo que es - La curva de aprendizaje es alta.Tapestry muy conveniente si se trabaja - Los ciclos definidos para lanzar conjuntamente con diseñadores nuevas versiones son excesivamente gráficos. largos. - En cada nueva versión se aportan gran cantidad de innovaciones. - Recomendado para desarrolladores - Las plantillas HTML se mezclan con Java, no para desarrolladores web. el código Java.Wicket - Las páginas y las vistas se encuentran - Se necesita tener un buen nivel de altamente enlazadas. programación orientada a objetos. - Participa una comunidad muy activa - Todo se hace en Java (Ticket Way). en dicho framework.6 de febrero de 2008 Tema 7 12
  • 13. 6 de febrero de 2008 Tema 7 13

×