Está en la página 1de 15

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 tambin 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
pgina JSP) o EJB puede limitar los
usuarios que pueden acceder a la misma
Java EE incluye clases y mecanismos
(anotaciones, etc.) para simplificar la
implementacin 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 aplicacin
web correspondiente muestra en primer lugar un
formulario o ventana de dilogo 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 definicin de
dominios de autentificacin de distintos
tipos (mediante certificado, comprobacin
de nombre de usuario y clave en un
fichero o en una base de datos, etc.)

Para especificar el control de acceso en


una aplicacin Java EE es preciso hacer
dos cosas:
Incluir en un dominio de seguridad del
servidor la informacin referente a los grupos
de usuarios (identificador, contrasea, roles,
etc.)
Incluir en las componentes web y EJBs
apropiadas anotaciones que determinen sus
limitaciones de acceso, o bien incluir la
informacin correspondiente en el fichero

Una aplicacin sencilla con limitacin de acceso


tiene las siguientes caractersticas:
Los servlets con limitaciones de acceso se anotan
mediante
@ServletSecurity(
@HttpConstraint(
rolesAllowed={},
transportGuarantee=))
(transportGuarantee puede ser CONFIDENTIAL o
NONE)

tiene las siguientes caractersticas:


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


El servidor tiene activado el dominio de seguridad
(realm) file y registrados los usuarios, con su
grupo y contrasea correspondientes
El servidor tiene configurada la seguridad con
asignacin por defecto de principal a rol (default
principal to role mapping)
Lo anterior evita tener que definir a qu rol de la
aplicacin corresponde cada grupo de usuarios
del servidor

Extensiones y variaciones:
Se puede utilizar un formulario en lugar de la
ventana de dilogo por defecto para la
autentificacin

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

También podría gustarte