Problemas con @firma 6.2

tgaya-dgtic commented 4 years ago

La versión actual de gdib tiene una comprobación que lanza una excepción cuando se conecta a un servidor @firma versión 6.2.

Las aplicaciones reciben el mensaje de error:

La firma del document ha produit un error al validar i custodiar: ArxiuCaibException: [HTTP_500, COD_021] Metadato tipoFirma con valor incorrecto para el documento ... . Formato DSS esperado http://uri.etsi.org/103172/v2.1.1#.

El trozo de código java es el siguiente:

         if(result.getValidationStatus() == ValidationStatus.CORRECTO){
                    LOGGER.debug("Resultado de validación de la firma electrónica del documento " + (node.getId() == null? "nuevo documento": node.getId()) + " correcto.");
                    //Si la firma es correcta, se verifica que el formato avanzado es igual o superior al mínimo exigido
                    signatureFormat = SignatureUtils.dssSigntureFormatToInernalSignatureFormat(result.getSignatureType(),result.getSignatureForm());
                    LOGGER.debug("Se verifica que la firma y el metadato de firma son coherentes (familia o tipo de firma).");
                    if(!currentSignatureFormat.getType().equalsIgnoreCase(signatureFormat.getType())){
                        //Se verifica que el formato de firma establecido para el nodo y el retornado por @firma
                        //pertenecen a la misma familia de formatos (CAdES, XAdES o PAdES)
                        throw new GdibException("Metadato " + EniModelUtilsInterface.PROP_TIPO_FIRMA + " con valor incorrecto para el documento " +
                                nodeIdValue + ". Formato DSS esperado " + result.getSignatureType() + ".");
                    }

Habría que corregir el if que lanza la excepción.

Suponemos que los nuevos tipos de firma que devuelve @firma 6.2 son los siguientes:

Format tradicional | Format Baseline

Entonces, si se tiene que seguir comprobando que el tipo de firma es el mismo, habría que añadir en el if que se compruebe que si es un formato equivalente (tanto tradicional como baseline), funcione bien.

atrobat-dgtic commented 4 years ago

He hablado con Cristina Miranzo sobre este tema, tendríamos que valorar si és más correcto no hacer esta validación y poner el tipo de firma que retorna @firma, ya que éste seguro que es el correcto y no tener en cuenta lo que envía la aplicación.

cbernus-memorandum commented 4 years ago

En la actualización de librerías Integra cambiaron las URIs de las firmas Baseline y se añadieron a Signature Utils en el siguiente commit : https://github.com/GovernIB/gdib/commit/14652b6fb39bf1bbe48725e5231aa70f994fdcad

tgaya-dgtic commented 4 years ago

El problema viene únicamente por este if, sacado del bloque de código que ya puse en esta issue. if(!currentSignatureFormat.getType().equalsIgnoreCase(signatureFormat.getType())){

Parece ser que esta comparación de strings funciona con @firma 6.1, pero @firma 6.2 devuelve un string (tipo de firma) distinto.

cbernus-memorandum commented 4 years ago

Si Toni, perdona, creo que no me explicado bien, lo que quiero decir que en gdib-1.5 esos nuevos formatos ya están contemplados y ya debería hacer bien la comparación dentro de ese método, como puedes ver en la imagen adjunta, se añadieron los nuevos formatos.

tgaya-dgtic commented 4 years ago

Ok, creía que era un String y es un objeto SignatureFormat.

Pues nada, habrá que ver si en desarrollo, apuntando a un servidor @firma 6.2, realizando esta operación, no se lanza la excepción.

GovernIB / gdib

Problemas con @firma 6.2 #37

Format tradicional | Format Baseline