Sesion04 Traspas

Especialista en Aplicaciones y Servicios
Web con Java Enterprise
Enterprise JavaBeans
Sesión 4:
Seguridad y transacciones
Enterprise Jav aBeans Copyright © 2005-2006 Univ ersidad de Alicante Seguridad y transacciones 1
Índice seguridad
 Características de seguridad de J2EE

 Autentificación
 Acceso a los EJB basado en roles
Arquitectura de seguridad en J2EE
La seguridad en J2EE como abstracción
 Existen diferencias entre los distintos entornos

operativos en los que va a desplegarse una
aplicación de J2EE
 Distintas representaciones de las credenciales de los
usuarios:
 usuario/contraseña, certificados, kerberos
 Servidor LDAP, base de datos, Sistema Operativo
 J2EE debe abstraer todas estas representaciones en
un único marco común
Conceptos fundamentales J2EE
 La seguridad en J2EE se representa mediante:

 Principals
 Roles
 Mapeado de Roles a Principals
Mapeado de roles
Específico
vendedor
en
despliegue
tiempo -de
del
J2EE – de
tiempo
desarrollo
en
Tipos de seguridad en EJB (1)
 1. Autentificación (¿cómo adquiere un Principal un

cliente de un bean?)
 No se dispone de ningún servicio de autentificación en EJB
 La autentificación debe ya estar realizada y el cliente que
la petición debe tener ya un Principal asociado
 2. Comunicación (¿son seguras las comunicaciones
entre los clientes y los beans?)
 Es posible usar SSL para codificar las comunicaciones,
pero depende del servidor de aplicaciones
Tipos de seguridad (2)
 3. Autorización (¿está el cliente autorizado a

acceder a un método del bean?)
 Autorización declarativa (lo usual): se restringe el acceso
a métodos mediante entradas en el fichero de despliegue
ejb-jar.xml
 Autorización por programación (no usual): en el código
de los beans se pregunta por el usuario o el rol del cliente
Autentificación
 El siguiente código proporciona un ejemplo de

autentificación de un cliente usando BEA WebLogic Server
properties.put(Context.SECURITY_PRINCIPAL, "domingo" );
properties.put(Context.SECURITY_CREDENTIALS, "dgldgldgl");
properties.put(Context.PROVIDER_URL, "t3://localhost:7001");
javax.naming.Context jndiContext =
new javax.naming.InitialContext(properties);
 El usuario domingo debe estar creado en el servidor de

aplicaciones con la contraseña dgldgldgl
Autentificación 2
 El Principal (usuario) domingo se propagará al

contexto de los beans creados en las siguientes
llamadas
Cliente Contenedor EJB
Context jndiContext = // en TraderBean.java, en el
new InitialContext(properties); // contenedor EJB
Object ref = jndiContext.lookup(
"TraderBean"); void compra(String symbol,
TraderHome home = (TraderHome) float amount) {
PortableRemoteObject.narrow( ...
ref, TraderHome.class);
Trader trader = home.create(); Principal currentUser =
trader.compra("BEAS",500); ejbContext.getCallerPrincipal();
// devuelve currentUser = domingo
if (ejbContext.isCallerInRole(
"registered")) {
...
}
¡Autorización por programación!
Autorización declarativa
<asembly-descriptor>
Declaración <security-role>
<role-name>Administrador</role-name>
de los roles <role-name>Usuario-registrado</role-name>
</security-role>
<method-permission>
<role-name>Usuario-registrado</role-name>
<method>
<ejb-name>Trader</ejb-name>
<method-name>compra</method-name>
</method>
<method-permission>
...
</asembly-descriptor>
Declaración
de los permisos
Asignación de Principals a roles
 La asignación de Principals a roles se hace en tiempo

de despliegue, en el fichero weblogic-ejb-jar.xml:
<security-role-assignment>
<principal-name>Administrators</principal-name>
<principal-name>dmartinez</principal-name>
</security-role-assignment>
RunAs
 Los componentes EJB pueden ejecutarse como un

rol determinado, ignorando el rol del cliente que les
llama
<security-identity>
ejb-jar.xml <run-as>EJBAppAdmin</run-as>
</security-role-assignment>
<run-as-role-assignment>
weblogic-ejb-jar.xml <role-name>EJBAppAdmin</role-name>
<run-as-principal-name>dmartinez</run-as>
</run-as-role-assignment>
Índice transacciones
 Introducción a las transacciones

 Gestión declarativa de las transacciones
 Atributos de una transacción EJB
 Manejo de transacciones por programa
Definición de transacción
Una transacción es un grupo de operaciones que

representa una unidad de trabajo y que deben
ejecutarse como tal unidad.
Las operaciones se realizan sobre recursos (como
lectura, escritura o actualización) y transforman un
estado consistente del sistema en un nuevo estado
consistente.
Una transacción debe ser ACID (Atomic, Consistent,
Isolated and Durable).
Atomicidad: transferencia entre cuentas
Más carácterísticas (ACID)
 Consistencia
 Responsabilidad del programador
 Aislamiento (o seriabilidad)
 El resultado de la ejecución de un conjunto concurrente
de transacciones debe ser equivalente a una ejecución en
serie de las misma.
 Los datos que participan en una transacción deben
quedar ocultos (aislados) hasta el commit.
 Durabilidad
Alcance de las transacciones
 Transacciones locales
 Usan un único gestor de recursos, por ejemplo una transacción que
accede a una única base de datos o recurso.
 Transacciones globales
 Son transacciones que usan un único gestor de transacciones y más
de una gestor de recursos. Se debe usar el protocolo two-phase
commit para realizar un commit de la transacción.
 Transacciones distribuidas
 Son transacciones en las que intervienen más de un gestor de
transacciones. Al igual que en las transacciones globales, se usa
también el protocolo two-phase-commit para asegurar la correcta
ejecución de la transacción.
Demarcación de transacciones
 En la mayor parte de los modelos de gestión de transacciones,

éstas no son declarativas, sino que se informan al gestor de
transacciones según se van ejecutando.
 Para marcar el comienzo y el final de las transacciones se
llama a los métodos begin y commit de un UserTransaction.
try {
userTran.begin();
cliente.grabaPedido(pedido);
tarjetaCredito = cliente.tarjetaCredito();
tarjetaCredito.carga(pedido.precio);
almacen.descuenta(pedido);
userTran.commit();
}
catch (Exception e} {
userTran.rollback();
}
Transacciones y concurrencia: problemas
 Supongamos las siguientes operaciones. Si se

ejecutan concurrentemente 2 instancias es posible
que X quede en un estado inconsistente.
Instancia 1 Instancia 2
1. Leer el dato X 1. Leer el dato X
2. Sumar 10 a X 2. Sumar 10 a X
3. Escribir el dato X 3. Escribir el dato X
Two-phase blocking
 Antes de usar un dato, éste se bloquea.

 Dos tipos de bloqueos: de lectura y de escritura.
 Un bloqueo de lectura entra en conflicto con otro
de escritura. Un bloqueo de escritura entra en
conflicto con otro de escritura.
 Una transacción puede obtener un dato si no se
produce ningún conflicto. En caso de no poder
obtener el dato, queda en espera hasta que el dato
se libera.
Ejemplo
1. Bloqueo de escritura 1. Bloqueo de escritura
sobre X sobre X
2. Leer el dato X 2. Leer el dato X
4. Escribir el dato X 4. Escribir el dato X
5. Liberar X 5. Liberar X
Control optimista
1. Clonar X, guardando 1. Clonar X, guardando
el número de versión el número de versión
3. Si el número de versión 3. Si el número de versión
de X es el mismo que el de X es el mismo que el
del clon: escribirlo del clon: escribirlo
4. Sino: abortar la transacción 4. Sino: abortar la transacción
TP Monitor
 Un TP Monitor es una aplicación que realiza el

control de las transacciones en una arquitectura de
3 capas
 Mercado maduro: existe desde los años 80
 Los servidores de aplicaciones son la siguiente
evolución de los monitores de procesamiento de
transacciones
Estándares en transacciones
 La existencia de unos estándares comunes

garantizan la interoperabilidad entre distintos
gestores de transacciones y gestores de recursos
 Estándares más comunes:
 Modelo DTP (Distributed Transaction Processing) de
X/Open
 OTS (Object Transaction Service) que define los
servicios de transacciones en CORBA
Modelo DTP de X/Open
JTA
 JTA (Java Transaction API)

 Conjunto de interfaces basadas en el DTP de X/Open
 La implementación la proporcionan servidores de
aplicaciones
Interfaces JTA
javax.transaction.Status
 STATUS_ACTIVE
 STATUS_COMMITED
 STATUS_COMMITTING
 STATUS_MARKED_ROLLBACK
 STATUS_PREPARED
 STATUS_PREPARING
 STATUS_ROLLEDBAC
javax.transaction.UserTransaction
 void begin()
 void commit()
 int getStatus()
 void rollback()
 void setRollbackOnly()
 void setTransactionTimeout
(int seconds)
Programación de transacciones con JTA
Context ictx = new InitialContext();

UserTransaction utc = (UserTransaction)
ictx.lookup("UserTransaction");
try {
utc.begin();
// operaciones sobre los recursos
utc.commit();
}
catch (Exception e) {
utc.rollback();
}
Transacciones en EJB
 En EJB se asume que el código de cualquier método

de un bean se ejecuta dentro de una transacción
 Si se produce una excepción dentro del método del
bean, se ejecuta automáticamente un rollback
 El cliente puede crear una transacción antes de
llamar al bean:
import javax.transaction.UserTransaction;
...
UserTransaction utc = (UserTransaction)

jndiContext.lookup(
"javax.transaction.UserTransaction");
utc.begin();
book.setPrice(precio);
...
utc.commit();
Propagación de transacciones
 El bean declara un atributo de transacción para

cada método:
 Required
 RequiresNew
 Mandatory
 Supports
 NotSupported
 Never
Propagación de transacciones
 Cuando el metodo es llamado el contenedor

generalmente hace una de las siguientes tres cosas:
 Ejecutar el método en la transacción del llamador (caller)
 Suspender la transacción del llamador e iniciar una nueva
transacción
 Lanzar una excepción porque el llamador no tiene una
transacción
Atributo Required
 Si el llamador tiene abierta la transacción A

 El método se ejecuta dentro de la transacción A
 Si el llamador no tiene abierta ninguna transacción

 El contenedor crea una transacción nueva
Atributo RequiresNew

 El contenedor suspende la transacción A hasta que el
método se termina. El método se ejecuta en una nueva
transacción B.

 El contenedor crea una transacción nueva
Atributo Mandatory

 El método se ejecuta dentro de la transacción A

 El contenedor lanza una excepción

Sesion04 Traspas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sesion04 Traspas

Cargado por

Copyright:

Formatos disponibles

Especialista en Aplicaciones y Servicios

Web con Java Enterprise

 Características de seguridad de J2EE

 Existen diferencias entre los distintos entornos

 La seguridad en J2EE se representa mediante:

 1. Autentificación (¿cómo adquiere un Principal un

 3. Autorización (¿está el cliente autorizado a

 El siguiente código proporciona un ejemplo de

 El usuario domingo debe estar creado en el servidor de

 El Principal (usuario) domingo se propagará al

¡Autorización por programación!

 La asignación de Principals a roles se hace en tiempo

 Los componentes EJB pueden ejecutarse como un

 Introducción a las transacciones

Una transacción es un grupo de operaciones que

 En la mayor parte de los modelos de gestión de transacciones,

 Supongamos las siguientes operaciones. Si se

 Antes de usar un dato, éste se bloquea.

 Un TP Monitor es una aplicación que realiza el

 La existencia de unos estándares comunes

 JTA (Java Transaction API)

Context ictx = new InitialContext();

 En EJB se asume que el código de cualquier método

UserTransaction utc = (UserTransaction)

 El bean declara un atributo de transacción para

 Cuando el metodo es llamado el contenedor

 Si el llamador tiene abierta la transacción A

 Si el llamador no tiene abierta ninguna transacción

 Si el llamador tiene abierta la transacción A

 Si el llamador no tiene abierta ninguna transacción

 Si el llamador tiene abierta la transacción A

 Si el llamador no tiene abierta ninguna transacción

También podría gustarte