Seguridad

SEGURIDAD JAVAEE

INTRODUCCIN

Las aplicaciones JavaEE constan de componentes que pueden utilizar tanto recursos protegidos, como recursos no protegidos. A menudo, es necesario proteger algunos recursos para asegurar que slo usuarios autenticados tienen acceso a dichos recursos. La Autorizacin es el proceso que permite establecer un acceso controlado a dichos recursos. El proceso de Autorizacin se basa en la identificacin y en la autenticacin. La identificacin es el proceso que nos permite reconocer una entidad en nuestro sistema y la autenticacin es el proceso que verifica la identidad de dicha entidad (entendiendo como entidad un usuario, dispositivo, proceso, etc). La Autorizacin y la Autenticacin son procesos que no se requieren para una entidad que accede a recursos no protegidos, lo que se conoce comnmente como acceso annimo

INTRODUCCIN

INTRODUCCIN

Usuario autorizado

INTRODUCCIN

CARACTERSTICAS DE LA SEGURIDAD DE APLICACIN

Autenticacin: El medio por el cul las entidades que intervienen en un escenario de comunicacin (por ejemplo, cliente-servidor) se demuestran la una a la otra que estn actuando en nombre de identidades especficas que estn autorizadas para el acceso. Esto asegura que los usuarios son quin dicen ser. Autorizacin o Control de Acceso: El medio por el cul las interacciones con los recursos se limitan a un grupo de usuarios o programas, con el fin de hacer cumplir la integridad, confidencialidad, o las restricciones de disponibilidad. Esto asegura que los usuarios tienen acceso para ejecutar operaciones o acceso a datos.

CARACTERSTICAS DE LA SEGURIDAD DE APLICACIN

Integridad de los datos: El medio usado para demostrar que la informacin no ha sido modificada por un tercero. Por ejemplo, un receptor de los datos enviados sobre una red abierta debe ser capaz de detectar y rechazar los mensajes que hubieran sido modificados despus de haber sido enviados. Esto asegura que slo usuarios autorizados pueden modificar datos. Confidencialidad o Privacidad de Datos: El medio usado para asegurar que la informacin se hace disponible slo para los usuarios que estn autorizados para acceder a ella. Esto asegura que slo usuarios autorizados pueden consultar datos sensibles.

CARACTERSTICAS DE LA SEGURIDAD DE APLICACIN

Non-repudiation: El medio usado para demostrar que un usuario llev a cabo alguna accin. Esto asegura que pueda ser demostrado que determinadas transacciones han ocurrido. Quality of Service (Qos): El medio usado para proporcionar mejores servicios al trfico de red sobre varias tecnologas. Auditora: El medio usado para obtener un registro de eventos relacionados con la seguridad con el fin de evaluar la efectividad de los mecanismos y polticas de seguridad. Para permitir esto, el sistema mantiene un registro de informacin de transacciones y seguridad.

TRABAJANDO CON REINOS, USUARIOS, GRUPOS Y ROLES

DEF. Reino: Para una aplicacin Web, un reino es una base de datos de usuarios y grupos que identifica los usuarios vlidos para la aplicacin Web y que son controlados por la misma poltica de autenticacin. DEF. Usuario: Un usuario es un individuo (o un programa) identificado que ha sido definido en el Servidor de Aplicaciones. En una aplicacin Web, un usuario puede tener un conjunto de roles asociados con esa identidad que le dan derechos de acceso a todos los recursos protegidos por esos roles. Los usuarios pueden ser asociados con un grupo.

TRABAJANDO CON REINOS, USUARIOS, GRUPOS Y ROLES

DEF. Grupo: Un grupo es un conjunto de usuarios autenticados, clasificados por rasgos comunes, definido en un Servidor de Aplicaciones. Por ejemplo, muchos de los clientes de una aplicacin de e-commerce pueden pertenecer al grupo de CLIENTES, mientras que los clientes preferentes (los que ms compran) perteneceran al grupo de PREFERENTES. Categorizar usuarios en grupos hace ms fcil el control de acceso cuando el sistema cuenta con un gran nmero de usuarios. Un grupo en el servidor de aplicaciones tiene un alcance distinto que el de un rol. Un grupo del AS tiene un alcance que contempla a todo el AS, mientras que un rol se asocia slo con una aplicacin especfica en el AS. DEF. Rol: Un rol es un nombre abstracto que define el permiso para acceder a un conjunto especfico de recursos en una aplicacin. Un rol puede verse como una llave que puede abrir una cerradura determinada. Muchas personas pueden tener una copia de la llave. A la cerradura no le importa quien seas, slo que tengas la llave correcta.

