Autor Tema: Login único y administración de permisos jerárquica  (Leído 4704 veces)

0 Usuarios y 1 Visitante están viendo este tema.

gmunoz

  • Newbie
  • *
  • Mensajes: 17
    • Ver Perfil
    • Email
  • Institución: Instituto Universitario Aeronáutico
  • Nombre y apellido: Gabriel Muñoz
  • Sistema: guarani 3. araucano, wichi, kolla
  • Teléfono laboral: 5353000 int 34135
  • Utilizo algun sistéma del SIU: Sí
Login único y administración de permisos jerárquica
« on: Febrero 24, 2010, 11:13:04 am »
Buenos días, desde la Universidad Nacional de Córdoba estamos avanzando con la Administración y Centralización de los usuario de los distintos sistemas.
Particularmente, ahora estamos enfocados en los usuario de ComDoc 3, sistema de bibliotecas Koha versión 3, un sistema ad-hoc llamado Convenios para registrar los convenios que celebra la UNC, un sistema de pago vía internet utilizando SPS, el sistema de control de acceso al Comedor Universitario, el sistema de toma de desición O3, sin perder de vista, pero en instancias posteriores, a Guarani3, Mapuche, autenticación de cuentas de correo, login de las computadoras, entre otros servicios.

Muchos de estos servicios necesitan almacenar información en varios lugares, como por ejemplo ComDoc3 necesita almacenar información en un servidor LDAP y en un servidor Postgres.
Algunos de estos servicios ya están integrados como por ejemplo la autenticación desde LDAP a Convenios y ComDoc3.

Lo que nos preguntamos es si toba usuario nos sirve como herramienta o no. Estamos seguros que herramientas desarrolladas con toba son o pueden ser compatibles con toba usuarios, pero con sistemas ajenos a toba, como por ejemplo Koha, no tiene autenticación a toba_usuario pero si a LDAP.
Actualmente estamos administrando los usuario de Convenios, que se guardan en un Ldap, desde una herramienta ad-hoc realizada con toba.
Una de las idea que se nos ocurre es modificar a toba usuario para que, en lugar de guardar sus datos en un servidor postgres, los guarde en un LDAP, otra idea es usar un ldap con backend al postgres de toba usuario, otra alternativa puede llegar a ser utilizar OpenID teniendo la ventaja de autenticarse con sistema externos.

El espíritu es el mismo en todas las alternativas: tener un login único y administración de permisos de manera jerárquica, pudiendo cada unidad de responsabilidad administrarlos descentralizadamente.

Nos gustaría saber que opina la comunidad con respecto a este tema, si tienen desarrollos o al menos la definición de una estrategia al respecto y ver la posibilidad de hacer un esfuerzo conjunto para avanzar en el mismo sentido.

Saludos y muchas gracias,
Ing. Gabriel Muñoz,
Universidad Nacional de Córdoba.

smarconi

  • Visitante
Re: Login único y administración de permisos jerárquica
« Respuesta #1 on: Febrero 26, 2010, 10:46:24 am »
Buen día Gabriel,
En función de la inquietud planteada y una charla que hemos tenido con Miguel ayer, vamos a analizar el tema en unos días para definir una estrategia compartida. Te mantengo en contacto por novedades, seguramente la semana que viene.

Saludos!



smarconi

  • Visitante
Re: Login único y administración de permisos jerárquica
« Respuesta #2 on: Marzo 08, 2010, 02:32:04 pm »
Hola Gabriel,
Primero te cuento lo que puntualmente tenemos previsto para mejorar la integración Toba-LDAP en el corto plazo:

  • Mejorar el esquema actual de autenticación permitiendo configurar los parámetros LDAP desde la administración del proyecto y  crear el usuario toba en el login en caso de que este no exista localmente y sí en el LDAP, el usuario se crearía con un perfil de acceso definido en la configuración del proyecto
  • Potenciar el proyecto toba_usuarios para que pueda alternativamente crear y modificar datos de autenticación contra LDAP

Fuera de esto y pensando en el largo plazo te voy respondiendo por partes:

Cita
Una de las idea que se nos ocurre es modificar a toba usuario para que, en lugar de guardar sus datos en un servidor postgres, los guarde en un LDAP
Si es simplemente la autenticación (usuario-clave) sería lo mismo que tenemos previsto. Si es incluir además la autorización (en el caso de toba sería los perfiles funcionales y de datos que posee el usuario) no sólo hay que hacer que el proyecto de administración de usuarios (toba_usuarios) lea y escriba esta información en el LDAP sino que también el núcleo de toba lea esta información en ejecución. Lo mismo sucede creo al intentar llevar la autorización al LDAP para el resto de los servicios no-toba que mencionas.

