150 likes | 360 Views
Control de acceso en Java EE. Seguridad en Java. Java incluye mecanismos de seguridad con distintas finalidades: Controlar los recursos a los que pueden acceder programas Java ( applets , etc.) Asegurar la seguridad en las comunicaciones. Seguridad en Java EE.
E N D
Seguridad en Java • Java incluye mecanismos de seguridad con distintas finalidades: • Controlar los recursos a los que pueden acceder programas Java (applets, etc.) • Asegurar la seguridad en las comunicaciones
Seguridad en Java EE • Java EE también incluye mecanismos de seguridad para controlar el acceso de los usuarios a las aplicaciones web. Estos mecanismos incluyen a algunos de los anteriores
Control de acceso en Java EE • Cualquier componente web (servleto página JSP) o EJB puede limitar los usuarios que pueden acceder a la misma • Java EE incluye clases y mecanismos (anotaciones, etc.) para simplificar la implementación del control de acceso de usuarios
Control de acceso en Java EE, II • El control de acceso se puede realizar por diversos procedimientos: usuario y clave, certificado digital, directorio de nombres, etc. • Cuando una componente web especifica limitaciones de acceso mediante usuario y clave y un usuario intenta acceder a ella, la aplicación web correspondiente muestra en primer lugar un formulario o ventana de diálogo que le solicita los datos requeridos. Si los datos son correctos, le permite el acceso; en caso contrario, le muestra una ventana o formulario de error.
Los servidores Java EE incluyen mecanismos para la definición de dominios de autentificación de distintos tipos (mediante certificado, comprobación de nombre de usuario y clave en un fichero o en una base de datos, etc.)
Para especificar el control de acceso en una aplicación Java EE es preciso hacer dos cosas: • Incluir en un dominio de seguridad del servidor la información referente a los grupos de usuarios (identificador, contraseña, roles, etc.) • Incluir en las componentes web y EJBs apropiadas anotaciones que determinen sus limitaciones de acceso, o bien incluir la información correspondiente en el fichero web.xml
Una aplicación sencilla con limitación de acceso tiene las siguientes características: • Los servlets con limitaciones de acceso se anotan mediante @ServletSecurity( @HttpConstraint( rolesAllowed={…}, transportGuarantee=“…”)) (transportGuarantee puede ser CONFIDENTIAL o NONE)
… tiene las siguientes características: • El fichero web.xml indica los roles existentes: <security-role> <role-name>coordinador</role-name> </security-role> <security-role> <role-name>tecnico</role-name> </security-role>
… tiene las siguientes características: • El servidor tiene activado el dominio de seguridad (realm) file y registrados los usuarios, con su grupo y contraseña correspondientes • El servidor tiene configurada la seguridad con asignación por defecto de principal a rol (default principal to role mapping) Lo anterior evita tener que definir a qué rol de la aplicación corresponde cada grupo de usuarios del servidor
Extensiones y variaciones: • Se puede utilizar un formulario en lugar de la ventana de diálogo por defecto para la autentificación • …
<login-config> <auth-method>FORM</auth-method> <realm-name>file</realm-name> <form-login-config> <form-login-page>/login.xhtml</form-login-page> <form-error-page>/error.xhtml</form-error-page> </form-login-config> </login-config>
Extensiones y variaciones: • … • Se pueden especificar los roles y el tipo de transporte en el fichero web.xml en lugar de utilizar anotaciones
<security-constraint> <web-resource-collection> <web-resource-name>retail</web-resource-name> <url-pattern>/acme/retail/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> …
… <auth-constraint> <role-name>CLIENT</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>