Cómo depurar errores cuando se usa Tipo de Autenticación por web services externos y el GAM

Unofficial Content

Cuando la aplicación usa el GAM y se tiene configurado el Tipo de Autenticación por web services externos (GAM External Web Services Authentication Type), si hay problemas en la configuración del Tipo de Autenticación en el GAM, se puede producir un error genérico cuando un usuario intenta loguearse:

Error in webservice response, the service is not responding, please contact the application's administrator. (GAM40)

Aqui se presenta una guía para detectar la causa de este problema y buscar una solución.

Tener en cuenta que el servicio web tiene que mandar y recibir una estructura predeterminada para que el GAM pueda usarlo como servicio de autenticación, los detalles se encuentran en el documento (GAM External Web Services Authentication Type).

Primero se debe verificar que el servicio responde correctamente antes de intentar autenticarse usando el GAM, una forma de verificarlo es ejecutar la URL del wsdl del servicio en el browser. Confirmado eso, revisar la configuración del Tipo de Autenticación en el GAM Backend. Para eso, ejecutar el backend del GAM (objeto gamhome), ir por "Authentication Types", presionar "update" en el tipo de autenticación ya definido, y verificar lo siguiente:

1. Private Encription Key

Que el Private Encription Key especificado sea el correcto. Este parámetro sirve para encriptar el user name y la password, usando la función encrypt64 de GeneXus. El web service debe usar dicha clave para desencriptar usando la función decrypt64. No es mandatorio especificar una key.

2.  Server name

Que el server name (se puede también configurar la IP) sea accesible desde el servidor de aplicaciones donde ejecuta la aplicación que usa el GAM.

3. Port

Se debe especificar el port donde escucha el servicio.

4. Base URL

La base URL es todo el contenido de la URL quitando el servername:port y quitando el nombre del servicio por ejemplo si la URL del servicio es la que sigue:

https://www.samples.com/gxlogin/agamwslogin.aspx?wsdl

especificar BASE URL: gxlogin

otro ejemplo, para el siguiente service URL:

https://www.samples.com/gxlogin/servlet/agamwslogin?wsdl

especificar BASE URL: gxlogin/servlet

5. Secure protocol

Si el web service escucha bajo HTTPS, como en los ejemplos anteriores, especificar:

Secure protocol= Yes, de lo contrario, si escucha bajo HTTP especificar Secure protocol= NO

6. Web service name

El webservice name no debe incluir la extensión.

Ejemplo si se tiene la siguiente URL para el servicio:

https://www.samples.com/gxlogin/agamwslogin.aspx?wsdl

espeificar:

web service name = agamwslogin
web service extension = aspx

otro ejemplo:

https://www.samples.com/gxlogin/servlet/agamwslogin?wsdl

web service name = agamwslogin
web service extension = <vacio>

Cómo saber más a fondo la causa de un problema de autenticación por web services externos

Mientras el servicio corra bajo HTTP (no HTTPS), se puede usar alguna herramienta como el tcptrace para poder interceptar la comunicación entre cliente y servidor y poder entender mejor la causa de un problema de conexión.
El tcptrace escucha la comunicación entre cliente y servidor, y se debe configurar para tal fin de forma de que el GAM redireccione al puerto de escucha del tcptrace y éste al web service.

Para eso seguir los siguientes pasos:

1. Ejecutar el backend del GAM y actualizar el Tipo de autenticación por web services externos, especificando:

  • server name: localhost (o el server name o IP de la máquina donde ejecuta el tcptrace)
  • server port: 88 (cualquier puerto libre)

como se muestra en la figura siguiente:

wsexternostcptrace
imagen 1.

2. Ejecutar el tcptrace, y configurar:

  • Listen on port: 88 (el puerto especificado en imagen 1).
  • Destination server : <server name donde ejecuta el web service>
  • Destination port: <puerto donde escucha el web service>
wsexternostcptrace2
imagen 2.

Cuando el usuario intente ingresar al sistema mediante el Tipo de Autenticación por web services externos definido, se va a poder visualizar en la consola del tcptrace el POST al servicio y la respuesta HTTP del mismo lo cual ayuda en muchos casos a detectar posibles causas de un error.