TRABAJANDO CON REINOS, USUARIOS, GRUPOS Y ROLES

DEF. Principal: Un principal es una entidad que puede ser autenticada por un protocolo de autenticacin en un servicio de seguridad que est desplegado en una empresa. Un principal se identifica usando un nombre de principal y se autentica usando datos de autenticacin (passwords, credenciales, etc). DEF. Poltica de Seguridad del Dominio (tambin conocido como Dominio de Seguridad o reino): Es el alcance sobre el que se define y se impone una poltica comn de seguridad, gestionada por el administrador del servicio de seguridad.

TRABAJANDO CON REINOS, USUARIOS, GRUPOS Y ROLES

DEF. Atributos de Seguridad: Un conjunto de atributos de seguridad se asocia con todos los principals. Los atributos de seguridad tienen muchos usos, por ejemplo, el acceso a recursos protegidos y auditoria de usuarios. Los atributos de seguridad pueden asociarse con un principal por medio de un protocolo de autenticacin. DEF. Credencial: Un credencial contiene o referencia atributos de seguridad usados para autenticar un principal.

JAAS (JAVA JAVA AUTHENTICATION AND AUTHORIZATION SERVICE)

JAAS fue introducido como un paquete adicional (extensin) en la J2SDK v 1.3 A partir de la v 1.4 viene integrado con la SDK. Es por tanto, parte de J2SE, no de la J2EE. JAAS puede ser usado para dos propsitos:

Para autenticacin de usuarios, es decir para determinar quin esta actualmente ejecutando cdigo Java, sin importar si el cdigo esta corriendo como una aplicacin, un applet, un bean o un servlet y Para autorizacin de usuarios de manera que se asegure que tienen los permisos requeridos para realizar las acciones ejecutadas.

JAAS INTRODUCCIN JAAS es un modelo de autenticacin pluggable. Esto permite a las aplicaciones permanecer independientes de las tecnologas de autenticacin subyacentes. Tecnologas de autenticacin nuevas o actualizadas pueden ser insertadas (plugged) bajo una aplicacin sin que se requieran modificaciones a la aplicacin en si misma.

JAAS INTRODUCCIN

Las aplicaciones permiten el proceso de autenticacin instanciando un objeto de tipo LoginContext que hace referencia a un objeto Configuration para determinar la tecnologa/s de autenticacin o LoginModule(s), que sern usados en el proceso de autenticacin. Las implementaciones de LoginModule tpicas suelen solicitar y verificar un nombre de usuario y una password. Otras implementaciones pueden ser por medio de la lectura y verificacin de voz, huellas dactilares, etc

JAAS INTRODUCCIN

Una vez que el usuario o servicio que ejecuta el cdigo ha sido autenticado, el componente JAAS de autorizacin se pone en funcionamiento para proteger el acceso a recursos sensibles. Las decisiones de control de acceso se basan en el usuario o servicio que ejecuta el cdigo, que es representado mediante un objeto de la clase Subject. El Subject es actualizado por un LoginModule con los Principals y credenciales si el proceso de autenticacin es exitoso.

JAAS CORE CLASSES AND INTERFACES

Las clases e interfaces principales de JAAS se pueden dividir en tres categoras:

Common

Classes
Principal, Credential (actually, any

Subject,

Object)
Authentication
LoginContext,

Classes e Interfaces
LoginModule, CallbackHandler,

Callback
Authorization

Classes

JAAS COMMON CLASSES

Las clases comunes son todas aquellas compartidas por los dos componentes del API JASS, autenticacin y autorizacin

JAAS COMMON CLASSES: SUBJECT

Para autorizar el acceso a los recursos, las aplicaciones necesitan primero autenticar el origen de la solicitud. El framework JAAS define el trmino subject para representar el origen de la solicitud. Un subject puede ser cualquier entidad, ya sea una persona o un servicio. Una vez el subject es autenticado un javax.security.auth.Subject es rellenado con las identidades asociadas, o Principals. Un subject puede tener muchos Principals. Por ejemplo, una persona puede tener un nombre principal (Roberto Matas) y un cdigo identificativo principal (1234-56), que lo distingue de otros subjects.

JAAS COMMON CLASSES: SUBJECT

Un Subject puede tener tambin atributos de seguridad propios, conocidos con el nombre de credentials. Credenciales sensibles, que requieren una proteccin especial, como por ejemplo una clave criptogrfica privada, se almacenan dentro de un conjunto (Set) de credenciales privados. Los Credenciales cuya finalidad es ser compartidos, como por ejemplo certificados pblicos, se almacenan dentro de conjunto (Set) de credenciales pblicos. Se requieren diferentes tipos de permisos para acceder y modificar los diferentes conjuntos de credenciales.

