Download Control de acceso en Java EE

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
• 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-loginpage>
<form-error-page>/error.xhtml</form-errorpage>
</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-resourcename>
<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>
<transportguarantee>CONFIDENTIAL</transportguarantee>
</user-data-constraint>
</security-constraint>