probemas para consumir Arai Docs

hola estimados
Espero que anden bien!
Como les supimos contar desde UNC (córdoba) estamos instalando Arai siguiendo la doc de https://expedientes.siu.edu.ar/

Con el despliegue nos fue bien y tenemos andando todos los contenedores inclusive el stack Sudocu

root@arai-dev-3:~# docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
idfppminz4st docs_api replicated 1/1 hub.siu.edu.ar:5005/siu/expedientes/docs-api:hotfix_1.0.7
fuyaqsyeko6c docs_docs-worker replicated 1/1 hub.siu.edu.ar:5005/siu/expedientes/docs-api:hotfix_1.0.7
mxxqt6hidg9x huarpe_memcached-server replicated 1/1 bitnami/memcached:1.6.6
d36r5pr7mccm huarpe_webapp replicated 1/1 hub.siu.edu.ar:5005/siu/expedientes/huarpe-core:v2.2.7
3dbe2sfm44gc sudocu_api-server replicated 1/1 ungs/sudocu-api-server:1.1.5
m0re0mtud5dc sudocu_cache replicated 1/1 redis:5.0.9
adnl8fbveg6n sudocu_gestion replicated 1/1 ungs/sudocu-gestion:1.1.4
h2ediuvwcgam sudocu_login replicated 1/1 ungs/sudocu-login:1.1.1
iqmjjg84z110 sudocu_mpc replicated 1/1 ungs/sudocu-mpc:1.1.3
xyp1yeu8fv76 sudocu_mpd replicated 1/1 ungs/sudocu-mpd:1.1.3
hluxtmpzjym3 sudocu_pdf replicated 1/1 browserless/chrome:1.29-chrome-stable
3mx1j02h778o traefik_reverse-proxy global 1/1 traefik:2.2 *:80->80/tcp, *:443->443/tcp
qozq2h7e8mil usr-cmd_idm replicated 1/1 hub.siu.edu.ar:5005/siu/expedientes/arai-usuarios/idm:v3.0.8
kmzvxua3198b usuarios_api replicated 1/1 hub.siu.edu.ar:5005/siu/expedientes/arai-usuarios/api:v3.0.8
xmftqf94943f usuarios_idm replicated 1/1 hub.siu.edu.ar:5005/siu/expedientes/arai-usuarios/idm:v3.0.8
bhpevbag5bol usuarios_idp replicated 1/1 hub.siu.edu.ar:5005/siu/expedientes/arai-usuarios/idp:v3.0.8
saov5plgcmnk usuarios_memcached-server replicated 1/1 bitnami/memcached:1.6.6

Hasta hemos logrado una prueba de conectar un Mapuche y migrar cuentas
En síntesis:
Nos logueamos en Huarpe y de alli vamos a Sudocu o a Mapuche y eso anda ok
Pero no estamos teniendo éxito con el uso de Arai Documentos
*Por ejemplo cuando estamos en Mapuche y queremos digitalizar algo nos dice
[2021-06-23 20:49:51] docs-cli.ERROR: Error postDocumento, codigo 0. Mensaje: . request: Array

Buscando en el foro encontramos la recomendación de usar el test https://documentacion.siu.edu.ar/documentos/docs/next/tests/
Lo ejecute desde mi pc y también desde el host donde están los containers. Los resultados fueron los mismos

root@arai-dev-3:/srv/tests# ./10-status-frontend.sh

===== Prueba desde un host fuera de la red del servidor =====

** La siguiente prueba esta enfocada a validar los endpoints
** de Araí-Documentos, de acuerdo a si deben estar accesibles o no
** La prueba debe ejecutarse desde una pc (no dentro del servidor)

Ingrese url base del servidor por ejemplo para https://uunn.edu.ar
Enter host: http://siu-lab.psi.unc.edu.ar
Ingrese path de servicios de Araí-Documentos. Por ejemplo ‘/docs’
Enter path: /docs
http://siu-lab.psi.unc.edu.ar/docs’’ es correcta? (Y/N): y
Obtenido Esperado Descripcion
307 502 Bad Gateway: No se debe permitir acceso al endpoint
302 502 Bad Gateway: No se debe permitir acceso al endpoint
302 400 Da error pero se puede acceder al endpoint