JAAS COMMON CLASSES: SUBJECT

Constructores:
public

Subject(); public Subject(boolean readOnly, Set principals, Set pubCredentials, Set privCredentials); El programador de la aplicacin no tiene que instanciar manualmente un objeto Subject. Si la aplicacin instancia un LoginContext y no le proporciona ningn Subject al constructor, el LoginContext instanciar uno vaco

JAAS COMMON CLASSES: SUBJECT

Mtodo public Set getPrincipals(); Descripcin Devuelve todos los Principals contenidos en el Subject Devuelve todos los Principals contenidos en el Subject que sean una instancia de la Clase c, o una instancia de una subclase de c Devuelve todos los credenciales contenidos en el Subject pblicos

public Set getPrincipals(Class c);

public Set getPublicCredentials();

public Set getPublicCredentials(Class c);

Devuelve todos los credenciales pblicos contenidos en el Subject que sean una instancia de la Clase c, o una instancia de una subclase de c Devuelve todos los credenciales contenidos en el Subject privados

public Set getPrivateCredentials();

public Set getPrivateCredentials(Class c); public boolean isReadOnly();

Devuelve todos los credenciales privados contenidos en el Subject que sean una instancia de la Clase c, o una instancia de una subclase de c Consulta si el Subject es de slo lectura

JAAS COMMON CLASSES: PRINCIPAL

Como hemos mencionado anteriormente, los Principals son asociados con un Subject cuando tiene lugar una autenticacin exitosa. Los Principals representan las identidades de los Subjects, y deben implementar las interfaces java.security.Principal y java.io.Serializable

JAAS COMMON CLASSES: CREDENCIAL

Las clases que representan credenciales, tanto pblicos como privados, no son parte de la librera JAAS. Cualquier clase puede representar un credencial. Los desarrolladores, sin embargo pueden decidir que sus clases credenciales implementen dos interfaces relacionadas con los credenciales que si son parte de

JAAS COMMON CLASSES: CREDENCIAL

Refreshable

La interface javax.security.auth.Refreshable proporciona a un credencial la carcaterstica de actualizarse a s mismo. Por ejemplo, un credencial que caduca con el tiempo puede implementar esta interface para permitir a los llamantes actualizar el periodo de tiempo durante el cul es vlido.
Mtodo boolean isCurrent(); Descripcin Este mtodo determina si el credencial es vlido o esta caducado. Este mtodo actualiza o aumenta el periodo de validez de un credencial. El mtodo implementado debera ejecutar un AuthPermission ("refreshCredential") para asegurar que el llamante tiene permisos para actualizar el credencial

void refresh() throws RefreshFailedException;

JAAS COMMON CLASSES: CREDENCIAL

Destroyable

La interface javax.security.auth.Destroyable proporciona la capacidad de destruir el contenido dentro de un credencial.

Mtodo

Descripcin

boolean isDestroyed();

Determina si el credencial ha sido destruido. Destruye y limpia la informacin asociada con el credencial. El mtodo implementado debera ejecutar un AuthPermission ("destroyCredential") para asegurar que el llamante tiene permisos para destruir el credencial

void destroy() throws DestroyFailedException;

JAAS AUTHENTICATION CLASSES E INTERFACES

Para autenticar un subject (usuario o servicio), se ejecutan los siguientes pasos:
1. 2. 3. 4.

5. 6.

Una aplicacin instancia un LoginContext El LoginContext consulta un objeto de la clase Configuration para cargar todos los LoginModule configurados para esa aplicacin. La aplicacin invoca al mtodo login de la clase LoginContext El mtodo login invoca todos los LoginModule cargados. Cada LoginModule intenta autenticar al subject. Si se consigue autenticar, los LoginModules asocian los Principals y credenciales con un objeto Subject que representa al sujeto ya autenticado. El LoginContext devuelve el estado (xito o fallo) de la autenticacin a la aplicacin. Si la autenticacin fue exitosa, la aplicacin recupera el Subject del LoginContext.

JAAS
AUTHENTICATION CLASSES E INTERFACES: LOGINCONTEXT

La clase javax.security.auth.login.LoginContext proporciona los mtodos bsicos para autenticar sujetos y la manera de desarrollar una aplicacin independiente de la tecnologa de autenticacin subyacente. El LoginContext consulta una Configuration para determinar los servicios de autenticacin o LoginModules, configurados para una aplicacin particular. Asimismo, diferentes LoginModules pueden ser aadidos sin que se requiera ninguna modificacin de la aplicacin en s misma.