Según como lo veo (corrijanme si me equivoco) la autenticación centralizada implica una clara ventaja para el usuario, ya que no debe preocuparse por mantener pares usuario-clave. La autorización centralizada supondría una ventaja para la institución, ya que los permisos de cada persona a los distintos sistemas se encuentran en un único lugar, supondría una ventaja de administración y claridad de dato invisible al usuario. También veo que llegado al caso la administración total centralizada de un usuario se puede simular con links a los distintos soft administradores de cada sistema (en el caso de toba, los toba_usuario de cada sistema) sin necesidad de tener los permisos en sí almacenados de forma centralizada, esto no haría necesario adaptar cada soft que no soporte guardar/leer los datos de autorización en LDAP

Cita
otra idea es usar un ldap con backend al postgres de toba usuario
En ese caso ¿no convendría directamente usar una base de datos como repositorio? Incluso habría que plantearse si LDAP en sí mismo supone una ventaja para la autenticación centralizada por sobre una base de datos como postgres.

Cita
otra alternativa puede llegar a ser utilizar OpenID teniendo la ventaja de autenticarse con sistema externos.
¿No abriría también potenciales problemas de seguridad y pérdida de privacidad? Loguearse a un sistema con el login de yahoo/google/etc suena interesante pero parece tener sus riesgos, hacerlo con un proveedor openid interno quitaría la mayor ventaja de openid que es la apertura. A ese nivel con lo poco que analizamos aún no lo vemos como un protocolo claro para el tipo de sistema de gestión que manejamos

Cita
El espíritu es el mismo en todas las alternativas: tener un login único y administración de permisos de manera jerárquica, pudiendo cada unidad de responsabilidad administrarlos descentralizadamente.
¿la unidad de responsabilidad sería la facultad por ejemplo? Si lo que necesitan es un corte por facultad o dependencia se puede incluir un perfil de datos al proyecto toba_usuarios donde los administradores tengan una restricción de administrar únicamente sus usuarios, suponiendo que hay un dato de negocio en el sistema que permite vincular un usuario a una o más facultades/departamentos/dependencias, etc. Nuevamente es más sencilo hacer esto 'cerca' del proyecto, ya que el dato de negocio esta en la base postgres y no quizás en el LDAP. También en esa línea para centralizar hay que tener en cuenta que todos los sistemas deben hablar del mismo concepto de  'dependencia' y no se si esto se da en la actualidad

Cita
Nos gustaría saber que opina la comunidad con respecto a este tema, si tienen desarrollos o al menos la definición de una estrategia al respecto y ver la posibilidad de hacer un esfuerzo conjunto para avanzar en el mismo sentido.
En nuestro caso desarrollos puntuales sobre esto no tenemos, pero nos interesa entender y participar de mejoras en este sentido.

Saludos y la seguimos

pgzavalla

  • Guarani
  • *
  • Mensajes: 43
    • Ver Perfil
    • Email
  • Institución: UNER (Facultad de Cs. Económicas)
  • Nombre y apellido: Pablo Gustavo Zavalla
  • Sistema: 0343 - 422 2172. Interno 2122
  • Teléfono laboral: Guarani
  • Utilizo algun sistéma del SIU: Sí
