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 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 (servlet o 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> <role-name>tecnico</role-name>

… 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>