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>