Re: Login único y administración de permisos jerárquica
« Respuesta #3 on: Noviembre 12, 2010, 08:42:16 am »
Hola, Gabriel: Espero no llegar a destiempo con la respuesta. Te comento que en la Facultad de Cs. Económicas de la UNER estamos utilizando toba con la autenticación ldap, pero con la gestión de usuarios de toba, para poder aprovechar sus funcionalidades como permisos para sistemas, opciones, datos, etc. Tenemos un PDC con windows 2000 y el toba lo tenemos funcionando en un servidor con la distribución 5.2 de centos.
Estamos con la versión 1.5.0 y paso a detallarte la manera en que logramos hacerlo andar. Pido disculpas si en alguna versión posterior esto se resuelve de otro modo. En realidad encontramos, por lo menos en esta versión, algunas funciones en el nucleo de toba que soportan autenticación ldap y lo que hicimos fue trabajar en estas funciones. Las mismas son la función autenticar que se encuentran en toba/1.5.0/php/nucleo/lib/toba_manejador_sesiones.php y la función autenticar_ldap que se encuentra en toba/1.5.0/php/nucleo/lib/toba_usuario_basico.php.
Los cambios que relizamos son los siguientes:
1. Realizar cambios en ...toba/1.5.0/php/nucleo/lib/toba_manejador_sesiones.php, buscar la función "autenticar", y en la linea 786 realizar los cambios necesarios para que esa linea quede: $estado = $this->invocar_metodo_usuario('autenticar_ldap', array($id_usuario, $clave, $datos_iniciales) ); (se le agrega "_ldap")
2. Realizar cambios en: ...toba/1.5.0/php/nucleo/lib/toba_usuario_basico.php. Transcribo a continuación la función completa, en la cual habría que definirle los parámetros que correspondan en cada caso al dominio o active directory y al PDC: (una cosa que me volvió loco encontrar la solución fue en la función ldap_search original que tenía el toba. Allí utilizaba un parámetro uid de ldap para realizar la búsqueda. En mi caso particular, no se si porque es windows 2000, no funcionaba. Buscando, encontré el parámetro samaccountname que funcionó de manera correcta. Otro cambio fue en la función ldap_bind, en la cual le agregué el usuario y contraseña. En mi caso particular, no funcionó sin estos datos. Acordate de colocar los datos de tu dominio y pdc dentro de la función que te mando)

/**
* Realiza la autentificacion utilizando un servidor LDAP
* @return $value Retorna TRUE o FALSE de acuerdo al estado de la autentifiacion
*/
static function autenticar_ldap($id_usuario, $clave, $datos_iniciales=null)
{ $ad_usuario=$id_usuario.'@economicas.local';
if (! extension_loaded('ldap')) {
throw new toba_error("[Autenticación LDAP] no se encuentra habilitada la extensión LDAP");
}
// $dn = 'dc=siu,dc=edu,dc=ar';
// $host = 'localhost';
$dn = 'dc=economicas,dc=local';
$host = '192.168.0.2';
$conexion = @ldap_connect($host);
ldap_set_option($conexion, LDAP_OPT_PROTOCOL_VERSION, 3);

if (! $conexion) {
toba::logger()->error('[Autenticación LDAP] No es posible conectarse con el servidor: '.ldap_error($conexion));
return false;
}

$bind = @ldap_bind($conexion, $ad_usuario, $clave);
if (! $bind) {
toba::logger()->error('[Autenticación LDAP] No es posible conectarse con el servidor: '.ldap_error($conexion));
return false;
}
$res_id = @ldap_search($conexion, "$dn", "samaccountname=$id_usuario");
if (! $res_id) {
toba::logger()->error('[Autenticación LDAP] Fallo búsqueda en el árbol: '.ldap_error($conexion));
return false;
}


$cantidad = ldap_count_entries($conexion, $res_id);
if ($cantidad == 0) {
toba::logger()->error("[Autenticación LDAP] El usuario $id_usuario no tiene una entrada en el árbol");
return false;
}

if ($cantidad > 1) {
toba::logger()->error("[Autenticación LDAP] El usuario $id_usuario tiene más de una entrada en el árbol");
return false;
}


$entrada_id = ldap_first_entry($conexion, $res_id);

if ($entrada_id == false) {
toba::logger()->error("[Autenticación LDAP] No puede obtenerse el resultado de la búsqueda". ldap_error($conexion));
return false;
}

$usuario_dn = ldap_get_dn($conexion, $entrada_id);
if ($usuario_dn == false) {
toba::logger()->error("[Autenticación LDAP] No pude obtenerse el DN del usuario: ". ldap_error($conexion));
return false;
}

$link_id = @ldap_bind($conexion, $usuario_dn, $clave);
if ($link_id == false) {
toba::logger()->error("[Autenticación LDAP] Usuario/Contraseña incorrecta: ".ldap_error($conexion));
return false;
}
ldap_close($conexion);
toba::logger()->debug("[Autenticación LDAP] OK");
return true;
}

//----------------------------------------------------------------------------------

Por último, no olvides agregar a todos los usuarios del dominio que utilicen sistemas en toba al toba_usuarios. QUizás haya alguna manera de hacerlo mediante un php que vaya leyendo cada usuario del dominio o active directory y agregando en la base de toba. La contraseña de cada usuario en la base de toba no tiene importancia, ya que la autenticación es contra el pdc.
Espero que sirva de algo. Quedo a tu disposición si necesitás alguna aclaración al respecto.
Un abrazo.

Pablo