JAAS
AUTHENTICATION CLASSES E INTERFACES: LOGINCONTEXT

Constructores:

public LoginContext(String name) throws LoginException; public LoginContext(String name, Subject subject) throws LoginException; public LoginContext(String name, CallbackHandler callbackHandler) throws LoginException public LoginContext(String name, Subject subject, CallbackHandler callbackHandler) throws LoginException

JAAS
AUTHENTICATION CLASSES E INTERFACES: LOGINCONTEXT

La autenticacin en s ocurre cuando se produce una llamada al siguiente mtodo:

public void login() throws LoginException;

Cuando este mtodo es invocado, todos los LoginModules configurados se invocan para ejecutar el proceso de autenticacin. Si la autenticacin es exitosa, el Subject (que puede ahora mantener Principals, credenciales pblicas y credenciales privadas) puede ser recuperado usando el siguiente mtodo:

public Subject getSubject();

Para ejecutar un logout sobre un Subject y borrar de esta manera, sus Principals y credenciales autenticados, debemos ejecutar el siguiente mtodo:

public void logout() throws LoginException;

JAAS
AUTHENTICATION CLASSES E INTERFACES: LOGINCONTEXT

// let the LoginContext instantiate a new Subject LoginContext lc = new LoginContext("entryFoo"); try { // authenticate the Subject lc.login(); System.out.println("authentication successful"); // get the authenticated Subject Subject subject = lc.getSubject(); ... // all finished -- logout lc.logout(); } catch (LoginException le) { System.err.println("authentication unsuccessful: " + le.getMessage()); }

JAAS
AUTHENTICATION CLASSES E INTERFACES: LOGINMODULE

El interface LoginModule da a los desarrolladores la habilidad de implementar diferentes tecnologas de autenticacin que pueden ser conectadas en una aplicacin. Por ejemplo, un tipo de LoginModule puede ejecutar un formulario de autenticacin basado en nombre de usuario y password. Otros LoginModules pueden servir de interface a dispositivos hardware tales como tarjetas inteligentes o dispositivos biomtricos. Los programadores de la aplicacin normalmente no necesitan entender como trabajan los LoginModules. Todo lo que deben saber es como especificar la informacin de configuracin (como por ejemplo, un fichero de configuracin de login), de manera que la aplicacin pueda utilizar los LoginModule especificados en dicha configuracin para autenticar al usuario.

JAAS
AUTHENTICATION CLASSES E INTERFACES: CALLBACKHANDLER

En algunos casos, los LoginModules deben comunicarse con el usuario para obtener informacin. Los LoginModules usan un javax.security.auth.callback.CallbackHandler para este propsito. Las aplicaciones implementan el interfaz CallBackHandler y los pasan al LoginContext (a travs de los constructores definidos para este propsito), el cal los redirecciona directamente a los LoginModule subyacentes

JAAS
AUTHENTICATION CLASSES E INTERFACES: CALLBACKHANDLER

Al permitir a la aplicacin especificar el CallBackHandler, los LoginModules subyacentes pueden permanecer independientes de las distintas formas en que la aplicacin interacte con los usuarios. Por ejemplo, la implementacin de un CallBackHandler para una aplicacin con una interfaz grfica de usuario puede mostrar una pantalla para solicitar informacin a los usuarios, mientras que la implementacin para una aplicacin sin interfaz grfica puede solicitar la informacin al usuario directamente desde lnea de comandos.

JAAS
AUTHENTICATION CLASSES E INTERFACES: CALLBACKHANDLER

La interfaz CallBackHandler tiene un nico mtodo a implementar:

void handle(Callback[] callbacks) throws java.io.IOException, UnsupportedCallbackException;

El LoginModule pasa al mtodo handle del CallBackHandler un array de los CallBacks usados por la aplicacin para obtener los datos de entrada del usuario, por ejemplo un NameCallback para el nombre de usuario y un PasswordCallback para la contrasea El CallBackHandler ejecuta la interaccin solicitada con el usuario, estableciendo los valores capturados en los CallBack. Por ejemplo, para procesar un NameCallBack, el CallBackHandler puede solicitar al usuario la introduccin de un nombre, recuperar el valor introducido para el nombre y llamar al mtodo setName de la clase NameCallBack para almacenarlo.

JAAS
AUTHENTICATION CLASSES E INTERFACES: CALLBACK

El paquete javax.security.auth.callback contiene el interfaz CallBack, as como varias implementaciones de la misma. Algunas de estas implementaciones son las anteriormente mencionadas: NameCallback y PasswordCallback.

