Hola Sergio! Te voy respondiendo abajo
Buenas, entendemos que la funcionalidad de cuentas por usuario solo se integran para los sistemas SIU. Es correcto esto?
En principio, sí. La idea es que resuelva el problema de tener un Pilaga/Diaguita/Mapuche andando con cuentas de usuarios y con diferentes identificadores. Permite crear una especie de mapeo... es por ello que la cuenta representa un identificador mas de uso interno por la aplicación Toba (en especial las ya existentes, donde es engorroso cambiar sus identificadores internos). No quiere decir que no lo usen para otros sistemas, pero ya esos sistemas han de ser sensibles a su posible existencia o no.... (las cuentas por usuario no son obligatorias crear!).
Tenemos una app como nextcloud, que en la conf del plugins del saml, solo permite mappear un atributo del IDP contra ( y solamente contra) el UID del usuario del nextcloud.
Esto quiere decir que, si o si un atributo de los usuarios del ARAI debe ser (mail. uid, etc) el mismo valor del usuario (uid) del nextcloud.
Bien, tratemos de aclarar esta parte. Hoy, en araí-usuarios el atributo unívoco es
uniqueIdentifier que tiene seguro el identificador del usuario con el que realiza login, es un valor que SIEMPRE se envía vía token SAML , es un valor que recomendamos utilizar para mapear las aplicaciones (entiendo que en tu app podes configurar que lea desde un atributo del saml, y lo mapeará internamente con el campo uid.... similar al
Mapping IDP en Moodle.
En nuestro caso, como se puede ver en la imagen, ya tenemos creados usuarios nextcloud, que no se corresponden con ningún atributo de arai-usuarios. Entendemos que la solución sería, al dar de alta la cuenta en arai usuarios en la seccion cuentas la cuenta de nextcloud, por ejemplo en la imagen el usauario de arai "luis luque" tiene la cuenta en NC "hluque".
Es así. Es bueno el ejemplo, pues si pueden lograr matchear estos usuarios con identificadores abreviados a los usuarios "reales" en arai-usuarios, los pueden agregar como cuentas. Es así que en el token SAML les aparecerá hoy en un atributo
userAccounts (ojo que este permite múltiples cuentas por usuario. En la rama 2.2.x la cuenta por defecto se copia al atributo
uid del token SAML).
La cuestión es que, el IDP no tiene en cuenta esta conf al momento del intercambio de los metadatos contra el SP, siempre le pasa el UID u otro atributo (mail, si es que se configuró asi).
Podemos ver que los atributos son
{
"Attributes": {
"uid": [
""
],
"cn": [
"luis luque"
],
"sn": [
"luque"
],
"givenName": [
"luis"
],
"jpegPhoto": [
"http://usuarios.unne.edu.ar/gestion/resources/img/usuario_foto/usuario_generico.png"
],
"mail": [
"hluque@unne.edu.ar"
],
"uniqueIdentifier": [
"hluque"
],
"accessTo": [
"siu_arai-usuarios-1.siu-arai-usuarios-gestion",
"docs.unne.edu.ar",
"siu_huarpe-1.siu-huarpe",
"virtual-moodle.unne.edu.ar",
"docs-test.unne.edu.ar"
],
"appLauncherData": [
"{\"aplicaciones\":[{\"url\":\"http:\\/\\/usuarios.unne.edu.ar\\/gestion\",\"etiqueta\":\"ARAI-Usuarios\",\"descripcion\":\"Gesti\\u00f3n de usuarios (Backend)\",\"appUniqueId\":\"siu_arai-usuarios-1.siu-arai-usuarios-gestion\",\"icono_url\":\"http:\\/\\/usuarios.unne.edu.ar\\/gestion\\/resources\\/img\\/aplicaciones_iconos\\/siu_arai-usuarios-1.siu-arai-usuarios-gestion.png\"},{\"url\":\"https:\\/\\/docs.unne.edu.ar\",\"etiqueta\":\"Nextcloud\",\"descripcion\":\"Nube Rectorado\",\"appUniqueId\":\"docs.unne.edu.ar\",\"icono_url\":\"http:\\/\\/usuarios.unne.edu.ar\\/gestion\\/resources\\/img\\/aplicaciones_iconos\\/docs.unne.edu.ar.png\"},{\"url\":\"http:\\/\\/huarpe.unne.edu.ar\",\"etiqueta\":\"SIU-Huarpe\",\"descripcion\":\"Portal de autogesti\\u00f3n\",\"appUniqueId\":\"siu_huarpe-1.siu-huarpe\",\"icono_url\":\"http:\\/\\/usuarios.unne.edu.ar\\/gestion\\/resources\\/img\\/aplicaciones_iconos\\/siu_huarpe-1.siu-huarpe.png\"},{\"url\":\"http:\\/\\/virtual-moodle.unne.edu.ar\\/auth\\/saml2\\/login.php?wants&idp=297bafffe77a86ad900a72007299f8fa&passive=off\",\"etiqueta\":\"Virtual Moodle\",\"descripcion\":\"Virtual Moodle\",\"appUniqueId\":\"virtual-moodle.unne.edu.ar\",\"icono_url\":\"http:\\/\\/usuarios.unne.edu.ar\\/gestion\\/resources\\/img\\/aplicaciones_iconos\\/virtual-moodle.unne.edu.ar.png\"},{\"url\":\"http:\\/\\/10.20.11.222:8092\\/\",\"etiqueta\":\"docs test\",\"descripcion\":\"docs test\",\"appUniqueId\":\"docs-test.unne.edu.ar\",\"icono_url\":\"http:\\/\\/usuarios.unne.edu.ar\\/gestion\\/resources\\/img\\/aplicaciones_iconos\\/docs-test.unne.edu.ar.png\"}],\"usuario_id\":\"hluque\",\"usuario_nombre\":\"luis luque\",\"usuario_foto\":\"http:\\/\\/usuarios.unne.edu.ar\\/gestion\\/resources\\/img\\/usuario_foto\\/usuario_generico.png\",\"perfil_url\":\"http:\\/\\/huarpe.unne.edu.ar\\/perfil\"}"
],
"userAccounts": [
""
]
},
"Authority": "usuarios_arai",
"AuthnInstant": 1572610727,
"Expire": 1572639527
}
y vemos que en la seccion userAccounts, no trae los valores.
Si cuando registran el SP (Nextcloud) en el IDP (arai-usuarios), consignan una aplicación (dan de alta vía ABM, agregan el atributo
appUniqueId en la entrada
service_provider del config/idp.yml ), pueden corroborar que les mandará el atributo
userAccounts debidamente cargado de datos o cuentas en la aplicación coincidente con lo que el usuario tiene definido, y siempre y cuando entren a ese SP; si van a otro y hacen el dump del token SAML recibirán las cuentas de ese otro SP.... por eso el filtro por appUniqueId).
Creemos que las alternativas son:
- Que funcione la sección de cuentas de ARAI USUARIOS, osea que se reemplace el UID de acuerdo al valor de la cuenta configurado para la app que se invoca desde huarpe. Esa es la idea no?
- Modificar el codigo del plugin de NC, para que considere el atributo, mail por ej. De este manera podriamos mappear el mail de ARAI contra el mail de NC, sin necesidad de modificar nada del UID del NC, de esta manera deberíamos cargar el mail de los usuarios del arai en la atributo mail del NC.
Esperamos se comprenda la situación y aguardamos sus comentarios.
1) La sección de cuentas funciona. Hoy si ingresas a un SP registrado y que está dado de alta como aplicación, siempre para ese SP se le envía en el token SAML las cuentas que posee el usuario. Así operan hoy las aplicaciones Toba hechas por el SIU. Nota de color: uid se completa hasta la versión 2.2.x con la cuenta para ese usuario, cuando accede a un SP registrado como aplicación (si tiene mas de una cuenta, tienen una opción para establecer la cuenta por defecto, con lo cual uid tendrá la cuenta por defecto).
2) ¿No pueden hacer uso de atributo uniqueIdentifier y mappearlo en NC? Adjunto captura, aclaro que desconozco la herramienta.... de todas formas podría ser otro campo, abajo mas detalles.
Ahora un pequeño update, en la próxima versión 2.3 de SIU-Araí: Usuarios estaremos corrigiendo este comportamiento extraño que tiene hoy el atributo
uid dentro del token SAML:
- se agrega un atributo defaultUserAccount que contiene la cuenta del usuario para el SP desde el cual está accediendo en ese momento. Si tiene mas de una cuenta, todas aparecen como hasta ahora en userAccounts
- el atributo uid en el token SAML dejará de tener este comportamiento extraño, para pasar a mostrar el valor "real" que tiene dicho campo en la misma base de datos LDAP, visible en el campo uid del ABM de usuarios.
- el resto de los atributos se mantienen "intactos"
Este parece un pequeño cambio, pero va a tener un gran impacto a nivel mapeo. Mi recomendación es que siempre que puedan utilicen
uniqueIdentifier, es mas estable, hasta ahora no cambió, contiene lo que hoy usan como identificador de login los usuarios.... a futuro el campo uid internamente puede ser transformado a un valor tipo UUID v4 en vista de
mejores prácticas.
Saludos!
