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