Problemas en Integración con SIU-Diaguita

SIU-Araí Araí - Instalación
1

Estamos integrando una instalación de Diaguita con el IDP de Arai Usuarios tal como se describe aca1, y nos pasa lo siguiente. En el paso de forzar uso de HTTPS, lo activamos y todos los archivos parecen configurarse bien, pero pasa lo siguiente:

Si dejamos la variables ‘proyecto_login’ vacía en ‘saml_onelogin.ini’ (tal como queda después de reconfigurar el sso) SAML redirige con HTTPS pero obviamente no funciona porque falta esa parte del Path.

Ahora, si le ponemos en esa variables el valor “diaguita”, arma bien el path pero sin la “s” de https.

Comparamos el resto de los archivos involucrados con instalaciones de Pilaga y Mapuche integradas al mismo IDP y funcionan ok.

Por ahora forzamos la redirección de http->https y “salvamos” la situación, pero queremos arreglar esto si se les ocurre que puede estar pasando.

2

Hola Tomas,

La entrada ‘proyecto_login’ en ‘saml_onelogin.ini’ dentro de la sección [sp] debería ir para Diaguita, si no lo agregó es por un bug en el mecanismo de reconfiguración. También, debería agregarles una entrada “usa_proxy_vars = 1” (si Diaguita usa Toba >=3.2.10 y siu/instalador >=1.9).

En teoría con tener en instalacion/web_server.ini la entrada https = “on” estaría forzando a que la componente SP responda a la interacción con el IDP indicándole que es https.

En Diaguita, ¿están detrás de un proxy reverso?

3

Claro, Diaguita aun tiene ese bug, pero descubrimos ese comportamiento raro que te comenté en el post original.

Claro, eso esta bien seteado tal como dice la guia. Por eso este reporte, no anda como en teoria deberia hacerlo (que tenemos funcionando en Mapuche y Pilaga).

No, la conexion entre IDP, SP y Cliente es directa a nivel HTTP.

4

Tomás, podes pasarnos:

  • error que te da del lado del IDP o SP respecto a http(s)
  • que tipo de ajuste hicieron para manejar el paso de http a https
5

A nivel del Browser era un 404.

Usando un debugger de SAML (via addon de firefox) podiamos ver en el mensaje XML de SAML que el Issuer iba sin la “s” de https (el endpoint que termina con default-sp)

El clasico mod_rewrite de apache:

RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Por eso pensamos que no es solucion definitiva, es mas bien un hack para que podamos mostrarlo “andando”.

Te mandaria capturas pero estamos teniendo bardo en los accesos a la uni (algun quilombo de conectividad con la ARIU hasta donde se)

6

Hola Tomas,

te hago una consulta puntual, fijate en el archivo instancia.ini si tiene seteado el parametro full_url para Diaguita y si esta colocado que vaya por https o comun.

Saludos

7

No tenia la “s” en el instancia.ini. Probamos agregandosela y no tuvimos exito.

Como dato de “color”, en el pilaga que esta integrado al mismo IDP, y esta por HTTPS, ese valor full_url esta sin la “s”. Y anda.

Por ahi un dato que nos serviria para empezar a debugguear es: ¿Donde levanta Toba esas variables (la de los ini)? Se almacenan en la instancia? En cada request se levantan desde los .ini? Por momento nos da la sensación de que estan “cacheados”.

8

Tomas, vamos por partes entonces.

Primero hay que verificar que tienen bien instalado dicho Diaguita.

Suponiendo que tenemos un diaguita en https://diaguita.unx.edu.ar, obtener los metadatos de SP accediendo a https://diaguita.unx.edu.ar/?metadata

<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
                     validUntil="2020-11-13T18:20:28Z"
                     cacheDuration="PT604800S"
                     entityID="https://diaguita.unx.edu.ar/default-sp">
    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
                                Location="https://diaguita.unx.edu.ar/?sls" />
        <md:NameIDFormat>defaultUserAccount</md:NameIDFormat>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                                     Location="https://diaguita.unx.edu.ar/?acs"
                                     index="1" />
    </md:SPSSODescriptor>
</md:EntityDescriptor>

Esto dará las URL con la que está trabajando Toba. Los puntos importantes acá (que tienen que exponerse con HTTPS) son:

Luego, en el IDM (abm de aplicaciones) ubican la app Diaguita/Conector SAML y los datos allí cargados deben coincidir.

9

Esto es extraño, ya que dicho parametro es el que se utiliza para armar la info del SP que luego se entrega al IDP.

Como dato de "color", en el pilaga que esta integrado al mismo IDP, y esta por HTTPS, ese valor [b]full_url[/b] esta sin la "s". Y anda.
Lo que lo hace aun mas bizarro... fijate lo que te paso abajo.
Por ahi un dato que nos serviria para empezar a debugguear es: ¿Donde levanta Toba esas variables (la de los ini)? Se almacenan en la instancia? En cada request se levantan desde los .ini? Por momento nos da la sensación de que estan "cacheados".

Los valores de la instancia se levantan cuando se abre la sesion en PHP, asi que si… es probable que tengas que usar una pestaña privada para probar si metiste algun cambio.
Mas alla de eso, el metodo que arma las URLs para el SP… saca la primera parte de aca, como ves si existe el parametro full_url el resto se vuelve irrelevante.

Saludos

PD: Algo que me olvide, cuando navegues a ?metadata tal como te pidio Sergio… fijate si podes capturar el log de Toba, por si hay algo que se nos este escapando.