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:
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 LDAPSi 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
otra idea es usar un ldap con backend al postgres de toba usuarioEn 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.
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
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 [b]perfil de datos[/b] 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
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