Hola,
En UNLP vamos a usar nuestro propio SSO pero vamos a seguir usando HUARPE como portal de entrada a SUDOCU ( y a futuro pilaga y diaguita integrados con el nuestro SSO tb). Sudocu ya nos funciona con nuestro SSO pero huarpe tira errores que hasta ahora son relacionados a la API de Arai Usuarios.
la version de Huarpe que se encuentra liberada hasta donde entiendo esta utilizando la API v1 de Arai-Usuarios.
Por lo tanto hasta que se modifique ello para utilizar Huarpe deberian tener una API compatible con esta definicion
De todas maneras no eliminen la que ya crearon, ya que les va a servir a futuro cuando Huarpe incluya dicho cambio.
Mayormente la diferencia gira alrededor de la forma en que se identifica a un usuario, en la v1 se usa el campo ‘identificador’ que es legible y se puede armar por convencion, mientras que en v2 se utiliza un ‘uuidv4’ para realizar la identificacion univoca del usuario.
Igual se podrá saber de alguna manera que servivios de toda la API V1 usa HUARPE. Por la API tiene un montón de cosas que entiendo no usa huarpe (alta, modificación, etc) porque eso se hace desde ARAI-Usuarios (y en nuestro caso nuestro propio SSO).
Por ahora tengo en el log de HUARPE que me tira error con el servicio: /integracion/usuarios/rest/usuarios/{identificador}/cuentas
Pero quería saber si tenia el listado completo de lo que se usa así ya implemento todo y no vamos a prueba y error.
Huarpe es un concentrador de servicios, dependiendo los bundles que tengan activos seran los servicios que se usen alli… por lo que aunque te pudiera decir lo que usa la base, no tengo manera de saber si el bundle de Mapuche usa el servicio de otra forma. Pensa ademas que la API puede estar dando servicio a otros modulos mas tradicionales, no solo a Huarpe.
Lo que si te puedo decir es que la funcionalidad (tanto de Huarpe, sus bundles y los modulos en gral) se genero alrededor de la especificacion de la API y por tanto se requiere que sea 100% compatible, si solo implementan una parte de la misma dicha compatibilidad empieza a tener comillas por todos lados y es entonces cuando una actualizacion te deja rengo.
Son pocos recursos y en su mayor parte similares, implementen la totalidad de la misma y se garantizan la interoperabilidad no solo de Huarpe sino del resto de los modulos que hacen uso de la API.
Perfecto, entendido.
Igual por ahora vamos ir por lo minimo para poder comenzar con sudocu, ningun otro bundler, pero iremos incrementalmente metiendo todos los servicios.
Implementamos completamente la api de Arai-Usuarios V1 sobre nuestro SSO y configuramos HUARPE para que la use. No todo el modelo se Arai-Usuarios se relaciona con nuestro SSO (por ejemplo el concepto de cuentas) , por lo que en esos casos la api retorna sin datos
Comenzando la prueba (usando nuestra API y SSO en huarpe) nos damos cuenta que si en el Token no van las apps en el atributo AccessTo y/o appLauncherData en HUARPE (version 2.2.7) no muestra nada (y tira unos errores de JS). Por defecto lo habiamos dejado vacio porque asumimos que las obtenia de la API directamente cuando el usuario se logueaba. Forzamos a que vaya algo en esos atributos del token y lo mostro en las apps (y no salto el error de JS).
Esto es así? o sea, tiene que ir si o si en el token todos los datos de las apps? o hay alguna forma de q una vez logueado todo eso se cargue en base a la API?
Te hago una consulta, ya que no tienen concepto de cuentas… como manejan el caso de una persona que necesita diferentes perfiles en una misma aplicacion?, lo maneja directamente la aplicacion?, lo mantienen ustedes en el SSO?
Tambien tocamos el Token SAML agregando los atributos q nos faltaban acorde a lo especificado en: https://documentacion.siu.edu.ar/wiki/SIU-Arai/usuarios
Estamos migrando la doc hacia un nuevo formato, asi que mejor seguila desde [url=https://documentacion.siu.edu.ar/usuarios/docs/cache/conceptos-atributos-disponibles/]aqui[/url] ya que cada nueva version se va publicando ahi.
Comenzando la prueba (usando nuestra API y SSO en huarpe) nos damos cuenta que si en el Token no van las apps en el atributo AccessTo y/o appLauncherData en HUARPE (version 2.2.7) no muestra nada (y tira unos errores de JS). Por defecto lo habiamos dejado vacio porque asumimos que las obtenia de la API directamente cuando el usuario se logueaba. Forzamos a que vaya algo en esos atributos del token y lo mostro en las apps (y no salto el error de JS).
Esto es así? o sea, tiene que ir si o si en el token todos los datos de las apps? o hay alguna forma de q una vez logueado todo eso se cargue en base a la API?
Esto es una optimizacion que tuvimos que llevar adelante para los proyectos basados en Toba, ya que el framework obtiene toda la informacion al momento del login, realiza las verificaciones del caso y luego mantiene dicha info en cache, por lo que no hay una forma directa desde los modulos para luego de realizar la llamada a la API poder propagar dicha informacion la framework y reemplazarla.
Huarpe hace uso de dicha informacion (a modo de inicializacion) porque simplemente ya se encuentra alli, calculo que al no estar hecho en Toba deberia poder actualizar dicha info sin problemas.
Perfecto , vamos a tener que seguir tocando el Token entonces.
Te pido si me podes ampliar los siguientes 3 atributos en lo que representan :
accessTo: Lista de aplicaciones accesibles
appLauncherData: Datos informativos para SIU-Toba
userAccounts: Lista todas las cuentas del usuario
Porque no entiendo bien la diff entre accessTo y AppLAuncherData y lo de las cuentas q nosotros no tenemos. Si la app esta en accessTo tb debe ir en appLauncherData ?
appLauncherData: es la info que se usa para armar el menú de aplicaciones del Usuario, tiene la info de URL, etiqueta, descripción, ícono, y un ID de dicha app.
accessTo: tiene un mapeo de las aplicaciones que puede acceder el usuario en la forma “[INDICE] => ‘ID de app’”. Se usa en el listado de aplicaciones (entrando en /aplicaciones digamos)
userAccounts: tiene la lista de cuentas con las que accede a dichas aplicaciones. Normalmente es el mapeo usuario/cuentas que comentan arriba.