Introducción
n
En este apartado veremos
n ¿ En qué difiere la programación de un applet frente a una aplicación stand-alone ?
n Problemas de seguridad en applets
n Uso de CORBA en entornos con firewalls n IIOP sobre SSL
n Funcionalidad proporcionada por el servicio de seguridad de CORBA
Programación de applets (1)
n En principio, la ventaja de que una aplicación cliente sea un
applet, es el no tener que instalar/actualizar la aplicación en las máquinas cliente
n En realidad, muchas veces es preciso descargar el ORB (y quizás los proxies de algunos servicios) con el propio applet (lo que incrementa notablemente el tiempo de descarga del applet)
n Browsers que no tienen ORB de CORBA
n Browsers con ORB de CORBA anticuado (en los que además, es preciso realizar modificaciones/actualizaciones de algunos componentes software)
n Además, es preciso hacer frente a determinados problemas de seguridad (se comentan más adelante)
n A diferencia de las aplicaciones, crean un ORB con
package org.omg.CORBA;
public abstract class ORB {
public static ORB init(java.applet.Applet, java.util.Properties properties) { ... } // ....
Programación de applets (2)
n
Ejemplo ClockNaming con cliente como applet
n Fichero$CORBA_JAVA_EXAMPLES/Subsystems/ClockNaming/Scripts/ClockNamingA pplet.html
<html> <head>
<title>Clock applet example</title> </head>
<body>
Clock applet example <p></p><p></p>
<applet code=es.udc.fbellas.corba.clocknaming.applet.ClockNamingApplet archive="OB.jar, OBNaming.jar, ClockNamingApplet.jar"
width=60 height=25>
<param name=org.omg.CORBA.ORBClass value=com.ooc.CORBA.ORB> <param name=org.omg.CORBA.ORBSingletonClass
value=com.ooc.CORBA.ORBSingleton> <param name=initialNamingContextURL
value=corbaloc::localhost:5000/NameService> You gotta be Java.
</applet> </body> </html>
Programación de applets (3)
n Applet =>
$CORBA_JAVA_EXAMPLES/Subsystems/ClockNaming/Sources/es/udc/fbellas/ corba/clocknaming/applet/ClockNamingApplet.java
/* Get 'initialNamingContextURL parameter. */
String initialNamingContextURL = getParameter("initialNamingContextURL"); if (initialNamingContextURL == null) {
// .. }
/* Initialize ORB. */
orb = ORB.init(this, null);
/* Get a reference to the initial naming context. */ org.omg.CORBA.Object initialNamingContextObject = orb.string_to_object(initialNamingContextURL); if (initialNamingContextObject == null) { // .. } NamingContext initialNamingContext = NamingContextHelper.narrow(initialNamingContextObject);
Programación de applets (y 4)
n
Comentarios
n El servidor podría escribir la IOR del objeto Clock en un fichero del servidor web (el applet lo puede leer fácilmente con java.net.URL), de manera que el applet no tenga
que usar el servicio de nombres
n Para ejecutar el ejemplo puede ser necesario adaptar el navegador
n Ej.: Véase manual de ORBacus para uso con Netscape
Problemas de seguridad en applets
n
Normalmente el gestor de seguridad que utilizan los
navegadores para los applets, impide que el applet
n Abra conexiones contra máquinas distintas a la del servidor web del que vino
n Acepte conexiones
n
Por tanto, en principio, un applet no podría
n Invocar operaciones sobre objetos remotos que están en máquinas distintas a la del servidor web del que vino
n Implementar objetos callback n
Soluciones
n Gateways IIOP (invocaciones sobre objetos de otras
máquinas distintas a la del servidor web) e IIOP bidreccional (callbacks)
n Usar el modelo de seguridad de Java
Gateway IIOP
n
Ejemplos
n Wonderwall (Orbix), Gatekeeper (Visibroker), Appligator (JacORB)
Servidor web
Gateway IIOP Servant Servidor IIOP Navegador Applet Stub IIOP
Modelo de seguridad de Java
n
Hasta JDK 1.0.x
n Código cargado localmente => todos los permisos
n El código cargado a través de la red (ej.: applets) => permisos restringidos por un
java.lang.SecurityManager
n
Con JDK 1.1.x
n Los applets se pueden firmar digitalmente (el fichero .jar) n Si el destinatario acepta el applet, se trata como si fuese
código cargado localmente
n
A partir de JDK 1.2
n Mismo control de seguridad para código local y para código cargado a través de la red
n Es posible especificar permisos y firmar digitalmente los ficheros .jar (jarsigner)
n Ej.: aceptar conexiones, permitir conexiones a máquinas,
Firewalls
n Firewalls
n Restringen el acceso desde el exterior (firewalls inbound) o hacia el exterior (firewalls outbound)
n Un mismo firewall puede funcionar como inbound y outbound
n En organizaciones grandes existen varios niveles de firewalls
n Mecanismos: filtrado de paquetes (a nivel de red y/o transporte => IP y/o TCP/UDP) y filtrado basado en protocolos de nivel de
aplicación (ej.: HTTP, FTP, etc.)
Cliente FWC1 FWC2 Enclave C1 Enclave C2 Servidor FWS1 FWS2 Enclave S2 Enclave S1 Firewalls outbound Firewalls inboud
Filtrado de paquetes
Desde x:x a
193.170.80.91:80/tcp
Desde subred 193.144.50.x:x a 193.170.80.123:21/tcp
Cualquier otro intento de comunicación
Filtrado
X
Filtrado basado en protocolos de nivel de aplicación
TCP Filtrado de paquetes FTP Gateway (proxy) para FTP Firewall Desde subred 193.144.50.x:x a 193.170.80.123:21/tcp, con FTP cq. comando excepto comandos de modificación (put, mput, delete, etc.)Servidor FTP
Problemas causados por los firewalls a las aplicaciones CORBA
n Con IIOP, un servidor normalmente elige el puerto o los puertos
por los que escucha dinámicamente
n Los ORBs suelen tener opciones para especificar el puerto que usa cada servidor
n Un mismo servidor puede correr en distintas máquinas en
distintos instantes de tiempo
n Incluso, la decisión puede tomarse dinámicamente (ej.: un repositorio de implementaciones con balanceo de carga)
n Los clientes que tienen objetos callback, también eligen puertos
dinámicamente y pueden correr en distintas máquinas
n Una primera solución
n Configurar los firewalls para permitir tráfico a y desde muchas máquinas y puertos
n Política de seguridad demasiado permisiva y difícil de administrar
n Soluciones reales
n HTTP tunneling
n Uso de gateways (proxies) GIOP
HTTP tunneling
n Tratan de salvar las restricciones impuestas por los firewalls outbound en los clientes
n Generalmente permiten hacer conexiones HTTP a casi cualquier máquina
(por el puerto 80)
n Con HTTP tunneling los mensajes IIOP se mandan dentro de mensajes
HTTP Servidor HTTP con HTTP tunneling Servant Servidor IIOP Navegador Applet Stub HTTP Firewall outbound en el cliente n Problemas
n Un applet no puede implementar objetos callback (necesitaría una
infraestructura similar a la del servidor, lo que no es realista)
n Si el cliente no es un applet, necesita configuración para especificar cuál es
el servidor HTTP con soporte para HTTP tunneling (para poder enviarle las peticiones)
Wonderwall (Orbix) Gatekeeper (Visibroker)
Gateways GIOP
n
Solucionan los problemas asociados a HTTP tunneling
Gateway IIOP Servant Servidor IIOP Cliente Stub IIOP n
Idea básica
n Invocaciones de objetos del servidor desde el cliente
n Las IORs que usa el cliente “apuntan” al gateway IIOP, y éste
las redirige la servidor
n Invocaciones de objetos del cliente desde el servidor
n Para evitar abrir una conexión y tener un gateway instalado en
la red cliente, el servidor reutiliza la conexión del cliente (GIOP bidireccional)
Wonderwall (Orbix) Gatekeeper (Visibroker)
IIOP sobre SSL
n
SSL (Secure Socket Layer)
n Extensión al API de sockets para TCP/IP
n Encriptación, autenticación del servidor y opcionalmente del cliente
n Se ha hecho popular con HTTP
n HTTP sobre SSL
n
El OMG ha estandarizado el uso de IIOP sobre SSL,
integrado dentro del servicio de seguridad
n
Muchos fabricantes proporcionan IIOP sobre SSL con
Servicio de seguridad de CORBA
n
Permite controlar la seguridad de aplicaciones CORBA
de una manera “más fina” que el uso de exclusivo de
firewalls
n Ej.: Especificar qué usuarios pueden invocar un método de un objeto
n
Es uno de los servicios más complejos
nFuncionalidad
n Identificación (“principals”) y autenticación n Control de acceso
n Trazado (“auditing”)
n Seguridad en la comunicación
n Autenticación del cliente y del objeto, integridad y
confidencialidad del mensaje
