Anterior
 Volver
 Siguiente

 
Asunto: Re: Proteger el acceso a objetos
Fecha: Mon Nov 29 11:05:52 1999
De: Diego Sevilla Ruiz <dsevilla@ditec.um.es>

 
Hola a todos:

"Jesús Egea Payá" wrote:

>  Hola Enrique y demás miembros de la lista.
>  No estoy seguro pero me parece que para solucionar tu problema podrías guardar
> tus referencias en un servicio de directorios tipo LDAP, si no estoy muy
> equivocado en LDAP se pueden definir permisos de acceso a la información
> alamcenada. Es como un servicio de nombres pero más potente
>

Efectivamente, aunque esto tiene la desventaja de tener que montar un servidor
LDAP, y escribir el código del cliente, etc.

>
> Espero que esto te sirva de ayuda. Jesús
>
> Enrique_Jesús_Fernández_González escribió:
>
> >     Ante todo un saludo a los miembros de la lista.
> >
> >     Mi problema es el siguiente:
> >     Tengo una serie de objetos distribuidos. Las referencias a estos objetos
> > se obtienen a traves del servicio de nombres. El problema radica en que
> > deberia tener un control acerca de quien puede o no puede tener acceso a
> > esos objetos y todo ello sin que se vea afectado el tiempo empleado en
> > invocar a los metodos.

Si las referencias se guardan en el servicio de nombres, éstas son accesibles por
cualquier cliente. Desafortunadamente, hasta que no existan implementaciones del
servicio de seguridad de CORBA, no será posible hacer este tipo de comprobaciones
(y cuando existan no serán la panacea, porque el servicio de seguridad es inmenso
y complicado). En la medida de que pongas las referencias en un servicio de
nombres, estarán públicamente disponibles.

Como siempre que no se ofrecen ventajas arquitecturales (de base), el programador
lo debe implementar todo. Una posible solución es utilizar un "mediador". El
mediador utiliza la información de quién le pide el servicio, y así puede elegir
si da o no la referencia. Esta alternativa será la que exploremos en un proyecto
que vamos a lanzar. La idea es (algo ardua) crear un "wrapper" para los servicios
de nombres o de obtención de referencias que contemple la seguridad, a través de
objetos "acreditación" que proporcionen los clientes, por ejemplo.

> El planteamiento seria algo similar a: si estas
> > autorizado entonces puedes obtener la referencia al objeto y a partir de
> > entoces las llamadas a metodos se realizan sin ningun tipo de comprobacion
> > (suponiendo que si puedes invocarlos es porque has obtenido la referencia y,
> > por tanto, estas autorizado).

Nota sin embargo, que esta solución es algo peligrosa. Nota que las primeras
referencias se obtienen (en teoría) de forma segura... pero después, esas
referencias circulan "libremente" por la red de objetos. ¿Qué pasa si esa
referencia se pasa a clientes que no tienen privilegios? Entonces podrán
utilizarla sin tener la autorización... Lo cual nos lleva (y perdona por la
divagación, pero estos temas no están muy claros) a que se debe atacar el problema
desde los mecanismos de invocación de CORBA. Como dices (más abajo) que estás
utilizando ORBacus, deberías mirar el OCI, que te permite controlar de qué
direcciones IP se requieren los servicios. Si se requieren desde una dirección IP
distinta o que no está autenticada, se puede iniciar el proceso de autenticación
(si estás interesado en este punto, dímelo y lo discutimos más detenidamente). Aún
así... el basarse en la dirección IP tampoco es seguro...  ¿algún comentario de
los gurús de CORBA por ahí?

>
> >     En el caso de que no quede otro remedio que utilizar alguna
> > implementacion de SSL, ¿alguien lo ha probado y puede decirme como afecta
> > (en tiempo) a la invocacion de los metodos?¿Que implementacion puedo emplear
> > teniendo en cuenta que estoy utilizando ORBACUS v3.2?
>

Bueno. Yo no he probado SSL, aunque hay un paquete para ORBacus. Supongo que
afectará negativamente aunque no mucho, pero también depende de las políticas de
compartición de conexiones y de multi-threading. Aún así, SSL no permite este tipo
de autentificación que tu pretendes. Aunque permite autenticación no se puede
utilizar en serio porque no hay mecanismo de apoyo en los niveles superiores (en
este caso CORBA), por lo que se resume a autenticación par a par y a encriptación
(es decir, evitar los infiltrados en la comunicación y evitar que se pueda extraer
la información que circula).

> >
> >      Agradeciendo de antemano las posibles ideas, hasta la proxima
> >
> >                                 Enrique Jesus Fernandez Gonzalez
> >                                 ejesus@isa.uniovi.es

Espero que esto ayude más que entorpezca... aunque, como ves, no está muy claro.

    diego.

--
Diego Sevilla Ruiz
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34-968-367570
E-mail: dsevilla@ditec.um.es

$_="\\l/) (>".     "_'\n<";@@=        /.|\n/g;$_=
"\@".     "\007f".   "DDq".           "DD5".   "\204".
"\@".     "DT4CE".    "D54E".         "DD".    "\244".
"\021".   "dBDTC".     "\010DD".      "\200\$FD\024".
"GDAG".   "DAGDT".       "CqI";$c     =0;$p    =5;for$q
(/./g)    {$q=              ord$q;    for(a,   b){$z[$c]
=$@[$p+=($q&15)    -4];$q>>=4;$c+=33  ;$c>98   &&($c-=98);}};print@z;



 Anterior
 Volver
 Siguiente