JAAS AUTHORIZATION CLASSES

Para que una autorizacin JAAS tenga lugar, se requiere la siguiente situacin:
1. 2. 3.

El usuario debe estar autenticado El Subject resultado de la autenticacin debe estar asociado con un contexto de control de acceso Deben estar configuradas las entradas referentes a qu Principals tienen permiso a qu recursos en el fichero de poltica de seguridad, como veremos ms adelante.

JAAS AUTHORIZATION CLASSES: POLICY

La clase java.security.Policy es una clase abstracta para representar la poltica de acceso del sistema. Por defecto, la J2SDK proporciona una subclase basada en ficheros, con soporte a entradas grant basadas en Principals en ficheros de poltica

JAAS
AUTHORIZATION CLASSES: AUTHPERMISSION

La clase javax.security.auth.AuthPermission encapsula los permisos bsicos requeridos por JAAS Adems de los constructores proporcionados por su superclase (java.security.Permission), la clase AuthPermission tiene estos dos constructores:

public AuthPermission(String name); public AuthPermission(String name, String actions);

JAAS
AUTHORIZATION CLASSES: AUTHPERMISSION

El primer constructor crea un nuevo AuthPermission con el nombre especificado. El segundo tambin crea un nuevo AuthPermission, pero tiene un argumento adicional actions, que no debe ser usado y debera ser null. Este constructor existe solamente para que el objeto Policy pueda instaciar nuevos objetos de tipo Permission. Para el resto, el primer constructor es el apropiado Comnmente el objeto AuthPermission se usa para proteger el acceso a los objetos Policy, Subject, LoginContext y Configuration. Para ello, en el parmetro nombre debemos especificar alguno de la lista siguiente:

JAAS
AUTHORIZATION CLASSES: AUTHPERMISSION

getSubject -

allow for the retrieval of the Subject(s) associated with the current Thread. allow the caller to set a Subject to be read-only.

refreshCredential - allow code to invoke the refresh method on a credential which implements the Refreshable interface. destroyCredential - allow code to invoke the destroy method on a credential object which implements the Destroyable interface. createLoginContext.{name} allow code to instantiate a LoginContext with the specified name. ..... ......

setReadOnly -

modifyPrincipals - allow the caller to modify the Set of Principals associated with a Subject modifyPublicCredentials - allow the caller to modify the Set of public credentials associated with a Subject modifyPrivateCredentials - allow the caller to modify the Set of private credentials associated with a Subject

JAAS
AUTHORIZATION CLASSES: PRIVATECREDENTIALPERMISSION

La clase javax.security.auth.PrivateCredentialPermission protege el acceso a los credenciales privados de un Subject.

JAAS
CONFIGURACIN DEL FICHERO DE PROPIEDADES DE SEGURIDAD

JAVA_HOME /lib/security/java.security (Solaris) JAVA.SECURITY JAVA_HOME\lib\security\java.security (Win32)

JAAS
CONFIGURACIN DEL FICHERO DE PROPIEDADES DE SEGURIDAD JAVA.SECURITY

Login Configuration Provider

Si

queremos especificar un proveedor de Login especfico debemos modificar la siguiente propiedad del fichero java.security: login.configuration.provider Si no se especifica ningn valor a esta propiedad se mantendr el valor por defecto, es decir, se usar el Login Provider proporcionado por Sun, esto es:

JAAS
CONFIGURACIN DEL FICHERO DE PROPIEDADES DE SEGURIDAD JAVA.SECURITY

Login Configuration URLs

Si estamos usando una configuracin de login que espera que la informacin de configuracin sea especificada en ficheros (como la implementacin por defecto de Sun), la localizacin de dichos ficheros puede ser estticamente especificada mediante la propiedad login.config.url.n donde n, es una secuencia consecutiva de nmeros comenzando por el 1 (tantos como ficheros de configuracin usemos). Por ejemplo, para establecer dos ficheros de configuracin de login:

login.config.url.1=file:C:/config/.java.login.config login.config.url.2=file:C:/users/foo/.foo.login.config

Si esta propiedad no es establecida estticamente en el fichero java.security y tampoco es especificada dinmicamente desde lnea de comandos (a travs de la opcin -Djava.security.auth.login.config), entonces JAAS cargar la cofiguracin de login por defecto, localizada en la siguiente ruta:

file:${USER_HOME}/.java.login.config

JAAS
CONFIGURACIN DEL FICHERO DE PROPIEDADES DE SEGURIDAD JAVA.SECURITY

Policy Provider
Si

queremos especificar un proveedor de polticas alternativo al de por defecto debemos modificar la siguiente propiedad del fichero java.security:
policy.provider