========================== Caution ==========================
[WARNING] Los endpoints rest/backend/* de Araí-Documentos no debe ser publicos
[WARNING] Los endpoints rest/backend/* de Araí-Documentos no debe ser publicos
[ERROR] La API rest/frontend/* de Araí-Documentos debe estar disponible para acceder publicamente

Si les sirve de dato en los logs de docs_api solo se ve que cuando se conecta Huarpe cuando me logueo (cálculo que es para mostrar docs en la bandeja). Pero no hay logs cuando intento subir una digitalización desde Mapuche.

La verdad que no se me ocurre por donde arrancar
Desde ya muchas Gracias!!
saludos al equipo!

Lucas

Disculpas
La prueba del test la puse mal (la habia probado con http y es con https)

Es esta la que vale
root@arai-dev-3:/srv/tests# ./10-status-frontend.sh

===== Prueba desde un host fuera de la red del servidor =====

** La siguiente prueba esta enfocada a validar los endpoints
** de Araí-Documentos, de acuerdo a si deben estar accesibles o no
** La prueba debe ejecutarse desde una pc (no dentro del servidor)

Ingrese url base del servidor por ejemplo para https://uunn.edu.ar
Enter host: https://siu-lab.psi.unc.edu.ar
Ingrese path de servicios de Araí-Documentos. Por ejemplo ‘/docs’
Enter path: /docs
https://siu-lab.psi.unc.edu.ar/docs’’ es correcta? (Y/N): y
Obtenido Esperado Descripcion
000 502 Bad Gateway: No se debe permitir acceso al endpoint
000 502 Bad Gateway: No se debe permitir acceso al endpoint
000 400 Da error pero se puede acceder al endpoint

========================== Caution ==========================
[WARNING] Los endpoints rest/backend/* de Araí-Documentos no debe ser publicos
[WARNING] Los endpoints rest/backend/* de Araí-Documentos no debe ser publicos
[ERROR] La API rest/frontend/* de Araí-Documentos debe estar disponible para acceder publicamente

saludos
Lucas

Hola Lucas como estas?

Parece que tiene un problema el certificado, intente haciendo un curl

curl https://siu-lab.psi.unc.edu.ar
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Hola Lucas,

Adicional a lo que dice Dario, al parecer hay algo con la cadena del certificado SSL del servidor siu-lab.psi.unc.edu.ar …

Vean esto:

openssl s_client -connect huarpe.siu.edu.ar:443

Genera una salida tipo:


CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = huarpe.siu.edu.ar
verify return:1

En cambio, para el server de uds falla en verificar la cadena del certificado:


CONNECTED(00000003)
depth=0 CN = unc.edu.ar
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = unc.edu.ar
verify error:num=21:unable to verify the first certificate
verify return:1

Ver como posible causante esto.

Saludos!

muchas Gracias por la rtas!
nos fijamos como se puede solucionar y les comentaremos como nos fue

De paso hago 2 consultas

  1. Cuando importamos usuarios a Arai desde Mapuche nos pasó que no les cargo la asociacion de la cuenta para la api de Mapuche a cada usuario que cargó en Arai Usuarios
    Esto se puede hacer por algún mecanismo?
    Es decir existe alguna automatización que asocie usuarios de Arai a aplicaciones en Arai Usuarios? (Esto pensando en conectar los que carguemos inicialmente para Mapuche como usuarios de otros sistemas Siu como Pilaga, Diaguita, Guarani, etc)

  2. Una vez asociada la Api al login de Huarpe vemos que “si o si” siempre se ingresa desde Huarpe a la Api, (ejemplo Mapuche)
    Existe algo que habilite el login toba u otro login aparte del de Huarpe? Por ejemplo hoy tenemos login openid en los sistemas SIU y también tenemos la posibilidad de habilitar el login toba en el openid.ini como asi tambien la posibilidad de tener mas de un proveedor openid

Desde ya muchas Gracias!
saludos y buen finde!!

Lucas

Hola Lucas,

Calculo que es el caso que planteaba Diana aca, lo mas probable es que no este coincidiendo el nombre de la aplicacion registrada en Arai-Usuarios con el que aparece en el JSON, la idea de la importacion justamente es que para aquellas aplicaciones que existen te vincule automaticamente una cuenta si es que dicha persona la poseia en el modulo originalmente.

2) Una vez asociada la Api al login de Huarpe vemos que "si o si" siempre se ingresa desde Huarpe a la Api, (ejemplo Mapuche) Existe algo que habilite el login toba u otro login aparte del de Huarpe? Por ejemplo hoy tenemos login openid en los sistemas SIU y también tenemos la posibilidad de habilitar el login toba en el openid.ini como asi tambien la posibilidad de tener mas de un proveedor openid

Aca me perdi un poco, te consulto… vos lo que queres es tener un mecanismo de login alternativo o no pasar por Huarpe?. ya que son cosas diferentes.

Saludos

hola Richard
Disculpa el delay
Respecto de la 2)
la pregunta apuntaba a un “mecanismo alternativo” o “extra”
Ya que el pasar por Huarpe es lo que estamos probando, sin embargo surgió la inquietud de tener alguna alternativa como el login original de toba del las apis de SIU, Mirándolo desde el lado de la continuidad y pensando también en la disponibilidad sumar mecanismos de login que en lo posible sean de SIU.

Saludos
Lucas

Hola Lucas

toda la idea de tener un SSO es que puedas realizar el login una sola vez y utilizarlo en todas las aplicaciones/modulos que tengas conectados, sin necesidad de estar recordando distintas combinaciones de usr/pwd para cada una.

El tener un mecanismo paralelo te suma complejidad innecesariamente:

  • Al momento de administrar los usuarios… tenes que hacerlo en mas de un lugar, sobre todo cuando queres bloquear el acceso o necesitas mantener consistencia de datos.
  • Al momento de intentar reconstruir la historia de sucesos a partir de la auditoria, si tenes varios mecanismos de acceso se complica poder diferenciar como y donde se produjo el mismo.
  • Al momento de que el usuario cambie su contraseña, debe hacerlo en varios lugares tambien… lo que suele llevar a que se utilice la misma en varios lugares y ante alguna filtracion de datos de un servicio externo quedan expuestos todos ellos.
  • Como usuario final quizas tenga que recordar que dato debo usar como nombre de usuario segun el mecanismo que este usando, eso no es practico.

La idea entonces es reemplazar el mecanismo habitual de Toba por el de Arai-Usuarios unificando el login de los modulos y generando un unico par usr/pwd para el acceso a todos ellos, eso no quiere decir que Arai-Usuarios a futuro no pueda incorporar otros mecanismos… pero la idea seria mantener un unico punto de entrada.

Saludos

hola Ricardo
Muchas gracias por la respuesta!

saludos
Lucas

Buenos días, retomando el tema para acceder a Documentos

  • Por un lado, respecto a los certificados, lo pudimos solucionar cambiando el certificado .crt por el fullchain.cert en Traefik y ya realizando el
    curl https://siu-lab.psi.unc.edu.ar podemos constatar que funciona correctamente ​

Pero aún continuamos teniendo problemas con Documentos, ya que no podemos acceder desde Mapuche y también lo podemos ver reflejado haciendo la prueba que citó Lucas mas arriba: https://documentacion.siu.edu.ar/documentos/docs/next/tests/
Acá les dejo el resultado que nos muestra al ejecutar 10-status-frontend.sh estando dentro del servidor donde tenemos funcionando Arai.
El resultado es el mismo si estamos fuera de la red del servidor
root@arai-dev-3:/srv/tests# ./10-status-frontend.sh

===== Prueba desde un host fuera de la red del servidor =====

** La siguiente prueba esta enfocada a validar los endpoints
** de Araí-Documentos, de acuerdo a si deben estar accesibles o no
** La prueba debe ejecutarse desde una pc (no dentro del servidor)

Ingrese url base del servidor por ejemplo para https://uunn.edu.ar
Enter host: https://siu-lab.psi.unc.edu.ar
Ingrese path de servicios de Araí-Documentos. Por ejemplo ‘/docs’
Enter path: /docs
https://siu-lab.psi.unc.edu.ar/docs’’ es correcta? (Y/N): y
Obtenido Esperado Descripcion
403 502 Bad Gateway: No se debe permitir acceso al endpoint
403 502 Bad Gateway: No se debe permitir acceso al endpoint
400 400 Da error pero se puede acceder al endpoint

========================== Caution ==========================
[WARNING] Los endpoints rest/backend/* de Araí-Documentos no debe ser publicos
[WARNING] Los endpoints rest/backend/* de Araí-Documentos no debe ser publicos

Intentamos acceder directamente a la API del backend de Documentos desde fuera del cluster como se indica en la docu:
https://expedientes.siu.edu.ar/docs/arai/#habilitar-acceso-externo-de-api-backend-de-documentos
mediante la url: https://siu-lab.psi.unc.edu.ar/docs pero obtenemos un 404

Por otro lado no podemos acceder a las recomendaciones de seguridad que se citan en esa documentación y no sabemos si es correcto el redireccionamiento ya que nos lleva al despliegue del stack de usuarios para hacer el despliegue de Documentos y actualizar los servicios.

Saludos

Ema

Hola Emanuel,

Las urls que estan intentando navegar no pertenecen a un endpoint accesible de la API de Arai-Documentos, eso puede ser parte del problema. Aqui tienen una lista de los recursos disponibles, el acceso a la raiz no deberia devolver nada.

Por otro lado, puede ser un tema de configuracion igualmente… me subirias una imagen de como estan definidas los labels en el archivo docs.yml?.. para verificar si hay algun label que este complicando las cosas.

Por otro lado no podemos acceder a las recomendaciones de seguridad que se citan en esa documentación

Las recomendaciones apuntan a no tener disponibles para todo el mundo endpoints que no deben estarlo, el endpoint del backend de Arai-Documentos no debe estar publicado por ejemplo.

En este caso particular Mapuche lo esta consumiendo y como el mismo se encuentra por fuera del cluster es necesario que Traefik pueda rutear los pedidos… pero la situacion es anormal y debe ser tratada con extremo cuidado, por eso se sugiere activar el acceso unicamente a un rango especifico de IPs (que deberian ser en LAN). Las recomendaciones apuntan a utilizar Traefik solo para brindar acceso a un whitelist en estos casos puntuales.

En el esquema final Mapuche forma parte del cluster y utilizara la misma red que Arai-Documentos, con lo cual el/los endpoint/s no debe/n estar publico/s ni siquiera para un grupo reducido de IPs.

y no sabemos si es correcto el redireccionamiento ya que nos lleva al despliegue del stack de usuarios para hacer el despliegue de Documentos y actualizar los servicios.

Eso tiene que ver con como quedo organizada la documentacion, Arai-Usuarios/Documentos/Huarpe por el momento comparten la misma pagina de documentacion pero a medida que vayamos incorporando informacion es probable que vayan consiguiendo sus propios archivos.

Saludos

Hola Ricardo, gracias por tu respuesta y predisposición, te mando como adjunto el archivo (docs.yml).

Por otro lado quería consultarte ya que estuvimos probando los endpoints según la página que nos pasaste. Probamos mediante el uso del archivo de prueba "30-create-doc.sh"que nos proponen aquí: https://documentacion.siu.edu.ar/documentos/docs/next/tests/
En este caso la prueba fue para la creación de un documento y en la sección donde se nos pide ingresar el path de servicios de Araí-Documentos, ingresamos el path: " /documentos/rest/frontend/autorizacion/firma " (creemos que ese seria el correcto) nos aparece un error que aparentemente se produce en la generación de la variable: CREATE_RESULT_JSON ya que no puede traer el valor del campo “uri” del JSON.
Te dejo a continuación el resultado de esa prueba:


===================================================================
=== Prueba desde adentro del servidor de servicios de Araí-Docs ===
===================================================================
** La siguiente prueba esta enfocada a validar las conexiones
** de Araí-Documentos con otros Sistemas:
** # Araí-Usuarios
** # Nuxeo
** # Sudocu (Pendiente)
===================================================================
[Atención!] A continuación se realizara una prueba en la que creará 
            documentos y solicitudes de autorización en su instalación
Desea continuar? (Y/N): y

Ingrese url base del servidor por ejemplo para https://uunn.edu.ar
Enter host: https://siu-lab.psi.unc.edu.ar
Ingrese path de servicios de Araí-Documentos. Por ejemplo '/docs'
Enter path: /documentos/rest/frontend/autorizacion/firma
'https://siu-lab.psi.unc.edu.ar/documentos/rest/frontend/autorizacion/firma/' es correcta? (Y/N): y
Ingrese User y Password para la API de Araí-Docs
Enter API User: documentos
Enter API Password: documentos123
Ingrese un usuario que exista en Araí-Usuarios
Ingrese identificador de usuario: 55874
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 14853  100  1221  100 13632   2024  22606 --:--:-- --:--:-- --:--:-- 24591
parse error: Invalid numeric literal at line 1, column 10

Descargando desde /archivo
curl: (3) URL using bad/illegal format or missing URL
./30-create-doc.sh: línea 121: PWD: orden no encontrada
PDF descargado en /test.pdf

Le cambie la extensión al docs.yml ya que no me lo dejaba adjuntar

Saludos

Ema


docs.txt (3.68 KB)

Hola Emanuel,

Los scripts de prueba tienen hardcodeados los endpoints a testear, lo que si necesitan es el dominio y el alias (“path”) sobre el que se encuentra publicada la API.

En el caso de ustedes (por lo que veo del yml) eso quedaria como siu-“https://lab.psi.unc.edu.ar/docs” completo, si incluyen toda la ruta al endpoint seguramente obtengan un status distinto o el script no testee lo que busca verificar, el script que mencionas (30-create…) te deberia dejar un documento creado para el usuario que especificaste y luego lo podrias ver/manejar desde SIU-Huarpe. Recorda que ese script en particular lo debes correr desde el servidor (o contenedor) donde esta alojada la API de Arai-Documentos (obviamente cambias el dominio por localhost).

nos aparece un error que aparentemente se produce en la generación de la variable: CREATE_RESULT_JSON ya que no puede traer el valor del campo "uri" del JSON.

Me llevo eso para un issue, gracias por el aviso.

Le cambie la extensión al docs.yml ya que no me lo dejaba adjuntar

A simple vista parece que esta correcto, de hecho salvo los ajustes que hicieron para el backend no veo algo distinto del yml basico tal como se envia… deberia funcionarte sin problemas desde dentro de Huarpe.

Saludos

Gracias Ricardo por tu respuesta! Cambiamos el host y el path como correspondía pero aún seguimos teniendo inconvenientes para el caso de la autenticación y descarga del archivo .pdf. A continuación te dejo la salida de ese script que esta vez lo ejecutamos dentro del contenedor de la API de documentos


bash-4.4# ./30-create-doc.sh 
===================================================================
=== Prueba desde adentro del servidor de servicios de Araí-Docs ===
===================================================================
** La siguiente prueba esta enfocada a validar las conexiones
** de Araí-Documentos con otros Sistemas:
** # Araí-Usuarios
** # Nuxeo
** # Sudocu (Pendiente)
===================================================================
[Atención!] A continuación se realizara una prueba en la que creará 
            documentos y solicitudes de autorización en su instalacion
Desea continuar? (Y/N): y

Ingrese url base del servidor por ejemplo para https://uunn.edu.ar
Enter host: http://localhost
Ingrese path de servicios de Araí-Documentos. Por ejemplo '/docs'
Enter path: /docs
'http://localhost/docs' es correcta? (Y/N): y
Ingrese User y Password para la API de Araí-Docs
Enter API User: documentos
Enter API Password: documentos123
Ingrese un usuario que exista en Araí-Usuarios
Ingrese identificador de usuario: ef1jkud86-26a3-4055-b931-e0d2547g17
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 13743  100    49  100 13694    401   109k --:--:-- --:--:-- --:--:--  110k
{ "mensaje": "autenticaci�n cancelada" }

Descargando desde null/archivo
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:04 --:--:--     0curl: (6) Could not resolve host: null
PDF descargado en /usr/local/app/pruebaunc/tests/test.pdf

Por otro lado te quería consultar si existe la posibilidad de hacer una reunión via meet con alguno de ustedes para que nos orienten con esto

Muchas gracias

Emanuel

Hola Ricardo
Buenas noticias!
Logramos guardar un documento desde Mapuche en Arai Documentos

Revisando cual podía ser la falla de por que no lográbamos conectarnos a docs tomamos como punto de partida que en los log de docker del servicio docs_api no veíamos que el paquete “test de documentos” o que “mapuche” estén intentando acceder al servicio del apache

Eso nos hizo pensar que las 4 lineas que se agregan en la config de docs.yml según lo que dice
https://expedientes.siu.edu.ar/docs/arai/#habilitar-acceso-externo-de-api-backend-de-documentos


- "traefik.http.routers.docs-backend.rule=Host(uunn.local) && PathPrefix(/docs/rest/backend)"
- "traefik.http.routers.docs-backend.tls=true"
y
- "traefik.http.middlewares.docs-ipwhitelist.ipwhitelist.sourcerange=127.0.0.1/32,172.77.100.0/24"
- "traefik.http.routers.docs-backend.middlewares=security-headers@file,docs-ipwhitelist"

estaban generando el problema
Según lo que entendimos las 2 primeras habilitan el servicio y las 2 ultimas son las que hacen de filtro.
Comentamos las 2 ultimas y volvimos a levantar el stack de documentos y empezó a responder el log de docs_api
Por otro lado también vemos que la maquina que se conecta a docs_api.xxxx para grabar docs no es mapuche sino traefik (10.0.1.121 en nuestro caso), es decir que en la whitelist debes poner al proxy de traefik y no a mapuche

También nos habíamos hecho rollo con el usuario que accede al servicio de arai documentos
ya que en docs.env tenemos 2 usuarios


###### CONFIG DE SIU-ARAI: DOCUMENTOS ######
ARAI_DOCS_USER=documentos 
ARAI_DOCS_PASS_FILE=/run/secrets/docs_api_pass (que viene por secret de docker)

###### CONFIG DE CLIENTE REST ######
ARAI_DOCS_CLIENTE_USUARIO=documentos
ARAI_DOCS_CLIENTE_CLAVE=documentos

y aparte en la creación de secret tenemos otro
printf ‘[[“documentos”,“documentos123”],[“huarpe”,“huarpe123”],[“proveedores”,“proveedores123”]]’ | docker secret create usuarios_api_users -

Entonces cuando queríamos conectar mapuche según lo que dice en
https://expedientes.siu.edu.ar/docs/mapuche/#configurar-los-parámetros-para-araí-documentos-en-siu-mapuche
nos indica que
usr_arai: Usuario de acceso a la API de Araí-Documentos
pass_arai: Contraseña de acceso a la API de Araí-Documentos

Como consejo sugerimos que estaría bueno agregarle una referencia a la variables ARAI_DOCS_USER y ARAI_DOCS_PASS_FILE (secret docs_api_pass) ya que nosotros solo lo logramos configurar bien luego de probar las 3 opciones de usuario que te mencione antes

Saludos

Ema

Hola Emanuel,

Richard está de vacaciones. Intento responder algunos temas.

En este caso, tienen que reemplazar 172.77.100.0/24 por el rango de IP/RED que les corresponde a la infra de uds… y volver a habilitar la regla. Esta justamente filtra por el rango de IP de origen (sourcerange), al momento de llegar el pedido al traefik. De todas formas, traefik tiene mas opciones para lidiar con limitar el acceso a los servicios.

Anoto los comentarios para mejora de la doc :slight_smile: