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!).
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.
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).
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).
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).
¿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:
[ol]- 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”[/ol]
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.