Si

no se especifica ningn valor a esta propiedad se mantendr el valor por defecto:

policy.provider=sun.security.provider.PolicyFile

JAAS
CONFIGURACIN DEL FICHERO DE PROPIEDADES DE SEGURIDAD JAVA.SECURITY

Policy File URLs

La localizacin de los ficheros de polticas puede ser estticamente especificada mediante la propiedad policy.url.n Por ejemplo, para establecer dos ficheros de configuracin de polticas:

policy.url.1=file:C:/policy/.java.policy policy.url.2=file:C:/users/foo/.foo.policy

Si esta propiedad no es establecida estticamente ni dinmicamente desde lnea de comandos (a travs de la opcin -Djava.security.policy), la poltica de control de acceso por defecto ser obtenida del fichero de poltica del sistema que se cre cuando fue instalada la J2SDK, localizada en la siguiente ruta:

JAVA_HOME/lib/security/java.policy (Solaris)JAVA_HOME \lib\security\java.policy (Win32)

SEGURIDAD EN JAVAEE

La seguridad en Java EE est ampliamente basada en el API de JAAS (Java Authentication and Authorization Service) JAAS esta diseado para poder ejecutar los pasos de autenticacin y autorizacin en cualquier capa JavaEE, incluyendo la capa web y la capa EJB A la mayora de las aplicaciones JavaEE se accede a travs de la Web y se comparte la informacin de autenticacin a travs de todas las capas de la aplicacin y no a travs del servidor de aplicaciones. JAAS esta en concordancia con esta realidad y, una vez que el usuario es autenticado en cualquier capa de la aplicacin, el contexto de autenticacin se pasa a travs de las capas siempre que sea posible, en vez de repetir el paso de autenticacin cada vez que se accede a un recurso protegido.

SEGURIDAD EN JAVAEE

El objeto Principal, que ya comentamos en el apartado dedicado a JAAS, representa este contexto de autenticacin validado y compartible a lo largo de las capas de la aplicacin.

SEGURIDAD EN JAVAEE

Un Escenario donde se plantea un problema de Seguridad

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

La especificacin Servlet de la capa web (http://java.sun.com/products/servlet) esconde un gran nmero de detalles de bajo nivel, tanto para el proceso de autenticacin como para el proceso de autorizacin. Como desarrollador, simplemente necesitas decirle al contenedor de Servlet del servidor de aplicaciones qu recursos quieres proteger, cmo protegerlos, cmo son pasados a travs de las capas de la aplicacin los credenciales de autenticacin y qu roles tienen acceso a los recursos protegidos. La seguridad en la capa Web es configurada principalmente usando los elementos login-config y security-constraint del fichero DD web.xml.

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

El siguiente ejemplo muestra como proteger el mdulo de Administracin de la aplicacin de subastas

<login-config> <auth-method>BASIC</auth-method> (1) <realm-name>ActionBazaarRealm</realm-name> (2) </login-config> ... <security-constraint> <web-resource-collection> <web-resource-name> ActionBazaar Administrative Component </web-resource-name> <url-pattern>/admin/*</url-pattern> (3) </web-resource-collection> <auth-constraint> <role-name>CSR</role-name> (4) </auth-constraint> </security-constraint>

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

BASIC (HTTP Basic Authentication) (I)

1. 2. 3. 4.

Un cliente solicita acceso a un recurso protegido El servidor devuelve una ventana de dilogo, que solicita el nombre de usuario y contrasea El cliente submite el nombre de usuario y password al servidor El servidor autentica al usuario en el reino especificado y, en caso de xito, devuelve el recurso solicitado.

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

BASIC (HTTP Basic Authentication) (II)

No seguro Basic Authentication enva el nombre de usuario y contrasea a travs de Internet como texto plano codificado en Base64 y, adems, el servidor de destino no esta autenticado. Si alguien consigue interceptar la transmisin, el nombre de usuario y contrasea pueden ser fcilmente decodificados. Sin embargo, cuando se usa un protocolo de transmisin seguro, como SSL en conjuncin con la basic authentication se puede reducir este problema.

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

FORM (Form-Based Authentication) (I)

La

autenticacin basada en formularios permite al desarrollador controlar el aspecto de las pantallas de login, permitiendo personalizar las pantallas de login y error que el navegador presenta al usuario final

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

FORM (Form-Based Authentication) (II)

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

FORM (Form-Based Authentication) (III)

Configuracin:

<login-config> <auth-method>FORM</auth-method> <realm-name>file</realm-name> <form-login-config> <form-login-page>/logon.jsp</form-loginpage> <form-error-page>/logonError.jsp</formerror-page> </form-login-config> </login-config>

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

FORM (Form-Based Authentication) (IV)

Cuando codifiquemos un login usando el mtodo FORM para autenticacin, el action del formulario de login debe ser siempre j_security_check. En este trozo de cdigo vemos estas restricciones de codificacin
<form method="POST" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> </form>

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

FORM (Form-Based Authentication) (V)

Form-based Authentication enva el nombre de usuario y contrasea a travs de Internet como texto plano y, adems, el servidor de destino no esta autenticado. Si alguien consigue interceptar la transmisin, el nombre de usuario y contrasea pueden ser fcilmente decodificados. Sin embargo, cuando se usa un protocolo de transmisin seguro, como SSL en conjuncin con el form-based authentication se puede reducir este problema.

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

CLIENT-CERT (HTTPS Client Authentication) (I)

Requiere que el cliente posea un certificado de clave pblica (PKC Public Key Certificate). Si especificamos este tipo de autenticacin, el servidor autenticar al cliente usando su certificado de clave pblica. HTTPS Client Authentication es el mtodo ms seguro de autenticacin. Usa HTTP sobre SSL (HTTPS). La tecnologa SSL (Secure Sockets Layer) proporciona encriptacin de datos, autenticacin del servidor, integridad de los mensajes y autenticacin de cliente opcional para una conexin TCP/IP. Podemos pensar en una PKC como el equivalente digital de un pasaporte. Es emitida por una organizacin de confianza, denominada Certificate Authority (CA).

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

CLIENT-CERT (HTTPS Client Authentication) (II)

Antes de usar HTTPS Client Authentication, debemos comprobar que las siguientes acciones han sido completadas:

El servidor ha sido configurado para soportar SSL Asegurarse de que el cliente tiene una PKC vlida.

<login-config> <auth-method>CLIENT-CERT</auth-method> </login-config>

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

CLIENT-CERT (HTTPS Client Authentication) (III)

Dos

tipos:

Mutual

Authentication: Con la autenticacin mutua, el cliente y el servidor se autentican el uno al otro. Existen dos tipos de autenticacin mutua Digest Authentication: Como la BASIC Authentication, pero transmitiendo la contrasea encriptada con un protocolo ms complejo que la codificacin Base64. Su uso no est demasiado extendido y la mayora de los AS no la

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

CLIENT-CERT (HTTPS Client Authentication) (IV)

Mutual

Authentication. Dos tipos:

Certificate-based

mutual authentication User name- and password-based mutual authentication

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

Certificate-based mutual authentication

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EN LA CAPA WEB

User name- and password-based mutual authentication

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

El modelo de autenticacin y autorizacin proporcionado por la especificacin EJB3 tiene dos enfoques:
Declarativo Programtico

Estudiaremos ambos enfoques codificando el escenario planteado anteriormente (cancelar una puja)

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa

En nuestra capa de lgica de negocio, para el escenario planteado, tenemos un EJB de sesin sin estado, que se encarga de la gestin de las pujas en las subastas; ste EJB se llama BeanManagerBean. Sin aplicar reglas de seguridad cualquier usuario podr ejecutar el cdigo asociado con el mtodo cancelBid. En el siguiente pedazo de cdigo mostramos la solucin desde una aproximacin declarativa

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa

@DeclareRoles({"BIDDER", "CSR", "ADMIN"}) (1) @Stateless public class BidManagerBean implements BidManager { @RolesAllowed({"CSR, ADMIN"}) (2) public void cancelBid(Bid bid, Item item) {...} @PermitAll (3) public List<Bid> getBids(Item item) {...}

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa: @DeclareRoles

Es muy recomendable que declaremos los roles de seguridad que sern empleados en nuestra aplicacin, modulo EJB, EJB o en nuestros mtodos de negocio. Existen varias maneras de declarar roles, una de ellas es a travs de la anotacin @DeclareRoles, que usamos en el punto (1). Esta anotacin se puede aplicar a nivel de clase o a nivel de mtodo y consta de un array de nombres de roles. En el ejemplo, estamos indicando que el EJB BidManagerBean usa los roles BIDDER, CSR y ADMIN. De manera alternativa, podramos haber especificado los roles para toda la aplicacin o para todo el mdulo EJB a travs de los descriptores de despliegue. Si no hacemos una declaracin explcita de los roles de la aplicacin en ningn lado, el contenedor construir automticamente una lista de roles, inspeccionando la anotacin @RolesAllowed.

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa: @RolesAllowed

La anotacin @RolesAllowed es la ms importante del enfoque declarativo en la gestin de la seguridad. Esta anotacin puede ser aplicada a nivel de mtodo o a nivel de clase. Cuando se aplica a nivel de clase (EJB), le dice al contenedor que roles tienen permiso para acceder a cualquier mtodo del EJB. Por otro lado, podemos usar esta anotacin en un mtodo para especificar la lista de roles permitidos para ese mtodo en particular. En el ejemplo (2) estamos especificando que slo los roles CSR y ADMIN tienen permiso para cancelar pujar a travs del mtodo cancelBid

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa: @PermitAll

Podemos usar la anotacin @PermitAll a nivel de clase o a nivel de mtodo para indicar que puede ser invocado por cualquier rol. En el ejemplo (3) usamos esta anotacin para indicar al contenedor que cualquier usuario puede recuperar las pujas realizadas hasta ahora para un artculo dado. Deberamos usar esta anotacin con moderacin, sobre todo a nivel de clase, ya que es posible dejar agujeros de seguridad que pasen inadvertidos.

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa: @DenyAll

La

anotacin @DenyAll hace justamente lo contrario que @PermitAll. Un escenario al que sera aplicable esta, en principio intil, anotacin podra ser cuando consideras el hecho de que tu aplicacin puede ser desplegada en un gran nmero de entornos que desconoces. Podras sencillamente invalidar un determinado mtodo para un entorno en particular, sin necesidad de cambiar el cdigo, aplicndole

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa: @RunAs (I)

Esta

anotacin es muy til cuando necesitamos asignar un nuevo rol dinmicamente al Principal en el alcance de la invocacin de un mtodo EJB. Esto puede ser necesario, por ejemplo, si estas invocando a otro EJB dentro de tu mtodo pero el otro EJB requiere un rol diferente al del actual Principal. Dependiendo de la situacin, el nuevo rol

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad declarativa: @RunAs (II)

El mtodo cancelBid podra necesitar invocar un EJB que gestione un registro histrico con la finalidad de obtener datos estadsticos del nmero de pujas canceladas. Sin embargo, el EJB que gestiona el histrico slo puede ser accedido con el rol de ADMIN. Usando la anotacin @RunAs, podemos asignar a un CSR el rol de ADMIN temporalmente, de manera que el EJB encargado del histrico piense que un ADMIN esta invocando uno de sus mtodos
@RunAS("ADMIN") @RolesAllowed("CSR") public class BidManagerBean implements BidManager { public void cancelBid(Bid bid, Item item) {...}

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad programtica (I)

El problema con la seguridad declarativa viene cuando necesitas implementar distintos tipos de acciones en funcin del rol de un Principal, es decir, necesitas cambiar el comportamiento de ciertos mtodos en funcin del rol del usuario que intenta ejecutar ese cdigo La seguridad programtica nos permite ir ms all en la implementacin de la seguridad en nuestra aplicacin, gracias al hecho de que tenemos acceso directo al Principal desde nuestro cdigo. El acceso al Principal se hace a travs del contexto EJB

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad programtica (II)

@Stateless public class BidManagerBean implements BidManager { @Resource SessionContext context; (1) ... public void cancelBid(Bid bid, Item item) { if (!context.isCallerInRole("CSR")) { (2) throw new SecurityException( "No permissions to cancel bid"); (3) } ... } ... }

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad programtica (III)

El interfaz EJBContext nos proporciona los siguientes mtodos relacionados con la gestin de la seguidad:
public interface EJBContext { ... public java.security.Principal getCallerPrincipal(); public boolean isCallerInRole(java.lang.String roleName); ... }

El mtodo getCallerPrincipal() nos da acceso directo al interfaz java.security.Principal que representa el contexto de autenticacin actual.

SEGURIDAD EN JAVAEE
AUTENTICACIN Y AUTORIZACIN EJB

Seguridad programtica (IV)

El nico mtodo de inters de la interfaz Principal es el mtodo getName(), que devuelve el nombre del principal, que, en la mayora de los casos, suele el nombre del usuario autenticado. Para mostrar un ejemplo de uso de este mtodo, imaginemos que cambiamos los requisitos de nuestro escenario de ejemplo y ahora, adems de los CSRs, los compradores tambin pueden cancelar sus propias pujas

public void cancelBid(Bid bid, Item item) { if (!context.isCallerInRole("CSR") && !(context.getCallerPrincipal().getName().equals( bid.getBidder().getUsername()) && (bid.getTimestamp() >= (getCurrentTime() - 60*1000))))) { throw new SecurityException("No permissions to cancel bid"); } } ...