LIB: Adaptacions Cl@ve 2.0

[sgelabert-dgtic]

Es continua amb la tasca #1 a fi d'adaptar el funcionament del plugin a Cl@ve 2.0

[rsanz-indra]

Se abre consulta al CAID para uso de parámetro spApplication:

En las instrucciones recibidas por el CAID para la integración con Clave2.0 se indica que: "Clave 1 permitía añadir el parámetro spApplication a la petición SAML. Sin embargo, en Cl@ve 2 ese parámetro ha desaparecido" Sin embargo en los fuentes de ejemplo de integración vemos que sí parece tener este parámetro: reqBuilder.spApplication(spApplication); ¿Podéis aclararlo?

[rsanz-indra]

Se realiza la consulta al CAID:

En las instrucciones recibidas por el CAID para la integración con Clave2.0 se indica que: "Clave 1 permitía añadir el parámetro spApplication a la petición SAML. Sin embargo, en Cl@ve 2 ese parámetro ha desaparecido" Sin embargo en los fuentes de ejemplo de integración vemos que sí parece tener este parámetro: reqBuilder.spApplication(spApplication); ¿Podéis aclararlo?

Contestan lo siguiente:

_El atributo spApplication continúa gestionándose en el código implementado para Cl@ve 2 pero en lugar de enviarse como parámetro independiente en la petición SAML se envía concatenado con el providerName que corresponda en la forma DIR3NIF;spApplication

Se vuelve a preguntar:

_No nos queda claro. Estamos integrándonos mediante Java y la petición SAML se construye mediante unas clases que proporcionan las librerías de Cl@ve: ¿Hay que establecerlo de esta forma? reqBuilder.providerName(DIR3_NIF + ";" + spApplication); reqBuilder.spApplication(spApplication); ¿O hay que hacerlo de esta otra forma? reqBuilder.providerName(DIR3NIF); reqBuilder.spApplication(spApplication);

Y finalmente responden la pregunta:

_Buenas tardes, Disculpen el error producido en nuestra respuesta del pasado día 12 de septiembre de 2018 (11:12 h) ya que la forma correcta de enviar el providerName asignado a cada Organismo integrado en el sistema Cl@ve 2 es de la forma NIFDIR3;spApplication El atributo spApplication debe ir concatenado al providerName en cuestión en esta nueva versión del sistema Cl@ve, por ejemplo, de la forma indicada en su primera propuesta.

[rsanz-indra]

Después de resolver temas a nivel de configuración ya se redirige a Cl@ve y se retorna, pero al interpretar el mensaje de vuelta nos encontramos con un error que no sabemos interpretar: Error (no. message.validation.error.code) processing request : message.validation.error.code - Audiences [http://localhost:8080/loginibfront/retornoLoginClave/YDIFUIXN-XJIBMJT8-T8ZPFVRK.html] are not allowed Hemos abierto CAID para preguntar por este error.

[rsanz-indra]

Después de varias consultas al CAID seguimos a la espera de que nos indiquen el problema. Adjuntamos comunicaciones con el CAID IncidenciaCAID.pdf

[rsanz-indra]

Se vuelve a insistir al CAID sobre el problema encontrado en la adaptación a Cl@ve 2.0

[rsanz-indra]

Hemos recibido respuesta hoy preguntando sobre el estado de la incidencia:

Número de Incidencia: 463906

Buenos días, Rogamos disculpen la demora producida en nuestra respuesta. Por favor, ¿podrían indicar si continúan experimentando el mismo tipo de problema en su integración con el servicio Cl@ve 2?. ¿En qué estado se hallan actualmente?.

Hemos repetido las pruebas y seguimos igual. Hemos reabierto la incidencia pasando los datos de la prueba.

[rsanz-indra]

Se obtiene la siguiente respuesta del CAID:

Buenas tardes, Por lo que se observa en las trazas de log del sistema Cl@ve, la pasarela responde correctamente y genera de forma adecuada la respuesta SAML hacia el endpoint que se proporciona en sus mensajes de petición. Quizá debería revisarse el propio servidor que recibe la respuesta SAML de la pasarela de Cl@ve por si existiese algún tipo de problema durante su procesamiento. Se adjunta la traza de log completa que puede observarse en la pasarela del sistema Cl@ve donde puede apreciarse que la respuesta es generada y enviada con éxito para el identificador de sesión C4TKVDUI-08MABRT8-T8YRS5JQ

Log_Clave_v2_0.zip

[rsanz-indra]

Se tracea el código de las librerías de Cl@ve y se detecta un error de configuración. Por tanto se desbloquea el desarrollo.

[rsanz-indra]

Encontrada nueva incidencia que reportamos al CAID, no parece que se pueda obtener el mecanismo de autenticación empleado. Mientras que se responde, seguimos avanzando.

Ya hemos encontrado el problema, era un error nuestro en la configuración. Solventado esto, nos hemos encontrado que en la respuesta que envía Cl@ve2 no encontramos el método de autenticación (idp) utilizado por el usuario para autenticarse

Para Cl@ve1 se obtenía a partir del issuer: authnResponse.getAssertions().get(0).getIssuer().getValue()

Para Cl@ve2 parece que se indica que se obtiene también a través del issuer tal como se indica en el fichero 6_ReturnAction_cambio_6.txt en el kit de migración, pero el valor que se obtiene de authnResponse.getIssuer() es "https://se-pasarela.clave.gob.es"

• if (authnResponse.getIssuer() != null){
• scope = authnResponse.getIssuer();
• switch(scope.substring(0, 6)) {
• case Constants.SCOPE_AFIRMA:
• scope = "DNIe / Certificado electrónico"; break;
• case Constants.SCOPE_AEAT:
• scope = "Cl@ve PIN";
• break;
• case Constants.SCOPE_SS:
• scope = "Cl@ve permanente";
• break;
• case Constants.SCOPE_STORK + "-":
• scope = "Ciudadanos UE - " + scope.substring(6); }

¿como se puede obtener el método de autenticación empleado?

[rsanz-indra]

Dudas pendientes de contestar por CAID (20/11/18)

[rsanz-indra]

Se obtiene la siguiente respuesta del CAID de Cl@ve:

Número de Incidencia: 463906

MENSAJE [Centro de Atención a Integradores y Desarrolladores]: Hola, Sentimos la demora en la respuesta. Estamos intentando resolver ambos temas. - Para la primera vamos a realizar un pequeño cambio en las librerías. Tal como se está devolviendo ahora el IdP, añadir un método para obtenerlo resulta difícil ya que requiere hacer cambios en las librerías eIDAS que se usan de base. Lo que se va a hacer es devolver el IdP como un atributo más de la respuesta SAML. Este es un cambio sencillo ya que solo requiere definir el atributo SAML en el fichero "additional_attributes.xml". Y el parseo será inmediato. - En cuanto a la segunda ya se ha resuelto y se ha añadido el namespace para que sea más sencillo parsearla. Estamos ahora mismo en la SGAD envueltos en el cambio del CPD por lo que resulta difícil avanzar una fecha pero esperamos que hacia finales de enero o principios de febrero pudiéramos tener esto en Servicios Estables. Saludos

[rsanz-indra]

Pendiente liberación nueva versión por parte del ministerio

[RodrigoTEF]

Se tracea el código de las librerías de Cl@ve y se detecta un error de configuración. Por tanto se desbloquea el desarrollo.

si estas utilizando el servidor en otro dns diferente a localhost tienes que cambiarlo en el sp.properties. Concretamente el sp.return