Estamos probando la integración de pilaga con sudocu.
Nosotros tenemos:
a pilaga andando hacer años con su base local de usuarios
nuestro propio SSO (con SAML) que tiene su base de usuarios
sudocu desde cero que arrancaría con nuestro SSO por lo que no habría problemas.
Encontramos es que para que un usuario de Arai-Usuarios entre a pilaga, en Arai-usuarios es necesario que el usuario se “relacione” con el nombre de usuario especifico de pilaga. Esto se indica en el instructivo que se pueden exportar los usuarios de pilaga para meter a arai-usuarios: https://expedientes.siu.edu.ar/docs/pilaga/#sincronizar-cuentas-de-usuarios
Tenemos el problema que al usar muestro SSO este modelo de relaciones que se plantea en la solución nos genera una traba importante. Pensábamos que la “relación” entre usuarios de SSO y pilaga era por el mail asociado a los usuarios en ambos sistemas, pero no es así. Esto obviamente radica en que tenemos 2 sistemas andando de hace unos cuantos años con su propia base de usuarios.
Existe otro método para que los usuarios se relacionen automáticamente por el mail institucional, que es un dato que podemos tener en ambos sistemas, y no por el username? Si no existe, hay factibilidad de poder hacerlo personalizando algo en alguno de los puntos (Arai-usuarios o pilaga)? Porque si no se pudiera nos seria imposible usar nuestro SSO para la autenticación de SUDOCU + Pilaga + Diaguita + etc.
Te comento, el modelo de vinculación de usuarios - cuentas - aplicaciones que ofrece el servicio arai-usuarios está pensado para integrar aplicaciones existentes (pilagá por ejemplo) que tenían un universo de cuentas creadas. Muchas veces, estas cuentas no se corresponden en todas las aplicaciones para una misma persona (sea nombre+apellido, email, etc). De ahí a que se pueda crear un mapeo o vinculación del usuario a la aplicación por medio de una cuenta. Al realizar este mapeo, toda aplicación hecha en Toba necesita leer del TOKEN SAML el identificador de usuario del atributo defaultUserAccout. Ese es el atributo que se configura por ej, en el archivo saml_onelogin.ini y es así que esa aplicación Toba buscará localmente en apex_usuario una cuenta que coincide con el valor de ese atributo, iniciándose la sesión localmente si es correcto.
Te hago unas preguntas:
¿piensan desplegar arai-usuarios?
¿piensan reemplazar su solución de SSO por arai-usuarios?
¿buscan integrar arai-usuarios con su solución existente de SSO?
para toda la integración contra arai-usuarios que actualmente existen en los módulos SIU, ¿buscan implementar en su solución SSO los componentes requeridos (api, atributos SAML, etc)?
Dependerá mucho del camino que deseen seguir, el trabajo previo que tendrán que realizar…
Hola!
Nuestra intención es usar nuestro SSO (con SAML) dado que ya tenemos mas de 68mil usuarios (entre personal y alumnxs y 3ros). Dejar HUARPE como portal de los sistemas administrativos (sistemas SIU) y bandeja de firma de documentos.
En las charlas de presentación de SUDOCU habíamos entendido, mal, que el cruce con los usuarios/sistemas existentes era por el mail.
Tanto los atributos SAML (estuvimos viendo la documentación) así como la api-usuarios que vimos que pilaga requiere en el proceso de integración (y que tb vimos la documentación que uds. disponen de métodos y respuestas) los podemos agregar acorde a los requerimientos.
Es un punto complicado el de desplazar nuestro SSO por uno nuevo (Arai-Usuarios) así como el proceso de integración entre sistemas por el nivel de descentralización que manejamos en la uni.
En principio, no hay motivo para que NO puedan utilizar su propio SSO basado en SAML.
Si el camino es NO instalar arai-usuarios, les va a requerir una serie de tareas adicionales claro, para lograr el nivel de integración mínimo esperado:
implementar una api REST para acceso a info del IDM (usuarios, cuentas, aplicaciones). En esencia la api v1 hoy vigente y en uso, la v2 iniciando su adopción.
asegurarse de ofrecer los atributos SAML requeridos. (la doc es escueta, consulten y lo vemos). Por ej, Huarpe usa el atributo “employeeNumber” para mostrar acceso a info de RRHH en su perfil.
en casos particulares, evaluar implementar un nuevo conector (en arai-docs por ejemplo, USUARIOS_CLASS permite especificar otra clase que maneja la interacción con una fuente de usuarios, api rest de arai-usuarios en nuestro caso). Este camino puede ser útil si no logran implementar la api rest…
Si el camino es instalar arai-usuarios, podrían analizar y encarar un mecanismo como este:
podrían usar arai-usuarios para contar con la api rest, mapeo de usuarios a cuentas, registro de aplicaciones y validación SAML.
arai-usuarios es un IDP basado en SimpleSAMLPhp. Es posible conectarlo mediante federación y/o delegar la autenticación a otro IDP. Depende de lo que tengan y a que nivel intervenir.
La base de usuarios podría administrarse desde SU solución de SSO e integrar con arai-usuarios vía api rest el aprovisionamiento de dichos usuarios.
les quedaría andando la integración araí en los toba_usuarios de Pilagá, etc.
Un tercer camino, mixto, no ofrecido hasta ahora pero en teoría factible es aprovechar la modularidad de arai-usuarios:
Suponiendo que disponen de una base LDAP, compatibilizar el esquema LDAP con el modelo de datos que maneja la solución arai-usuarios. atributos/esquemas.
instanciar una base PostgreSQL.
desplegar los módulos IDM y API, evitando desplegar el módulo IDP.
conectar el IDM al ldap/postgres y al SSO SAML de uds.
conectar API al ldap/postgres.
ejecutar el boostrap del IDM.
personalizar atributos SAML en su SSO.
Les dejo todas las opciones que creo son factibles.
Respecto a la integración por mail, creo que lo que escucharon es que SUDOCU necesita vincular los usuarios de arai-usuarios con los usuarios locales mediante el atributo mail. Del lado de arai-usuarios, evitamos manipular el email como identificador de los usuarios por los posibles escenarios que se plantean. Ya tenemos un esquema en marcha para soportar login por el valor de diversos atributos (uniqueIdentifier, mail, employeeNumber, etc.) pero falta que lo manejen el IDP/IDM… en una futura versión.
te hago otra consulta que surgió en una charla por este tema.
Es posible personalizar el componente que usa toba Toba y que hace la integración con SAML para que la relación de usuario-saml y usuario-toba la realice por el mail que viaja en el saml?
Es por medio del valor en atributo_usuario en el archivo saml_onelogin.ini que se especifica contra que atributo del token SAML una aplicación Toba verifica…
Está documentado acá. AraiUsuarios ofrece el atributo defaultUserAccout que es la cuenta por defecto de un usuario en una aplicación (puede tener mas de una cuenta cada uusuario, etc).