From eea96120c311b938429e3af81b792b13062e08e8 Mon Sep 17 00:00:00 2001 From: Emma Kuppart Date: Mon, 22 Apr 2024 08:46:59 +0300 Subject: [PATCH 01/11] Implement timemark hashcode validation with Digidoc4j --- .../proxy/HasBdocTimemarkPolicyService.java | 40 +++ .../siva/proxy/HashcodeValidationMapper.java | 51 ++++ .../siva/proxy/HashcodeValidationProxy.java | 81 ++++-- .../HasBdocTimemarkPolicyServiceTest.java | 43 +++ .../proxy/HashcodeValidationProxyTest.java | 254 +++++++++++------- .../test-files/no_timemark_signature.xml | 94 +++++++ .../test/resources/test-files/signatures.xml | 1 + .../test-files/timemark_signature.xml | 81 ++++++ .../HashcodeValidationControllerTest.java | 52 ++-- .../HashcodeGenericValidationService.java | 54 ---- .../HashcodeGenericValidationServiceTest.java | 53 +--- .../TimemarkHashcodeValidationService.java | 71 +++++ .../AsicContainerValidationReportBuilder.java | 36 +-- .../DDOCContainerValidationReportBuilder.java | 18 +- ...emarkContainerValidationReportBuilder.java | 225 ++-------------- ...memarkHashcodeValidationReportBuilder.java | 159 +++++++++++ .../util/SignatureCertificateParser.java | 52 ++++ .../timemark/util/SignatureInfoParser.java | 122 +++++++++ .../timemark/util/SignatureScopeParser.java | 44 +++ .../util/SigningCertificateParser.java | 43 +++ .../timemark/util/ValidationErrorMapper.java | 44 +++ .../test-files/timemark_signature.xml | 81 ++++++ .../siva/validation/util/SubjectDNParser.java | 2 +- 23 files changed, 1226 insertions(+), 475 deletions(-) create mode 100644 siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyService.java create mode 100644 siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationMapper.java create mode 100644 siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyServiceTest.java create mode 100644 siva-parent/siva-validation-proxy/src/test/resources/test-files/no_timemark_signature.xml create mode 100644 siva-parent/siva-validation-proxy/src/test/resources/test-files/signatures.xml create mode 100755 siva-parent/siva-validation-proxy/src/test/resources/test-files/timemark_signature.xml create mode 100644 validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/TimemarkHashcodeValidationService.java create mode 100644 validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java create mode 100644 validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureCertificateParser.java create mode 100644 validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureInfoParser.java create mode 100644 validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java create mode 100644 validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SigningCertificateParser.java create mode 100644 validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/ValidationErrorMapper.java create mode 100755 validation-services-parent/timemark-container-validation-service/src/test/resources/test-files/timemark_signature.xml diff --git a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyService.java b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyService.java new file mode 100644 index 000000000..c5e2b3e52 --- /dev/null +++ b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyService.java @@ -0,0 +1,40 @@ +package ee.openeid.siva.proxy; + +import ee.openeid.siva.validation.document.ValidationDocument; +import eu.europa.esig.dss.utils.Utils; +import eu.europa.esig.dss.xml.common.definition.DSSNamespace; +import eu.europa.esig.dss.xml.utils.DomUtils; +import eu.europa.esig.xades.definition.xades132.XAdES132Element; +import org.digidoc4j.dss.xades.BDocTmSupport; +import org.springframework.stereotype.Service; +import org.w3c.dom.Element; + +import java.util.Optional; + +import static eu.europa.esig.dss.xml.common.definition.AbstractPath.allFromCurrentPosition; + +@Service +public class HasBdocTimemarkPolicyService { + boolean hasBdocTimemarkPolicy(ValidationDocument validationDocument) { + return extractSigPolicyIdElement(validationDocument) + .map(this::extractSigPolicyIdValue) + .map(this::matchesBdocTimemarkPolicyId) + .orElse(false); + } + + private Optional extractSigPolicyIdElement(ValidationDocument validationDocument) { + DomUtils.registerNamespace(new DSSNamespace("http://uri.etsi.org/01903/v1.3.2#", "xades132")); + return Optional.of(validationDocument.getBytes()) + .filter(DomUtils::startsWithXmlPreamble) + .map(DomUtils::buildDOM) + .map(dom -> DomUtils.getElement(dom, allFromCurrentPosition(XAdES132Element.SIG_POLICY_ID))); + } + + private String extractSigPolicyIdValue(Element sigPolicyId) { + return Utils.trim(DomUtils.getValue(sigPolicyId, allFromCurrentPosition(XAdES132Element.IDENTIFIER))); + } + + private boolean matchesBdocTimemarkPolicyId(String sigPolicyIdValue) { + return Utils.areStringsEqualIgnoreCase(BDocTmSupport.BDOC_TM_POLICY_ID, sigPolicyIdValue); + } +} diff --git a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationMapper.java b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationMapper.java new file mode 100644 index 000000000..c7233b84e --- /dev/null +++ b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationMapper.java @@ -0,0 +1,51 @@ +package ee.openeid.siva.proxy; + +import ee.openeid.siva.proxy.document.ProxyHashcodeDataSet; +import ee.openeid.siva.validation.document.SignatureFile; +import ee.openeid.siva.validation.document.ValidationDocument; +import ee.openeid.siva.validation.document.report.Reports; +import ee.openeid.siva.validation.document.report.ValidationConclusion; +import org.springframework.stereotype.Service; + +import java.util.List; + +@Service +public class HashcodeValidationMapper { + public List mapToValidationDocuments(ProxyHashcodeDataSet proxyRequest) { + return proxyRequest.getSignatureFiles() + .stream() + .map(signatureFile -> createValidationDocument(proxyRequest.getSignaturePolicy(), signatureFile)) + .toList(); + } + + private ValidationDocument createValidationDocument(String signaturePolicy, SignatureFile signatureFile) { + ValidationDocument validationDocument = new ValidationDocument(); + validationDocument.setSignaturePolicy(signaturePolicy); + validationDocument.setBytes(signatureFile.getSignature()); + validationDocument.setDatafiles(signatureFile.getDatafiles()); + return validationDocument; + } + + Reports mergeReportsToOne(List reportsList) { + int signaturesCount = 0; + int validSignaturesCount = 0; + Reports response = null; + for (Reports reports : reportsList) { + ValidationConclusion validationConclusion = reports.getSimpleReport().getValidationConclusion(); + if (signaturesCount == 0) { + response = reports; + validSignaturesCount = validationConclusion.getValidSignaturesCount(); + } else { + response.getSimpleReport().getValidationConclusion().getSignatures().addAll(validationConclusion.getSignatures()); + validSignaturesCount = validSignaturesCount + validationConclusion.getValidSignaturesCount(); + } + signaturesCount = signaturesCount + validationConclusion.getSignaturesCount(); + } + if (response != null) { + ValidationConclusion validationConclusion = response.getSimpleReport().getValidationConclusion(); + validationConclusion.setSignaturesCount(signaturesCount); + validationConclusion.setValidSignaturesCount(validSignaturesCount); + } + return response; + } +} diff --git a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationProxy.java b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationProxy.java index 5ddf98940..80ea092ad 100644 --- a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationProxy.java +++ b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/HashcodeValidationProxy.java @@ -19,55 +19,92 @@ import ee.openeid.siva.proxy.document.ProxyHashcodeDataSet; import ee.openeid.siva.proxy.document.ReportType; import ee.openeid.siva.statistics.StatisticsService; -import ee.openeid.siva.validation.document.SignatureFile; +import ee.openeid.siva.validation.document.Datafile; import ee.openeid.siva.validation.document.ValidationDocument; import ee.openeid.siva.validation.document.report.Reports; import ee.openeid.siva.validation.document.report.SimpleReport; -import ee.openeid.siva.validation.service.ValidationService; +import ee.openeid.siva.validation.exception.MalformedSignatureFileException; +import ee.openeid.siva.validation.security.SecureSAXParsers; +import ee.openeid.validation.service.generic.SignatureXmlHandler; import ee.openeid.validation.service.generic.HashcodeGenericValidationService; +import ee.openeid.validation.service.timemark.TimemarkHashcodeValidationService; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.ApplicationContext; import org.springframework.core.env.Environment; import org.springframework.stereotype.Service; +import org.springframework.util.CollectionUtils; +import javax.xml.parsers.SAXParser; +import java.io.ByteArrayInputStream; import java.util.List; -import java.util.stream.Collectors; +import java.util.Optional; @Service public class HashcodeValidationProxy extends ValidationProxy { - - private static final String HASHCODE_GENERIC_SERVICE = "hashcodeGeneric"; + private final HasBdocTimemarkPolicyService hasBdocTimemarkPolicyService; + private final HashcodeValidationMapper hashcodeValidationMapper; + private final HashcodeGenericValidationService hashcodeGenericValidationService; + private final TimemarkHashcodeValidationService timemarkHashcodeValidationService; @Autowired - public HashcodeValidationProxy(StatisticsService statisticsService, ApplicationContext applicationContext, Environment environment) { + public HashcodeValidationProxy(StatisticsService statisticsService, + ApplicationContext applicationContext, + Environment environment, + HasBdocTimemarkPolicyService hasBdocTimemarkPolicyService, + HashcodeValidationMapper hashcodeValidationMapper, + HashcodeGenericValidationService hashcodeGenericValidationService, + TimemarkHashcodeValidationService timemarkHashcodeValidationService) { super(statisticsService, applicationContext, environment); + this.hasBdocTimemarkPolicyService = hasBdocTimemarkPolicyService; + this.hashcodeValidationMapper = hashcodeValidationMapper; + this.hashcodeGenericValidationService = hashcodeGenericValidationService; + this.timemarkHashcodeValidationService = timemarkHashcodeValidationService; } @Override String constructValidatorName(ProxyRequest proxyRequest) { - return HASHCODE_GENERIC_SERVICE + SERVICE_BEAN_NAME_POSTFIX; + throw new IllegalStateException("Method is unimplemented"); } @Override public SimpleReport validateRequest(ProxyRequest proxyRequest) { - ValidationService validationService = getServiceForType(proxyRequest); - if (validationService instanceof HashcodeGenericValidationService && proxyRequest instanceof ProxyHashcodeDataSet) { - - List validationDocuments = ((ProxyHashcodeDataSet) proxyRequest).getSignatureFiles() - .stream() - .map(signatureFile -> createValidationDocument(proxyRequest.getSignaturePolicy(), signatureFile)) - .collect(Collectors.toList()); - Reports reports = ((HashcodeGenericValidationService) validationService).validate(validationDocuments); - return chooseReport(reports, ReportType.SIMPLE); + if (proxyRequest instanceof ProxyHashcodeDataSet) { + var reports = hashcodeValidationMapper.mapToValidationDocuments((ProxyHashcodeDataSet) proxyRequest) + .stream() + .map(this::validateDocument) + .toList(); + return chooseReport(hashcodeValidationMapper.mergeReportsToOne(reports), ReportType.SIMPLE); } throw new IllegalStateException("Something went wrong with hashcode validation"); } - ValidationDocument createValidationDocument(String signaturePolicy, SignatureFile signatureFile) { - ValidationDocument validationDocument = new ValidationDocument(); - validationDocument.setSignaturePolicy(signaturePolicy); - validationDocument.setBytes(signatureFile.getSignature()); - validationDocument.setDatafiles(signatureFile.getDatafiles()); - return validationDocument; + private Reports validateDocument(ValidationDocument validationDocument) { + Optional.ofNullable(getDataFileInfoIfNeeded(validationDocument)) + .filter(dataFiles -> !dataFiles.isEmpty()) + .ifPresent(validationDocument::setDatafiles); + if (hasBdocTimemarkPolicyService.hasBdocTimemarkPolicy(validationDocument)) { + return timemarkHashcodeValidationService.validateDocument(validationDocument); + } else { + return hashcodeGenericValidationService.validateDocument(validationDocument); + } + } + + private List getDataFileInfoIfNeeded(ValidationDocument validationDocument) { + if (!CollectionUtils.isEmpty(validationDocument.getDatafiles())) { + return null; + } else { + try { + SAXParser saxParser = SecureSAXParsers.createParser(); + SignatureXmlHandler handler = new SignatureXmlHandler(); + saxParser.parse(new ByteArrayInputStream(validationDocument.getBytes()), handler); + return handler.getDatafiles(); + } catch (Exception e) { + throw constructMalformedDocumentException(new RuntimeException(e)); + } + } + } + + private RuntimeException constructMalformedDocumentException(Exception cause) { + return new MalformedSignatureFileException(cause, "Signature file malformed"); } } diff --git a/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyServiceTest.java b/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyServiceTest.java new file mode 100644 index 000000000..95f6f1262 --- /dev/null +++ b/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HasBdocTimemarkPolicyServiceTest.java @@ -0,0 +1,43 @@ +package ee.openeid.siva.proxy; + +import ee.openeid.siva.validation.document.ValidationDocument; +import ee.openeid.siva.validation.document.builder.DummyValidationDocumentBuilder; +import lombok.SneakyThrows; +import org.junit.jupiter.api.Test; + +import static org.junit.jupiter.api.Assertions.assertFalse; +import static org.junit.jupiter.api.Assertions.assertTrue; + +class HasBdocTimemarkPolicyServiceTest { + private final HasBdocTimemarkPolicyService hasBdocTimemarkPolicyService = new HasBdocTimemarkPolicyService(); + + @Test + void hasBdocTimemarkPolicy_whenInputIsNotXmlFile_shouldReturnFalse() { + assertFalse( + hasBdocTimemarkPolicyService.hasBdocTimemarkPolicy(createValidationDocument("timestamptoken-ddoc.asics")) + ); + } + + @Test + void hasBdocTimemarkPolicy_whenSignatureDoesNotHaveBdocTimemark_shouldReturnFalse() { + assertFalse( + hasBdocTimemarkPolicyService.hasBdocTimemarkPolicy(createValidationDocument("no_timemark_signature.xml")) + ); + } + + @Test + void hasBdocTimemarkPolicy_whenSignatureHasBdocTimemark_shouldReturnTrue() { + assertTrue( + hasBdocTimemarkPolicyService.hasBdocTimemarkPolicy(createValidationDocument("timemark_signature.xml")) + ); + } + + @SneakyThrows + private ValidationDocument createValidationDocument(String file) { + return DummyValidationDocumentBuilder + .aValidationDocument() + .withDocument("test-files/" + file) + .withName(file) + .build(); + } +} diff --git a/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HashcodeValidationProxyTest.java b/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HashcodeValidationProxyTest.java index 8a1e9df74..f920007e3 100644 --- a/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HashcodeValidationProxyTest.java +++ b/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/HashcodeValidationProxyTest.java @@ -19,104 +19,174 @@ import ee.openeid.siva.proxy.document.ProxyHashcodeDataSet; import ee.openeid.siva.proxy.document.ReportType; -import ee.openeid.siva.proxy.exception.ValidatonServiceNotFoundException; import ee.openeid.siva.statistics.StatisticsService; import ee.openeid.siva.validation.document.Datafile; import ee.openeid.siva.validation.document.SignatureFile; import ee.openeid.siva.validation.document.ValidationDocument; +import ee.openeid.siva.validation.document.builder.DummyValidationDocumentBuilder; +import ee.openeid.siva.validation.document.report.DetailedReport; +import ee.openeid.siva.validation.document.report.DiagnosticReport; import ee.openeid.siva.validation.document.report.Error; -import ee.openeid.siva.validation.document.report.*; +import ee.openeid.siva.validation.document.report.Info; +import ee.openeid.siva.validation.document.report.Policy; +import ee.openeid.siva.validation.document.report.Reports; +import ee.openeid.siva.validation.document.report.SignatureValidationData; +import ee.openeid.siva.validation.document.report.SimpleReport; +import ee.openeid.siva.validation.document.report.ValidatedDocument; +import ee.openeid.siva.validation.document.report.ValidationConclusion; import ee.openeid.validation.service.generic.HashcodeGenericValidationService; +import ee.openeid.validation.service.timemark.TimemarkHashcodeValidationService; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; -import org.junit.jupiter.api.extension.ExtendWith; -import org.mockito.BDDMockito; -import org.mockito.Mock; -import org.springframework.beans.factory.NoSuchBeanDefinitionException; import org.springframework.context.ApplicationContext; import org.springframework.core.env.Environment; -import org.springframework.test.context.junit.jupiter.SpringExtension; import java.util.Arrays; import java.util.Collections; import java.util.List; +import static org.junit.jupiter.api.Assertions.assertAll; import static org.junit.jupiter.api.Assertions.assertEquals; import static org.junit.jupiter.api.Assertions.assertFalse; import static org.junit.jupiter.api.Assertions.assertThrows; import static org.junit.jupiter.api.Assertions.assertTrue; -import static org.mockito.Mockito.*; +import static org.mockito.ArgumentMatchers.any; +import static org.mockito.Mockito.mock; +import static org.mockito.Mockito.verifyNoInteractions; +import static org.mockito.Mockito.when; -@ExtendWith(SpringExtension.class) class HashcodeValidationProxyTest { + private final StatisticsService statisticsService = mock(StatisticsService.class); + private final ApplicationContext applicationContext = mock(ApplicationContext.class); + private final Environment environment = mock(Environment.class); + private final HasBdocTimemarkPolicyService hasBdocTimemarkPolicyService = mock(HasBdocTimemarkPolicyService.class); + private final HashcodeValidationMapper hashcodeValidationMapper = mock(HashcodeValidationMapper.class); + private final HashcodeGenericValidationService hashcodeGenericValidationService = mock(HashcodeGenericValidationService.class); + private final TimemarkHashcodeValidationService timemarkHashcodeValidationService = mock(TimemarkHashcodeValidationService.class); private HashcodeValidationProxy hashcodeValidationProxy; - @Mock - private StatisticsService statisticsService; - - @Mock - private ApplicationContext applicationContext; - - @Mock - private Environment environment; - - private ValidationServiceSpy validationServiceSpy; - @BeforeEach - public void setUp() { - hashcodeValidationProxy = new HashcodeValidationProxy(statisticsService, applicationContext, environment); - - validationServiceSpy = new ValidationServiceSpy(); + void setUp() { + hashcodeValidationProxy = new HashcodeValidationProxy( + statisticsService, + applicationContext, + environment, + hasBdocTimemarkPolicyService, + hashcodeValidationMapper, + hashcodeGenericValidationService, + timemarkHashcodeValidationService + ); } @Test - void applicationContextHasNoBeanWithGivenNameThrowsException() { - BDDMockito.given(applicationContext.getBean(anyString())).willThrow(new NoSuchBeanDefinitionException("Bean not loaded")); - ProxyHashcodeDataSet proxyDocument = mockHashCodeDataSet(); + void constructValidatorName_whenInvoked_shouldThrowException() { + assertThrows(IllegalStateException.class, () -> + hashcodeValidationProxy.constructValidatorName(mockHashCodeDataSet()) + ); + } - ValidatonServiceNotFoundException caughtException = assertThrows( - ValidatonServiceNotFoundException.class, () -> { - hashcodeValidationProxy.validate(proxyDocument); - } + @Test + void validate_givenSignatureDoesNotHaveBdocTimemarkPolicy_shouldUseGenericValidation() { + final Reports reports = createDummyReports(); + when(hashcodeValidationMapper.mapToValidationDocuments(any())).thenReturn(List.of(createDummyValidationDocument())); + when(hasBdocTimemarkPolicyService.hasBdocTimemarkPolicy(any())).thenReturn(false); + when(hashcodeGenericValidationService.validateDocument(any())).thenReturn(reports); + when(hashcodeValidationMapper.mergeReportsToOne(any())).thenReturn(reports); + + SimpleReport report = hashcodeValidationProxy.validate(mockHashCodeDataSet()); + + assertAll( + () -> verifyNoInteractions(timemarkHashcodeValidationService), + () -> assertEquals(reports.getSimpleReport(), report) ); - assertEquals("hashcodeGenericValidationService not found", caughtException.getMessage()); - verify(applicationContext).getBean(anyString()); } @Test - void proxyDocumentShouldReturnValidationReport() { - when(applicationContext.getBean("hashcodeGenericValidationService")).thenReturn(validationServiceSpy); + void validate_givenSignatureHasBdocTimemarkPolicy_shouldUseTimemarkValidation() { + final Reports reports = createDummyReports(); + when(hashcodeValidationMapper.mapToValidationDocuments(any())).thenReturn(List.of(createDummyValidationDocument())); + when(hasBdocTimemarkPolicyService.hasBdocTimemarkPolicy(any())).thenReturn(true); + when(timemarkHashcodeValidationService.validateDocument(any())).thenReturn(reports); + when(hashcodeValidationMapper.mergeReportsToOne(any())).thenReturn(reports); + + SimpleReport report = hashcodeValidationProxy.validate(mockHashCodeDataSet()); + + assertAll( + () -> verifyNoInteractions(hashcodeGenericValidationService), + () -> assertEquals(reports.getSimpleReport(), report) + ); + } - ProxyHashcodeDataSet proxyDocument = mockHashCodeDataSet(); - SimpleReport report = hashcodeValidationProxy.validate(proxyDocument); - assertEquals(validationServiceSpy.reports.getSimpleReport(), report); + @Test + void validate_givenSignaturesWithMixedPolicies_shouldUseDifferentValidations() { + final Reports reports = createDummyReports(); + when(hashcodeValidationMapper.mapToValidationDocuments(any())) + .thenReturn(List.of(createDummyValidationDocument(), createDummyValidationDocument())); + when(hasBdocTimemarkPolicyService.hasBdocTimemarkPolicy(any())) + .thenReturn(true) + .thenReturn(false); + when(timemarkHashcodeValidationService.validateDocument(any())).thenReturn(reports); + when(hashcodeGenericValidationService.validateDocument(any())).thenReturn(reports); + when(hashcodeValidationMapper.mergeReportsToOne(any())).thenReturn(reports); + + SimpleReport report = hashcodeValidationProxy.validate(mockHashCodeDataSet()); + + assertEquals(reports.getSimpleReport(), report); } @Test - void hashcodeValidationAlwaysReturnsSimpleReport() { - when(applicationContext.getBean("hashcodeGenericValidationService")).thenReturn(validationServiceSpy); + void validate_whenHashcodeValidationInvokedWithDifferentReportTypes_shouldReturnSimpleReport() { ProxyHashcodeDataSet proxyDocument = mockHashCodeDataSet(); + Reports reports = createDummyReports(); + reports.setDetailedReport(new DetailedReport()); + reports.setDiagnosticReport(new DiagnosticReport()); for (ReportType reportType : ReportType.values()) { proxyDocument.setReportType(reportType); + when(hashcodeValidationMapper.mapToValidationDocuments(any())) + .thenReturn(List.of(createDummyValidationDocument())); + when(hashcodeValidationMapper.mergeReportsToOne(any())).thenReturn(reports); + SimpleReport report = hashcodeValidationProxy.validate(proxyDocument); + assertTrue(report instanceof SimpleReport); assertFalse(report instanceof DetailedReport); assertFalse(report instanceof DiagnosticReport); } } + @Test + void validDataFromSignatureFile() { + final Reports reports = createDummyReports(); + when(hashcodeValidationMapper.mapToValidationDocuments(any())) + .thenReturn(List.of(DummyValidationDocumentBuilder.aValidationDocument() + .withDocument("test-files/signatures.xml") + .withName("signatures.xml") + .build())); + when(hashcodeValidationMapper.mergeReportsToOne(any())).thenReturn(reports); + + SimpleReport report = hashcodeValidationProxy.validate(mockHashCodeDataSet()); + + assertEquals(reports.getSimpleReport(), report); + } + private ProxyHashcodeDataSet mockHashCodeDataSet() { ProxyHashcodeDataSet proxyHashcodeDataSet = new ProxyHashcodeDataSet(); SignatureFile signatureFile = new SignatureFile(); signatureFile.setSignature("hash".getBytes()); signatureFile.setDatafiles(createDatafiles(createDatafile("test", "test-hash-1", "SHA256"))); proxyHashcodeDataSet.setSignatureFiles(Collections.singletonList(signatureFile)); - return proxyHashcodeDataSet; } + private static ValidationDocument createDummyValidationDocument() { + ValidationDocument validationDocument = new ValidationDocument(); + validationDocument.setBytes(new byte[1]); + validationDocument.setDatafiles(List.of(new Datafile())); + return validationDocument; + } + private List createDatafiles(Datafile... datafiles) { return Arrays.asList(datafiles); } @@ -129,67 +199,55 @@ private Datafile createDatafile(String filename, String hash, String hashAlgo) { return datafile; } - private class ValidationServiceSpy extends HashcodeGenericValidationService { - - Reports reports; - - @Override - public Reports validateDocument(ValidationDocument validationDocument) { - reports = createDummyReports(); - return reports; - } - - private Reports createDummyReports() { - ValidationConclusion validationConclusion = new ValidationConclusion(); - validationConclusion.setValidSignaturesCount(0); - validationConclusion.setSignaturesCount(1); - validationConclusion.setValidationTime("ValidationTime"); - validationConclusion.setValidatedDocument(createDummyValidatedDocument()); - validationConclusion.setPolicy(createDummyPolicy()); - validationConclusion.setSignatures(createDummySignatures()); - SimpleReport simpleReport = new SimpleReport(validationConclusion); - return new Reports(simpleReport, null, null); - } - - private ValidatedDocument createDummyValidatedDocument() { - ValidatedDocument validatedDocument = new ValidatedDocument(); - validatedDocument.setFilename("DocumentName"); - return validatedDocument; - } + private static Reports createDummyReports() { + ValidationConclusion validationConclusion = new ValidationConclusion(); + validationConclusion.setValidSignaturesCount(0); + validationConclusion.setSignaturesCount(1); + validationConclusion.setValidationTime("ValidationTime"); + validationConclusion.setValidatedDocument(createDummyValidatedDocument()); + validationConclusion.setPolicy(createDummyPolicy()); + validationConclusion.setSignatures(createDummySignatures()); + SimpleReport simpleReport = new SimpleReport(validationConclusion); + return new Reports(simpleReport, null, null); + } - private List createDummySignatures() { - SignatureValidationData signature = new SignatureValidationData(); - signature.setSignatureLevel("SignatureLevel"); - signature.setClaimedSigningTime("ClaimedSigningTime"); - signature.setInfo(createDummySignatureInfo()); - signature.setSignatureFormat("SingatureFormat"); - signature.setId("id1"); - signature.setSignedBy("Some Name 123456789"); - signature.setIndication(SignatureValidationData.Indication.TOTAL_FAILED); - signature.setWarnings(Collections.emptyList()); - signature.setErrors(createDummyErrors()); - return Collections.singletonList(signature); - } + private static ValidatedDocument createDummyValidatedDocument() { + ValidatedDocument validatedDocument = new ValidatedDocument(); + validatedDocument.setFilename("DocumentName"); + return validatedDocument; + } - private List createDummyErrors() { - Error error = new Error(); - error.setContent("ErrorContent"); - return Collections.singletonList(error); - } + private static List createDummySignatures() { + SignatureValidationData signature = new SignatureValidationData(); + signature.setSignatureLevel("SignatureLevel"); + signature.setClaimedSigningTime("ClaimedSigningTime"); + signature.setInfo(createDummySignatureInfo()); + signature.setSignatureFormat("SingatureFormat"); + signature.setId("id1"); + signature.setSignedBy("Some Name 123456789"); + signature.setIndication(SignatureValidationData.Indication.TOTAL_FAILED); + signature.setWarnings(Collections.emptyList()); + signature.setErrors(createDummyErrors()); + return Collections.singletonList(signature); + } - private Info createDummySignatureInfo() { - Info info = new Info(); - info.setBestSignatureTime("BestSignatureTime"); - return info; - } + private static List createDummyErrors() { + Error error = new Error(); + error.setContent("ErrorContent"); + return Collections.singletonList(error); + } - private Policy createDummyPolicy() { - Policy policy = new Policy(); - policy.setPolicyDescription("PolicyDescription"); - policy.setPolicyName("PolicyName"); - policy.setPolicyUrl("http://policyUrl.com"); - return policy; - } + private static Info createDummySignatureInfo() { + Info info = new Info(); + info.setBestSignatureTime("BestSignatureTime"); + return info; } + private static Policy createDummyPolicy() { + Policy policy = new Policy(); + policy.setPolicyDescription("PolicyDescription"); + policy.setPolicyName("PolicyName"); + policy.setPolicyUrl("http://policyUrl.com"); + return policy; + } } diff --git a/siva-parent/siva-validation-proxy/src/test/resources/test-files/no_timemark_signature.xml b/siva-parent/siva-validation-proxy/src/test/resources/test-files/no_timemark_signature.xml new file mode 100644 index 000000000..7026b10ca --- /dev/null +++ b/siva-parent/siva-validation-proxy/src/test/resources/test-files/no_timemark_signature.xml @@ -0,0 +1,94 @@ + + + + + + + + + LvhnsrgBZBK9kTQ8asbPtcsjuEhBo9s3QDdCcIxlMmo= + + + + + + + GReY0NHU8hDlLnheTqowfcigLZmWArw4t4qY+UCz7FQ= + + + + RUgxq4Fr9sT9j7kH/sDHpYZ+fhaNRiEQ9q0cLmaHg+pefNShDYtxGKhBCGw7r+RBrnVEoxsBtojnHaQYyyYzIIk8jdUgUcsRPc2lCMp4iP22k+Z15ItPOrPRXhvJnV+1RMoZ+F+Y+iheLoChsXGKUAB7hn1IaL7OQsX3fHb8kls= + + + + + MIIFkjCCBHqgAwIBAgIObV8h37aTlaYAAgAJ1/wwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoSXNzdWluZ0NBLUEpMB4XDTE2MTIxMDE1NDgzMFoXDTE4MTIxMDE1NDgzMFowZTELMAkGA1UEBhMCTFQxGjAYBgNVBAMTEVBBVUxJVVMgUE9ET0xTS0lTMRIwEAYDVQQEEwlQT0RPTFNLSVMxEDAOBgNVBCoTB1BBVUxJVVMxFDASBgNVBAUTCzM4NjA1MTcwNTk2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCXzG2E+Sc+pqvohM6Beom1A7DHSxTd7ilLFTl5Go3AX62QEYXLhDRPHmSkcrQKbpmEAbao5OcRr/e/dlrftzxVpRchyoaoUTsqLum3Kmzc9A1Gn5udFvuGOub4bPKYWKYi2bSsjeoZVjej0qfYkbMKD/auAYCD88iF0VwuKHCGJwIDAQABo4ICiTCCAoUwHQYDVR0OBBYEFLP89gCOqo/BzUhpfXPjQf87LFsDMB8GA1UdIwQYMBaAFEpKzujSwdeIfCb7qH6cuwhAYs0+MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jc3AucmNzYy5sdC9jZHAvVkklMjBSZWdpc3RydSUyMENlbnRyYXMlMjBSQ1NDJTIwKElzc3VpbmdDQS1BKSgyKS5jcmwwgZ4GCCsGAQUFBwEBBIGRMIGOMFgGCCsGAQUFBzAChkxodHRwOi8vY3NwLnJjc2MubHQvYWlhL1ZJJTIwUmVnaXN0cnUlMjBDZW50cmFzJTIwUkNTQyUyMChJc3N1aW5nQ0EtQSkoMikuY3J0MDIGCCsGAQUFBzABhiZodHRwOi8vb2NzcC5yY3NjLmx0L29jc3ByZXNwb25kZXIucmNzYzAvBgNVHREEKDAmoCQGCisGAQQBgjcUAgOgFgwUODkzNzAwMTAxMDAwMTUyNDc5NTcwDgYDVR0PAQH/BAQDAgbAMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIKc7HuEpsAKhOWRDoaTmGOHgtFegWGCq/QvgtnIKAIBZAIBBTAfBgNVHSUEGDAWBgorBgEEAYI3CgMMBggrBgEFBQcDBDBFBgNVHSAEPjA8MDoGCysGAQQBgfE3AQIDMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly93d3cucmNzYy5sdC9yZXBvc2l0b3J5MCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDDDAKBggrBgEFBQcDBDAvBggrBgEFBQcBAwQjMCEwCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5GAQQwDQYJKoZIhvcNAQEFBQADggEBAAejGnySZuhSPPRVpWIVPFX+xwW4XqdvX8JehkOAv21H7dfLxvxTaYusisrRWIQiEE2MjIDvFLM3ozo8WQ5Xj2RWIan8whxTTAuzyIU8K+fuHy4JiMvqBa+RGvFP0EGDDnWbxeiDE+LfpotPyB5g3fzCWTWNDEpOh6NCfcKoF3pcjkA1alk82i8QY8w0PpmIKL+W6jJtS7Fhi4wCq7lPLOFOEmSOKsvi0D8gRjZsy9/4SVcdBQ4fUTvXPGgprUM8Za1HRkFWXzNizZK3Z51XkdD7PuCsAOCLMjbsGM8WPqBA6lmL+VzTtbu/B/8rejvOkhe4w3Qacs26bTX1xXYuFwQ= + + + + + + + + 2017-06-28T06:30:41Z + + + + + pgVzkk7l4seSU7raauGJeomBYdKbv7+WhsI5e3N6buk= + + + CN=VI Registru Centras RCSC (IssuingCA-A),OU=Registru Centro Sertifikavimo + Centras,O=VI Registru Centras - I.k. 124110246,C=LT + + 2218319805694862221298688051501052 + + + + + Tallinn + Harjumaa + 12345 + Eesti + + + + Direktorius + + + + + + application/pdf + + + + + + + + + MIAGCSqGSIb3DQEHAqCAMIIIGwIBAzEPMA0GCWCGSAFlAwQCAwUAMIHlBgsqhkiG9w0BCRABBKCB1QSB0jCBzwIBAQYGBACPZwEBMDEwDQYJYIZIAWUDBAIBBQAEIBf8So+lfR/lrfzu5i+SZwguJGakhr/W+eHwrAQJ0acJAghoiq8pjS37GxgPMjAxNzA2MjgwNjMwNTdaMAMCAQECBgFc7WVJOqBnpGUwYzELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRpZml0c2VlcmltaXNrZXNrdXMxDDAKBgNVBAsMA1RTQTEiMCAGA1UEAwwZU0sgVElNRVNUQU1QSU5HIEFVVEhPUklUWaCCBBEwggQNMIIC9aADAgECAhAkr+zrEmjQAlQX94btbwFZMA0GCSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKDBlBUyBTZXJ0aWZpdHNlZXJpbWlza2Vza3VzMSgwJgYDVQQDDB9FRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTQwOTE2MDg0MDM4WhcNMTkwOTE2MDg0MDM4WjBjMQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEMMAoGA1UECwwDVFNBMSIwIAYDVQQDDBlTSyBUSU1FU1RBTVBJTkcgQVVUSE9SSVRZMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAk9r91Ap6ZIoI1LCUxSn1gpBjrNA5+z2+BSdvNNEcJEFF2xptliSfFMjgOpDn4k+rDwxOQO9vqd8NkZ3Xm3ihji0ddegJ9GtsyMn34NX4ztt36+sEjy+LsMEIzn39UCPEEC5n0/tOyDyjwGtWqoH1zR7OVIK0WDxfTHYRPdkG1nj1QBGH9c/Tsjt5GT8O1Ithq7EkM/NdURmZIkIjJtyWjH3e7wXn+jwbJJsPkZgyF984mBea6X9XPt5HR3lLEIy8khGs/tZ+IlhpSMtiovbCMVB7+dSW1wYKfYq2oYLIfu+X5fN595rpeNzx5tOBqfYUnRQfSYe/3yVYAMq5MjZ9dwIDAQABo4GqMIGnMA4GA1UdDwEB/wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDCDAdBgNVHQ4EFgQUsbC99+agaRZsIOVR+1z0MGJzVycwHwYDVR0jBBgwFoAUEvJaPupWHL/NBqzx8SXJqUvUFJkwPQYDVR0fBDYwNDAyoDCgLoYsaHR0cDovL3d3dy5zay5lZS9yZXBvc2l0b3J5L2NybHMvZWVjY3JjYS5jcmwwDQYJKoZIhvcNAQELBQADggEBAKilxT3fbBU8Pp5536wMGG3jO36Qw88Ve/WkhfRGBuLNoq8dZTigelEfzNyCj+Cmi1EuUuFlse273iksU3p6emLIc3B6+SZTK+sFbKU41HViHBvh0tLykEYYVHp5F2EbOgoBQXgHh0ihc6PinbqrXJhQsXlmRkfGFAU2Lm7FqT22AIWUa3Ne6aMvmMGa1Z4NMYThhJrfinMNePPxUCM8n2xW46YrYTSDJbFRMtcX1h6+tbNEvNUWrD6p7AFXYjih//qaJk45PbCUD+Z4vvOveGd+jspIlCYw1SNnqWHpEEhW9gjS34D9+lMqJl++LP9efZ7g8LqLnvCYfkSA45q/RQoxggMGMIIDAgIBATCBiTB1MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEoMCYGA1UEAwwfRUUgQ2VydGlmaWNhdGlvbiBDZW50cmUgUm9vdCBDQTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlAhAkr+zrEmjQAlQX94btbwFZMA0GCWCGSAFlAwQCAwUAoIIBTTAaBgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQAQQwHAYJKoZIhvcNAQkFMQ8XDTE3MDYyODA2MzA1N1owTwYJKoZIhvcNAQkEMUIEQEfZlzGBaoABQONw3UG7tP5mO5PJ/nLrU5yH5RVQfEs1Q28IHv3FoHm6xlrpvNwzBL9jwcoLjfkk4Vu6LJBgfh8wgb8GCyqGSIb3DQEJEAIMMYGvMIGsMIGpMIGmBBSy0CGC8LluKhxofs4yNAgjmBkwtjCBjTB5pHcwdTELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRpZml0c2VlcmltaXNrZXNrdXMxKDAmBgNVBAMMH0VFIENlcnRpZmljYXRpb24gQ2VudHJlIFJvb3QgQ0ExGDAWBgkqhkiG9w0BCQEWCXBraUBzay5lZQIQJK/s6xJo0AJUF/eG7W8BWTANBgkqhkiG9w0BAQEFAASCAQA8vhLy9xlqEwh3qbXNpwKNQxif1UMER8NXTzou4xZc4ZH3MOBV68skEJ+I87KYrGARXvmAl3XO9N0Ocblad2HUemGuMkqJ3z7lJ/cyK1bwF6kFmFYp4xNFCfCx21ct0QUnXBWEbZAtIm9E05B6+v6JA90jNC9GUSoau29YsNnA47hJEPpdFyma2NBm2bK4S9fLeaqthq0DoReY1OoCvY++OYji0bmF4gOn8aa393NSz3XNx0Rwo3ZGgB8xGYtNfRXEpfSDOsboJiM2eM9o/0QcNY8ZnW4EgqEExVyxEBp6GLHRjqKzg6OeMSdjDaCETySEOpSX5mqEVA2UQeWQABqwAAAAAA== + + + + + MIIF0DCCBLigAwIBAgIObV8h37aTlaYAAgAIUqQwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoSXNzdWluZ0NBLUEpMB4XDTE2MDgyNTA1MTAzOFoXDTE4MDgyNTA1MTAzOFowgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgT0NTUCAoSXNzdWluZ0NBLUEpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuCrIb7RJULHdem5pfiPGCqsABmW1paWGbGRveWdaGMwoiiGJO/1JTb0Uzv6+A38JJ3pAN7EG/IdibysT0oyGXVne2af/ytpqA6ewQSoCFcV6UhMztT973J+UeSgaVZHc1dQ0EUwOdQ0uncPqTOidmSxU8bQZzpHaVL+1cwtGcextygI/fMl6dNAsG8Bnd+lPTlI1hEuUkZMiDd5GOhb6O74dwKwuASdrSOA01HHZ09wcxS7BpyLIu5WGjFIVQHetuEKd0HHcCjyUJu1Sxh8nZ718loqavbuU0S7wPYhPk4s0WRB870fBbAK2EMjjR8+wi3FiUFDZygnpnzflWjY3ywIDAQABo4ICCjCCAgYwCwYDVR0PBAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMJMEUGA1UdIAQ+MDwwOgYLKwYBBAGB8TcBAQIwKzApBggrBgEFBQcCARYdaHR0cDovL3d3dy5yY3NjLmx0L3JlcG9zaXRvcnkwHQYDVR0OBBYEFMfRoXt0+B6d3a8QCJrGrlwQ/NljMB8GA1UdIwQYMBaAFEpKzujSwdeIfCb7qH6cuwhAYs0+MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jc3AucmNzYy5sdC9jZHAvVkklMjBSZWdpc3RydSUyMENlbnRyYXMlMjBSQ1NDJTIwKElzc3VpbmdDQS1BKSgyKS5jcmwwgZ4GCCsGAQUFBwEBBIGRMIGOMFgGCCsGAQUFBzAChkxodHRwOi8vY3NwLnJjc2MubHQvYWlhL1ZJJTIwUmVnaXN0cnUlMjBDZW50cmFzJTIwUkNTQyUyMChJc3N1aW5nQ0EtQSkoMikuY3J0MDIGCCsGAQUFBzABhiZodHRwOi8vb2NzcC5yY3NjLmx0L29jc3ByZXNwb25kZXIucmNzYzA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiCnOx7hKbACoTlkQ6Gk5hjh4LRXoFhhbfNDIfw0S4CAWQCAQowGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDCTANBgkqhkiG9w0BAQUFAAOCAQEAkvDEqT3JKr3u0+YcLHbkt9lSsYPSY+bLLIu/tqYsGR911Z7n35Cp5FRA5AnkvKBJooBZvoTIGbEyOOXKt4QZjprJ2YYfQ69VNlDLUhBdGE61MNcfpVyzjAw0F1n6Bv/DyoYjUyx6o4cNAKN92AYddYt0VhqMehAvQFC+rd3wEiZWzp2OS32I8hYlaG5NJvXMYUzEi0rtbBxQiolK9tOqesDvP6ucrKG3jF/gK40sXa09KPsU0ZJzUfpOFuw0ezQo1oS3v/JKnFzTgbqzjvDg27bmij2bLw/lxHRn5hb7O5K1uSsNY8A/H2fJubDex/MkF7kKiWVCL0g2xTQh0FzIkA== + + + MIIF7jCCBNagAwIBAgIOEvrAfT5Zs1YAAwAAABowDQYJKoZIhvcNAQEFBQAwgZoxCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLDAqBgNVBAMTI1ZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoUG9saWN5Q0EpMB4XDTE2MDgyNTA0NDgzMloXDTIwMDgyNTA0NDgzMlowgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoSXNzdWluZ0NBLUEpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyrju/xMZCEHbHFbX4A+75s7SOOZhMxKudvr+H4mLjbKvsxwIeY7bS/XI4YpOHK3rSOj0VjsXV1ayQjbp2YmeEGXxLFvtd1ataco+3S1K6hjldRX4IYbmeQymOEviciw1De1uhd+u7mmxQWp6Jm7+lEdOBKuA5wTG3cx2g2yY50ix6kA/7qjayDZnO/hYI+uOQJmktePbupDZr9wYT1PIo2x2trgIuZsiFsESkxdK5Jdjj3Afeb5aOS4yz0pb6xgErPZIxPOZxviEFx6JYB/rPQfMVnolvGwj+T/7dUXERfTjUz5le8qfu6VmVCA6bH4urmPRX6jeITpVsC+kCeLDoQIDAQABo4ICKzCCAicwDgYDVR0PAQH/BAQDAgEGMC8GCCsGAQUFBwEDBCMwITAIBgYEAI5GAQEwCwYGBACORgEDAgEKMAgGBgQAjkYBBDASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcVAgQWBBT9S1iad8cz3A3gLwWCOHwrTBklAjAdBgNVHQ4EFgQUSkrO6NLB14h8Jvuofpy7CEBizT4wRQYDVR0gBD4wPDA6BgsrBgEEAYHxNwEBATArMCkGCCsGAQUFBwIBFh1odHRwOi8vd3d3LnJjc2MubHQvcmVwb3NpdG9yeTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFMNxxrwDp5f/HZvUXX/jID9JQixxMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jc3AucmNzYy5sdC9jZHAvVkklMjBSZWdpc3RydSUyMENlbnRyYXMlMjBSQ1NDJTIwKFBvbGljeUNBKSgzKS5jcmwwgZsGCCsGAQUFBwEBBIGOMIGLMDIGCCsGAQUFBzABhiZodHRwOi8vb2NzcC5yY3NjLmx0L29jc3ByZXNwb25kZXIucmNzYzBVBggrBgEFBQcwAoZJaHR0cDovL2NzcC5yY3NjLmx0L2FpYS9WSSUyMFJlZ2lzdHJ1JTIwQ2VudHJhcyUyMFJDU0MlMjAoUG9saWN5Q0EpKDMpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAL07ALD5jt5N8EEDI6YkcMAtjBf32qMcx2tPPRIC1ds+kvcMCICiN8cOlGEwwwj5qm6074M9bw1ZD9vvqr/jzwqbXJZMMfcsAAQqrFxBZVgTKYN43fxwjCr5OJR7Se0BpzGWfkxaMrhxuuqydjsHuL+YpyTSUWF/icXOpyOavrUEMH5USO7gcrMsn1U9K9Elj5Pltt24hef7QRvK1JfSSSQg+k1IM8hTQbjX7CIFMLkyVT6s1kKzXOA/PZXIHiaHTzCkdmjB5kcX7nD/PBEJwxNEkreECXokAPFIWzTRHQQcDonZMtXXT/4jyckTBarlNm6V4VelS05GpwB9kt1o2wA== + + + + + + MIIHvQoBAKCCB7YwggeyBgkrBgEFBQcwAQEEggejMIIHnzCBrKIWBBTH0aF7dPgend2vEAiaxq5cEPzZYxgPMjAxNzA2MjgwNjMxMDNaMIGAMH4wRTAHBgUrDgMCGgQUiAZi9n976e6Nv4VK5emy0j/6lLUEFEpKzujSwdeIfCb7qH6cuwhAYs0+Ag5tXyHftpOVpgACAAnX/IAAGA8yMDE3MDYyODA2MzAzM1qhIjAgMB4GCSsGAQUFBzABBgQRGA8yMDE2MDYyODA5MzEwM1owDQYJKoZIhvcNAQEFBQADggEBALO5yJSXpOrcMNTZfifxrBY9p7OZyfhq1DBDGYyphx7ZKEfSqlKM0gwrKYLmbzGaSUWv0Z0fiTGw8k7Ui9NtpYB5VqO0zIYq78z/TYv9H7j3lIrxNIJu9iC8DUI1O3k1W0aQYPNABvmrHepvLBHgDLjjpDS6jRLXVoUvA7qlbEHGlPVJIOkcuk8t22GR7CtEVsnRrYWSSh/i5BNxJ0XDdoPivcPExRxtvLkNQ5pcDxIUFCL5ZQCBUv5xu3QFZUMd2JjGLu7mLAAtTpYccTHIgQyVVbgW1wPcS5LhN1Lt0Fu6c+bDCmjgef1N4uPc/xq/ljIOixryx+G3TpDf/EEIUYigggXYMIIF1DCCBdAwggS4oAMCAQICDm1fId+2k5WmAAIACFKkMA0GCSqGSIb3DQEBBQUAMIGdMQswCQYDVQQGEwJMVDEtMCsGA1UEChMkVkkgUmVnaXN0cnUgQ2VudHJhcyAtIEkuay4gMTI0MTEwMjQ2MS4wLAYDVQQLEyVSZWdpc3RydSBDZW50cm8gU2VydGlmaWthdmltbyBDZW50cmFzMS8wLQYDVQQDEyZWSSBSZWdpc3RydSBDZW50cmFzIFJDU0MgKElzc3VpbmdDQS1BKTAeFw0xNjA4MjUwNTEwMzhaFw0xODA4MjUwNTEwMzhaMIGdMQswCQYDVQQGEwJMVDEtMCsGA1UEChMkVkkgUmVnaXN0cnUgQ2VudHJhcyAtIEkuay4gMTI0MTEwMjQ2MS4wLAYDVQQLEyVSZWdpc3RydSBDZW50cm8gU2VydGlmaWthdmltbyBDZW50cmFzMS8wLQYDVQQDEyZWSSBSZWdpc3RydSBDZW50cmFzIE9DU1AgKElzc3VpbmdDQS1BKTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALgqyG+0SVCx3XpuaX4jxgqrAAZltaWlhmxkb3lnWhjMKIohiTv9SU29FM7+vgN/CSd6QDexBvyHYm8rE9KMhl1Z3tmn/8raagOnsEEqAhXFelITM7U/e9yflHkoGlWR3NXUNBFMDnUNLp3D6kzonZksVPG0Gc6R2lS/tXMLRnHsbcoCP3zJenTQLBvAZ3fpT05SNYRLlJGTIg3eRjoW+ju+HcCsLgEna0jgNNRx2dPcHMUuwaciyLuVhoxSFUB3rbhCndBx3Ao8lCbtUsYfJ2e9fJaKmr27lNEu8D2IT5OLNFkQfO9HwWwCthDI40fPsItxYlBQ2coJ6Z835Vo2N8sCAwEAAaOCAgowggIGMAsGA1UdDwQEAwIGwDATBgNVHSUEDDAKBggrBgEFBQcDCTBFBgNVHSAEPjA8MDoGCysGAQQBgfE3AQECMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly93d3cucmNzYy5sdC9yZXBvc2l0b3J5MB0GA1UdDgQWBBTH0aF7dPgend2vEAiaxq5cEPzZYzAfBgNVHSMEGDAWgBRKSs7o0sHXiHwm+6h+nLsIQGLNPjBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3NwLnJjc2MubHQvY2RwL1ZJJTIwUmVnaXN0cnUlMjBDZW50cmFzJTIwUkNTQyUyMChJc3N1aW5nQ0EtQSkoMikuY3JsMIGeBggrBgEFBQcBAQSBkTCBjjBYBggrBgEFBQcwAoZMaHR0cDovL2NzcC5yY3NjLmx0L2FpYS9WSSUyMFJlZ2lzdHJ1JTIwQ2VudHJhcyUyMFJDU0MlMjAoSXNzdWluZ0NBLUEpKDIpLmNydDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3AucmNzYy5sdC9vY3NwcmVzcG9uZGVyLnJjc2MwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIgpzse4SmwAqE5ZEOhpOYY4eC0V6BYYW3zQyH8NEuAgFkAgEKMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwkwDQYJKoZIhvcNAQEFBQADggEBAJLwxKk9ySq97tPmHCx25LfZUrGD0mPmyyyLv7amLBkfddWe59+QqeRUQOQJ5LygSaKAWb6EyBmxMjjlyreEGY6aydmGH0OvVTZQy1IQXRhOtTDXH6Vcs4wMNBdZ+gb/w8qGI1MseqOHDQCjfdgGHXWLdFYajHoQL0BQvq3d8BImVs6djkt9iPIWJWhuTSb1zGFMxItK7WwcUIqJSvbTqnrA7z+rnKyht4xf4CuNLF2tPSj7FNGSc1H6ThbsNHs0KNaEt7/ySpxc04G6s47w4Nu25oo9my8P5cR0Z+YW+zuStbkrDWPAPx9nybmw3sfzJBe5CollQi9INsU0IdBcyJA= + + + + + + + + + \ No newline at end of file diff --git a/siva-parent/siva-validation-proxy/src/test/resources/test-files/signatures.xml b/siva-parent/siva-validation-proxy/src/test/resources/test-files/signatures.xml new file mode 100644 index 000000000..cd5ebed4b --- /dev/null +++ b/siva-parent/siva-validation-proxy/src/test/resources/test-files/signatures.xml @@ -0,0 +1 @@ +LvhnsrgBZBK9kTQ8asbPtcsjuEhBo9s3QDdCcIxlMmo=GReY0NHU8hDlLnheTqowfcigLZmWArw4t4qY+UCz7FQ=RUgxq4Fr9sT9j7kH/sDHpYZ+fhaNRiEQ9q0cLmaHg+pefNShDYtxGKhBCGw7r+RBrnVEoxsBtojnHaQYyyYzIIk8jdUgUcsRPc2lCMp4iP22k+Z15ItPOrPRXhvJnV+1RMoZ+F+Y+iheLoChsXGKUAB7hn1IaL7OQsX3fHb8kls=MIIFkjCCBHqgAwIBAgIObV8h37aTlaYAAgAJ1/wwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoSXNzdWluZ0NBLUEpMB4XDTE2MTIxMDE1NDgzMFoXDTE4MTIxMDE1NDgzMFowZTELMAkGA1UEBhMCTFQxGjAYBgNVBAMTEVBBVUxJVVMgUE9ET0xTS0lTMRIwEAYDVQQEEwlQT0RPTFNLSVMxEDAOBgNVBCoTB1BBVUxJVVMxFDASBgNVBAUTCzM4NjA1MTcwNTk2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCXzG2E+Sc+pqvohM6Beom1A7DHSxTd7ilLFTl5Go3AX62QEYXLhDRPHmSkcrQKbpmEAbao5OcRr/e/dlrftzxVpRchyoaoUTsqLum3Kmzc9A1Gn5udFvuGOub4bPKYWKYi2bSsjeoZVjej0qfYkbMKD/auAYCD88iF0VwuKHCGJwIDAQABo4ICiTCCAoUwHQYDVR0OBBYEFLP89gCOqo/BzUhpfXPjQf87LFsDMB8GA1UdIwQYMBaAFEpKzujSwdeIfCb7qH6cuwhAYs0+MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jc3AucmNzYy5sdC9jZHAvVkklMjBSZWdpc3RydSUyMENlbnRyYXMlMjBSQ1NDJTIwKElzc3VpbmdDQS1BKSgyKS5jcmwwgZ4GCCsGAQUFBwEBBIGRMIGOMFgGCCsGAQUFBzAChkxodHRwOi8vY3NwLnJjc2MubHQvYWlhL1ZJJTIwUmVnaXN0cnUlMjBDZW50cmFzJTIwUkNTQyUyMChJc3N1aW5nQ0EtQSkoMikuY3J0MDIGCCsGAQUFBzABhiZodHRwOi8vb2NzcC5yY3NjLmx0L29jc3ByZXNwb25kZXIucmNzYzAvBgNVHREEKDAmoCQGCisGAQQBgjcUAgOgFgwUODkzNzAwMTAxMDAwMTUyNDc5NTcwDgYDVR0PAQH/BAQDAgbAMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCIKc7HuEpsAKhOWRDoaTmGOHgtFegWGCq/QvgtnIKAIBZAIBBTAfBgNVHSUEGDAWBgorBgEEAYI3CgMMBggrBgEFBQcDBDBFBgNVHSAEPjA8MDoGCysGAQQBgfE3AQIDMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly93d3cucmNzYy5sdC9yZXBvc2l0b3J5MCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDDDAKBggrBgEFBQcDBDAvBggrBgEFBQcBAwQjMCEwCAYGBACORgEBMAsGBgQAjkYBAwIBCjAIBgYEAI5GAQQwDQYJKoZIhvcNAQEFBQADggEBAAejGnySZuhSPPRVpWIVPFX+xwW4XqdvX8JehkOAv21H7dfLxvxTaYusisrRWIQiEE2MjIDvFLM3ozo8WQ5Xj2RWIan8whxTTAuzyIU8K+fuHy4JiMvqBa+RGvFP0EGDDnWbxeiDE+LfpotPyB5g3fzCWTWNDEpOh6NCfcKoF3pcjkA1alk82i8QY8w0PpmIKL+W6jJtS7Fhi4wCq7lPLOFOEmSOKsvi0D8gRjZsy9/4SVcdBQ4fUTvXPGgprUM8Za1HRkFWXzNizZK3Z51XkdD7PuCsAOCLMjbsGM8WPqBA6lmL+VzTtbu/B/8rejvOkhe4w3Qacs26bTX1xXYuFwQ=2017-06-28T06:30:41ZpgVzkk7l4seSU7raauGJeomBYdKbv7+WhsI5e3N6buk=CN=VI Registru Centras RCSC (IssuingCA-A),OU=Registru Centro Sertifikavimo Centras,O=VI Registru Centras - I.k. 124110246,C=LT2218319805694862221298688051501052VilniusDirektoriusapplication/pdfMIAGCSqGSIb3DQEHAqCAMIIIGwIBAzEPMA0GCWCGSAFlAwQCAwUAMIHlBgsqhkiG9w0BCRABBKCB1QSB0jCBzwIBAQYGBACPZwEBMDEwDQYJYIZIAWUDBAIBBQAEIBf8So+lfR/lrfzu5i+SZwguJGakhr/W+eHwrAQJ0acJAghoiq8pjS37GxgPMjAxNzA2MjgwNjMwNTdaMAMCAQECBgFc7WVJOqBnpGUwYzELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRpZml0c2VlcmltaXNrZXNrdXMxDDAKBgNVBAsMA1RTQTEiMCAGA1UEAwwZU0sgVElNRVNUQU1QSU5HIEFVVEhPUklUWaCCBBEwggQNMIIC9aADAgECAhAkr+zrEmjQAlQX94btbwFZMA0GCSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKDBlBUyBTZXJ0aWZpdHNlZXJpbWlza2Vza3VzMSgwJgYDVQQDDB9FRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTQwOTE2MDg0MDM4WhcNMTkwOTE2MDg0MDM4WjBjMQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEMMAoGA1UECwwDVFNBMSIwIAYDVQQDDBlTSyBUSU1FU1RBTVBJTkcgQVVUSE9SSVRZMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAk9r91Ap6ZIoI1LCUxSn1gpBjrNA5+z2+BSdvNNEcJEFF2xptliSfFMjgOpDn4k+rDwxOQO9vqd8NkZ3Xm3ihji0ddegJ9GtsyMn34NX4ztt36+sEjy+LsMEIzn39UCPEEC5n0/tOyDyjwGtWqoH1zR7OVIK0WDxfTHYRPdkG1nj1QBGH9c/Tsjt5GT8O1Ithq7EkM/NdURmZIkIjJtyWjH3e7wXn+jwbJJsPkZgyF984mBea6X9XPt5HR3lLEIy8khGs/tZ+IlhpSMtiovbCMVB7+dSW1wYKfYq2oYLIfu+X5fN595rpeNzx5tOBqfYUnRQfSYe/3yVYAMq5MjZ9dwIDAQABo4GqMIGnMA4GA1UdDwEB/wQEAwIGwDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDCDAdBgNVHQ4EFgQUsbC99+agaRZsIOVR+1z0MGJzVycwHwYDVR0jBBgwFoAUEvJaPupWHL/NBqzx8SXJqUvUFJkwPQYDVR0fBDYwNDAyoDCgLoYsaHR0cDovL3d3dy5zay5lZS9yZXBvc2l0b3J5L2NybHMvZWVjY3JjYS5jcmwwDQYJKoZIhvcNAQELBQADggEBAKilxT3fbBU8Pp5536wMGG3jO36Qw88Ve/WkhfRGBuLNoq8dZTigelEfzNyCj+Cmi1EuUuFlse273iksU3p6emLIc3B6+SZTK+sFbKU41HViHBvh0tLykEYYVHp5F2EbOgoBQXgHh0ihc6PinbqrXJhQsXlmRkfGFAU2Lm7FqT22AIWUa3Ne6aMvmMGa1Z4NMYThhJrfinMNePPxUCM8n2xW46YrYTSDJbFRMtcX1h6+tbNEvNUWrD6p7AFXYjih//qaJk45PbCUD+Z4vvOveGd+jspIlCYw1SNnqWHpEEhW9gjS34D9+lMqJl++LP9efZ7g8LqLnvCYfkSA45q/RQoxggMGMIIDAgIBATCBiTB1MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEoMCYGA1UEAwwfRUUgQ2VydGlmaWNhdGlvbiBDZW50cmUgUm9vdCBDQTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlAhAkr+zrEmjQAlQX94btbwFZMA0GCWCGSAFlAwQCAwUAoIIBTTAaBgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQAQQwHAYJKoZIhvcNAQkFMQ8XDTE3MDYyODA2MzA1N1owTwYJKoZIhvcNAQkEMUIEQEfZlzGBaoABQONw3UG7tP5mO5PJ/nLrU5yH5RVQfEs1Q28IHv3FoHm6xlrpvNwzBL9jwcoLjfkk4Vu6LJBgfh8wgb8GCyqGSIb3DQEJEAIMMYGvMIGsMIGpMIGmBBSy0CGC8LluKhxofs4yNAgjmBkwtjCBjTB5pHcwdTELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRpZml0c2VlcmltaXNrZXNrdXMxKDAmBgNVBAMMH0VFIENlcnRpZmljYXRpb24gQ2VudHJlIFJvb3QgQ0ExGDAWBgkqhkiG9w0BCQEWCXBraUBzay5lZQIQJK/s6xJo0AJUF/eG7W8BWTANBgkqhkiG9w0BAQEFAASCAQA8vhLy9xlqEwh3qbXNpwKNQxif1UMER8NXTzou4xZc4ZH3MOBV68skEJ+I87KYrGARXvmAl3XO9N0Ocblad2HUemGuMkqJ3z7lJ/cyK1bwF6kFmFYp4xNFCfCx21ct0QUnXBWEbZAtIm9E05B6+v6JA90jNC9GUSoau29YsNnA47hJEPpdFyma2NBm2bK4S9fLeaqthq0DoReY1OoCvY++OYji0bmF4gOn8aa393NSz3XNx0Rwo3ZGgB8xGYtNfRXEpfSDOsboJiM2eM9o/0QcNY8ZnW4EgqEExVyxEBp6GLHRjqKzg6OeMSdjDaCETySEOpSX5mqEVA2UQeWQABqwAAAAAA==MIIF0DCCBLigAwIBAgIObV8h37aTlaYAAgAIUqQwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoSXNzdWluZ0NBLUEpMB4XDTE2MDgyNTA1MTAzOFoXDTE4MDgyNTA1MTAzOFowgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgT0NTUCAoSXNzdWluZ0NBLUEpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuCrIb7RJULHdem5pfiPGCqsABmW1paWGbGRveWdaGMwoiiGJO/1JTb0Uzv6+A38JJ3pAN7EG/IdibysT0oyGXVne2af/ytpqA6ewQSoCFcV6UhMztT973J+UeSgaVZHc1dQ0EUwOdQ0uncPqTOidmSxU8bQZzpHaVL+1cwtGcextygI/fMl6dNAsG8Bnd+lPTlI1hEuUkZMiDd5GOhb6O74dwKwuASdrSOA01HHZ09wcxS7BpyLIu5WGjFIVQHetuEKd0HHcCjyUJu1Sxh8nZ718loqavbuU0S7wPYhPk4s0WRB870fBbAK2EMjjR8+wi3FiUFDZygnpnzflWjY3ywIDAQABo4ICCjCCAgYwCwYDVR0PBAQDAgbAMBMGA1UdJQQMMAoGCCsGAQUFBwMJMEUGA1UdIAQ+MDwwOgYLKwYBBAGB8TcBAQIwKzApBggrBgEFBQcCARYdaHR0cDovL3d3dy5yY3NjLmx0L3JlcG9zaXRvcnkwHQYDVR0OBBYEFMfRoXt0+B6d3a8QCJrGrlwQ/NljMB8GA1UdIwQYMBaAFEpKzujSwdeIfCb7qH6cuwhAYs0+MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jc3AucmNzYy5sdC9jZHAvVkklMjBSZWdpc3RydSUyMENlbnRyYXMlMjBSQ1NDJTIwKElzc3VpbmdDQS1BKSgyKS5jcmwwgZ4GCCsGAQUFBwEBBIGRMIGOMFgGCCsGAQUFBzAChkxodHRwOi8vY3NwLnJjc2MubHQvYWlhL1ZJJTIwUmVnaXN0cnUlMjBDZW50cmFzJTIwUkNTQyUyMChJc3N1aW5nQ0EtQSkoMikuY3J0MDIGCCsGAQUFBzABhiZodHRwOi8vb2NzcC5yY3NjLmx0L29jc3ByZXNwb25kZXIucmNzYzA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiCnOx7hKbACoTlkQ6Gk5hjh4LRXoFhhbfNDIfw0S4CAWQCAQowGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDCTANBgkqhkiG9w0BAQUFAAOCAQEAkvDEqT3JKr3u0+YcLHbkt9lSsYPSY+bLLIu/tqYsGR911Z7n35Cp5FRA5AnkvKBJooBZvoTIGbEyOOXKt4QZjprJ2YYfQ69VNlDLUhBdGE61MNcfpVyzjAw0F1n6Bv/DyoYjUyx6o4cNAKN92AYddYt0VhqMehAvQFC+rd3wEiZWzp2OS32I8hYlaG5NJvXMYUzEi0rtbBxQiolK9tOqesDvP6ucrKG3jF/gK40sXa09KPsU0ZJzUfpOFuw0ezQo1oS3v/JKnFzTgbqzjvDg27bmij2bLw/lxHRn5hb7O5K1uSsNY8A/H2fJubDex/MkF7kKiWVCL0g2xTQh0FzIkA==MIIF7jCCBNagAwIBAgIOEvrAfT5Zs1YAAwAAABowDQYJKoZIhvcNAQEFBQAwgZoxCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLDAqBgNVBAMTI1ZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoUG9saWN5Q0EpMB4XDTE2MDgyNTA0NDgzMloXDTIwMDgyNTA0NDgzMlowgZ0xCzAJBgNVBAYTAkxUMS0wKwYDVQQKEyRWSSBSZWdpc3RydSBDZW50cmFzIC0gSS5rLiAxMjQxMTAyNDYxLjAsBgNVBAsTJVJlZ2lzdHJ1IENlbnRybyBTZXJ0aWZpa2F2aW1vIENlbnRyYXMxLzAtBgNVBAMTJlZJIFJlZ2lzdHJ1IENlbnRyYXMgUkNTQyAoSXNzdWluZ0NBLUEpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyrju/xMZCEHbHFbX4A+75s7SOOZhMxKudvr+H4mLjbKvsxwIeY7bS/XI4YpOHK3rSOj0VjsXV1ayQjbp2YmeEGXxLFvtd1ataco+3S1K6hjldRX4IYbmeQymOEviciw1De1uhd+u7mmxQWp6Jm7+lEdOBKuA5wTG3cx2g2yY50ix6kA/7qjayDZnO/hYI+uOQJmktePbupDZr9wYT1PIo2x2trgIuZsiFsESkxdK5Jdjj3Afeb5aOS4yz0pb6xgErPZIxPOZxviEFx6JYB/rPQfMVnolvGwj+T/7dUXERfTjUz5le8qfu6VmVCA6bH4urmPRX6jeITpVsC+kCeLDoQIDAQABo4ICKzCCAicwDgYDVR0PAQH/BAQDAgEGMC8GCCsGAQUFBwEDBCMwITAIBgYEAI5GAQEwCwYGBACORgEDAgEKMAgGBgQAjkYBBDASBgkrBgEEAYI3FQEEBQIDAgACMCMGCSsGAQQBgjcVAgQWBBT9S1iad8cz3A3gLwWCOHwrTBklAjAdBgNVHQ4EFgQUSkrO6NLB14h8Jvuofpy7CEBizT4wRQYDVR0gBD4wPDA6BgsrBgEEAYHxNwEBATArMCkGCCsGAQUFBwIBFh1odHRwOi8vd3d3LnJjc2MubHQvcmVwb3NpdG9yeTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFMNxxrwDp5f/HZvUXX/jID9JQixxMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jc3AucmNzYy5sdC9jZHAvVkklMjBSZWdpc3RydSUyMENlbnRyYXMlMjBSQ1NDJTIwKFBvbGljeUNBKSgzKS5jcmwwgZsGCCsGAQUFBwEBBIGOMIGLMDIGCCsGAQUFBzABhiZodHRwOi8vb2NzcC5yY3NjLmx0L29jc3ByZXNwb25kZXIucmNzYzBVBggrBgEFBQcwAoZJaHR0cDovL2NzcC5yY3NjLmx0L2FpYS9WSSUyMFJlZ2lzdHJ1JTIwQ2VudHJhcyUyMFJDU0MlMjAoUG9saWN5Q0EpKDMpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAL07ALD5jt5N8EEDI6YkcMAtjBf32qMcx2tPPRIC1ds+kvcMCICiN8cOlGEwwwj5qm6074M9bw1ZD9vvqr/jzwqbXJZMMfcsAAQqrFxBZVgTKYN43fxwjCr5OJR7Se0BpzGWfkxaMrhxuuqydjsHuL+YpyTSUWF/icXOpyOavrUEMH5USO7gcrMsn1U9K9Elj5Pltt24hef7QRvK1JfSSSQg+k1IM8hTQbjX7CIFMLkyVT6s1kKzXOA/PZXIHiaHTzCkdmjB5kcX7nD/PBEJwxNEkreECXokAPFIWzTRHQQcDonZMtXXT/4jyckTBarlNm6V4VelS05GpwB9kt1o2wA==MIIHvQoBAKCCB7YwggeyBgkrBgEFBQcwAQEEggejMIIHnzCBrKIWBBTH0aF7dPgend2vEAiaxq5cEPzZYxgPMjAxNzA2MjgwNjMxMDNaMIGAMH4wRTAHBgUrDgMCGgQUiAZi9n976e6Nv4VK5emy0j/6lLUEFEpKzujSwdeIfCb7qH6cuwhAYs0+Ag5tXyHftpOVpgACAAnX/IAAGA8yMDE3MDYyODA2MzAzM1qhIjAgMB4GCSsGAQUFBzABBgQRGA8yMDE2MDYyODA5MzEwM1owDQYJKoZIhvcNAQEFBQADggEBALO5yJSXpOrcMNTZfifxrBY9p7OZyfhq1DBDGYyphx7ZKEfSqlKM0gwrKYLmbzGaSUWv0Z0fiTGw8k7Ui9NtpYB5VqO0zIYq78z/TYv9H7j3lIrxNIJu9iC8DUI1O3k1W0aQYPNABvmrHepvLBHgDLjjpDS6jRLXVoUvA7qlbEHGlPVJIOkcuk8t22GR7CtEVsnRrYWSSh/i5BNxJ0XDdoPivcPExRxtvLkNQ5pcDxIUFCL5ZQCBUv5xu3QFZUMd2JjGLu7mLAAtTpYccTHIgQyVVbgW1wPcS5LhN1Lt0Fu6c+bDCmjgef1N4uPc/xq/ljIOixryx+G3TpDf/EEIUYigggXYMIIF1DCCBdAwggS4oAMCAQICDm1fId+2k5WmAAIACFKkMA0GCSqGSIb3DQEBBQUAMIGdMQswCQYDVQQGEwJMVDEtMCsGA1UEChMkVkkgUmVnaXN0cnUgQ2VudHJhcyAtIEkuay4gMTI0MTEwMjQ2MS4wLAYDVQQLEyVSZWdpc3RydSBDZW50cm8gU2VydGlmaWthdmltbyBDZW50cmFzMS8wLQYDVQQDEyZWSSBSZWdpc3RydSBDZW50cmFzIFJDU0MgKElzc3VpbmdDQS1BKTAeFw0xNjA4MjUwNTEwMzhaFw0xODA4MjUwNTEwMzhaMIGdMQswCQYDVQQGEwJMVDEtMCsGA1UEChMkVkkgUmVnaXN0cnUgQ2VudHJhcyAtIEkuay4gMTI0MTEwMjQ2MS4wLAYDVQQLEyVSZWdpc3RydSBDZW50cm8gU2VydGlmaWthdmltbyBDZW50cmFzMS8wLQYDVQQDEyZWSSBSZWdpc3RydSBDZW50cmFzIE9DU1AgKElzc3VpbmdDQS1BKTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALgqyG+0SVCx3XpuaX4jxgqrAAZltaWlhmxkb3lnWhjMKIohiTv9SU29FM7+vgN/CSd6QDexBvyHYm8rE9KMhl1Z3tmn/8raagOnsEEqAhXFelITM7U/e9yflHkoGlWR3NXUNBFMDnUNLp3D6kzonZksVPG0Gc6R2lS/tXMLRnHsbcoCP3zJenTQLBvAZ3fpT05SNYRLlJGTIg3eRjoW+ju+HcCsLgEna0jgNNRx2dPcHMUuwaciyLuVhoxSFUB3rbhCndBx3Ao8lCbtUsYfJ2e9fJaKmr27lNEu8D2IT5OLNFkQfO9HwWwCthDI40fPsItxYlBQ2coJ6Z835Vo2N8sCAwEAAaOCAgowggIGMAsGA1UdDwQEAwIGwDATBgNVHSUEDDAKBggrBgEFBQcDCTBFBgNVHSAEPjA8MDoGCysGAQQBgfE3AQECMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly93d3cucmNzYy5sdC9yZXBvc2l0b3J5MB0GA1UdDgQWBBTH0aF7dPgend2vEAiaxq5cEPzZYzAfBgNVHSMEGDAWgBRKSs7o0sHXiHwm+6h+nLsIQGLNPjBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3NwLnJjc2MubHQvY2RwL1ZJJTIwUmVnaXN0cnUlMjBDZW50cmFzJTIwUkNTQyUyMChJc3N1aW5nQ0EtQSkoMikuY3JsMIGeBggrBgEFBQcBAQSBkTCBjjBYBggrBgEFBQcwAoZMaHR0cDovL2NzcC5yY3NjLmx0L2FpYS9WSSUyMFJlZ2lzdHJ1JTIwQ2VudHJhcyUyMFJDU0MlMjAoSXNzdWluZ0NBLUEpKDIpLmNydDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3AucmNzYy5sdC9vY3NwcmVzcG9uZGVyLnJjc2MwPgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIgpzse4SmwAqE5ZEOhpOYY4eC0V6BYYW3zQyH8NEuAgFkAgEKMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwkwDQYJKoZIhvcNAQEFBQADggEBAJLwxKk9ySq97tPmHCx25LfZUrGD0mPmyyyLv7amLBkfddWe59+QqeRUQOQJ5LygSaKAWb6EyBmxMjjlyreEGY6aydmGH0OvVTZQy1IQXRhOtTDXH6Vcs4wMNBdZ+gb/w8qGI1MseqOHDQCjfdgGHXWLdFYajHoQL0BQvq3d8BImVs6djkt9iPIWJWhuTSb1zGFMxItK7WwcUIqJSvbTqnrA7z+rnKyht4xf4CuNLF2tPSj7FNGSc1H6ThbsNHs0KNaEt7/ySpxc04G6s47w4Nu25oo9my8P5cR0Z+YW+zuStbkrDWPAPx9nybmw3sfzJBe5CollQi9INsU0IdBcyJA= \ No newline at end of file diff --git a/siva-parent/siva-validation-proxy/src/test/resources/test-files/timemark_signature.xml b/siva-parent/siva-validation-proxy/src/test/resources/test-files/timemark_signature.xml new file mode 100755 index 000000000..77d5acc28 --- /dev/null +++ b/siva-parent/siva-validation-proxy/src/test/resources/test-files/timemark_signature.xml @@ -0,0 +1,81 @@ + + + + + + + + + RnKZobNWVy8u92sDL4S2j1BUzMT5qTgt6hm90TfAGRo= + + + + + + + 5Bk7RHmH+P8bihr1kdd/4apnRVoJfn3yH55123tipQw= + + + pn8r7FZWhBFKnMaLb810NMmMD8PQlLh2w9SCnhZpntENG4XbKCvK+/8rCsTaBR/hrQMFFIkNHahdRGrhN3k3binLhq/2kwIn6hC5NoqixSc/fwyFjE5mv0reHGWDW2E9 + + + MIID6zCCA02gAwIBAgIQT7j6zk6pmVRcyspLo5SqejAKBggqhkjOPQQDBDBgMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEbMBkGA1UEAwwSVEVTVCBvZiBFU1RFSUQyMDE4MB4XDTE5MDUwMjEwNDUzMVoXDTI5MDUwMjEwNDUzMVowfzELMAkGA1UEBhMCRUUxFjAUBgNVBCoMDUpBQUstS1JJU1RKQU4xEDAOBgNVBAQMB0rDlUVPUkcxKjAoBgNVBAMMIUrDlUVPUkcsSkFBSy1LUklTVEpBTiwzODAwMTA4NTcxODEaMBgGA1UEBRMRUE5PRUUtMzgwMDEwODU3MTgwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAASkwENR8GmCpEs6OshDWDfIiKvGuyNMOD2rjIQW321AnZD3oIsqD0svBMNEJJj9Dlvq/47TYDObIa12KAU5IuOBfJs2lrFdSXZjaM+a5TWT3O2JTM36YDH2GcMe/eisepejggGrMIIBpzAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIGQDBIBgNVHSAEQTA/MDIGCysGAQQBg5EhAQIBMCMwIQYIKwYBBQUHAgEWFWh0dHBzOi8vd3d3LnNrLmVlL0NQUzAJBgcEAIvsQAECMB0GA1UdDgQWBBTVX3s48Spy/Es2TcXgkRvwUn2YcjCBigYIKwYBBQUHAQMEfjB8MAgGBgQAjkYBATAIBgYEAI5GAQQwEwYGBACORgEGMAkGBwQAjkYBBgEwUQYGBACORgEFMEcwRRY/aHR0cHM6Ly9zay5lZS9lbi9yZXBvc2l0b3J5L2NvbmRpdGlvbnMtZm9yLXVzZS1vZi1jZXJ0aWZpY2F0ZXMvEwJFTjAfBgNVHSMEGDAWgBTAhJkpxE6fOwI09pnhClYACCk+ezBzBggrBgEFBQcBAQRnMGUwLAYIKwYBBQUHMAGGIGh0dHA6Ly9haWEuZGVtby5zay5lZS9lc3RlaWQyMDE4MDUGCCsGAQUFBzAChilodHRwOi8vYy5zay5lZS9UZXN0X29mX0VTVEVJRDIwMTguZGVyLmNydDAKBggqhkjOPQQDBAOBiwAwgYcCQgGBr+Jbo1GeqgWdIwgMo7SA29AP38JxNm2HWq2Qb+kIHpusAK574Co1K5D4+Mk7/ITTuXQaET5WphHoN7tdAciTaQJBAn0zBigYyVPYSTO68HM6hmlwTwi/KlJDdXW/2NsMjSqofFFJXpGvpxk2CTqSRCjcavxLPnkasTbNROYSJcmM8Xc= + + + + + + + 2020-05-21T14:07:04Z + + + + + +pli41INDQEEIMW6dPXct4dXJSk8bIQ5Ny1TcNC35eA= + + + CN=TEST of ESTEID2018,2.5.4.97=#0c0e4e545245452d3130373437303133,O=SK ID Solutions AS,C=EE + 105969481236726016406974448130977999482 + + + + + + + urn:oid:1.3.6.1.4.1.10015.1000.3.2.1 + + + + 7pudpH4eXlguSZY2e/pNbKzGsq+fu//woYL1SZFws1A= + + + + https://www.sk.ee/repository/bdoc-spec21.pdf + + + + + + + + application/octet-stream + + + + + + + MIIEijCCA3KgAwIBAgIQaI8x6BnacYdNdNwlYnn/mzANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMyMjQ1WhcNMjQwOTA3MTIyMjQ1WjCBgzELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRpZml0c2VlcmltaXNrZXNrdXMxDTALBgNVBAsMBE9DU1AxJzAlBgNVBAMMHlRFU1Qgb2YgU0sgT0NTUCBSRVNQT05ERVIgMjAxMTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0cw6Cja17BbYbHi6frwccDI4BIQLk/fiCE8L45os0xhPgEGR+EHE8LPCIqofPgf4gwN1vDE6cQNUlK0Od+Ush39i9Z45esnfpGq+2HsDJaFmFr5+uC1MEz5Kn1TazEvKbRjkGnSQ9BertlGer2BlU/kqOk5qA5RtJfhT0psc1ixKdPipv59wnf+nHx1+T+fPWndXVZLoDg4t3w8lIvIE/KhOSMlErvBIHIAKV7yH1hOxyeGLghqzMiAn3UeTEOgoOS9URv0C/T5C3mH+Y/uakMSxjNuz41PneimCzbEJZJRiEaMIj8qPAubcbL8GtY03MWmfNtX6/wh6u6TMfW8S2wIDAQABo4H+MIH7MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMJMB0GA1UdDgQWBBR9/5CuRokEgGiqSzYuZGYAogl8TzCBoAYDVR0gBIGYMIGVMIGSBgorBgEEAc4fAwEBMIGDMFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQAaQBtAGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4AZwAuMCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LnNrLmVlL2FqYXRlbXBlbC8wHwYDVR0jBBgwFoAUtTQKnaUvEMXnIQ6+xLFlRxsDdv4wDQYJKoZIhvcNAQEFBQADggEBAAbaj7kTruTAPHqToye9ZtBdaJ3FZjiKug9/5RjsMwDpOeqFDqCorLd+DBI4tgdu0g4lhaI3aVnKdRBkGV18kqp84uU97JRFWQEf6H8hpJ9k/LzAACkP3tD+0ym+md532mV+nRz1Jj+RPLAUk9xYMV7KPczZN1xnl2wZDJwBbQpcSVH1DjlZv3tFLHBLIYTS6qOK4SxStcgRq7KdRczfW6mfXzTCRWM3G9nmDei5Q3+XTED41j8szRWglzYf6zOv4djkja64WYraQ5zb4x8Xh7qTCk6UupZ7je+0oRfuz0h/3zyRdjcRPkjloSpQp/NG8Rmrcnr874p8d9fdwCrRI7U= + MIIFLDCCBI2gAwIBAgIQImvqKVwtGyZbh+ecdKPc7zAKBggqhkjOPQQDBDBiMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEdMBsGA1UEAwwUVEVTVCBvZiBFRS1Hb3ZDQTIwMTgwHhcNMTgwODMwMTI0ODI4WhcNMzMwODMwMTI0ODI4WjBiMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEdMBsGA1UEAwwUVEVTVCBvZiBFRS1Hb3ZDQTIwMTgwgZswEAYHKoZIzj0CAQYFK4EEACMDgYYABABZN0DFpEKsj3SzsySoR/bcwAUoLc+S2HrvHY0xIDkFFTtUQXfjxXyexNIx+ALe2IYJZLTl0T79C5by4/mO/5H7UgCxZZCRKtdcKqSGYJOVpT0XoA51yX8eBk8aPVrTcwABcBhU6nTNGEoNXfeS7mrZB6Gs3eFxEVdejIEjNObWVFYMbqOCAuAwggLcMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMDQGA1UdJQEB/wQqMCgGCCsGAQUFBwMJBggrBgEFBQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMBMB0GA1UdDgQWBBR/DHDY9OWPAXfux20pKbn0yfxqwDAfBgNVHSMEGDAWgBR/DHDY9OWPAXfux20pKbn0yfxqwDCCAiQGA1UdIASCAhswggIXMAgGBgQAj3oBAjAJBgcEAIvsQAECMDIGCysGAQQBg5EhAQIBMCMwIQYIKwYBBQUHAgEWFWh0dHBzOi8vd3d3LnNrLmVlL0NQUzANBgsrBgEEAYORIQECAjANBgsrBgEEAYORfwECATANBgsrBgEEAYORIQECBTANBgsrBgEEAYORIQECBjANBgsrBgEEAYORIQECBzANBgsrBgEEAYORIQECAzANBgsrBgEEAYORIQECBDANBgsrBgEEAYORIQECCDANBgsrBgEEAYORIQECCTANBgsrBgEEAYORIQECCjANBgsrBgEEAYORIQECCzANBgsrBgEEAYORIQECDDANBgsrBgEEAYORIQECDTANBgsrBgEEAYORIQECDjANBgsrBgEEAYORIQECDzANBgsrBgEEAYORIQECEDANBgsrBgEEAYORIQECETANBgsrBgEEAYORIQECEjANBgsrBgEEAYORIQECEzANBgsrBgEEAYORIQECFDANBgsrBgEEAYORfwECAjANBgsrBgEEAYORfwECAzANBgsrBgEEAYORfwECBDANBgsrBgEEAYORfwECBTANBgsrBgEEAYORfwECBjBVBgorBgEEAYORIQoBMEcwIQYIKwYBBQUHAgEWFWh0dHBzOi8vd3d3LnNrLmVlL0NQUzAiBggrBgEFBQcCAjAWGhRURVNUIG9mIEVFLUdvdkNBMjAxODAYBggrBgEFBQcBAwQMMAowCAYGBACORgEBMAoGCCqGSM49BAMEA4GMADCBiAJCAeTjfRrMt+4ecVYozAfdpTjCikf332XcuRkuJ6fbLqqMm7C3v/d5ebyOqvDG6wWAp8Z0GZA5ONIvS2rm8kJ7HR5tAkIAoFn7n5ZW62dXMmPk+LReR1hUyTpxrxC31QjqvMqM2AbM8luw0f/AaC5qsEdwKrKT+p1xvnjSyIVfcMiu6Q3T2EE= + MIIFfDCCBN2gAwIBAgIQNhjzSfd2UEpbkO14EY4ORTAKBggqhkjOPQQDBDBiMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEdMBsGA1UEAwwUVEVTVCBvZiBFRS1Hb3ZDQTIwMTgwHhcNMTgwOTA2MDkwMzUyWhcNMzMwODMwMTI0ODI4WjBgMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEbMBkGA1UEAwwSVEVTVCBvZiBFU1RFSUQyMDE4MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQBxYug4cEqwmIj+3TVaUlhfxCV9FQgfuglC2/0Ux1Ieqw11mDjNvnGJhkWxaLbWJi7QtthMG5R104l7Np7lBevrBgBDtfgja9e3MLTQkY+cFS+UQxjt9ZihTUJVsR7lowYlaGEiqqsGbEhlwfu27Xsm8b2rhSiTOvNdjTtG57NnwVAX+ijggMyMIIDLjAfBgNVHSMEGDAWgBR/DHDY9OWPAXfux20pKbn0yfxqwDAdBgNVHQ4EFgQUwISZKcROnzsCNPaZ4QpWAAgpPnswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwggHNBgNVHSAEggHEMIIBwDAIBgYEAI96AQIwCQYHBACL7EABAjAyBgsrBgEEAYORIQECATAjMCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5zay5lZS9DUFMwDQYLKwYBBAGDkSEBAgIwDQYLKwYBBAGDkX8BAgEwDQYLKwYBBAGDkSEBAgUwDQYLKwYBBAGDkSEBAgYwDQYLKwYBBAGDkSEBAgcwDQYLKwYBBAGDkSEBAgMwDQYLKwYBBAGDkSEBAgQwDQYLKwYBBAGDkSEBAggwDQYLKwYBBAGDkSEBAgkwDQYLKwYBBAGDkSEBAgowDQYLKwYBBAGDkSEBAgswDQYLKwYBBAGDkSEBAgwwDQYLKwYBBAGDkSEBAg0wDQYLKwYBBAGDkSEBAg4wDQYLKwYBBAGDkSEBAg8wDQYLKwYBBAGDkSEBAhAwDQYLKwYBBAGDkSEBAhEwDQYLKwYBBAGDkSEBAhIwDQYLKwYBBAGDkSEBAhMwDQYLKwYBBAGDkSEBAhQwDQYLKwYBBAGDkX8BAgIwDQYLKwYBBAGDkX8BAgMwDQYLKwYBBAGDkX8BAgQwDQYLKwYBBAGDkX8BAgUwDQYLKwYBBAGDkX8BAgYwKgYDVR0lAQH/BCAwHgYIKwYBBQUHAwkGCCsGAQUFBwMCBggrBgEFBQcDBDB3BggrBgEFBQcBAQRrMGkwLgYIKwYBBQUHMAGGImh0dHA6Ly9haWEuZGVtby5zay5lZS9lZS1nb3ZjYTIwMTgwNwYIKwYBBQUHMAKGK2h0dHA6Ly9jLnNrLmVlL1Rlc3Rfb2ZfRUUtR292Q0EyMDE4LmRlci5jcnQwGAYIKwYBBQUHAQMEDDAKMAgGBgQAjkYBATA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vYy5zay5lZS9UZXN0X29mX0VFLUdvdkNBMjAxOC5jcmwwCgYIKoZIzj0EAwQDgYwAMIGIAkIBIF+LqytyaV4o5wUSm30VysB8LdWtoOrzNq2QhB6tGv4slg5z+CR58e60eRFqNxT7eccA/HgoPWs0B1Z+L067qtUCQgCB8OP0kHx/j1t7htN2CXjpSjGFZw5TTI4s1eGyTbe0UJRBXEkUKfFbZVmzGPFPprwUdSPi8PpO7+xGBYlFHA4z+Q== + + + + + + + + + + + \ No newline at end of file diff --git a/siva-parent/siva-webapp/src/test/java/ee/openeid/siva/webapp/HashcodeValidationControllerTest.java b/siva-parent/siva-webapp/src/test/java/ee/openeid/siva/webapp/HashcodeValidationControllerTest.java index 1918ddf2c..906a60297 100644 --- a/siva-parent/siva-webapp/src/test/java/ee/openeid/siva/webapp/HashcodeValidationControllerTest.java +++ b/siva-parent/siva-webapp/src/test/java/ee/openeid/siva/webapp/HashcodeValidationControllerTest.java @@ -16,6 +16,8 @@ package ee.openeid.siva.webapp; +import ee.openeid.siva.proxy.HasBdocTimemarkPolicyService; +import ee.openeid.siva.proxy.HashcodeValidationMapper; import ee.openeid.siva.proxy.HashcodeValidationProxy; import ee.openeid.siva.proxy.ProxyRequest; import ee.openeid.siva.proxy.document.ProxyHashcodeDataSet; @@ -25,12 +27,11 @@ import ee.openeid.siva.webapp.request.HashcodeValidationRequest; import ee.openeid.siva.webapp.request.SignatureFile; import ee.openeid.siva.webapp.transformer.HashcodeValidationRequestToProxyDocumentTransformer; +import ee.openeid.validation.service.generic.HashcodeGenericValidationService; +import ee.openeid.validation.service.timemark.TimemarkHashcodeValidationService; import org.json.JSONObject; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; -import org.junit.jupiter.api.extension.ExtendWith; -import org.mockito.Mock; -import org.mockito.junit.jupiter.MockitoExtension; import org.springframework.context.ApplicationContext; import org.springframework.core.env.Environment; import org.springframework.http.MediaType; @@ -43,30 +44,37 @@ import static org.junit.jupiter.api.Assertions.assertEquals; import static org.junit.jupiter.api.Assertions.assertFalse; import static org.junit.jupiter.api.Assertions.assertNotNull; +import static org.mockito.Mockito.mock; import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status; import static org.springframework.test.web.servlet.setup.MockMvcBuilders.standaloneSetup; -@ExtendWith(MockitoExtension.class) class HashcodeValidationControllerTest { private HashcodeValidationRequestToProxyDocumentTransformerSpy hashRequestTransformerSpy = new HashcodeValidationRequestToProxyDocumentTransformerSpy(); - @Mock - private StatisticsService statisticsService; - - @Mock - private ApplicationContext applicationContext; - - @Mock - private Environment environment; + private final StatisticsService statisticsService = mock(StatisticsService.class); + private final ApplicationContext applicationContext = mock(ApplicationContext.class); + private final Environment environment = mock(Environment.class); + private final HasBdocTimemarkPolicyService hasBdocTimemarkPolicyService = mock(HasBdocTimemarkPolicyService.class); + private final HashcodeValidationMapper hashcodeValidationMapper = mock(HashcodeValidationMapper.class); + private final HashcodeGenericValidationService hashcodeGenericValidationService = mock(HashcodeGenericValidationService.class); + private final TimemarkHashcodeValidationService timemarkHashcodeValidationService = mock(TimemarkHashcodeValidationService.class); private MockMvc mockMvc; @BeforeEach public void setUp() { ValidationController validationController = new ValidationController(); - HashcodeValidationProxySpy validationProxySpy = new HashcodeValidationProxySpy(statisticsService, applicationContext, environment); + HashcodeValidationProxySpy validationProxySpy = new HashcodeValidationProxySpy( + statisticsService, + applicationContext, + environment, + hasBdocTimemarkPolicyService, + hashcodeValidationMapper, + hashcodeGenericValidationService, + timemarkHashcodeValidationService + ); validationController.setHashRequestTransformer(hashRequestTransformerSpy); validationController.setHashcodeValidationProxy(validationProxySpy); mockMvc = standaloneSetup(validationController).build(); @@ -155,8 +163,22 @@ void hashRequestWithNonBase64EncodedHashReturnsErroneousResponse() throws Except private static class HashcodeValidationProxySpy extends HashcodeValidationProxy { - HashcodeValidationProxySpy(StatisticsService statisticsService, ApplicationContext applicationContext, Environment environment) { - super(statisticsService, applicationContext, environment); + HashcodeValidationProxySpy(StatisticsService statisticsService, + ApplicationContext applicationContext, + Environment environment, + HasBdocTimemarkPolicyService hasBdocTimemarkPolicyService, + HashcodeValidationMapper hashcodeValidationMapper, + HashcodeGenericValidationService hashcodeGenericValidationService, + TimemarkHashcodeValidationService timemarkHashcodeValidationService) { + super( + statisticsService, + applicationContext, + environment, + hasBdocTimemarkPolicyService, + hashcodeValidationMapper, + hashcodeGenericValidationService, + timemarkHashcodeValidationService + ); } @Override diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/HashcodeGenericValidationService.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/HashcodeGenericValidationService.java index 02b84e63c..9e94a09f4 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/HashcodeGenericValidationService.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/HashcodeGenericValidationService.java @@ -18,10 +18,7 @@ import ee.openeid.siva.validation.document.Datafile; import ee.openeid.siva.validation.document.ValidationDocument; -import ee.openeid.siva.validation.document.report.Reports; -import ee.openeid.siva.validation.document.report.ValidationConclusion; import ee.openeid.siva.validation.exception.MalformedSignatureFileException; -import ee.openeid.siva.validation.security.SecureSAXParsers; import eu.europa.esig.dss.enumerations.DigestAlgorithm; import eu.europa.esig.dss.model.DSSDocument; import eu.europa.esig.dss.model.DigestDocument; @@ -30,46 +27,19 @@ import org.springframework.stereotype.Service; import org.springframework.util.CollectionUtils; -import javax.xml.parsers.SAXParser; -import java.io.ByteArrayInputStream; import java.util.List; import java.util.stream.Collectors; @Service public class HashcodeGenericValidationService extends GenericValidationService { - - public Reports validate(List validationDocuments) { - List reports = validationDocuments.stream().map(validationDocument -> validateDocument(validationDocument)).collect(Collectors.toList()); - return mergeReportsToOne(reports); - } - @Override protected SignedDocumentValidator createValidatorFromDocument(final ValidationDocument validationDocument) { - List datafiles = getDataFileInfoIfNeeded(validationDocument); - if(!CollectionUtils.isEmpty(datafiles)){ - validationDocument.setDatafiles(datafiles); - } SignedDocumentValidator validator = super.createValidatorFromDocument(validationDocument); List detachedContents = createDetachedContents(validationDocument.getDatafiles()); validator.setDetachedContents(detachedContents); return validator; } - private List getDataFileInfoIfNeeded(ValidationDocument validationDocument) { - if (!CollectionUtils.isEmpty(validationDocument.getDatafiles())) { - return null; - } else { - try { - SAXParser saxParser = SecureSAXParsers.createParser(); - SignatureXmlHandler handler = new SignatureXmlHandler(); - saxParser.parse(new ByteArrayInputStream(validationDocument.getBytes()), handler); - return handler.getDatafiles(); - } catch (Exception e) { - throw constructMalformedDocumentException(new RuntimeException(e)); - } - } - } - @Override protected RuntimeException constructMalformedDocumentException(Exception cause) { return new MalformedSignatureFileException(cause, "Signature file malformed"); @@ -101,28 +71,4 @@ private DigestDocument createDigestDocument(final Datafile datafile) { return digestDocument; } - - private Reports mergeReportsToOne(List reportsList) { - int signaturesCount = 0; - int validSignaturesCount = 0; - Reports response = null; - for (Reports reports : reportsList) { - ValidationConclusion validationConclusion = reports.getSimpleReport().getValidationConclusion(); - if (signaturesCount == 0) { - response = reports; - validSignaturesCount = validationConclusion.getValidSignaturesCount(); - } else { - response.getSimpleReport().getValidationConclusion().getSignatures().addAll(validationConclusion.getSignatures()); - validSignaturesCount = validSignaturesCount + validationConclusion.getValidSignaturesCount(); - } - signaturesCount = signaturesCount + validationConclusion.getSignaturesCount(); - } - if (response != null) { - ValidationConclusion validationConclusion = response.getSimpleReport().getValidationConclusion(); - validationConclusion.setSignaturesCount(signaturesCount); - validationConclusion.setValidSignaturesCount(validSignaturesCount); - } - return response; - } - } diff --git a/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java b/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java index cc4d33fac..7b0c1a14f 100644 --- a/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java +++ b/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java @@ -49,7 +49,6 @@ import java.security.cert.Certificate; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; -import java.util.ArrayList; import java.util.Collections; import java.util.List; @@ -60,8 +59,6 @@ @SpringBootTest(classes = {PDFValidationServiceTest.TestConfiguration.class}) @ExtendWith(SpringExtension.class) class HashcodeGenericValidationServiceTest { - - private HashcodeGenericValidationService validationService; private ConstraintLoadingSignaturePolicyService signaturePolicyService; @Autowired @@ -77,13 +74,12 @@ class HashcodeGenericValidationServiceTest { @BeforeEach public void setUp() { + signaturePolicyService = new ConstraintLoadingSignaturePolicyService(policySettings); + validationService = new HashcodeGenericValidationService(); validationService.setTrustedListsCertificateSource(trustedListsCertificateSource); - - signaturePolicyService = new ConstraintLoadingSignaturePolicyService(policySettings); validationService.setSignaturePolicyService(signaturePolicyService); validationService.setReportConfigurationProperties(new ReportConfigurationProperties(true)); - validationService.setContainerValidatorFactory(containerValidatorFactory); validationService.setRevocationFreshnessValidatorFactory(revocationFreshnessValidatorFactory); validationService.setOcspSourceFactory(ocspSourceFactory); @@ -91,7 +87,7 @@ public void setUp() { @Test void validHashcodeRequest() throws Exception { - Reports response = validationService.validate(getValidationDocumentSingletonList()); + Reports response = validationService.validateDocument(getValidationDocument()); SignatureScope signatureScope = response.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureScopes().get(0); assertEquals("LvhnsrgBZBK9kTQ8asbPtcsjuEhBo9s3QDdCcIxlMmo=", signatureScope.getHash()); assertEquals("SHA256", signatureScope.getHashAlgo()); @@ -100,30 +96,9 @@ void validHashcodeRequest() throws Exception { assertEquals(1L, response.getSimpleReport().getValidationConclusion().getSignatures().size()); } - @Test - void validMultipleSignatures() throws Exception { - List validationDocuments = getValidationDocumentSingletonList(); - validationDocuments.addAll(getValidationDocumentSingletonList()); - Reports response = validationService.validate(validationDocuments); - assertEquals((Integer) 2, response.getSimpleReport().getValidationConclusion().getValidSignaturesCount()); - assertEquals((Integer) 2, response.getSimpleReport().getValidationConclusion().getSignaturesCount()); - assertEquals(2L, response.getSimpleReport().getValidationConclusion().getSignatures().size()); - } - - @Test - void validDataFromSignatureFile() throws Exception { - List validationDocuments = getValidationDocumentSingletonList(); - validationDocuments.get(0).setDatafiles(null); - Reports response = validationService.validate(validationDocuments); - SignatureScope signatureScope = response.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureScopes().get(0); - assertEquals("LvhnsrgBZBK9kTQ8asbPtcsjuEhBo9s3QDdCcIxlMmo=", signatureScope.getHash()); - assertEquals("SHA256", signatureScope.getHashAlgo()); - assertEquals("test.pdf", signatureScope.getName()); - } - @Test void hashcodeValidationCertificateCorrectlyPresent() throws Exception { - Reports response = validationService.validate(getValidationDocumentSingletonList()); + Reports response = validationService.validateDocument(getValidationDocument()); SignatureValidationData signatureValidationData = response.getSimpleReport().getValidationConclusion().getSignatures().get(0); CertificateFactory cf = CertificateFactory.getInstance("X.509"); @@ -149,7 +124,7 @@ void hashcodeValidationCertificateCorrectlyPresent() throws Exception { @Test void hashcodeValidationSubjectDNCorrectlyPresent() throws Exception { - Reports reports = validationService.validate(getValidationDocumentSingletonList()); + Reports reports = validationService.validateDocument(getValidationDocument()); assertSame(1, reports.getSimpleReport().getValidationConclusion().getSignatures().size()); SignatureValidationData signature = reports.getSimpleReport().getValidationConclusion().getSignatures().get(0); @@ -160,7 +135,7 @@ void hashcodeValidationSubjectDNCorrectlyPresent() throws Exception { @Test void populatesSignerRole() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList()); + Reports reports = validationService.validateDocument(getValidationDocument()); List signerRole = reports.getSimpleReport().getValidationConclusion().getSignatures().get(0).getInfo().getSignerRole(); assertEquals(1, signerRole.size()); assertEquals("Direktorius", signerRole.get(0).getClaimedRole()); @@ -168,7 +143,7 @@ void populatesSignerRole() throws IOException, URISyntaxException { @Test void populatesSignatureProductionPlace() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList("test-files/signatures_with_sig_production_place.xml")); + Reports reports = validationService.validateDocument(getValidationDocument("test-files/signatures_with_sig_production_place.xml")); SignatureProductionPlace signatureProductionPlace = reports.getSimpleReport().getValidationConclusion() .getSignatures().get(0).getInfo().getSignatureProductionPlace(); @@ -180,31 +155,29 @@ void populatesSignatureProductionPlace() throws IOException, URISyntaxException @Test void populatesSignatureMethod() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList("test-files/signatures_with_sig_production_place.xml")); + Reports reports = validationService.validateDocument(getValidationDocument("test-files/signatures_with_sig_production_place.xml")); assertEquals("http://www.w3.org/2001/04/xmldsig-more#rsa-sha256", reports.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureMethod()); } @Test void populatesTimeAssertionMessageImprint() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList()); + Reports reports = validationService.validateDocument(getValidationDocument()); assertEquals("MDEwDQYJYIZIAWUDBAIBBQAEIBf8So+lfR/lrfzu5i+SZwguJGakhr/W+eHwrAQJ0acJ", reports.getSimpleReport().getValidationConclusion().getSignatures().get(0).getInfo().getTimeAssertionMessageImprint()); } - private List getValidationDocumentSingletonList() throws URISyntaxException, IOException { - return getValidationDocumentSingletonList("test-files/signatures.xml"); + private ValidationDocument getValidationDocument() throws URISyntaxException, IOException { + return getValidationDocument("test-files/signatures.xml"); } - private List getValidationDocumentSingletonList(String signatureTestFile) throws URISyntaxException, IOException { - List validationDocuments = new ArrayList<>(); + private ValidationDocument getValidationDocument(String signatureTestFile) throws URISyntaxException, IOException { ValidationDocument validationDocument = new ValidationDocument(); validationDocument.setDatafiles(Collections.singletonList(getDataFile())); Path documentPath = Paths.get(getClass().getClassLoader().getResource(signatureTestFile).toURI()); validationDocument.setBytes(Files.readAllBytes(documentPath)); validationDocument.setSignaturePolicy("POLv3"); - validationDocuments.add(validationDocument); - return validationDocuments; + return validationDocument; } private Datafile getDataFile() { diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/TimemarkHashcodeValidationService.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/TimemarkHashcodeValidationService.java new file mode 100644 index 000000000..b8745fed9 --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/TimemarkHashcodeValidationService.java @@ -0,0 +1,71 @@ +package ee.openeid.validation.service.timemark; + +import ee.openeid.siva.validation.configuration.ReportConfigurationProperties; +import ee.openeid.siva.validation.document.Datafile; +import ee.openeid.siva.validation.document.ValidationDocument; +import ee.openeid.siva.validation.document.report.Reports; +import ee.openeid.siva.validation.service.ValidationService; +import ee.openeid.validation.service.timemark.report.TimemarkHashcodeValidationReportBuilder; +import ee.openeid.validation.service.timemark.signature.policy.BDOCConfigurationService; +import ee.openeid.validation.service.timemark.signature.policy.PolicyConfigurationWrapper; +import eu.europa.esig.dss.enumerations.MimeType; +import lombok.SneakyThrows; +import org.digidoc4j.Configuration; +import org.digidoc4j.DetachedXadesSignatureBuilder; +import org.digidoc4j.DigestAlgorithm; +import org.digidoc4j.DigestDataFile; +import org.digidoc4j.Signature; +import org.digidoc4j.ValidationResult; +import org.springframework.beans.factory.annotation.Autowired; +import org.springframework.stereotype.Service; + +import java.util.Base64; + +@Service +public class TimemarkHashcodeValidationService implements ValidationService { + private final BDOCConfigurationService bdocConfigurationService; + private final ReportConfigurationProperties reportConfigurationProperties; + + @Autowired + public TimemarkHashcodeValidationService(BDOCConfigurationService bdocConfigurationService, + ReportConfigurationProperties reportConfigurationProperties) { + this.bdocConfigurationService = bdocConfigurationService; + this.reportConfigurationProperties = reportConfigurationProperties; + } + + @Override + public Reports validateDocument(ValidationDocument validationDocument) { + final PolicyConfigurationWrapper configuration = loadConfiguration(validationDocument); + final Signature signature = createSignature(validationDocument, configuration.getConfiguration()); + final ValidationResult validationResult = signature.validateSignature(); + return new TimemarkHashcodeValidationReportBuilder( + validationResult, + configuration.getPolicy(), + signature, + validationDocument, + reportConfigurationProperties.isReportSignatureEnabled() + ).build(); + } + + private Signature createSignature(ValidationDocument validationDocument, Configuration configuration) { + final DetachedXadesSignatureBuilder signatureBuilder = DetachedXadesSignatureBuilder.withConfiguration(configuration); + addDataFiles(signatureBuilder, validationDocument); + return signatureBuilder.openAdESSignature(validationDocument.getBytes()); + } + + private PolicyConfigurationWrapper loadConfiguration(ValidationDocument validationDocument) { + return bdocConfigurationService.loadPolicyConfiguration(validationDocument.getSignaturePolicy()); + } + + @SneakyThrows + private void addDataFiles(DetachedXadesSignatureBuilder signatureBuilder, ValidationDocument validationDocument) { + for (final Datafile dataFile : validationDocument.getDatafiles()) { + signatureBuilder.withDataFile(new DigestDataFile( + dataFile.getFilename(), + DigestAlgorithm.valueOf(dataFile.getHashAlgo().toUpperCase()), + Base64.getDecoder().decode(dataFile.getHash()), + MimeType.fromFileName(dataFile.getFilename()).getMimeTypeString() + )); + } + } +} diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java index 07959a2f1..296da244f 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java @@ -23,27 +23,24 @@ import ee.openeid.siva.validation.document.report.SignatureValidationData; import ee.openeid.siva.validation.document.report.ValidationConclusion; import ee.openeid.siva.validation.document.report.ValidationWarning; -import ee.openeid.siva.validation.document.report.Warning; import ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils; import ee.openeid.siva.validation.service.signature.policy.properties.ValidationPolicy; import eu.europa.esig.dss.enumerations.SignatureQualification; import eu.europa.esig.dss.enumerations.SubIndication; import org.digidoc4j.Container; -import org.digidoc4j.DataFile; import org.digidoc4j.Signature; import org.digidoc4j.SignatureProfile; import org.digidoc4j.ValidationResult; +import org.digidoc4j.impl.asic.AsicSignature; import org.digidoc4j.impl.asic.asice.AsicESignature; -import java.io.UnsupportedEncodingException; -import java.net.URLDecoder; import java.security.cert.X509Certificate; import java.util.Collections; import java.util.List; import java.util.Map; -import java.util.stream.Collectors; -import static org.digidoc4j.X509Cert.SubjectName.CN; +import static ee.openeid.validation.service.timemark.util.SignatureScopeParser.getAsicSignatureScopes; +import static ee.openeid.validation.service.timemark.util.SignatureCertificateParser.getCertificate; public class AsicContainerValidationReportBuilder extends TimemarkContainerValidationReportBuilder { public AsicContainerValidationReportBuilder(Container container, ValidationDocument validationDocument, ValidationPolicy validationPolicy, ValidationResult validationResult, boolean isReportSignatureEnabled) { @@ -77,7 +74,6 @@ protected String getSubIndication(Signature signature, Map getExtraValidationWarnings() { @Override List getSignatureScopes(Signature signature, List dataFilenames) { - AsicESignature bDocSignature = (AsicESignature) signature; - return bDocSignature.getOrigin().getReferences() - .stream() - .map(r -> decodeUriIfPossible(r.getURI())) - .filter(dataFilenames::contains) //filters out Signed Properties - .map(AsicContainerValidationReportBuilder::createFullSignatureScopeForDataFile) - .collect(Collectors.toList()); + return getAsicSignatureScopes((AsicSignature) signature, dataFilenames); } @Override @@ -120,22 +110,4 @@ String getSignatureForm() { String getSignatureFormat(SignatureProfile profile) { return XADES_FORMAT_PREFIX + profile.toString(); } - - private static SignatureScope createFullSignatureScopeForDataFile(String filename) { - SignatureScope signatureScope = new SignatureScope(); - signatureScope.setName(filename); - signatureScope.setScope(FULL_SIGNATURE_SCOPE); - signatureScope.setContent(FULL_DOCUMENT); - return signatureScope; - } - - private String decodeUriIfPossible(String uri) { - try { - return URLDecoder.decode(uri, "UTF-8"); - } catch (UnsupportedEncodingException e) { - LOGGER.warn("datafile " + uri + " has unsupported encoding", e); - return uri; - } - } - } diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java index 4654a2ddc..714454188 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java @@ -21,8 +21,8 @@ import ee.openeid.siva.validation.document.report.SignatureValidationData; import ee.openeid.siva.validation.document.report.ValidationConclusion; import ee.openeid.siva.validation.document.report.ValidationWarning; -import ee.openeid.siva.validation.document.report.Warning; import ee.openeid.siva.validation.service.signature.policy.properties.ValidationPolicy; +import ee.openeid.validation.service.timemark.util.SignatureScopeParser; import org.apache.commons.lang3.StringUtils; import org.digidoc4j.Container; import org.digidoc4j.DigestDataFile; @@ -35,7 +35,6 @@ import java.util.Collections; import java.util.List; import java.util.Map; -import java.util.stream.Collectors; public class DDOCContainerValidationReportBuilder extends TimemarkContainerValidationReportBuilder { @@ -79,10 +78,9 @@ List getExtraValidationWarnings() { @Override List getSignatureScopes(Signature signature, List dataFilenames) { - return dataFilenames - .stream() - .map(this::mapDataFile) - .collect(Collectors.toList()); + return dataFilenames.stream() + .map(SignatureScopeParser::createFullSignatureScopeForDataFile) + .toList(); } @Override @@ -96,14 +94,6 @@ String getSignatureFormat(SignatureProfile profile) { return dDocFacade.getFormat().replaceAll("-", "_") + "_" + dDocFacade.getVersion(); } - private SignatureScope mapDataFile(String filename) { - SignatureScope signatureScope = new SignatureScope(); - signatureScope.setName(filename); - signatureScope.setContent(FULL_DOCUMENT); - signatureScope.setScope(FULL_SIGNATURE_SCOPE); - return signatureScope; - } - private String getDigidocXmlSignatureForm() { return DDOC_SIGNATURE_FORM_PREFIX + ((DDocContainer) container).getDDoc4JFacade().getVersion() + getSignatureFormSuffix(); } diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java index df3c5ae76..14bf51c3e 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java @@ -17,17 +17,21 @@ package ee.openeid.validation.service.timemark.report; import ee.openeid.siva.validation.document.ValidationDocument; +import ee.openeid.siva.validation.document.report.Certificate; +import ee.openeid.siva.validation.document.report.DetailedReport; +import ee.openeid.siva.validation.document.report.DiagnosticReport; import ee.openeid.siva.validation.document.report.Error; -import ee.openeid.siva.validation.document.report.*; +import ee.openeid.siva.validation.document.report.Reports; +import ee.openeid.siva.validation.document.report.SignatureScope; +import ee.openeid.siva.validation.document.report.SignatureValidationData; +import ee.openeid.siva.validation.document.report.SimpleReport; +import ee.openeid.siva.validation.document.report.ValidationConclusion; +import ee.openeid.siva.validation.document.report.ValidationWarning; +import ee.openeid.siva.validation.document.report.Warning; import ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils; import ee.openeid.siva.validation.service.signature.policy.properties.ValidationPolicy; -import ee.openeid.siva.validation.util.CertUtil; -import ee.openeid.siva.validation.util.DistinguishedNameUtil; -import eu.europa.esig.dss.diagnostic.DiagnosticData; -import eu.europa.esig.dss.diagnostic.SignatureWrapper; -import eu.europa.esig.dss.diagnostic.TimestampWrapper; -import eu.europa.esig.dss.enumerations.TimestampType; -import org.apache.commons.codec.binary.Base64; +import ee.openeid.validation.service.timemark.util.SignatureCertificateParser; +import ee.openeid.validation.service.timemark.util.ValidationErrorMapper; import org.apache.commons.lang3.StringUtils; import org.digidoc4j.Container; import org.digidoc4j.DataFile; @@ -35,33 +39,25 @@ import org.digidoc4j.SignatureProfile; import org.digidoc4j.ValidationResult; import org.digidoc4j.X509Cert; -import org.digidoc4j.exceptions.CertificateNotFoundException; -import org.digidoc4j.exceptions.DigiDoc4JException; import org.digidoc4j.impl.asic.asice.AsicESignature; import org.slf4j.LoggerFactory; -import java.security.cert.X509Certificate; -import java.util.ArrayList; -import java.util.Collection; -import java.util.Collections; -import java.util.Comparator; -import java.util.Date; import java.util.HashMap; import java.util.List; import java.util.Map; -import java.util.Optional; import java.util.stream.Collectors; import java.util.stream.Stream; -import static ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils.*; -import static org.digidoc4j.X509Cert.SubjectName.CN; +import static ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils.createReportPolicy; +import static ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils.getValidationTime; +import static ee.openeid.validation.service.timemark.util.SignatureInfoParser.getInfo; +import static ee.openeid.validation.service.timemark.util.SigningCertificateParser.parseSignedBy; +import static ee.openeid.validation.service.timemark.util.SigningCertificateParser.parseSubjectDistinguishedName; public abstract class TimemarkContainerValidationReportBuilder { protected static final org.slf4j.Logger LOGGER = LoggerFactory.getLogger(TimemarkContainerValidationReportBuilder.class); - protected static final String FULL_SIGNATURE_SCOPE = "FullSignatureScope"; - protected static final String FULL_DOCUMENT = "Digest of the document content"; protected static final String XADES_FORMAT_PREFIX = "XAdES_BASELINE_"; protected static final String REPORT_INDICATION_INDETERMINATE = "INDETERMINATE"; protected static final String BDOC_SIGNATURE_FORM = "ASiC-E"; @@ -86,24 +82,6 @@ protected TimemarkContainerValidationReportBuilder(Container container, Validati this.isReportSignatureEnabled = isReportSignatureEnabled; } - static Warning createWarning(String content) { - Warning warning = new Warning(); - warning.setContent(emptyWhenNull(content)); - return warning; - } - - private static Warning mapDigidoc4JWarning(DigiDoc4JException digiDoc4JException) { - Warning warning = new Warning(); - warning.setContent(emptyWhenNull(digiDoc4JException.getMessage())); - return warning; - } - - private static Error mapDigidoc4JException(DigiDoc4JException digiDoc4JException) { - Error error = new Error(); - error.setContent(emptyWhenNull(digiDoc4JException.getMessage())); - return error; - } - public Reports build() { ValidationConclusion validationConclusion = getValidationConclusion(); processSignatureIndications(validationConclusion, validationPolicy.getName()); @@ -188,147 +166,24 @@ private SignatureValidationData createSignatureValidationData(Signature signatur return signatureValidationData; } - private String parseSignedBy(X509Cert signingCertificate) { - return Optional.ofNullable(signingCertificate) - .flatMap(certificate -> Optional - .ofNullable(certificate.getX509Certificate()) - .map(DistinguishedNameUtil::getSubjectSurnameAndGivenNameAndSerialNumber) - .or(() -> Optional - .ofNullable(certificate.getSubjectName(CN)) - .map(this::removeQuotes)) - ) - .orElseGet(ReportBuilderUtils::valueNotPresent); - } - - private SubjectDistinguishedName parseSubjectDistinguishedName(X509Cert signingCertificate) { - String serialNumber = signingCertificate.getSubjectName(X509Cert.SubjectName.SERIALNUMBER); - String commonName = signingCertificate.getSubjectName(CN); - String givenName = signingCertificate.getSubjectName(X509Cert.SubjectName.GIVENNAME); - String surname = signingCertificate.getSubjectName(X509Cert.SubjectName.SURNAME); - return SubjectDistinguishedName.builder() - .serialNumber(serialNumber != null ? removeQuotes(serialNumber) : null) - .commonName(commonName != null ? removeQuotes(commonName) : null) - .givenName(givenName != null ? removeQuotes(givenName) : null) - .surname(surname != null ? removeQuotes(surname) : null) - .build(); - } - - String removeQuotes(String subjectName) { - return subjectName.replaceAll("(^\")|(\"$)", ""); - } - eu.europa.esig.dss.simplereport.SimpleReport getDssSimpleReport(AsicESignature bDocSignature) { return bDocSignature.getDssValidationReport().getReports().getSimpleReport(); } - private Info getInfo(Signature signature) { - Info info = new Info(); - info.setBestSignatureTime(getBestSignatureTime(signature)); - if (signature.getProfile() == SignatureProfile.LT) { - info.setTimestampCreationTime(getTimestampTime(signature)); - } - info.setOcspResponseCreationTime(getOcspTime(signature)); - info.setTimeAssertionMessageImprint(getTimeAssertionMessageImprint(signature)); - info.setSignerRole(getSignerRole(signature)); - info.setSignatureProductionPlace(getSignatureProductionPlace(signature)); - return info; - } - - private String getOcspTime(Signature signature) { - return formatTime(signature.getOCSPResponseCreationTime()); - } - - private String getTimestampTime(Signature signature) { - return formatTime(signature.getTimeStampCreationTime()); - } - - private String getBestSignatureTime(Signature signature) { - return formatTime(signature.getTrustedSigningTime()); - } - - private String formatTime(Date date) { - return date != null - ? ReportBuilderUtils.getDateFormatterWithGMTZone().format(date) - : null; - } - - private String getTimeAssertionMessageImprint(Signature signature) { - if (signature.getProfile() != SignatureProfile.LT_TM) { - TimestampWrapper timestamp = getBestTimestampWrapper(signature); - try { - return ReportBuilderUtils.parseTimeAssertionMessageImprint(timestamp); - } catch (Exception e) { - LOGGER.warn("Unable to parse time assertion message imprint from timestamp: ", e); - return ""; //parse errors due to corrupted timestamp data should be present in validation errors already - } - } - - try { - return StringUtils.defaultString(Base64.encodeBase64String(signature.getOCSPNonce())); - } catch (DigiDoc4JException e) { - LOGGER.warn("Unable to parse time assertion message imprint from OCSP nonce: ", e); - return ""; //parse errors due to corrupted OCSP data should be present in validation errors already - } - } - - private TimestampWrapper getBestTimestampWrapper(Signature signature) { - DiagnosticData diagnosticData = ((AsicESignature) signature).getDssValidationReport().getReports().getDiagnosticData(); - SignatureWrapper signatureWrapper = diagnosticData.getSignatureById(signature.getUniqueId()); - List timestamps = signatureWrapper.getTimestampListByType(TimestampType.SIGNATURE_TIMESTAMP); - return timestamps.isEmpty() ? null : Collections.min(timestamps, Comparator.comparing(TimestampWrapper::getProductionTime)); - - } - - private List getSignerRole(Signature signature) { - return signature.getSignerRoles().stream() - .filter(StringUtils::isNotEmpty) - .map(this::mapSignerRole) - .collect(Collectors.toList()); - } - - private SignerRole mapSignerRole(String claimedRole) { - SignerRole signerRole = new SignerRole(); - signerRole.setClaimedRole(claimedRole); - return signerRole; - } - - private SignatureProductionPlace getSignatureProductionPlace(Signature signature) { - if (isSignatureProductionPlaceEmpty(signature)) { - return null; - } - - SignatureProductionPlace signatureProductionPlace = new SignatureProductionPlace(); - signatureProductionPlace.setCountryName(StringUtils.defaultString(signature.getCountryName())); - signatureProductionPlace.setStateOrProvince(StringUtils.defaultString(signature.getStateOrProvince())); - signatureProductionPlace.setCity(StringUtils.defaultString(signature.getCity())); - signatureProductionPlace.setPostalCode(StringUtils.defaultString(signature.getPostalCode())); - return signatureProductionPlace; - } - - private boolean isSignatureProductionPlaceEmpty(Signature signature) { - return StringUtils.isAllEmpty( - signature.getCountryName(), - signature.getStateOrProvince(), - signature.getCity(), - signature.getPostalCode()); - } - private List getWarnings(Signature signature) { ValidationResult signatureValidationResult = signatureValidationResults.get(signature.getUniqueId()); - return Stream.of(signatureValidationResult.getWarnings(), this.validationResult.getWarnings()) - .flatMap(Collection::stream) - .distinct() - .map(TimemarkContainerValidationReportBuilder::mapDigidoc4JWarning) - .collect(Collectors.toList()); + return ValidationErrorMapper.getWarnings(Stream.of( + signatureValidationResult.getWarnings(), + this.validationResult.getWarnings() + )); } private List getErrors(Signature signature) { ValidationResult signatureValidationResult = signatureValidationResults.get(signature.getUniqueId()); - return Stream.of(signatureValidationResult.getErrors(), this.validationResult.getErrors()) - .flatMap(Collection::stream) - .distinct() - .map(TimemarkContainerValidationReportBuilder::mapDigidoc4JException) - .collect(Collectors.toList()); + return ValidationErrorMapper.getErrors(Stream.of( + signatureValidationResult.getErrors(), + this.validationResult.getErrors() + )); } private String getCountryCode(Signature signature) { @@ -336,35 +191,7 @@ private String getCountryCode(Signature signature) { } protected List getCertificateList(Signature signature) { - List certificateList = new ArrayList<>(); - - X509Cert ocspCertificate; - try { - ocspCertificate = signature.getOCSPCertificate(); - } catch (CertificateNotFoundException e) { - LOGGER.warn("Failed to acquire OCSP certificate from signature", e); - ocspCertificate = null; - } - if (ocspCertificate != null) { - X509Certificate x509Certificate = ocspCertificate.getX509Certificate(); - certificateList.add(getCertificate(x509Certificate, CertificateType.REVOCATION)); - } - - X509Cert signingCertificate = signature.getSigningCertificate(); - if (signingCertificate != null) { - X509Certificate x509Certificate = signingCertificate.getX509Certificate(); - certificateList.add(getCertificate(x509Certificate, CertificateType.SIGNING)); - } - - return certificateList; - } - - protected Certificate getCertificate(X509Certificate x509Certificate, CertificateType type) { - Certificate certificate = new Certificate(); - certificate.setContent(CertUtil.encodeCertificateToBase64(x509Certificate)); - certificate.setCommonName(CertUtil.getCommonName(x509Certificate)); - certificate.setType(type); - return certificate; + return SignatureCertificateParser.getCertificateList(signature); } abstract void processSignatureIndications(ValidationConclusion validationConclusion, String policyName); diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java new file mode 100644 index 000000000..05a4a1063 --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java @@ -0,0 +1,159 @@ +package ee.openeid.validation.service.timemark.report; + +import ee.openeid.siva.validation.document.Datafile; +import ee.openeid.siva.validation.document.ValidationDocument; +import ee.openeid.siva.validation.document.report.Reports; +import ee.openeid.siva.validation.document.report.SignatureScope; +import ee.openeid.siva.validation.document.report.SignatureValidationData; +import ee.openeid.siva.validation.document.report.SimpleReport; +import ee.openeid.siva.validation.document.report.ValidationConclusion; +import ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils; +import ee.openeid.siva.validation.service.signature.policy.properties.ConstraintDefinedPolicy; +import org.apache.commons.lang3.StringUtils; +import org.digidoc4j.Signature; +import org.digidoc4j.ValidationResult; +import org.digidoc4j.X509Cert; +import org.digidoc4j.impl.asic.AsicSignature; + +import java.util.List; +import java.util.Optional; +import java.util.stream.Stream; + +import static ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils.createReportPolicy; +import static ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils.getValidationTime; +import static ee.openeid.validation.service.timemark.report.TimemarkContainerValidationReportBuilder.REPORT_INDICATION_INDETERMINATE; +import static ee.openeid.validation.service.timemark.util.SignatureScopeParser.getAsicSignatureScopes; +import static ee.openeid.validation.service.timemark.util.SignatureCertificateParser.getCertificateList; +import static ee.openeid.validation.service.timemark.util.SignatureInfoParser.getInfo; +import static ee.openeid.validation.service.timemark.util.SigningCertificateParser.parseSignedBy; +import static ee.openeid.validation.service.timemark.util.SigningCertificateParser.parseSubjectDistinguishedName; +import static ee.openeid.validation.service.timemark.util.ValidationErrorMapper.getErrors; +import static ee.openeid.validation.service.timemark.util.ValidationErrorMapper.getWarnings; +import static java.util.Collections.emptyList; + +public class TimemarkHashcodeValidationReportBuilder { + private final ValidationResult validationResult; + private final ConstraintDefinedPolicy validationPolicy; + private final Signature signature; + private final ValidationDocument validationDocument; + private final boolean isReportSignatureEnabled; + + + public TimemarkHashcodeValidationReportBuilder(ValidationResult validationResult, + ConstraintDefinedPolicy validationPolicy, + Signature signature, + ValidationDocument validationDocument, + boolean isReportSignatureEnabled) { + this.validationResult = validationResult; + this.validationPolicy = validationPolicy; + this.signature = signature; + this.validationDocument = validationDocument; + this.isReportSignatureEnabled = isReportSignatureEnabled; + } + + public Reports build() { + final var validationConclusion = getValidationConclusion(); + final var simpleReport = new SimpleReport(validationConclusion); + return new Reports(simpleReport, null, null); + } + + private ValidationConclusion getValidationConclusion() { + ValidationConclusion validationConclusion = new ValidationConclusion(); + validationConclusion.setPolicy(createReportPolicy(validationPolicy)); + validationConclusion.setValidationTime(getValidationTime()); + validationConclusion.setValidationWarnings(emptyList()); + validationConclusion.setSignatures(List.of(buildSignatureValidationData())); + validationConclusion.setSignaturesCount(validationConclusion.getSignatures().size()); + validationConclusion.setValidatedDocument(ReportBuilderUtils.createValidatedDocument(isReportSignatureEnabled, validationDocument.getName(), validationDocument.getBytes())); + validationConclusion.setValidSignaturesCount((int) validationConclusion.getSignatures() + .stream() + .filter(vd -> StringUtils.equals(vd.getIndication(), SignatureValidationData.Indication.TOTAL_PASSED.toString())).count()); + return validationConclusion; + } + + private SignatureValidationData buildSignatureValidationData() { + SignatureValidationData signatureValidationData = new SignatureValidationData(); + signatureValidationData.setId(signature.getId()); + signatureValidationData.setSignatureFormat(getSignatureFormat()); + signatureValidationData.setSignatureMethod(signature.getSignatureMethod()); + signatureValidationData.setSignatureLevel(getSignatureLevel()); + signatureValidationData.setSignedBy(parseSignedBy(signature.getSigningCertificate())); + signatureValidationData.setSubjectDistinguishedName(parseSubjectDistinguishedName(signature.getSigningCertificate())); + signatureValidationData.setErrors(getErrors(Stream.of(validationResult.getErrors()))); + signatureValidationData.setWarnings(getWarnings(Stream.of(validationResult.getWarnings()))); + signatureValidationData.setSignatureScopes(getSignatureScopes()); + signatureValidationData.setClaimedSigningTime(ReportBuilderUtils.getDateFormatterWithGMTZone().format(signature.getClaimedSigningTime())); + signatureValidationData.setInfo(getInfo(signature)); + signatureValidationData.setIndication(getIndication()); + signatureValidationData.setSubIndication(getSubIndication()); + signatureValidationData.setCountryCode(getCountryCode(signature)); + signatureValidationData.setCertificates(getCertificateList(signature)); + return signatureValidationData; + } + + private String getCountryCode(Signature signature) { + return signature.getSigningCertificate().getSubjectName(X509Cert.SubjectName.C); + } + + private List getDataFileNames() { + return validationDocument.getDatafiles() + .stream() + .map(Datafile::getFilename) + .toList(); + } + + private String getSignatureLevel() { + return getAsicSignatureSimpleReport() + .map(simpleReport -> simpleReport.getSignatureQualification(signature.getUniqueId())) + .map(Enum::name) + .orElse(null); + } + + private String getSignatureFormat() { + return getAsicSignatureSimpleReport() + .map(simpleReport -> simpleReport.getSignatureFormat(signature.getUniqueId())) + .map(Enum::name) + .orElse(null); + } + + private Optional getAsicSignatureSimpleReport() { + return signature instanceof AsicSignature + ? Optional.of(((AsicSignature) signature).getDssValidationReport().getReports().getSimpleReport()) + : Optional.empty(); + } + + private List getSignatureScopes() { + return signature instanceof AsicSignature + ? getAsicSignatureScopes((AsicSignature) signature, getDataFileNames()) + : emptyList(); + } + + private SignatureValidationData.Indication getIndication() { + if (validationResult.isValid() && validationResult.getErrors().isEmpty()) { + return SignatureValidationData.Indication.TOTAL_PASSED; + } + if (isIndeterminate() && validationResult.getErrors().isEmpty()) { + return SignatureValidationData.Indication.INDETERMINATE; + } + return SignatureValidationData.Indication.TOTAL_FAILED; + } + + private boolean isIndeterminate() { + return getAsicSignatureSimpleReport() + .map(simpleReport -> simpleReport.getIndication(signature.getUniqueId())) + .map(Enum::name) + .filter(REPORT_INDICATION_INDETERMINATE::equals) + .isPresent(); + } + + private String getSubIndication() { + if (SignatureValidationData.Indication.TOTAL_PASSED.equals(getIndication())) { + return ""; + } + return getAsicSignatureSimpleReport() + .map(simpleReport -> simpleReport.getSubIndication(signature.getUniqueId())) + .map(Enum::name) + .orElse(""); + + } +} diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureCertificateParser.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureCertificateParser.java new file mode 100644 index 000000000..a193129cd --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureCertificateParser.java @@ -0,0 +1,52 @@ +package ee.openeid.validation.service.timemark.util; + +import ee.openeid.siva.validation.document.report.Certificate; +import ee.openeid.siva.validation.document.report.CertificateType; +import ee.openeid.siva.validation.util.CertUtil; +import lombok.experimental.UtilityClass; +import org.digidoc4j.Signature; +import org.digidoc4j.X509Cert; +import org.digidoc4j.exceptions.CertificateNotFoundException; +import org.slf4j.LoggerFactory; + +import java.security.cert.X509Certificate; +import java.util.ArrayList; +import java.util.List; + + +@UtilityClass +public class SignatureCertificateParser { + private static final org.slf4j.Logger LOGGER = LoggerFactory.getLogger(SignatureCertificateParser.class); + + public static List getCertificateList(Signature signature) { + List certificateList = new ArrayList<>(); + + X509Cert ocspCertificate; + try { + ocspCertificate = signature.getOCSPCertificate(); + } catch (CertificateNotFoundException e) { + LOGGER.warn("Failed to acquire OCSP certificate from signature", e); + ocspCertificate = null; + } + if (ocspCertificate != null) { + X509Certificate x509Certificate = ocspCertificate.getX509Certificate(); + certificateList.add(getCertificate(x509Certificate, CertificateType.REVOCATION)); + } + + X509Cert signingCertificate = signature.getSigningCertificate(); + if (signingCertificate != null) { + X509Certificate x509Certificate = signingCertificate.getX509Certificate(); + certificateList.add(getCertificate(x509Certificate, CertificateType.SIGNING)); + } + + return certificateList; + } + + public static Certificate getCertificate(X509Certificate x509Certificate, CertificateType type) { + Certificate certificate = new Certificate(); + certificate.setContent(CertUtil.encodeCertificateToBase64(x509Certificate)); + certificate.setCommonName(CertUtil.getCommonName(x509Certificate)); + certificate.setType(type); + return certificate; + } +} diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureInfoParser.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureInfoParser.java new file mode 100644 index 000000000..e32ed818c --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureInfoParser.java @@ -0,0 +1,122 @@ +package ee.openeid.validation.service.timemark.util; + +import ee.openeid.siva.validation.document.report.Info; +import ee.openeid.siva.validation.document.report.SignatureProductionPlace; +import ee.openeid.siva.validation.document.report.SignerRole; +import ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils; +import eu.europa.esig.dss.diagnostic.DiagnosticData; +import eu.europa.esig.dss.diagnostic.SignatureWrapper; +import eu.europa.esig.dss.diagnostic.TimestampWrapper; +import eu.europa.esig.dss.enumerations.TimestampType; +import lombok.experimental.UtilityClass; +import org.apache.commons.codec.binary.Base64; +import org.apache.commons.lang3.StringUtils; +import org.digidoc4j.Signature; +import org.digidoc4j.SignatureProfile; +import org.digidoc4j.exceptions.DigiDoc4JException; +import org.digidoc4j.impl.asic.asice.AsicESignature; +import org.slf4j.LoggerFactory; + +import java.util.Collections; +import java.util.Comparator; +import java.util.Date; +import java.util.List; +import java.util.Optional; +import java.util.stream.Collectors; + +@UtilityClass +public class SignatureInfoParser { + private static final org.slf4j.Logger LOGGER = LoggerFactory.getLogger(SignatureInfoParser.class); + + public static Info getInfo(Signature signature) { + Info info = new Info(); + info.setBestSignatureTime(getBestSignatureTime(signature)); + if (signature.getProfile() == SignatureProfile.LT) { + info.setTimestampCreationTime(getTimestampTime(signature)); + } + info.setOcspResponseCreationTime(getOcspTime(signature)); + info.setTimeAssertionMessageImprint(getTimeAssertionMessageImprint(signature)); + info.setSignerRole(getSignerRole(signature)); + info.setSignatureProductionPlace(getSignatureProductionPlace(signature)); + return info; + } + + private static String getTimeAssertionMessageImprint(Signature signature) { + if (signature.getProfile() != SignatureProfile.LT_TM) { + TimestampWrapper timestamp = getBestTimestampWrapper(signature); + try { + return ReportBuilderUtils.parseTimeAssertionMessageImprint(timestamp); + } catch (Exception e) { + LOGGER.warn("Unable to parse time assertion message imprint from timestamp: ", e); + return ""; //parse errors due to corrupted timestamp data should be present in validation errors already + } + } + + try { + return StringUtils.defaultString(Base64.encodeBase64String(signature.getOCSPNonce())); + } catch (DigiDoc4JException e) { + LOGGER.warn("Unable to parse time assertion message imprint from OCSP nonce: ", e); + return ""; //parse errors due to corrupted OCSP data should be present in validation errors already + } + } + + private static TimestampWrapper getBestTimestampWrapper(Signature signature) { + DiagnosticData diagnosticData = ((AsicESignature) signature).getDssValidationReport().getReports().getDiagnosticData(); + SignatureWrapper signatureWrapper = diagnosticData.getSignatureById(signature.getUniqueId()); + List timestamps = signatureWrapper.getTimestampListByType(TimestampType.SIGNATURE_TIMESTAMP); + return timestamps.isEmpty() ? null : Collections.min(timestamps, Comparator.comparing(TimestampWrapper::getProductionTime)); + } + + private static SignatureProductionPlace getSignatureProductionPlace(Signature signature) { + if (isSignatureProductionPlaceEmpty(signature)) { + return null; + } + + SignatureProductionPlace signatureProductionPlace = new SignatureProductionPlace(); + signatureProductionPlace.setCountryName(StringUtils.defaultString(signature.getCountryName())); + signatureProductionPlace.setStateOrProvince(StringUtils.defaultString(signature.getStateOrProvince())); + signatureProductionPlace.setCity(StringUtils.defaultString(signature.getCity())); + signatureProductionPlace.setPostalCode(StringUtils.defaultString(signature.getPostalCode())); + return signatureProductionPlace; + } + + private static boolean isSignatureProductionPlaceEmpty(Signature signature) { + return StringUtils.isAllEmpty( + signature.getCountryName(), + signature.getStateOrProvince(), + signature.getCity(), + signature.getPostalCode() + ); + } + + private static String getBestSignatureTime(Signature signature) { + return formatTime(signature.getTrustedSigningTime()); + } + + private static String getOcspTime(Signature signature) { + return formatTime(signature.getOCSPResponseCreationTime()); + } + + private static String getTimestampTime(Signature signature) { + return formatTime(signature.getTimeStampCreationTime()); + } + + private static String formatTime(Date date) { + return Optional.ofNullable(date) + .map(d -> ReportBuilderUtils.getDateFormatterWithGMTZone().format(d)) + .orElse(null); + } + + private static List getSignerRole(Signature signature) { + return signature.getSignerRoles().stream() + .filter(StringUtils::isNotEmpty) + .map(SignatureInfoParser::mapSignerRole) + .collect(Collectors.toList()); + } + + private static SignerRole mapSignerRole(String claimedRole) { + SignerRole signerRole = new SignerRole(); + signerRole.setClaimedRole(claimedRole); + return signerRole; + } +} diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java new file mode 100644 index 000000000..26f40c0b8 --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java @@ -0,0 +1,44 @@ +package ee.openeid.validation.service.timemark.util; + +import ee.openeid.siva.validation.document.report.SignatureScope; +import lombok.experimental.UtilityClass; +import org.digidoc4j.impl.asic.AsicSignature; +import org.slf4j.LoggerFactory; + +import java.io.UnsupportedEncodingException; +import java.net.URLDecoder; +import java.util.List; +import java.util.stream.Collectors; + +@UtilityClass +public class SignatureScopeParser { + private static final org.slf4j.Logger LOGGER = LoggerFactory.getLogger(SignatureScopeParser.class); + private static final String FULL_SIGNATURE_SCOPE = "FullSignatureScope"; + private static final String FULL_DOCUMENT = "Digest of the document content"; + + public static List getAsicSignatureScopes(AsicSignature signature, List dataFilenames) { + return signature.getOrigin().getReferences() + .stream() + .map(r -> decodeUriIfPossible(r.getURI())) + .filter(dataFilenames::contains) //filters out Signed Properties + .map(SignatureScopeParser::createFullSignatureScopeForDataFile) + .collect(Collectors.toList()); + } + + private static String decodeUriIfPossible(String uri) { + try { + return URLDecoder.decode(uri, "UTF-8"); + } catch (UnsupportedEncodingException e) { + LOGGER.warn("datafile " + uri + " has unsupported encoding", e); + return uri; + } + } + + public static SignatureScope createFullSignatureScopeForDataFile(String filename) { + SignatureScope signatureScope = new SignatureScope(); + signatureScope.setName(filename); + signatureScope.setScope(FULL_SIGNATURE_SCOPE); + signatureScope.setContent(FULL_DOCUMENT); + return signatureScope; + } +} diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SigningCertificateParser.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SigningCertificateParser.java new file mode 100644 index 000000000..c3e99f691 --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SigningCertificateParser.java @@ -0,0 +1,43 @@ +package ee.openeid.validation.service.timemark.util; + +import ee.openeid.siva.validation.document.report.SubjectDistinguishedName; +import ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils; +import ee.openeid.siva.validation.util.DistinguishedNameUtil; +import ee.openeid.siva.validation.util.SubjectDNParser; +import lombok.experimental.UtilityClass; +import org.digidoc4j.X509Cert; + +import java.util.Optional; + +import static org.digidoc4j.X509Cert.SubjectName.CN; + +@UtilityClass +public class SigningCertificateParser { + public static SubjectDistinguishedName parseSubjectDistinguishedName(X509Cert signingCertificate) { + return SubjectDistinguishedName.builder() + .serialNumber(getSubjectName(signingCertificate, X509Cert.SubjectName.SERIALNUMBER)) + .commonName(getSubjectName(signingCertificate, X509Cert.SubjectName.CN)) + .givenName(getSubjectName(signingCertificate, X509Cert.SubjectName.GIVENNAME)) + .surname(getSubjectName(signingCertificate, X509Cert.SubjectName.SURNAME)) + .build(); + } + + private static String getSubjectName(X509Cert signingCertificate, X509Cert.SubjectName subjectName) { + return Optional.ofNullable(signingCertificate) + .map(cert -> cert.getSubjectName(subjectName)) + .map(SubjectDNParser::removeQuotes) + .orElse(null); + } + + public static String parseSignedBy(X509Cert signingCertificate) { + return Optional.ofNullable(signingCertificate) + .flatMap(certificate -> Optional + .ofNullable(certificate.getX509Certificate()) + .map(DistinguishedNameUtil::getSubjectSurnameAndGivenNameAndSerialNumber) + .or(() -> Optional + .ofNullable(certificate.getSubjectName(CN)) + .map(SubjectDNParser::removeQuotes)) + ) + .orElseGet(ReportBuilderUtils::valueNotPresent); + } +} diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/ValidationErrorMapper.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/ValidationErrorMapper.java new file mode 100644 index 000000000..f881ea1c8 --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/ValidationErrorMapper.java @@ -0,0 +1,44 @@ +package ee.openeid.validation.service.timemark.util; + +import ee.openeid.siva.validation.document.report.Error; +import ee.openeid.siva.validation.document.report.Warning; +import lombok.experimental.UtilityClass; +import org.digidoc4j.exceptions.DigiDoc4JException; + +import java.util.Collection; +import java.util.List; +import java.util.function.Function; +import java.util.stream.Stream; + +import static ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils.emptyWhenNull; + +@UtilityClass +public class ValidationErrorMapper { + public static List getWarnings(Stream> warnings) { + return mapExceptions(warnings, ValidationErrorMapper::mapDigidoc4JWarning); + } + + public static List getErrors(Stream> errors) { + return mapExceptions(errors, ValidationErrorMapper::mapDigidoc4JException); + } + + private static List mapExceptions(Stream> exceptions, + Function mapper) { + return exceptions.flatMap(Collection::stream) + .distinct() + .map(mapper) + .toList(); + } + + private static Warning mapDigidoc4JWarning(DigiDoc4JException digiDoc4JException) { + Warning warning = new Warning(); + warning.setContent(emptyWhenNull(digiDoc4JException.getMessage())); + return warning; + } + + private static Error mapDigidoc4JException(DigiDoc4JException digiDoc4JException) { + Error error = new Error(); + error.setContent(emptyWhenNull(digiDoc4JException.getMessage())); + return error; + } +} diff --git a/validation-services-parent/timemark-container-validation-service/src/test/resources/test-files/timemark_signature.xml b/validation-services-parent/timemark-container-validation-service/src/test/resources/test-files/timemark_signature.xml new file mode 100755 index 000000000..77d5acc28 --- /dev/null +++ b/validation-services-parent/timemark-container-validation-service/src/test/resources/test-files/timemark_signature.xml @@ -0,0 +1,81 @@ + + + + + + + + + RnKZobNWVy8u92sDL4S2j1BUzMT5qTgt6hm90TfAGRo= + + + + + + + 5Bk7RHmH+P8bihr1kdd/4apnRVoJfn3yH55123tipQw= + + + pn8r7FZWhBFKnMaLb810NMmMD8PQlLh2w9SCnhZpntENG4XbKCvK+/8rCsTaBR/hrQMFFIkNHahdRGrhN3k3binLhq/2kwIn6hC5NoqixSc/fwyFjE5mv0reHGWDW2E9 + + + MIID6zCCA02gAwIBAgIQT7j6zk6pmVRcyspLo5SqejAKBggqhkjOPQQDBDBgMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEbMBkGA1UEAwwSVEVTVCBvZiBFU1RFSUQyMDE4MB4XDTE5MDUwMjEwNDUzMVoXDTI5MDUwMjEwNDUzMVowfzELMAkGA1UEBhMCRUUxFjAUBgNVBCoMDUpBQUstS1JJU1RKQU4xEDAOBgNVBAQMB0rDlUVPUkcxKjAoBgNVBAMMIUrDlUVPUkcsSkFBSy1LUklTVEpBTiwzODAwMTA4NTcxODEaMBgGA1UEBRMRUE5PRUUtMzgwMDEwODU3MTgwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAASkwENR8GmCpEs6OshDWDfIiKvGuyNMOD2rjIQW321AnZD3oIsqD0svBMNEJJj9Dlvq/47TYDObIa12KAU5IuOBfJs2lrFdSXZjaM+a5TWT3O2JTM36YDH2GcMe/eisepejggGrMIIBpzAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIGQDBIBgNVHSAEQTA/MDIGCysGAQQBg5EhAQIBMCMwIQYIKwYBBQUHAgEWFWh0dHBzOi8vd3d3LnNrLmVlL0NQUzAJBgcEAIvsQAECMB0GA1UdDgQWBBTVX3s48Spy/Es2TcXgkRvwUn2YcjCBigYIKwYBBQUHAQMEfjB8MAgGBgQAjkYBATAIBgYEAI5GAQQwEwYGBACORgEGMAkGBwQAjkYBBgEwUQYGBACORgEFMEcwRRY/aHR0cHM6Ly9zay5lZS9lbi9yZXBvc2l0b3J5L2NvbmRpdGlvbnMtZm9yLXVzZS1vZi1jZXJ0aWZpY2F0ZXMvEwJFTjAfBgNVHSMEGDAWgBTAhJkpxE6fOwI09pnhClYACCk+ezBzBggrBgEFBQcBAQRnMGUwLAYIKwYBBQUHMAGGIGh0dHA6Ly9haWEuZGVtby5zay5lZS9lc3RlaWQyMDE4MDUGCCsGAQUFBzAChilodHRwOi8vYy5zay5lZS9UZXN0X29mX0VTVEVJRDIwMTguZGVyLmNydDAKBggqhkjOPQQDBAOBiwAwgYcCQgGBr+Jbo1GeqgWdIwgMo7SA29AP38JxNm2HWq2Qb+kIHpusAK574Co1K5D4+Mk7/ITTuXQaET5WphHoN7tdAciTaQJBAn0zBigYyVPYSTO68HM6hmlwTwi/KlJDdXW/2NsMjSqofFFJXpGvpxk2CTqSRCjcavxLPnkasTbNROYSJcmM8Xc= + + + + + + + 2020-05-21T14:07:04Z + + + + + +pli41INDQEEIMW6dPXct4dXJSk8bIQ5Ny1TcNC35eA= + + + CN=TEST of ESTEID2018,2.5.4.97=#0c0e4e545245452d3130373437303133,O=SK ID Solutions AS,C=EE + 105969481236726016406974448130977999482 + + + + + + + urn:oid:1.3.6.1.4.1.10015.1000.3.2.1 + + + + 7pudpH4eXlguSZY2e/pNbKzGsq+fu//woYL1SZFws1A= + + + + https://www.sk.ee/repository/bdoc-spec21.pdf + + + + + + + + application/octet-stream + + + + + + + MIIEijCCA3KgAwIBAgIQaI8x6BnacYdNdNwlYnn/mzANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMyMjQ1WhcNMjQwOTA3MTIyMjQ1WjCBgzELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRpZml0c2VlcmltaXNrZXNrdXMxDTALBgNVBAsMBE9DU1AxJzAlBgNVBAMMHlRFU1Qgb2YgU0sgT0NTUCBSRVNQT05ERVIgMjAxMTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0cw6Cja17BbYbHi6frwccDI4BIQLk/fiCE8L45os0xhPgEGR+EHE8LPCIqofPgf4gwN1vDE6cQNUlK0Od+Ush39i9Z45esnfpGq+2HsDJaFmFr5+uC1MEz5Kn1TazEvKbRjkGnSQ9BertlGer2BlU/kqOk5qA5RtJfhT0psc1ixKdPipv59wnf+nHx1+T+fPWndXVZLoDg4t3w8lIvIE/KhOSMlErvBIHIAKV7yH1hOxyeGLghqzMiAn3UeTEOgoOS9URv0C/T5C3mH+Y/uakMSxjNuz41PneimCzbEJZJRiEaMIj8qPAubcbL8GtY03MWmfNtX6/wh6u6TMfW8S2wIDAQABo4H+MIH7MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMJMB0GA1UdDgQWBBR9/5CuRokEgGiqSzYuZGYAogl8TzCBoAYDVR0gBIGYMIGVMIGSBgorBgEEAc4fAwEBMIGDMFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQAaQBtAGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4AZwAuMCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LnNrLmVlL2FqYXRlbXBlbC8wHwYDVR0jBBgwFoAUtTQKnaUvEMXnIQ6+xLFlRxsDdv4wDQYJKoZIhvcNAQEFBQADggEBAAbaj7kTruTAPHqToye9ZtBdaJ3FZjiKug9/5RjsMwDpOeqFDqCorLd+DBI4tgdu0g4lhaI3aVnKdRBkGV18kqp84uU97JRFWQEf6H8hpJ9k/LzAACkP3tD+0ym+md532mV+nRz1Jj+RPLAUk9xYMV7KPczZN1xnl2wZDJwBbQpcSVH1DjlZv3tFLHBLIYTS6qOK4SxStcgRq7KdRczfW6mfXzTCRWM3G9nmDei5Q3+XTED41j8szRWglzYf6zOv4djkja64WYraQ5zb4x8Xh7qTCk6UupZ7je+0oRfuz0h/3zyRdjcRPkjloSpQp/NG8Rmrcnr874p8d9fdwCrRI7U= + MIIFLDCCBI2gAwIBAgIQImvqKVwtGyZbh+ecdKPc7zAKBggqhkjOPQQDBDBiMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEdMBsGA1UEAwwUVEVTVCBvZiBFRS1Hb3ZDQTIwMTgwHhcNMTgwODMwMTI0ODI4WhcNMzMwODMwMTI0ODI4WjBiMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEdMBsGA1UEAwwUVEVTVCBvZiBFRS1Hb3ZDQTIwMTgwgZswEAYHKoZIzj0CAQYFK4EEACMDgYYABABZN0DFpEKsj3SzsySoR/bcwAUoLc+S2HrvHY0xIDkFFTtUQXfjxXyexNIx+ALe2IYJZLTl0T79C5by4/mO/5H7UgCxZZCRKtdcKqSGYJOVpT0XoA51yX8eBk8aPVrTcwABcBhU6nTNGEoNXfeS7mrZB6Gs3eFxEVdejIEjNObWVFYMbqOCAuAwggLcMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMDQGA1UdJQEB/wQqMCgGCCsGAQUFBwMJBggrBgEFBQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMBMB0GA1UdDgQWBBR/DHDY9OWPAXfux20pKbn0yfxqwDAfBgNVHSMEGDAWgBR/DHDY9OWPAXfux20pKbn0yfxqwDCCAiQGA1UdIASCAhswggIXMAgGBgQAj3oBAjAJBgcEAIvsQAECMDIGCysGAQQBg5EhAQIBMCMwIQYIKwYBBQUHAgEWFWh0dHBzOi8vd3d3LnNrLmVlL0NQUzANBgsrBgEEAYORIQECAjANBgsrBgEEAYORfwECATANBgsrBgEEAYORIQECBTANBgsrBgEEAYORIQECBjANBgsrBgEEAYORIQECBzANBgsrBgEEAYORIQECAzANBgsrBgEEAYORIQECBDANBgsrBgEEAYORIQECCDANBgsrBgEEAYORIQECCTANBgsrBgEEAYORIQECCjANBgsrBgEEAYORIQECCzANBgsrBgEEAYORIQECDDANBgsrBgEEAYORIQECDTANBgsrBgEEAYORIQECDjANBgsrBgEEAYORIQECDzANBgsrBgEEAYORIQECEDANBgsrBgEEAYORIQECETANBgsrBgEEAYORIQECEjANBgsrBgEEAYORIQECEzANBgsrBgEEAYORIQECFDANBgsrBgEEAYORfwECAjANBgsrBgEEAYORfwECAzANBgsrBgEEAYORfwECBDANBgsrBgEEAYORfwECBTANBgsrBgEEAYORfwECBjBVBgorBgEEAYORIQoBMEcwIQYIKwYBBQUHAgEWFWh0dHBzOi8vd3d3LnNrLmVlL0NQUzAiBggrBgEFBQcCAjAWGhRURVNUIG9mIEVFLUdvdkNBMjAxODAYBggrBgEFBQcBAwQMMAowCAYGBACORgEBMAoGCCqGSM49BAMEA4GMADCBiAJCAeTjfRrMt+4ecVYozAfdpTjCikf332XcuRkuJ6fbLqqMm7C3v/d5ebyOqvDG6wWAp8Z0GZA5ONIvS2rm8kJ7HR5tAkIAoFn7n5ZW62dXMmPk+LReR1hUyTpxrxC31QjqvMqM2AbM8luw0f/AaC5qsEdwKrKT+p1xvnjSyIVfcMiu6Q3T2EE= + MIIFfDCCBN2gAwIBAgIQNhjzSfd2UEpbkO14EY4ORTAKBggqhkjOPQQDBDBiMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEdMBsGA1UEAwwUVEVTVCBvZiBFRS1Hb3ZDQTIwMTgwHhcNMTgwOTA2MDkwMzUyWhcNMzMwODMwMTI0ODI4WjBgMQswCQYDVQQGEwJFRTEbMBkGA1UECgwSU0sgSUQgU29sdXRpb25zIEFTMRcwFQYDVQRhDA5OVFJFRS0xMDc0NzAxMzEbMBkGA1UEAwwSVEVTVCBvZiBFU1RFSUQyMDE4MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQBxYug4cEqwmIj+3TVaUlhfxCV9FQgfuglC2/0Ux1Ieqw11mDjNvnGJhkWxaLbWJi7QtthMG5R104l7Np7lBevrBgBDtfgja9e3MLTQkY+cFS+UQxjt9ZihTUJVsR7lowYlaGEiqqsGbEhlwfu27Xsm8b2rhSiTOvNdjTtG57NnwVAX+ijggMyMIIDLjAfBgNVHSMEGDAWgBR/DHDY9OWPAXfux20pKbn0yfxqwDAdBgNVHQ4EFgQUwISZKcROnzsCNPaZ4QpWAAgpPnswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwggHNBgNVHSAEggHEMIIBwDAIBgYEAI96AQIwCQYHBACL7EABAjAyBgsrBgEEAYORIQECATAjMCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5zay5lZS9DUFMwDQYLKwYBBAGDkSEBAgIwDQYLKwYBBAGDkX8BAgEwDQYLKwYBBAGDkSEBAgUwDQYLKwYBBAGDkSEBAgYwDQYLKwYBBAGDkSEBAgcwDQYLKwYBBAGDkSEBAgMwDQYLKwYBBAGDkSEBAgQwDQYLKwYBBAGDkSEBAggwDQYLKwYBBAGDkSEBAgkwDQYLKwYBBAGDkSEBAgowDQYLKwYBBAGDkSEBAgswDQYLKwYBBAGDkSEBAgwwDQYLKwYBBAGDkSEBAg0wDQYLKwYBBAGDkSEBAg4wDQYLKwYBBAGDkSEBAg8wDQYLKwYBBAGDkSEBAhAwDQYLKwYBBAGDkSEBAhEwDQYLKwYBBAGDkSEBAhIwDQYLKwYBBAGDkSEBAhMwDQYLKwYBBAGDkSEBAhQwDQYLKwYBBAGDkX8BAgIwDQYLKwYBBAGDkX8BAgMwDQYLKwYBBAGDkX8BAgQwDQYLKwYBBAGDkX8BAgUwDQYLKwYBBAGDkX8BAgYwKgYDVR0lAQH/BCAwHgYIKwYBBQUHAwkGCCsGAQUFBwMCBggrBgEFBQcDBDB3BggrBgEFBQcBAQRrMGkwLgYIKwYBBQUHMAGGImh0dHA6Ly9haWEuZGVtby5zay5lZS9lZS1nb3ZjYTIwMTgwNwYIKwYBBQUHMAKGK2h0dHA6Ly9jLnNrLmVlL1Rlc3Rfb2ZfRUUtR292Q0EyMDE4LmRlci5jcnQwGAYIKwYBBQUHAQMEDDAKMAgGBgQAjkYBATA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vYy5zay5lZS9UZXN0X29mX0VFLUdvdkNBMjAxOC5jcmwwCgYIKoZIzj0EAwQDgYwAMIGIAkIBIF+LqytyaV4o5wUSm30VysB8LdWtoOrzNq2QhB6tGv4slg5z+CR58e60eRFqNxT7eccA/HgoPWs0B1Z+L067qtUCQgCB8OP0kHx/j1t7htN2CXjpSjGFZw5TTI4s1eGyTbe0UJRBXEkUKfFbZVmzGPFPprwUdSPi8PpO7+xGBYlFHA4z+Q== + + + + + + + + + + + \ No newline at end of file diff --git a/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/util/SubjectDNParser.java b/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/util/SubjectDNParser.java index d32e96ce6..01e163f0e 100644 --- a/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/util/SubjectDNParser.java +++ b/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/util/SubjectDNParser.java @@ -48,7 +48,7 @@ public static String parse(String subjectDistinguishedName, RDN relativeDistingu return null; } - private static String removeQuotes(String value) { + public static String removeQuotes(String value) { return value.replaceAll("(^\")|(\"$)", ""); } From 937ff72eca634e22109e34f728174a6edcf2419a Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 10:34:14 +0300 Subject: [PATCH 02/11] Normalize line endings --- README.md | 296 +-- .../documentation_deployment_instructions.txt | 84 +- docs/index.md | 74 +- docs/siva/appendix/validation_policy.md | 372 ++-- docs/siva/v2/systemintegrators_guide.md | 1100 +++++------ docs/siva2/appendix/known_issues.md | 6 +- docs/siva2/appendix/validation_policy.md | 422 ++--- docs/siva2/component_diagram.md | 188 +- docs/siva2/definitions.md | 84 +- docs/siva2/deployment.md | 40 +- docs/siva2/deployment_view.md | 68 +- docs/siva2/interfaces.md | 1658 ++++++++--------- docs/siva2/logging.md | 186 +- docs/siva2/overview.md | 108 +- docs/siva2/qa_strategy.md | 310 +-- docs/siva2/references.md | 16 +- docs/siva2/systemintegrators_guide.md | 1174 ++++++------ docs/siva3/appendix/known_issues.md | 6 +- docs/siva3/appendix/validation_policy.md | 424 ++--- docs/siva3/definitions.md | 86 +- docs/siva3/deployment.md | 40 +- docs/siva3/deployment_guide.md | 1096 +++++------ docs/siva3/interfaces.md | 1436 +++++++------- docs/siva3/qa_strategy.md | 214 +-- mkdocs.yml | 156 +- .../MonitoringConfiguration.java | 112 +- .../indicator/ApplicationHealthIndicator.java | 192 +- .../indicator/UrlHealthIndicator.java | 280 +-- .../ApplicationHealthIndicatorTest.java | 268 +-- .../ContainerMimetypeFileException.java | 46 +- .../validation/ZipMimetypeValidator.java | 256 +-- .../siva/proxy/ZipMimetypeValidatorTest.java | 366 ++-- .../service/generic/PolicyUtil.java | 108 +- .../TLevelSignatureFilterProperties.java | 100 +- .../RevocationFreshnessValidatorFactory.java | 50 +- ...lSignatureOfNonListedCountryPredicate.java | 102 +- .../filter/AllowedCountriesFilter.java | 68 +- .../validator/filter/CountryFilter.java | 44 +- .../filter/NotAllowedCountriesFilter.java | 68 +- .../validator/ocsp/CompositeOCSPSource.java | 84 +- .../ocsp/LoggingOSCPSourceWrapper.java | 140 +- .../validator/ocsp/OCSPRequestPredicate.java | 86 +- .../validator/ocsp/OCSPSourceFactory.java | 48 +- .../resources/test-certs/TEST EECCRCA.crt | 48 +- .../resources/test-certs/TEST EID-SK 2011.crt | 56 +- .../test-certs/TEST ESTEID-SK 2011.crt | 56 +- .../resources/test-certs/TEST Juur-SK.crt | 46 +- .../resources/test-certs/TEST KLASS3 2010.crt | 56 +- .../test-certs/TEST SK OCSP 2011.crt | 54 +- .../test-certs/TEST-SK OCSP 2005.crt | 34 +- .../src/main/resources/test-certs/TEST-SK.crt | 58 +- .../constant/AsicContainerConstants.java | 52 +- 52 files changed, 6261 insertions(+), 6261 deletions(-) diff --git a/README.md b/README.md index ad238cf02..69fbb7318 100644 --- a/README.md +++ b/README.md @@ -1,148 +1,148 @@ -Co-funded by the European Union - -# Signature Verification Service - -[![SiVa CI with Maven](https://github.com/open-eid/siva/actions/workflows/siva-verify.yml/badge.svg?branch=master)](https://github.com/open-eid/siva/actions/workflows/siva-verify.yml) -[![GitHub license](https://img.shields.io/badge/license-EUPLv1.1-blue.svg)](https://raw.githubusercontent.com/open-eid/SiVa/develop/LICENSE.md) - -SiVa is digital signature validation web service that provides JSON API to validate following file types: - -* Estonian DDOC containers -* Estonian BDOC containers with TimeMark and TimeStamp signatures -* Estonian ASiC-S containers with time stamp tokens -* ETSI standard based ASiC-E and ASiC-S containers -* ETSI standard based XAdES, CAdES and PAdES signatures -* ETSI standard based XAdES signatures with datafiles in hashcode form - -### Libraries used in validation services - -Below is list of Java libraries used for validation: - -* [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate DDOC and BDOC digital signature containers. -* [DigiDoc4J DSS fork](https://github.com/open-eid/sd-dss) - to validate all other digitally signed files. - -## Requirements - -These are minimum requirements to build and develop SiVa project: - -* **git** - to easily download and update code. You can [download git here](https://git-scm.com/) -* **Java JDK 17** - to compile and run SiVa applications. -* **IDE** - to develop SiVa. We recommend to use [JetBrains IntelliJ](https://www.jetbrains.com/idea/) -* **2 GB of RAM** the RAM requirement is here because when building the project the integration tests take up a lot of memory -* Optionally You can also install **Maven** but it is not needed because SiVa project uses Maven wrapper to install maven - -## How to build - -### Using Maven Wrapper - -Recommended way of building this project is using [Maven Wrapper](https://github.com/takari/maven-wrapper). -Run following command: - -```bash -./mvnw clean install -``` - -After that, you can optionally create an image for Docker: - -```bash -./mvnw spring-boot:build-image -pl siva-parent/siva-webapp -DskipTests -``` - -## How-to run - -### With docker - -Before continuing, the [siva-demo-application](https://github.com/open-eid/SiVa-demo-application) docker image must be built and available on Docker as `siva-demo-application:latest`. - -The following command will run siva-webapp along with siva-demo-application: - -``` -docker compose up -``` - -Now SiVa itself is accessible http://siva.localhost:8080/ and siva-demo-application http://siva-demo.localhost:9000/. -Logs for all running containers can be viewed at http://localhost:11080. - -### Without docker - -SiVa project compiles **2 fat executable JAR** files that You can run after successfully building the -project by issuing below command: - -**Starting the SiVa REST webservice. NB! X.X.X denotes the version you are running.** - -```bash -java -jar siva-parent/siva-webapp/target/siva-webapp-X.X.X-exec.jar -``` - -The SiVa webapp by default runs on port **8080**. - -Easiest way to test out validation is to [start SiVa Demo Application without docker](https://github.com/open-eid/SiVa-demo-application#without-docker). - -## WAR and Tomcat setup for legacy systems - -> **NOTE**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version -> conflicts. - -To build the WAR file use helper script with all the correct Maven parameters. - -```bash -./build-war.sh -``` - -Copy built WAR file into Tomcat `webapps` directory and start the servlet container. NB! X.X.X denotes the version you are running. - -```bash -cp siva-parent/siva-webapp/target/siva-webapp-X.X.X.war apache-tomcat-7.0.70/webapps -./apache-tomcat-7.0.77/bin/catalina.sh run -``` - -> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validation certificates -> `siva-keystore.jks` (or `test-siva-keystore.jks` if `test` profile is used). Default location for this directory -> is application root or `$CATALINA_HOME`. To change this default behavior you should set environment variable -> `DSS_DATA_FOLDER` - -### How-to set WAR deployed SiVa `application.properties` - -SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. -To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. - -Contents of the `setenv.sh` file should look like: - -```bash -export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" -``` - -## How-to run tests - -Unit test are integral part of the SiVa code base. The tests are automatically executed every -time the application is built. The build will fail if any of the tests fail. - -To execute the tests from command line after application is built use: - -```bash -./mvnw verify -``` - -### How to run integration tests -Integration tests can be found [here](https://github.com/open-eid/SiVa-Test), and executing them requires running SiVa Web application instance. - -### How to run integration tests in docker -Before starting the docker instances, the `docker-compose.yaml` file must be modified. Add the following under the siva-webapp service to run the docker image with the test profile: - -``` -environment: - - "SPRING_PROFILES_ACTIVE=test" -``` - -### How to run load tests - -Load tests are available in the [SiVa-perftests](https://github.com/open-eid/SiVa-perftests) repository. - -## Open source software used to build SiVa - -Full list of open source Java libraries used to build SiVa can be found in our -[Open Source Software used page](OSS_USED.md) - -## Documentation - -Read [SiVa documentation](http://open-eid.github.io/SiVa/) +Co-funded by the European Union + +# Signature Verification Service + +[![SiVa CI with Maven](https://github.com/open-eid/siva/actions/workflows/siva-verify.yml/badge.svg?branch=master)](https://github.com/open-eid/siva/actions/workflows/siva-verify.yml) +[![GitHub license](https://img.shields.io/badge/license-EUPLv1.1-blue.svg)](https://raw.githubusercontent.com/open-eid/SiVa/develop/LICENSE.md) + +SiVa is digital signature validation web service that provides JSON API to validate following file types: + +* Estonian DDOC containers +* Estonian BDOC containers with TimeMark and TimeStamp signatures +* Estonian ASiC-S containers with time stamp tokens +* ETSI standard based ASiC-E and ASiC-S containers +* ETSI standard based XAdES, CAdES and PAdES signatures +* ETSI standard based XAdES signatures with datafiles in hashcode form + +### Libraries used in validation services + +Below is list of Java libraries used for validation: + +* [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate DDOC and BDOC digital signature containers. +* [DigiDoc4J DSS fork](https://github.com/open-eid/sd-dss) - to validate all other digitally signed files. + +## Requirements + +These are minimum requirements to build and develop SiVa project: + +* **git** - to easily download and update code. You can [download git here](https://git-scm.com/) +* **Java JDK 17** - to compile and run SiVa applications. +* **IDE** - to develop SiVa. We recommend to use [JetBrains IntelliJ](https://www.jetbrains.com/idea/) +* **2 GB of RAM** the RAM requirement is here because when building the project the integration tests take up a lot of memory +* Optionally You can also install **Maven** but it is not needed because SiVa project uses Maven wrapper to install maven + +## How to build + +### Using Maven Wrapper + +Recommended way of building this project is using [Maven Wrapper](https://github.com/takari/maven-wrapper). +Run following command: + +```bash +./mvnw clean install +``` + +After that, you can optionally create an image for Docker: + +```bash +./mvnw spring-boot:build-image -pl siva-parent/siva-webapp -DskipTests +``` + +## How-to run + +### With docker + +Before continuing, the [siva-demo-application](https://github.com/open-eid/SiVa-demo-application) docker image must be built and available on Docker as `siva-demo-application:latest`. + +The following command will run siva-webapp along with siva-demo-application: + +``` +docker compose up +``` + +Now SiVa itself is accessible http://siva.localhost:8080/ and siva-demo-application http://siva-demo.localhost:9000/. +Logs for all running containers can be viewed at http://localhost:11080. + +### Without docker + +SiVa project compiles **2 fat executable JAR** files that You can run after successfully building the +project by issuing below command: + +**Starting the SiVa REST webservice. NB! X.X.X denotes the version you are running.** + +```bash +java -jar siva-parent/siva-webapp/target/siva-webapp-X.X.X-exec.jar +``` + +The SiVa webapp by default runs on port **8080**. + +Easiest way to test out validation is to [start SiVa Demo Application without docker](https://github.com/open-eid/SiVa-demo-application#without-docker). + +## WAR and Tomcat setup for legacy systems + +> **NOTE**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version +> conflicts. + +To build the WAR file use helper script with all the correct Maven parameters. + +```bash +./build-war.sh +``` + +Copy built WAR file into Tomcat `webapps` directory and start the servlet container. NB! X.X.X denotes the version you are running. + +```bash +cp siva-parent/siva-webapp/target/siva-webapp-X.X.X.war apache-tomcat-7.0.70/webapps +./apache-tomcat-7.0.77/bin/catalina.sh run +``` + +> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validation certificates +> `siva-keystore.jks` (or `test-siva-keystore.jks` if `test` profile is used). Default location for this directory +> is application root or `$CATALINA_HOME`. To change this default behavior you should set environment variable +> `DSS_DATA_FOLDER` + +### How-to set WAR deployed SiVa `application.properties` + +SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. +To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. + +Contents of the `setenv.sh` file should look like: + +```bash +export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" +``` + +## How-to run tests + +Unit test are integral part of the SiVa code base. The tests are automatically executed every +time the application is built. The build will fail if any of the tests fail. + +To execute the tests from command line after application is built use: + +```bash +./mvnw verify +``` + +### How to run integration tests +Integration tests can be found [here](https://github.com/open-eid/SiVa-Test), and executing them requires running SiVa Web application instance. + +### How to run integration tests in docker +Before starting the docker instances, the `docker-compose.yaml` file must be modified. Add the following under the siva-webapp service to run the docker image with the test profile: + +``` +environment: + - "SPRING_PROFILES_ACTIVE=test" +``` + +### How to run load tests + +Load tests are available in the [SiVa-perftests](https://github.com/open-eid/SiVa-perftests) repository. + +## Open source software used to build SiVa + +Full list of open source Java libraries used to build SiVa can be found in our +[Open Source Software used page](OSS_USED.md) + +## Documentation + +Read [SiVa documentation](http://open-eid.github.io/SiVa/) diff --git a/docs/documentation_deployment_instructions.txt b/docs/documentation_deployment_instructions.txt index a88fee9da..227d6c4be 100644 --- a/docs/documentation_deployment_instructions.txt +++ b/docs/documentation_deployment_instructions.txt @@ -1,42 +1,42 @@ -Our documentation is written using [MkDocs](http://www.mkdocs.org/) static documentation site generator with [Material theme](https://squidfunk.github.io/mkdocs-material/) and [Markdown](https://daringfireball.net/projects/markdown/). - -System requirements -------------------- - -* **Python 3** - currently used version is 3.10 -* **pip** - Python package manager -* **Text Editor** - to edit Markdown documents (i.e [Haroopad](http://pad.haroopress.com/#)) - -Installing required software ------------------ - -### Ubuntu and Mac OS X - -Both Ubuntu and Mac OS X come `python` already installed (the version depends on OS) - -1. Install `pip` on Ubuntu 18.04 `sudo apt-get install python-pip` on Mac OS X `sudo easy_install pip` -2. Install `mkdocs` using [pip](https://pip.pypa.io/en/stable/): `pip install mkdocs` -3. Install material theme `pip install mkdocs-material` - -### Windows - -1. Install python. Download the installer from the official `python` homepage: and install -> **NOTE:** Starting with version 2.7.9 and onwards `pip` ships along with python, so there shouldn't be any need to install `pip` separately. -2. Install `mkdocs` using [pip](https://pip.pypa.io/en/stable/): `pip install mkdocs` -3. Install material theme `pip install mkdocs-material` - -PS! There can be a need to add the directory, were `mkdocs` and `mkdocs-material` were installed, manually to the PATH. - -Editing content ---------------- - -1. Edit markdown files inside the `docs` directory -2. Preview Your changes by issuing `mkdocs serve` and navigating to -3. Commit and push Your changes to `git` - -Deploying changes to GitHub pages ---------------------------------- - -1. Generate the static site `mkdocs build` -2. Deploy the generated site to GitHub Pages: `mkdocs gh-deploy` -3. You are done and can go check the updated documentation at: +Our documentation is written using [MkDocs](http://www.mkdocs.org/) static documentation site generator with [Material theme](https://squidfunk.github.io/mkdocs-material/) and [Markdown](https://daringfireball.net/projects/markdown/). + +System requirements +------------------- + +* **Python 3** - currently used version is 3.10 +* **pip** - Python package manager +* **Text Editor** - to edit Markdown documents (i.e [Haroopad](http://pad.haroopress.com/#)) + +Installing required software +----------------- + +### Ubuntu and Mac OS X + +Both Ubuntu and Mac OS X come `python` already installed (the version depends on OS) + +1. Install `pip` on Ubuntu 18.04 `sudo apt-get install python-pip` on Mac OS X `sudo easy_install pip` +2. Install `mkdocs` using [pip](https://pip.pypa.io/en/stable/): `pip install mkdocs` +3. Install material theme `pip install mkdocs-material` + +### Windows + +1. Install python. Download the installer from the official `python` homepage: and install +> **NOTE:** Starting with version 2.7.9 and onwards `pip` ships along with python, so there shouldn't be any need to install `pip` separately. +2. Install `mkdocs` using [pip](https://pip.pypa.io/en/stable/): `pip install mkdocs` +3. Install material theme `pip install mkdocs-material` + +PS! There can be a need to add the directory, were `mkdocs` and `mkdocs-material` were installed, manually to the PATH. + +Editing content +--------------- + +1. Edit markdown files inside the `docs` directory +2. Preview Your changes by issuing `mkdocs serve` and navigating to +3. Commit and push Your changes to `git` + +Deploying changes to GitHub pages +--------------------------------- + +1. Generate the static site `mkdocs build` +2. Deploy the generated site to GitHub Pages: `mkdocs gh-deploy` +3. You are done and can go check the updated documentation at: diff --git a/docs/index.md b/docs/index.md index 1b58389b5..55d2db819 100755 --- a/docs/index.md +++ b/docs/index.md @@ -1,37 +1,37 @@ - - - - -SiVa is digital signature validation web service that provides JSON -API to validate following file types: - - * Estonian DDOC containers - * Estonian BDOC containers with `TimeMark` and `TimeStamp` signatures - * Estonian ASiCS containers with time stamp tokens - * ETSI standard based ASiCE and ASiCS containers - * ETSI standard based XAdES, CAdES and PAdES signatures - * ETSI standard based XAdES signatures with datafiles in hashcode form - -Main purpose of this documentation is to give overview what SiVa is, how it is built and provide information for deploying the service and integrating with the service. - -## SiVa architecture document sections overview - -Below list will give You an overview of what each section of the -SiVa architecture document will cover: - -* [**Definitions**](siva3/definitions) - defines and explains most common concepts used in SiVa documentation -* [**Background**](siva3/background) - gives overview what SiVa is and - it's main features. -* [**Structure and activities**](siva3/structure_and_activities) - gives overview of - main SiVa subsystems and base validation Java libraries - used for different validation services -* [**Interfaces**](siva3/interfaces) - Description of SiVa - JSON API request and response -* [**Deployment**](siva3/deployment) - gives general overview of - servers required when deploying SiVa validation web service - into production -* [**Quality Assurance**](siva3/qa_strategy) - overview of quality assurance strategy and testing -* [**Roadmap**](siva3/roadmap) - info about planned releases - + + + + +SiVa is digital signature validation web service that provides JSON +API to validate following file types: + + * Estonian DDOC containers + * Estonian BDOC containers with `TimeMark` and `TimeStamp` signatures + * Estonian ASiCS containers with time stamp tokens + * ETSI standard based ASiCE and ASiCS containers + * ETSI standard based XAdES, CAdES and PAdES signatures + * ETSI standard based XAdES signatures with datafiles in hashcode form + +Main purpose of this documentation is to give overview what SiVa is, how it is built and provide information for deploying the service and integrating with the service. + +## SiVa architecture document sections overview + +Below list will give You an overview of what each section of the +SiVa architecture document will cover: + +* [**Definitions**](siva3/definitions) - defines and explains most common concepts used in SiVa documentation +* [**Background**](siva3/background) - gives overview what SiVa is and + it's main features. +* [**Structure and activities**](siva3/structure_and_activities) - gives overview of + main SiVa subsystems and base validation Java libraries + used for different validation services +* [**Interfaces**](siva3/interfaces) - Description of SiVa + JSON API request and response +* [**Deployment**](siva3/deployment) - gives general overview of + servers required when deploying SiVa validation web service + into production +* [**Quality Assurance**](siva3/qa_strategy) - overview of quality assurance strategy and testing +* [**Roadmap**](siva3/roadmap) - info about planned releases + diff --git a/docs/siva/appendix/validation_policy.md b/docs/siva/appendix/validation_policy.md index b139e1e60..46cbd2c27 100644 --- a/docs/siva/appendix/validation_policy.md +++ b/docs/siva/appendix/validation_policy.md @@ -1,186 +1,186 @@ -# SiVa Signature Validation Policy - -## Introduction -This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). - -### Versioning - -Different policy versions may be used by the service in the following conditions: - -* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; -* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); -* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. -* for later reference, previous versions of validation policy documents should remain available for the Service's users. - -The following validation policy versions are supported in SiVa service: - -1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](validation_policy/#POLv1) -2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](validation_policy/#POLv2) - -### General principles of SiVa validation policies - -1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. -* All rules described for electronic signatures also apply for electronic seals and digital stamps. -* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: - * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). - * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). - -!!! note - When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. - - -## SiVA Signature Validation Policy - Version 1 (POLv1) - - -### Description -Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -``` - -### POLv1 validation constraints -1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: - * Qualified Certificate (QC) requirement - * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * Signer certificate may or may not comply with SSCD/QSCD criteria. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. -* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section - - -## SiVA Signature Validation Policy - Version 2 (POLv2) - - -### Description -Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -``` - -### POLv2 validation constraints - -1. The signature must be a Qualified Electronic Signature (QES), taking account of the following requirements: - * Qualified Certificate (QC) requirement - * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. - * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * Signer certificate must comply with SSCD/QSCD criteria. - * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. - * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: - * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). -* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section - - -## Common validation constraints (POLv1, POLv2) - - -### General constraints - -1. The validation result returned by SiVa determines whether a signature is technically valid and also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** -2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. - -### Signature format constraints - - -1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: - - * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures - * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures - * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures - * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures - * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) - -### Base libraries' constraints - -1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: - - * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. - * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate ASiC-E/XAdES signatures that conform with BDOC 2.1 digital signature format - * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate PAdES signatures - * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. - -### Baseline Profile constraints -1. The signature must comply with Baseline Profile of the respective signature format: - * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) - * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) -2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. -3. The following table describes supported Baseline Profile levels, according to signature formats: - -| Signature format | BASELINE_B_BES | BASELINE_B_EPES | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | -|--|--|--|--|--|--|--| -|**BDOC** | NOK | NOK | NOK| **OK** | **OK** | **OK** | -|**X-Road signature (simple form)** | NOK | NOK | NOK | **OK** | NOK | NOK | -|**X-Road signature (batch signature)** | **OK** | **OK** | NOK | NOK | NOK | NOK | -|**PAdES** | NOK | NOK | NOK | **OK** | NOK | **OK** | -|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | NOK | **OK** | NOK | -|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | NOK | **OK** | NOK | - -Legend: - -* OK - the respective Baseline Profile level is supported and acceptable. -* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. - - -### X.509 validation constraints - -1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). - - -### Cryptographic algorithm constraints -1. Hash algorithm constraints: - * In case of BDOC and PAdES formats: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. -* Asymmetric cryptographic algorithm contraints: - * RSA and ECC cryptographic algorithms are supported - * In case of BDOC and PAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. - -### Trust anchor constraints -1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. -* Trust Anchors are: - * In case of BDOC, PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). - * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. - * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. - - -### Revocation data constraints -1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. -* The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960). -* No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. -* Checking revocation of certificates regarded as Trust Anchors: - * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. - * In case of BDOC, PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. - - -### Signer certificate's revocation freshness constraints -1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. -* In case of BDOC 2.1 BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: - * The revocation data must be issued after the signature time-stamp production time. - * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 15 minutes then a validation warning is returned. - * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. -* In case of PAdES signatures, the default DSS base library's revocation freshness check is used. - - -### Trusted signing time constraints -1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: - * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. - * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. - * In case of basic signature (BASELINE_B_BES or BASELINE_B_EPES level) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. - - -### BDOC/ASiC-E container spceific requirements -1. File extension - * ".asice", ".sce" and ".bdoc" file extensions are supported during signature validation. -* Only one signature shall be stored in one signatures.xml file. -* All signatures in the container must sign all of the data files. -* All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. -* Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. -* Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". -* "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). - - +# SiVa Signature Validation Policy + +## Introduction +This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). + +### Versioning + +Different policy versions may be used by the service in the following conditions: + +* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; +* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); +* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. +* for later reference, previous versions of validation policy documents should remain available for the Service's users. + +The following validation policy versions are supported in SiVa service: + +1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](validation_policy/#POLv1) +2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](validation_policy/#POLv2) + +### General principles of SiVa validation policies + +1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. +* All rules described for electronic signatures also apply for electronic seals and digital stamps. +* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: + * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). + * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). + +!!! note + When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. + + +## SiVA Signature Validation Policy - Version 1 (POLv1) + + +### Description +Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +``` + +### POLv1 validation constraints +1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: + * Qualified Certificate (QC) requirement + * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * Signer certificate may or may not comply with SSCD/QSCD criteria. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. +* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section + + +## SiVA Signature Validation Policy - Version 2 (POLv2) + + +### Description +Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +``` + +### POLv2 validation constraints + +1. The signature must be a Qualified Electronic Signature (QES), taking account of the following requirements: + * Qualified Certificate (QC) requirement + * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. + * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * Signer certificate must comply with SSCD/QSCD criteria. + * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. + * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: + * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). +* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section + + +## Common validation constraints (POLv1, POLv2) + + +### General constraints + +1. The validation result returned by SiVa determines whether a signature is technically valid and also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** +2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. + +### Signature format constraints + + +1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: + + * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures + * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures + * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures + * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures + * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) + +### Base libraries' constraints + +1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: + + * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. + * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate ASiC-E/XAdES signatures that conform with BDOC 2.1 digital signature format + * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate PAdES signatures + * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. + +### Baseline Profile constraints +1. The signature must comply with Baseline Profile of the respective signature format: + * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) + * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) +2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. +3. The following table describes supported Baseline Profile levels, according to signature formats: + +| Signature format | BASELINE_B_BES | BASELINE_B_EPES | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | +|--|--|--|--|--|--|--| +|**BDOC** | NOK | NOK | NOK| **OK** | **OK** | **OK** | +|**X-Road signature (simple form)** | NOK | NOK | NOK | **OK** | NOK | NOK | +|**X-Road signature (batch signature)** | **OK** | **OK** | NOK | NOK | NOK | NOK | +|**PAdES** | NOK | NOK | NOK | **OK** | NOK | **OK** | +|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | NOK | **OK** | NOK | +|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | NOK | **OK** | NOK | + +Legend: + +* OK - the respective Baseline Profile level is supported and acceptable. +* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. + + +### X.509 validation constraints + +1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). + + +### Cryptographic algorithm constraints +1. Hash algorithm constraints: + * In case of BDOC and PAdES formats: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. +* Asymmetric cryptographic algorithm contraints: + * RSA and ECC cryptographic algorithms are supported + * In case of BDOC and PAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. + +### Trust anchor constraints +1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. +* Trust Anchors are: + * In case of BDOC, PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). + * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. + * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. + + +### Revocation data constraints +1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. +* The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960). +* No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. +* Checking revocation of certificates regarded as Trust Anchors: + * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. + * In case of BDOC, PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. + + +### Signer certificate's revocation freshness constraints +1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. +* In case of BDOC 2.1 BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: + * The revocation data must be issued after the signature time-stamp production time. + * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 15 minutes then a validation warning is returned. + * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. +* In case of PAdES signatures, the default DSS base library's revocation freshness check is used. + + +### Trusted signing time constraints +1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: + * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. + * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. + * In case of basic signature (BASELINE_B_BES or BASELINE_B_EPES level) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. + + +### BDOC/ASiC-E container spceific requirements +1. File extension + * ".asice", ".sce" and ".bdoc" file extensions are supported during signature validation. +* Only one signature shall be stored in one signatures.xml file. +* All signatures in the container must sign all of the data files. +* All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. +* Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. +* Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". +* "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). + + diff --git a/docs/siva/v2/systemintegrators_guide.md b/docs/siva/v2/systemintegrators_guide.md index 91129356c..c587a53fa 100644 --- a/docs/siva/v2/systemintegrators_guide.md +++ b/docs/siva/v2/systemintegrators_guide.md @@ -1,550 +1,550 @@ -This guide describes how to integrate SiVa service with other applications. -The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. - -### System requirements - -Following are the minimum requirements to build and deploy SiVa webapps as a service: - -* Java 8 or above Oracle JVM is supported -* Git version control system version 1.8 or above is recommended -* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM -* Minimum 1 processor core -* Open internet connection -* 1GB of free disk space -* Supported operating system is Ubuntu 14.04 LTS - -## Building - -### Building SiVa webapps on Ubuntu 16.04 - -First we need to install Git and Java SDK 8 by issuing below commands: - -```bash -sudo apt-get update -sudo apt-get install git -y -sudo apt-get install default-jdk -y -``` - -Next we need to clone the SiVa Github repository: - -```bash -git clone https://github.com/open-eid/SiVa.git --branch master -``` - -Final step is building the SiVa project using Maven Wrapper - -```bash -cd SiVa -./mvnw clean install -``` - -!!! note - The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the - required dependencies - -To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. -The last lines of build output should look very similar to below image: - -```text -[INFO] Reactor Summary: -[INFO] -[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 25.258 s] -[INFO] validation-services-parent ......................... SUCCESS [ 0.479 s] -[INFO] validation-commons ................................. SUCCESS [01:45 min] -[INFO] tsl-loader ......................................... SUCCESS [ 16.507 s] -[INFO] PDF Validation Service ............................. SUCCESS [ 42.263 s] -[INFO] BDOC Validation Service ............................ SUCCESS [ 58.864 s] -[INFO] DDOC Validation Service ............................ SUCCESS [ 9.929 s] -[INFO] xroad-validation-service ........................... SUCCESS [ 5.664 s] -[INFO] SIVa webapp and other core modules ................. SUCCESS [ 0.315 s] -[INFO] SiVa validation service proxy ...................... SUCCESS [ 43.098 s] -[INFO] siva-webapp ........................................ SUCCESS [04:06 min] -[INFO] SiVa Web Service integration tests ................. SUCCESS [03:41 min] -[INFO] siva-distribution .................................. SUCCESS [ 56.941 s] -[INFO] ------------------------------------------------------------------------ -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 18:30 min -[INFO] Finished at: 2016-07-22T13:40:31+00:00 -[INFO] Final Memory: 80M/250M -[INFO] ------------------------------------------------------------------------ -``` - - -## Deploying - -### OPTION 1 - starting webapps from command line -SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the -project by issuing below commands: - -**First start the Siva webapp** - -```bash -./siva-parent/siva-webapp/target/siva-webapp-3.1.0.jar -``` - -**Second we need to start X-road validation webapp** - -```bash -./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.1.0.jar -``` - -The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. -Easiest way to test out validation is run SiVa demo application. - -**Start the [SiVa Demo Application](https://github.com/open-eid/SiVa-demo-application)** - -```bash -./target/siva-demo-application-3.1.0.jar -``` - -Now point Your browser to URL: - - -### OPTION 2 - running webapps as systemd services - -Maven build generates executable JAR files. This means web container and all its dependencies are package inside -single JAR file. It makes a lot easier to deploy it into servers. - -Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. - -For that we first need to create service file: -```bash -vim siva-webapp.service -``` - -Inside it we need to paste below text. You need to change few things in service setup file. - -* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` -* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. -* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file - -```ini -[Unit] -Description=siva-webapp -After=syslog.target - -[Service] -User=root -ExecStart=/var/apps/siva-webapp.jar -Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 -SuccessExitStatus=143 - -[Install] -WantedBy=multi-user.target -``` - -Save and close the `siva-webapp.service` file. -Next we need to move `siva-webapp-3.1.0.jar` into newly created `/var/apps` directory and rename to -JAR file to `siva-webapp.jar`. match - -!!! note - The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file - -```bash -sudo mkdir /var/apps -sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.1.0.jar /var/apps/siva-webapp.jar -``` - -Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. -Then we are ready to start the `siva-webapp` service. - -```bash -sudo cp siva-webapp.service /lib/systemd/system -sudo systemctl start siva-webapp -``` - -Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below -command. - -```bash -systemctl status siva-webapp -``` - -It should print out similar to below picture: - -``` -● siva-webapp.service - siva-webapp - Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) - Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago - Main PID: 15965 (siva-webapp.jar) - Tasks: 34 - Memory: 429.6M - CPU: 2min 5.721s - CGroup: /system.slice/siva-webapp.service - ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar - └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar - -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -``` - -### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) - -> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet -> containers also possible container application libraries conflicts - -> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version -> conflicts. - -> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - -the http connector parameter `maxPostSize` should be configured with the desired limit. - -> **NOTE 4**: The war file must be deployed to Tomcat ROOT. - -First we need to download Tomcat web servlet container as of the writing latest version available in version 7 branch is 7.0.77. We will download it with `wget` - -```bash -wget http://www-eu.apache.org/dist/tomcat/tomcat-7/v7.0.70/bin/apache-tomcat-7.0.70.tar.gz -``` - -Unpack it somewhere: - -```bash -tar xf apache-tomcat-7.0.70.tar.gz -``` - -Now we should build the WAR file. We have created helper script with all the correct Maven parameters. - -```bash -./war-build.sh -``` - -> **NOTE** The script will skip running the integration tests when building WAR files - -Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. - -```bash -cp siva-parent/siva-webapp/target/siva-webapp-3.1.0.war apache-tomcat-7.0.70/webapps -./apache-tomcat-7.0.77/bin/catalina.sh run -``` - -> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates -> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change -> this default behavior you should set environment variable `DSS_DATA_FOLDER` - -### How-to set WAR deployed SiVa `application.properties` - -SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. -To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. - -Contents of the `setenv.sh` file should look like: - -```bash -export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" -``` - - -### Smoke testing your deployed system - -**Step 1**. Install HTTPIE -`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed -and started correctly on our server. - -If you have Python and its package manager `pip` installed. Then You can issue below command: - -```bash -pip install httpie -``` - -**Step 2**. Download a sample JSON request file. - -```bash -http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdoc_pass.json -``` - -**Step 3**. After successful download issue below command in same directory where you downloaded the file using -the command below. - -```bash -http POST http://10.211.55.9:8080/validate < bdoc_pass.json -``` -**Step 4**. Verify the output. The output of previous command should look like below screenshot. Look for `signatureCount` and -`validSignatureCount` they **must** be equal. - - -![HTTPIE output validation](../../img/siva/siva-output.png) - - -## Logging - -By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. - -For example, adding application.properties to classpath with the **logging.config** property -```bash -logging.config=/path/to/logback.xml -``` - -## Statistics - -For every report validated, a statistical report is composed that collects the following data: - -| Data | Description | -| ----- | ----- | -| Validation duration | The time it takes to process an incoming request - measured in milliseconds | -| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, PAdES or ASiC-E (BatchSignature) ) | -| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | -| Total signatures count | The value of the `signaturesCount` element in the validation report -| Valid signatures count | The value of the `validSignaturesCount` element in the validation report -| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | -| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | -| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | - -There are two channels where this information is sent: - -1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. - -2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. - -The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) - -## Monitoring - -SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. - -!!! note - Note that this endpoint is disabled by default. - - -The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. - -* **Enabling and disabling the monitoring endpoint** - -To enable the endpoint, use the following configuration parameter: -```bash -endpoints.health.enabled=true -``` - -* **Customizing external service health indicators** - -The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. - -Demo webapp and Siva webapp also include additional information about the health of their dependent services. -These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. - -However, using the following parameters, these links can be overridden: - -| Property | Description | -| -------- | ----------- | -|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| -|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| -|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| - -For example: -```bash -endpoints.health.links[0].name=linkToXroad -endpoints.health.links[0].url=http://localhost:7777/monitoring/health -endpoints.health.links[0].timeout=1000 -``` - -!!! note - The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . - - --------------------------------------------------------------------------------------- -## Configuration parameters - -All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. -However, all the properties can be overridden on the service or embedded web server level, if necessary. - -By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. -Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. - -For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: -```bash -server.port=8080 -``` - -Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: -```bash -server.max-http-post-size: 13981016 -``` - -See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot - -### Siva webapp parameters - -* Updating TSL - -| Property | Description | -| -------- | ----------- | -| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| -| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| -| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| -| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 * * ?**
| -| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| -| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| -| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| - -!!! note - Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). - -!!! note - TSL is currently used only by PDF and BDOC validators - - -* Forward to custom X-road webapp instance - -| Property | Description | -| ------ | ----------- | -| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| - -* Collecting statistics with Google Analytics - -| Property | Description | -| -------- | ----------- | -| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| -| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| -| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| -| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| - -* BDOC validation parameters - -| Property | Description | -| -------- | ----------- | -| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| - -Customizing BDOC validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.bdoc.signaturePolicy.policies[0].name=POLv1 -siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml - -siva.bdoc.signaturePolicy.policies[1].name=POLv2 -siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml - -siva.bdoc.signaturePolicy.defaultPolicy=POLv1 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* PadES validation - customize validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.pdf.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.pdf.signaturePolicy.policies[0].name=POLv1 -siva.pdf.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.pdf.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.pdf.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml - -siva.pdf.signaturePolicy.policies[1].name=POLv2 -siva.pdf.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.pdf.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -siva.pdf.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml - -siva.pdf.signaturePolicy.defaultPolicy=POLv1 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* DDOC validation - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| - -Customizing DDOC validation policies: - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.ddoc.signaturePolicy.policies[0].name=POLv1 -siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml - -siva.ddoc.signaturePolicy.policies[1].name=POLv2 -siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -siva.ddoc.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml - -siva.ddoc.signaturePolicy.defaultPolicy=POLv1 -``` -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -### X-road validation webapp parameters - -* X-road validation - -| Property | Description | -| -------- | ----------- | -|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| - - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.ddoc.signaturePolicy.policies[0].name=POLv1 -siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml - -siva.ddoc.signaturePolicy.defaultPolicy= POLv1 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) -!!! note - By default, X-road validation currently supports only POLv1 - - -### Demo webapp parameters - -* Linking to SiVa webapp - -| Property | Description | -| -------- | ----------- | -|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| -|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| -|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| - - -## FAQ - ---------------------------------------------------- -Q: SiVa webapp API-s require that you specify the document type? Is it possible to detect the container/file type automatically based on the provided file. - -A: There is a demo webapp that provides a reference solution. See `ee.openeid.siva.sample.siva.ValidationRequestUtils` for reference. - ---------------------------------------------------- +This guide describes how to integrate SiVa service with other applications. +The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. + +### System requirements + +Following are the minimum requirements to build and deploy SiVa webapps as a service: + +* Java 8 or above Oracle JVM is supported +* Git version control system version 1.8 or above is recommended +* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM +* Minimum 1 processor core +* Open internet connection +* 1GB of free disk space +* Supported operating system is Ubuntu 14.04 LTS + +## Building + +### Building SiVa webapps on Ubuntu 16.04 + +First we need to install Git and Java SDK 8 by issuing below commands: + +```bash +sudo apt-get update +sudo apt-get install git -y +sudo apt-get install default-jdk -y +``` + +Next we need to clone the SiVa Github repository: + +```bash +git clone https://github.com/open-eid/SiVa.git --branch master +``` + +Final step is building the SiVa project using Maven Wrapper + +```bash +cd SiVa +./mvnw clean install +``` + +!!! note + The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the + required dependencies + +To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. +The last lines of build output should look very similar to below image: + +```text +[INFO] Reactor Summary: +[INFO] +[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 25.258 s] +[INFO] validation-services-parent ......................... SUCCESS [ 0.479 s] +[INFO] validation-commons ................................. SUCCESS [01:45 min] +[INFO] tsl-loader ......................................... SUCCESS [ 16.507 s] +[INFO] PDF Validation Service ............................. SUCCESS [ 42.263 s] +[INFO] BDOC Validation Service ............................ SUCCESS [ 58.864 s] +[INFO] DDOC Validation Service ............................ SUCCESS [ 9.929 s] +[INFO] xroad-validation-service ........................... SUCCESS [ 5.664 s] +[INFO] SIVa webapp and other core modules ................. SUCCESS [ 0.315 s] +[INFO] SiVa validation service proxy ...................... SUCCESS [ 43.098 s] +[INFO] siva-webapp ........................................ SUCCESS [04:06 min] +[INFO] SiVa Web Service integration tests ................. SUCCESS [03:41 min] +[INFO] siva-distribution .................................. SUCCESS [ 56.941 s] +[INFO] ------------------------------------------------------------------------ +[INFO] BUILD SUCCESS +[INFO] ------------------------------------------------------------------------ +[INFO] Total time: 18:30 min +[INFO] Finished at: 2016-07-22T13:40:31+00:00 +[INFO] Final Memory: 80M/250M +[INFO] ------------------------------------------------------------------------ +``` + + +## Deploying + +### OPTION 1 - starting webapps from command line +SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the +project by issuing below commands: + +**First start the Siva webapp** + +```bash +./siva-parent/siva-webapp/target/siva-webapp-3.1.0.jar +``` + +**Second we need to start X-road validation webapp** + +```bash +./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.1.0.jar +``` + +The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. +Easiest way to test out validation is run SiVa demo application. + +**Start the [SiVa Demo Application](https://github.com/open-eid/SiVa-demo-application)** + +```bash +./target/siva-demo-application-3.1.0.jar +``` + +Now point Your browser to URL: + + +### OPTION 2 - running webapps as systemd services + +Maven build generates executable JAR files. This means web container and all its dependencies are package inside +single JAR file. It makes a lot easier to deploy it into servers. + +Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. + +For that we first need to create service file: +```bash +vim siva-webapp.service +``` + +Inside it we need to paste below text. You need to change few things in service setup file. + +* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` +* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. +* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file + +```ini +[Unit] +Description=siva-webapp +After=syslog.target + +[Service] +User=root +ExecStart=/var/apps/siva-webapp.jar +Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 +SuccessExitStatus=143 + +[Install] +WantedBy=multi-user.target +``` + +Save and close the `siva-webapp.service` file. +Next we need to move `siva-webapp-3.1.0.jar` into newly created `/var/apps` directory and rename to +JAR file to `siva-webapp.jar`. match + +!!! note + The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file + +```bash +sudo mkdir /var/apps +sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.1.0.jar /var/apps/siva-webapp.jar +``` + +Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. +Then we are ready to start the `siva-webapp` service. + +```bash +sudo cp siva-webapp.service /lib/systemd/system +sudo systemctl start siva-webapp +``` + +Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below +command. + +```bash +systemctl status siva-webapp +``` + +It should print out similar to below picture: + +``` +● siva-webapp.service - siva-webapp + Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) + Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago + Main PID: 15965 (siva-webapp.jar) + Tasks: 34 + Memory: 429.6M + CPU: 2min 5.721s + CGroup: /system.slice/siva-webapp.service + ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar + └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar + +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +``` + +### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) + +> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet +> containers also possible container application libraries conflicts + +> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version +> conflicts. + +> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - +the http connector parameter `maxPostSize` should be configured with the desired limit. + +> **NOTE 4**: The war file must be deployed to Tomcat ROOT. + +First we need to download Tomcat web servlet container as of the writing latest version available in version 7 branch is 7.0.77. We will download it with `wget` + +```bash +wget http://www-eu.apache.org/dist/tomcat/tomcat-7/v7.0.70/bin/apache-tomcat-7.0.70.tar.gz +``` + +Unpack it somewhere: + +```bash +tar xf apache-tomcat-7.0.70.tar.gz +``` + +Now we should build the WAR file. We have created helper script with all the correct Maven parameters. + +```bash +./war-build.sh +``` + +> **NOTE** The script will skip running the integration tests when building WAR files + +Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. + +```bash +cp siva-parent/siva-webapp/target/siva-webapp-3.1.0.war apache-tomcat-7.0.70/webapps +./apache-tomcat-7.0.77/bin/catalina.sh run +``` + +> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates +> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change +> this default behavior you should set environment variable `DSS_DATA_FOLDER` + +### How-to set WAR deployed SiVa `application.properties` + +SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. +To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. + +Contents of the `setenv.sh` file should look like: + +```bash +export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" +``` + + +### Smoke testing your deployed system + +**Step 1**. Install HTTPIE +`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed +and started correctly on our server. + +If you have Python and its package manager `pip` installed. Then You can issue below command: + +```bash +pip install httpie +``` + +**Step 2**. Download a sample JSON request file. + +```bash +http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdoc_pass.json +``` + +**Step 3**. After successful download issue below command in same directory where you downloaded the file using +the command below. + +```bash +http POST http://10.211.55.9:8080/validate < bdoc_pass.json +``` +**Step 4**. Verify the output. The output of previous command should look like below screenshot. Look for `signatureCount` and +`validSignatureCount` they **must** be equal. + + +![HTTPIE output validation](../../img/siva/siva-output.png) + + +## Logging + +By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. + +For example, adding application.properties to classpath with the **logging.config** property +```bash +logging.config=/path/to/logback.xml +``` + +## Statistics + +For every report validated, a statistical report is composed that collects the following data: + +| Data | Description | +| ----- | ----- | +| Validation duration | The time it takes to process an incoming request - measured in milliseconds | +| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, PAdES or ASiC-E (BatchSignature) ) | +| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | +| Total signatures count | The value of the `signaturesCount` element in the validation report +| Valid signatures count | The value of the `validSignaturesCount` element in the validation report +| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | +| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | +| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | + +There are two channels where this information is sent: + +1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. + +2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. + +The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) + +## Monitoring + +SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. + +!!! note + Note that this endpoint is disabled by default. + + +The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. + +* **Enabling and disabling the monitoring endpoint** + +To enable the endpoint, use the following configuration parameter: +```bash +endpoints.health.enabled=true +``` + +* **Customizing external service health indicators** + +The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. + +Demo webapp and Siva webapp also include additional information about the health of their dependent services. +These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. + +However, using the following parameters, these links can be overridden: + +| Property | Description | +| -------- | ----------- | +|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| +|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| +|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| + +For example: +```bash +endpoints.health.links[0].name=linkToXroad +endpoints.health.links[0].url=http://localhost:7777/monitoring/health +endpoints.health.links[0].timeout=1000 +``` + +!!! note + The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . + + +-------------------------------------------------------------------------------------- +## Configuration parameters + +All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. +However, all the properties can be overridden on the service or embedded web server level, if necessary. + +By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. +Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. + +For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: +```bash +server.port=8080 +``` + +Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: +```bash +server.max-http-post-size: 13981016 +``` + +See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot + +### Siva webapp parameters + +* Updating TSL + +| Property | Description | +| -------- | ----------- | +| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| +| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| +| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| +| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 * * ?**
| +| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| +| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| +| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| + +!!! note + Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). + +!!! note + TSL is currently used only by PDF and BDOC validators + + +* Forward to custom X-road webapp instance + +| Property | Description | +| ------ | ----------- | +| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| + +* Collecting statistics with Google Analytics + +| Property | Description | +| -------- | ----------- | +| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| +| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| +| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| +| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| + +* BDOC validation parameters + +| Property | Description | +| -------- | ----------- | +| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| + +Customizing BDOC validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.bdoc.signaturePolicy.policies[0].name=POLv1 +siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml + +siva.bdoc.signaturePolicy.policies[1].name=POLv2 +siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml + +siva.bdoc.signaturePolicy.defaultPolicy=POLv1 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* PadES validation - customize validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.pdf.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.pdf.signaturePolicy.policies[0].name=POLv1 +siva.pdf.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.pdf.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.pdf.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml + +siva.pdf.signaturePolicy.policies[1].name=POLv2 +siva.pdf.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.pdf.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +siva.pdf.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml + +siva.pdf.signaturePolicy.defaultPolicy=POLv1 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* DDOC validation + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| + +Customizing DDOC validation policies: + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.ddoc.signaturePolicy.policies[0].name=POLv1 +siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml + +siva.ddoc.signaturePolicy.policies[1].name=POLv2 +siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +siva.ddoc.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml + +siva.ddoc.signaturePolicy.defaultPolicy=POLv1 +``` +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +### X-road validation webapp parameters + +* X-road validation + +| Property | Description | +| -------- | ----------- | +|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| + + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.ddoc.signaturePolicy.policies[0].name=POLv1 +siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml + +siva.ddoc.signaturePolicy.defaultPolicy= POLv1 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) +!!! note + By default, X-road validation currently supports only POLv1 + + +### Demo webapp parameters + +* Linking to SiVa webapp + +| Property | Description | +| -------- | ----------- | +|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| +|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| +|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| + + +## FAQ + +--------------------------------------------------- +Q: SiVa webapp API-s require that you specify the document type? Is it possible to detect the container/file type automatically based on the provided file. + +A: There is a demo webapp that provides a reference solution. See `ee.openeid.siva.sample.siva.ValidationRequestUtils` for reference. + +--------------------------------------------------- diff --git a/docs/siva2/appendix/known_issues.md b/docs/siva2/appendix/known_issues.md index 3fcd1b2b4..fac0a7411 100644 --- a/docs/siva2/appendix/known_issues.md +++ b/docs/siva2/appendix/known_issues.md @@ -1,4 +1,4 @@ - - -## Known issues + + +## Known issues All known issues should be reported and managed under GitHub project [issues section](https://github.com/open-eid/SiVa/issues) \ No newline at end of file diff --git a/docs/siva2/appendix/validation_policy.md b/docs/siva2/appendix/validation_policy.md index 8a7a73da5..437e0de94 100644 --- a/docs/siva2/appendix/validation_policy.md +++ b/docs/siva2/appendix/validation_policy.md @@ -1,211 +1,211 @@ -# SiVa Signature Validation Policy - -## Introduction -This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). - -### Versioning - -Different policy versions may be used by the service in the following conditions: - -* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; -* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); -* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. -* for later reference, previous versions of validation policy documents should remain available for the Service's users. - -The following validation policy versions are supported in SiVa 2.0 service: - -1. [**SiVA Signature Validation Policy - Version 3 (POLv3)**](validation_policy/#POLv3) -2. [**SiVA Signature Validation Policy - Version 4 (POLv4)**](validation_policy/#POLv4) - -The following validation policy versions are marked as obsolete in SiVa 2.0 service: - -1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1) -2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2) - -### General principles of SiVa validation policies - -1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. -* All rules described for electronic signatures also apply for electronic seals and digital stamps if not explicitly stated otherwise. -* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: - * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). - * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). - -!!! note - When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. - - -## SiVA Signature Validation Policy - Version 3 (POLv3) - - -### Description -Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv3 -``` - -### POLv3 validation constraints -1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: - * Qualified Certificate (QC) requirement - * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * Signer certificate may or may not comply with SSCD/QSCD criteria. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. -* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section - - -## SiVA Signature Validation Policy - Version 4 (POLv4) - - -### Description -Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 -``` - -### POLv4 validation constraints - -1. The requirements for the signature level depend on signature type. - * Qualified Certificate (QC) requirement - * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. - * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * In case of Signatures, signer certificate should comply with SSCD/QSCD criteria, otherwise warning is returned. - * In case of Seals, there is no requirement for SSCD/QSCD criteria. - * If it is not possible to determine the signature type, it must comply with SSCD/QSCD criteria. - * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. - * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: - * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). -* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section - - -## Common validation constraints (POLv3, POLv4) - - -### General constraints - -1. The validation result returned by SiVa determines whether a signature is technically valid and depending of a container type also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** -2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. - -### Signature format constraints - - -1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: - - * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures - * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures - * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures - * [XAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf) signatures - * [CAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.01.01_60/en_31912201v010101p.pdf) signatures - * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures - * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) - -### Base libraries' constraints - - -1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: - - * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. - * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate signatures in BDOC 2.1 format - * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - is used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. - * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate all other signature formats than mentioned above - -### Baseline Profile constraints -1. The signature must comply with Baseline Profile of the respective signature format: - * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) - * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) - * [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) -2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. -3. The following table describes supported Baseline Profile levels, according to signature formats: - -| Signature format | BASELINE_B | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | -|--|--|--|--|--|--| -|**BDOC** | NOK | NOK| **OK** | **OK** | **OK** | -|**X-Road signature (simple form)** | NOK | NOK | **OK** | NOK | NOK | -|**X-Road signature (batch signature)** | **OK** | NOK | NOK | NOK | NOK | -|**PAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**XAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**CAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | **OK** | NOK | -|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | **OK** | NOK | - -Legend: - -* OK - the respective Baseline Profile level is supported and acceptable. -* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. - - -### X.509 validation constraints - -1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). - - -### Cryptographic algorithm constraints -1. Hash algorithm constraints: - * In case of BDOC format: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. -2. Asymmetric cryptographic algorithm contraints: - * RSA and ECC cryptographic algorithms are supported - * In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. - -### Trust anchor constraints -1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. -2. Trust Anchors are: - * In case of XAdES/CAdES/PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). - * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. - * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. - - -### Revocation data constraints -1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. -2. The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960) or as a Certificate Revocation List. -3. No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. -4. Checking revocation of certificates regarded as Trust Anchors: - * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. - * In case of XAdES/CAdES/PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. - - -### Signer certificate's revocation freshness constraints -1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. -2. In case of XAdES/CAdES/PAdES BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: - * In case of OCSP responce if difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. If the difference is more than 15 minutes and less then 24h then a validation warning is returned. - * In case of Certificate Revocation List the signature time-stamp's production time (genTime field) must be within validity range of the CRL (between thisUpdate and nextUpdate) - - -### Trusted signing time constraints -1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: - * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. - * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. - * In case of basic signature (BASELINE_B) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. - - -### BDOC container spceific requirements -The BDOC container must conform with [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) standard. -1. File extension - * ".bdoc" file extension is supported during signature validation. -2. Only one signature shall be stored in one signatures.xml file. -3. All signatures in the container must sign all of the data files. -4. All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. -5. Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. -6. Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". -7. "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). - -### ASICE container spceific requirements -The ASICE container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) standard. -1. Warning is returned when signatures in the container do not sign all of the data files. -2. Manifest file must be present. - -### ASICS container spceific requirements -The service supports both signature and Time Stamp Token (TST) based ASIC-S containers. Evidence record based containers are not supported. The ASIC-S container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) and [ETSI EN 319 162-2](http://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf) standards. - -1. Manifest file can not be present in case of signature based ASIC-S containers. -2. Only one TimeStampToken per container is supported. No AsicArchiveManifest.xml support. -3. No TSL based verification of certificates is done in case of TimeStampToken based containers. - - - +# SiVa Signature Validation Policy + +## Introduction +This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). + +### Versioning + +Different policy versions may be used by the service in the following conditions: + +* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; +* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); +* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. +* for later reference, previous versions of validation policy documents should remain available for the Service's users. + +The following validation policy versions are supported in SiVa 2.0 service: + +1. [**SiVA Signature Validation Policy - Version 3 (POLv3)**](validation_policy/#POLv3) +2. [**SiVA Signature Validation Policy - Version 4 (POLv4)**](validation_policy/#POLv4) + +The following validation policy versions are marked as obsolete in SiVa 2.0 service: + +1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1) +2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2) + +### General principles of SiVa validation policies + +1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. +* All rules described for electronic signatures also apply for electronic seals and digital stamps if not explicitly stated otherwise. +* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: + * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). + * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). + +!!! note + When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. + + +## SiVA Signature Validation Policy - Version 3 (POLv3) + + +### Description +Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv3 +``` + +### POLv3 validation constraints +1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: + * Qualified Certificate (QC) requirement + * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * Signer certificate may or may not comply with SSCD/QSCD criteria. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. +* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section + + +## SiVA Signature Validation Policy - Version 4 (POLv4) + + +### Description +Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 +``` + +### POLv4 validation constraints + +1. The requirements for the signature level depend on signature type. + * Qualified Certificate (QC) requirement + * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. + * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * In case of Signatures, signer certificate should comply with SSCD/QSCD criteria, otherwise warning is returned. + * In case of Seals, there is no requirement for SSCD/QSCD criteria. + * If it is not possible to determine the signature type, it must comply with SSCD/QSCD criteria. + * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. + * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: + * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). +* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section + + +## Common validation constraints (POLv3, POLv4) + + +### General constraints + +1. The validation result returned by SiVa determines whether a signature is technically valid and depending of a container type also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** +2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. + +### Signature format constraints + + +1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: + + * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures + * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures + * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures + * [XAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf) signatures + * [CAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.01.01_60/en_31912201v010101p.pdf) signatures + * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures + * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) + +### Base libraries' constraints + + +1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: + + * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. + * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate signatures in BDOC 2.1 format + * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - is used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. + * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate all other signature formats than mentioned above + +### Baseline Profile constraints +1. The signature must comply with Baseline Profile of the respective signature format: + * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) + * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) + * [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) +2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. +3. The following table describes supported Baseline Profile levels, according to signature formats: + +| Signature format | BASELINE_B | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | +|--|--|--|--|--|--| +|**BDOC** | NOK | NOK| **OK** | **OK** | **OK** | +|**X-Road signature (simple form)** | NOK | NOK | **OK** | NOK | NOK | +|**X-Road signature (batch signature)** | **OK** | NOK | NOK | NOK | NOK | +|**PAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**XAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**CAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | **OK** | NOK | +|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | **OK** | NOK | + +Legend: + +* OK - the respective Baseline Profile level is supported and acceptable. +* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. + + +### X.509 validation constraints + +1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). + + +### Cryptographic algorithm constraints +1. Hash algorithm constraints: + * In case of BDOC format: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. +2. Asymmetric cryptographic algorithm contraints: + * RSA and ECC cryptographic algorithms are supported + * In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. + +### Trust anchor constraints +1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. +2. Trust Anchors are: + * In case of XAdES/CAdES/PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). + * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. + * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. + + +### Revocation data constraints +1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. +2. The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960) or as a Certificate Revocation List. +3. No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. +4. Checking revocation of certificates regarded as Trust Anchors: + * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. + * In case of XAdES/CAdES/PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. + + +### Signer certificate's revocation freshness constraints +1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. +2. In case of XAdES/CAdES/PAdES BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: + * In case of OCSP responce if difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. If the difference is more than 15 minutes and less then 24h then a validation warning is returned. + * In case of Certificate Revocation List the signature time-stamp's production time (genTime field) must be within validity range of the CRL (between thisUpdate and nextUpdate) + + +### Trusted signing time constraints +1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: + * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. + * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. + * In case of basic signature (BASELINE_B) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. + + +### BDOC container spceific requirements +The BDOC container must conform with [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) standard. +1. File extension + * ".bdoc" file extension is supported during signature validation. +2. Only one signature shall be stored in one signatures.xml file. +3. All signatures in the container must sign all of the data files. +4. All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. +5. Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. +6. Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". +7. "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). + +### ASICE container spceific requirements +The ASICE container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) standard. +1. Warning is returned when signatures in the container do not sign all of the data files. +2. Manifest file must be present. + +### ASICS container spceific requirements +The service supports both signature and Time Stamp Token (TST) based ASIC-S containers. Evidence record based containers are not supported. The ASIC-S container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) and [ETSI EN 319 162-2](http://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf) standards. + +1. Manifest file can not be present in case of signature based ASIC-S containers. +2. Only one TimeStampToken per container is supported. No AsicArchiveManifest.xml support. +3. No TSL based verification of certificates is done in case of TimeStampToken based containers. + + + diff --git a/docs/siva2/component_diagram.md b/docs/siva2/component_diagram.md index 1cf4ead19..468234c96 100644 --- a/docs/siva2/component_diagram.md +++ b/docs/siva2/component_diagram.md @@ -1,94 +1,94 @@ - - -![SiVa component diagram](../img/siva/siva_module_diagram.png) - -## Web API - -Web API is standard Spring Boot Web application module inside SiVa webapp it will take in JSON or SOAP requests sent by -systems that are integrated with SiVa web service API. The incoming requests will be converted to **SiVa Proxy Module** -Java request objects. Web API module also does basic validation of incoming requests. Checking that all the required -fields are present and document type is correct. - -When validation has been completed by proxy selected validation service the returned qualified validation report Java object -will be marshalled based on incoming request to JSON or SOAP and returned to client that requested the validation. - -### External configuration resources - -* Optionally SiVa webapp can load in configuration file (i.e application.yml) at application startup time. - Configuration file can control Spring Boot configuration options in addition to SiVa application - specific options. -* Optionally SiVa webapp can also load in logging configuration options - -## Validation proxy service - -**Validation proxy service** or validation service selector is Spring Boot module that will take the Web API sent -request object and try to find matching validation service based on the `documentType`inside the request object. -When matching validation service have been found the proxy request is converted to validation request and sent to matched -validation service. - -When no matching validation service has not been found exception is raised and error object is -returned to Web API module. On successful validation the qualified validation report Java object sent from validation -service is returned to Web API module. - -!!! note - Validation services can be added dynamically to SiVa by conforming to pattern `documentType + "ValidationService"` and new - validation service module must be Maven dependency of `siva-validation-proxy`. Example - would be `BDOCValidationService`. - -## Validation reporting service - -**Validation reporting service** is optional module that can be turned on or off using configuration file. It's Spring Boot module and -main purpose is to collect data about: incoming request, validation reports and errors that have been reported during validation process. - -When HTTP authentication header have been set the reporting service will also collect its and adds to required statistics reports. - -After the report object have been created the data will be sent to configured reporting service. SiVa is preconfigured to work with -Google Analytics. - -## TSL Loader - -TSL loader loads in contents of TSL file from given URL in online mode or from directory when -using offline mode in predefined interval. - -## Validation services - -All validation services use different Java library to validate given document in request. The used validation -library is described in each of the validation service section. - -Common process that all validation services do with proxy forwarded validation process is: - -* Convert the Base64 encoded document into `InputStream` byte array -* Check that given document is correct format (i.e valid BDOC). If not then error is thrown and - validation process is terminated. -* After validation of signatures has been completed the validation service starts to build - qualified validation report -* Validation report is created even validation `FAILED` or ended with `INDETERMINATE` result - -### PDF Validation service - -PDF or PaDES as known in DSS validation service uses [Digidoc4J DSS fork Java library](https://github.com/open-eid/sd-dss) PaDES validation -functionality using the validation policy that complies with Estonian laws and regulations. - -Configurable functionality: - -* Possibility to add additional validation policies using SiVa `application.yml` configuration section. - -### BDOC validation service - -BDOC for ASiC compliant containers both TM and TS will latest Maven released **DigiDoc4J** library - -### DDOC Validation service - -DDOC for previous generation digitally signed files will use latest Maven release of **JDigiDoc** - -### X-Road validation service - -X-Road containers are similar to ASiCE containers but are **not** valid ASiCE containers. There we could not use DSS nor DigiDoc4J provided -ASiCE validation functionality but need to X-Road developed `asicverifier` Java command line utility to validate these containers. - -Source code for `asicverifier` can be found in [GitHub xroad-public repository](https://github.com/ria-ee/X-Road/tree/master/src/asicverifier)*[]: -`Asicverfier` has been integrated into SiVa as Java library. Making possible to use all the Java libraries packaged into `asicverifier` fat JAR. - -Configurable functionality: - -* In SiVa configuration `application.yml` file You can define alternative location for `globalconf` directory to be loaded in using input stream + + +![SiVa component diagram](../img/siva/siva_module_diagram.png) + +## Web API + +Web API is standard Spring Boot Web application module inside SiVa webapp it will take in JSON or SOAP requests sent by +systems that are integrated with SiVa web service API. The incoming requests will be converted to **SiVa Proxy Module** +Java request objects. Web API module also does basic validation of incoming requests. Checking that all the required +fields are present and document type is correct. + +When validation has been completed by proxy selected validation service the returned qualified validation report Java object +will be marshalled based on incoming request to JSON or SOAP and returned to client that requested the validation. + +### External configuration resources + +* Optionally SiVa webapp can load in configuration file (i.e application.yml) at application startup time. + Configuration file can control Spring Boot configuration options in addition to SiVa application + specific options. +* Optionally SiVa webapp can also load in logging configuration options + +## Validation proxy service + +**Validation proxy service** or validation service selector is Spring Boot module that will take the Web API sent +request object and try to find matching validation service based on the `documentType`inside the request object. +When matching validation service have been found the proxy request is converted to validation request and sent to matched +validation service. + +When no matching validation service has not been found exception is raised and error object is +returned to Web API module. On successful validation the qualified validation report Java object sent from validation +service is returned to Web API module. + +!!! note + Validation services can be added dynamically to SiVa by conforming to pattern `documentType + "ValidationService"` and new + validation service module must be Maven dependency of `siva-validation-proxy`. Example + would be `BDOCValidationService`. + +## Validation reporting service + +**Validation reporting service** is optional module that can be turned on or off using configuration file. It's Spring Boot module and +main purpose is to collect data about: incoming request, validation reports and errors that have been reported during validation process. + +When HTTP authentication header have been set the reporting service will also collect its and adds to required statistics reports. + +After the report object have been created the data will be sent to configured reporting service. SiVa is preconfigured to work with +Google Analytics. + +## TSL Loader + +TSL loader loads in contents of TSL file from given URL in online mode or from directory when +using offline mode in predefined interval. + +## Validation services + +All validation services use different Java library to validate given document in request. The used validation +library is described in each of the validation service section. + +Common process that all validation services do with proxy forwarded validation process is: + +* Convert the Base64 encoded document into `InputStream` byte array +* Check that given document is correct format (i.e valid BDOC). If not then error is thrown and + validation process is terminated. +* After validation of signatures has been completed the validation service starts to build + qualified validation report +* Validation report is created even validation `FAILED` or ended with `INDETERMINATE` result + +### PDF Validation service + +PDF or PaDES as known in DSS validation service uses [Digidoc4J DSS fork Java library](https://github.com/open-eid/sd-dss) PaDES validation +functionality using the validation policy that complies with Estonian laws and regulations. + +Configurable functionality: + +* Possibility to add additional validation policies using SiVa `application.yml` configuration section. + +### BDOC validation service + +BDOC for ASiC compliant containers both TM and TS will latest Maven released **DigiDoc4J** library + +### DDOC Validation service + +DDOC for previous generation digitally signed files will use latest Maven release of **JDigiDoc** + +### X-Road validation service + +X-Road containers are similar to ASiCE containers but are **not** valid ASiCE containers. There we could not use DSS nor DigiDoc4J provided +ASiCE validation functionality but need to X-Road developed `asicverifier` Java command line utility to validate these containers. + +Source code for `asicverifier` can be found in [GitHub xroad-public repository](https://github.com/ria-ee/X-Road/tree/master/src/asicverifier)*[]: +`Asicverfier` has been integrated into SiVa as Java library. Making possible to use all the Java libraries packaged into `asicverifier` fat JAR. + +Configurable functionality: + +* In SiVa configuration `application.yml` file You can define alternative location for `globalconf` directory to be loaded in using input stream diff --git a/docs/siva2/definitions.md b/docs/siva2/definitions.md index bbac7bcac..b609712b2 100644 --- a/docs/siva2/definitions.md +++ b/docs/siva2/definitions.md @@ -1,43 +1,43 @@ - - -BDOC -: A digital signature format that was created in order to replace the DDOC (DigiDoc) digital signature format that is specific to Estonia. - -DDOC -: A format of digitally signed files based on the ETSI TS 101 903 Standard that is called ‘XML Advanced Electronic Signatures (XAdES)’. The standard describes the structure of digitally signed documents on various levels of incorporation of additional validity verification information. DigiDoc corresponds to the XAdES profile ‘XAdES-X-L’. - -DSS -: Digital Signature Services is Java library to sign and validate European digital signature formats - -Fat JAR -: The fat JAR is the JAR, which contains classes from all the libraries, on which your project depends and, - the classes of built project. - -JAR -: Java Archive is a package file format typically used to aggregate many Java class files and associated metadata - and resources (text, images, etc.) into one file to distribute application software or libraries on the Java platform. - -JVM -: The Java Virtual Machine is the runtime engine of the Java Platform, which - allows any program written in Java or other language compiled into Java bytecode to run on any - computer that has a native JVM. - -Linux -: an operating system, based on UNIX, that runs on many different hardware platforms and whose source - code is available to the public. - -PDF -: Portable document format is a file format that provides an electronic image of text or text and graphics that - looks like a printed document and can be viewed, printed, and electronically transmitted. - -SiVa -: is RESTful web service providing digital signature validation services for BDOC, DDOC, PDF and X-Road - files - -Spring Boot -: is a framework from the team at Pivotal, designed to simplify the bootstrapping and development of a new - Spring application. The framework takes an opinionated approach to configuration, freeing developers from the - need to define boilerplate configuration - -X-Road + + +BDOC +: A digital signature format that was created in order to replace the DDOC (DigiDoc) digital signature format that is specific to Estonia. + +DDOC +: A format of digitally signed files based on the ETSI TS 101 903 Standard that is called ‘XML Advanced Electronic Signatures (XAdES)’. The standard describes the structure of digitally signed documents on various levels of incorporation of additional validity verification information. DigiDoc corresponds to the XAdES profile ‘XAdES-X-L’. + +DSS +: Digital Signature Services is Java library to sign and validate European digital signature formats + +Fat JAR +: The fat JAR is the JAR, which contains classes from all the libraries, on which your project depends and, + the classes of built project. + +JAR +: Java Archive is a package file format typically used to aggregate many Java class files and associated metadata + and resources (text, images, etc.) into one file to distribute application software or libraries on the Java platform. + +JVM +: The Java Virtual Machine is the runtime engine of the Java Platform, which + allows any program written in Java or other language compiled into Java bytecode to run on any + computer that has a native JVM. + +Linux +: an operating system, based on UNIX, that runs on many different hardware platforms and whose source + code is available to the public. + +PDF +: Portable document format is a file format that provides an electronic image of text or text and graphics that + looks like a printed document and can be viewed, printed, and electronically transmitted. + +SiVa +: is RESTful web service providing digital signature validation services for BDOC, DDOC, PDF and X-Road + files + +Spring Boot +: is a framework from the team at Pivotal, designed to simplify the bootstrapping and development of a new + Spring application. The framework takes an opinionated approach to configuration, freeing developers from the + need to define boilerplate configuration + +X-Road : X-Road, the data exchange layer for information systems, is a technological and organizational environment enabling a secure Internet-based data exchange between information systems. \ No newline at end of file diff --git a/docs/siva2/deployment.md b/docs/siva2/deployment.md index cb7616169..d830e7bcc 100644 --- a/docs/siva2/deployment.md +++ b/docs/siva2/deployment.md @@ -1,20 +1,20 @@ -The deployment view of the architecture describes the various physical nodes in the most typical configuration for SiVa service provider. - -![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) - -### Nodes - -In the following section, a description of each network node element is described in detail. - -| Node | Setup description | -| ------ | ----------- | -| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used.| -| **Siva server** | Two separate services are set up to run on SiVa server: the **SiVa webapp** itself and the **X-road validation webapp**, to provide X-road support
  • SiVa webapp

SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.

There also should be separate user created to run executalbe JAR as Linux service.

Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service)
  • X-road validation webapp

SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081

Note that X-Road separate installation is required to avoid BouncyCastle library version conflicts and class loader issues.| -| **X-road security server** | A standard X-road security server setup. The SiVa validation service wsdl has to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaton (see the [official installation instructions](https://www.ria.ee/en/x-road-instructions.html#v6)).| -| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation.
  • Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service.
| - -### Horizontal scaling - -Neither the **Siva webapp**, **X-road validation webapp**, nor **Demo wbapp** persist their state in sessions between requests. Therefore it is possible to install multiple instances of these services behind respective load balancers. - - +The deployment view of the architecture describes the various physical nodes in the most typical configuration for SiVa service provider. + +![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) + +### Nodes + +In the following section, a description of each network node element is described in detail. + +| Node | Setup description | +| ------ | ----------- | +| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used.| +| **Siva server** | Two separate services are set up to run on SiVa server: the **SiVa webapp** itself and the **X-road validation webapp**, to provide X-road support
  • SiVa webapp

SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.

There also should be separate user created to run executalbe JAR as Linux service.

Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service)
  • X-road validation webapp

SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081

Note that X-Road separate installation is required to avoid BouncyCastle library version conflicts and class loader issues.| +| **X-road security server** | A standard X-road security server setup. The SiVa validation service wsdl has to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaton (see the [official installation instructions](https://www.ria.ee/en/x-road-instructions.html#v6)).| +| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation.
  • Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service.
| + +### Horizontal scaling + +Neither the **Siva webapp**, **X-road validation webapp**, nor **Demo wbapp** persist their state in sessions between requests. Therefore it is possible to install multiple instances of these services behind respective load balancers. + + diff --git a/docs/siva2/deployment_view.md b/docs/siva2/deployment_view.md index ba021290d..a27566681 100644 --- a/docs/siva2/deployment_view.md +++ b/docs/siva2/deployment_view.md @@ -1,34 +1,34 @@ - - -![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) - -## Load balancer - -Load balancer can distribute traffic between SiVa nodes when there is more then one instance running. -SiVa do not set any specific requirements for load balancer but in diagram the Nginx reverse proxy option is used. - -## SiVa web application - -SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are -packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable -if its not already. - -There also should be separate user created to run executalbe JAR as Linux service. - -Read more about running -[Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service) - -## SiVa X-Road validation service - -SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux -service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081 - -X-Road separate installation is required to avoid BouncyCastle libraries version conflicts and class loader -issues. - -## Security server - -Into XRoad v6 security server the SiVa validation service will be registered to provide service to other organisations -using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaiton. - - + + +![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) + +## Load balancer + +Load balancer can distribute traffic between SiVa nodes when there is more then one instance running. +SiVa do not set any specific requirements for load balancer but in diagram the Nginx reverse proxy option is used. + +## SiVa web application + +SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are +packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable +if its not already. + +There also should be separate user created to run executalbe JAR as Linux service. + +Read more about running +[Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service) + +## SiVa X-Road validation service + +SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux +service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081 + +X-Road separate installation is required to avoid BouncyCastle libraries version conflicts and class loader +issues. + +## Security server + +Into XRoad v6 security server the SiVa validation service will be registered to provide service to other organisations +using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaiton. + + diff --git a/docs/siva2/interfaces.md b/docs/siva2/interfaces.md index 989cb0482..23f90fa19 100644 --- a/docs/siva2/interfaces.md +++ b/docs/siva2/interfaces.md @@ -1,829 +1,829 @@ - - -In this section the SiVa external interfaces are described. For information of internal components and their interfaces, please refer to [**Structure and activities**](structure_and_activities). - -SiVa service provides **REST JSON** and **SOAP** interfaces that enable the service users to: - -* Request validation of signatures in a digitally signed document (i.e. signature container like BDOC,ASiC-E/PDF/...); -* Request validation of signature with providing data file hashes. -* Receive a response with the validation result of all the signatures in the document. -* Request datafiles inside of DDOC container -* Receive datafiles from DDOC container - -SiVa service SOAP interface supports X-Road v6. However, it is optional whether to integrate SiVa service using X-Road or using "plain" SOAP interface. This document only describes the SiVa service part of the interface, for the X-Road specifics visit Riigi Infosüsteemi Amet [webpage](https://www.ria.ee/ee/x-tee.html). - -In the following subsections, the SiVa validation request and response interfaces are described in detail. - -## Validation request interface - - -** REST JSON Endpoint ** - -``` -POST https:///validate -``` - -** SOAP Endpoint ** -``` -POST https:///soap/validationWebService/validateDocument -``` - -** SOAP WSDL ** -``` -POST https:///soap/validationWebService/validateDocument?wsdl -``` - -### Validation request parameters - -Validation request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-------------|----------------| -| document | Document | + | String | Base64 encoded string of digitally signed document to be validated | -| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.bdoc), max length 255 characters. | -| documentType | DocumentType | - | String | If not present document type is determined automatically based on the file extension used in the filename. This parameter is necessary to differentiate XROAD ASIC-E containers from standard ASIC-E containers.
**Possible values:**
XROAD - for documents created in the [X-Road](https://www.ria.ee/en/x-road.html) information system, see also [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) of the signature format. | -| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | -| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | - -### Sample JSON request with mandatory parameters - -```json -{ - "filename":"sample.bdoc", - "document":"PD94bWwgdmVyc2lvbj0iMS4...." -} -``` -### Sample JSON request with all parameters - -```json -{ - "filename":"sample.asice", - "document":"PD94bWwgdmVyc2lvbj0iMS4....", - "documentType":"XROAD", - "signaturePolicy":"POLv3", - "reportType":"Detailed" -} -``` - -### Sample SOAP request - -```xml - - - - - - PD94bWwgdmVyc2lvbj0iMS4.... - sample.asice - XROAD - POLv3 - Detailed - - - - -``` - -## Validation request interface for hashcode - -Hashcode XAdES validation is supported for **REST JSON** and **SOAP** interfaces. - -** REST JSON Endpoint ** - -``` -POST https:///validateHashcode -``` - -** SOAP Endpoint ** -``` -POST https:///soap/hashcodeValidationWebService -``` - -** SOAP WSDL ** -``` -POST https:///soap/hashcodeValidationWebService?wsdl -``` - -### Validation request parameters - -Validation request parameters for JSON interface are described in the table below. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|----------------|-------------| -| signatureFile | SignatureFile | + | String | Base64 encoded string of XAdES document to be validated | -| filename | Filename | + | String | File name of the XAdES document (i.e. signature0.xml). Only XML files supported. | -| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | -| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | -| datafiles | DataFiles | + | Array | Array containing the information for datafiles that signature is covering | -| datafiles[0] | DataFile | + | Object | Object containing data file information | -| datafiles.filename | Filename | + | String | File name of the hashed data file, max length 255 characters. | -| datafiles.hashAlgo | HashAlgo | + | String | Hash algorithm used for hashing the data file (must match with algorithm in signature file). Accepted values are dependant of validation policy | -| datafiles.hash | Hash | + | String | Data file hash in Base64 encoded format. | - -### Sample JSON request with mandatory parameters - -```json -{ - "signatureFile": "PD94bWwgdmVyc2lvbj0iMS4...." - "filename": "signature0.xml", - "datafiles": [{ - "filename": "test.pdf", - "hashAlgo": "SHA256", - "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" - }] -} -``` -### Sample JSON request with all parameters and multiple datafiles - -```json -{ - "signatureFile":"sample.asice", - "filename":"PD94bWwgdmVyc2lvbj0iMS4....", - "signaturePolicy":"POLv3", - "reportType":"Detailed", - "datafiles": [{ - "filename": "test.pdf", - "hashAlgo": "SHA256", - "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" - }, - { - "filename": "test2.pdf", - "hashAlgo": "SHA256", - "hash": "IucjUcbRo9Rke0bZLiHc23SSasw9pSrSPr7LKln1EiI=" - }] -} -``` - -### Sample SOAP request with mandatory parameters - -```xml - - - - - PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... - signature.xml - - - test.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - - - - -``` -### Sample SOAP request with all parameters and multiple datafiles - -```xml - - - - - PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... - signature.xml - Simple - POLv4 - - - test.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - test2.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - test3.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - - - - -``` - -## Validation response interface -The signature validation report (i.e. the validation response) for JSON and SOAP interfaces depends on what type of validation report was requested. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva2/appendix/wsdl). - -### Validation response parameters Simple Report (successful scenario) - -General structure of validation response. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-----------------|-------------| -| validationReport | ValidationReport | + | Object | Object containing SIVA validation report | -| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion | - -Structure of validationConclusion block - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-----------------|-------------| -| policy | Policy | + | Object | Object containing information of the SiVa signature validation policy that was used for validation. | -| policy.policyName | Policy.PolicyName | + | String | Name of the validation policy | -| policy. policyDescription | Policy. PolicyDescription | + | String | Short description of the validation policy. | -| policy.policyUrl | Policy.PolicyUrl | + | String | URL where the signature validation policy document can be downloaded. The validation policy document shall include information about validation of all the document formats, including the different validation policies that are used in case of different file formats and base libraries. | -| signaturesCount | SignaturesCount | + | Number | Number of signatures found inside digitally signed file. | -| validSignaturesCount | ValidSignaturesCount | + | Number | Signatures count that have validated to `TOTAL-PASSED`. See also `Signature.Indication` field. | -| validationLevel | ValidationLevel | - | Date | Validation process against what the document is validated, only applicable on DSS based validations.
**Possible values:**
ARCHIVAL_DATA| -| validationTime | ValidationTime | + | Date | Time of validating the signature by the service. | -| validationWarnings | ValidationWarnings | - | Array | Array of SiVa validation warnings that do not affect the overall validation result. See also `signatures.warnings` parameter. | -| validationWarnings[0] | ValidationWarning | + | Object | Object containing the warning. | -| validationWarnings[0]. content | ValidationWarning. Content| + | String | Description of the warning. | -| validatedDocument | ValidatedDocument | + | Object | Object containing information about validated document. | -| validatedDocument. filename | ValidatedDocument. Filename | + | String | Digitally signed document's file name. | -| validatedDocument. fileHashInHex | ValidatedDocument. FileHashInHex | - | String | Calculated hash in hex of validated document. | -| validatedDocument. hashAlgo | ValidatedDocument. HashAlgo | - | String | Hash algorithm used. | -| signatureForm | SignatureForm | - | String | Format (and optionally version) of the digitally signed document container.
In case of documents in [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) format, the "hashcode" suffix is used to denote that the container was validated in [hashcode mode](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode), i.e. without original data files.
**Possible values:**
DIGIDOC_XML_1.0
DIGIDOC_XML_1.0_hashcode
DIGIDOC_XML_1.1
DIGIDOC_XML_1.1_hashcode
DIGIDOC_XML_1.2
DIGIDOC_XML_1.2_hashcode
DIGIDOC_XML_1.3
DIGIDOC_XML_1.3_hashcode
ASiC_E - used in case of all ASIC-E ([BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf)) documents and X-Road simple containers that don't use batch time-stamping (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_E_batchsignature - used in case of X-Road containers with batch signature (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_S - used in case of all ASIC-S documents | -| signatures | Signatures | - | Array | Collection of signatures found in digitally signed document | -| signatures[0] | Signature | + | Object | Signature information object | -| signatures[0]. claimedSigningTime | Signature. ClaimedSigningTime | + | Date | Claimed signing time, i.e. signer's computer time during signature creation | -| signatures[0].id | Signature.Id | + | String | Signature ID attribute | -| signatures[0].indication | Signature.Indication | + | String | Overall result of the signature's validation process, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 5: Status indications of the signature validation process".
Note that the validation results of different signatures in one signed document (signature container) may vary.
See also `validSignaturesCount` and `SignaturesCount` fields.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED
INDETERMINATE | -| signatures[0]. subIndication | Signature. SubIndication | - | String | Additional subindication in case of failed or indeterminate validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics" | -| signatures[0].errors | Signature.Errors | - | Array | Information about validation error(s), array of error messages. | -| signatures[0].errors[0] | Signature.Errors. Error | + | Object | Object containing the error | -| signatures[0].errors[0]. content | Signature.Errors. Error.Content | + | String | Error message, as returned by the base library that was used for signature validation. | -| signatures[0].info | Signature.Info | - | Object | Object containing trusted signing time information. | -| signatures[0].info. bestSignatureTime | Signature.Info. BestSignatureTime | + | Date | Time value that is regarded as trusted signing time, denoting the earliest time when it can be trusted by the validation application (because proven by some Proof-of-Existence present in the signature) that a signature has existed.
The source of the value depends on the signature profile (see also `SignatureFormat` parameter):
- Signature with time-mark (LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature.
- Signature with time-stamp (LT or LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature.
- Signature with BES or EPES level - the value is empty, i.e. there is no trusted signing time value available. | -| signatures[0]. signatureFormat | Signature. SignatureFormat | + | String | Format and profile (according to Baseline Profile) of the signature. See [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf), [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) and [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) for detailed description of the Baseline Profile levels. Levels that are accepted in SiVa validation policy are described in [SiVa signature validation policy](/siva/appendix/validation_policy)
**Possible values:**
XAdES_BASELINE_B
XAdES_BASELINE_B_BES
XAdES_BASELINE_B_EPES
XAdES_BASELINE_T
XAdES_BASELINE_LT - long-term level XAdES signature where time-stamp is used as a assertion of trusted signing time
XAdES_BASELINE_LT_TM - long-term level XAdES signature where time-mark is used as a assertion of trusted signing time. Used in case of [BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) signatures with time-mark profile and [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) signatures.
XAdES_BASELINE_LTA
CAdES_BASELINE_B
CAdES_BASELINE_T
CAdES_BASELINE_LT
CAdES_BASELINE_LTA
PAdES_BASELINE_B
PAdES_BASELINE_T
PAdES_BASELINE_LT
PAdES_BASELINE_LTA | -| signatures[0]. signatureLevel | Signature. SignatureLevel | - |String | Legal level of the signature, according to Regulation (EU) No 910/2014.
- **Possible values on positive validation result:**
QESIG
QESEAL
QES
ADESIG_QC
ADESEAL_QC
ADES_QC
ADESIG
ADESEAL
ADES
- **Possible values on indeterminate validation result:**
prefix INDETERMINATE is added to the level described in positive result. For example INDETERMINATE_QESIG
- **Possible values on negative validation result:**
In addition to abovementioned
NOT_ADES_QC_QSCD
NOT_ADES_QC
NOT_ADES
NA
- In case of DIGIDOC-XML 1.0..1.3 formats, value is missing as the signature level is not checked by the JDigiDoc base library that is used for validation. However, the signatures can be indirectly regarded as QES level signatures, see also [SiVa Validation Policy](/siva2/appendix/validation_policy)
- In case of XROAD ASICE containers the value is missing as the asicverifier base library do not check the signature level.| -| signatures[0].signedBy | Signature.SignedBy | + | String | Signers name and identification number, i.e. value of the CN field of the signer's certificate | -| signatures[0]. signatureScopes | Signature. SignatureScopes | - | Array | Contains information of the original data that is covered by the signature. | -| signatures[0]. signatureScopes[0]. name | Signature. SignatureScopes. SignatureScope.Name | + | String | Name of the signature scope. | -| signatures[0]. signatureScopes[0]. scope | Signature. SignatureScopes. SignatureScope. Scope | + | String | Type of the signature scope. | -| signatures[0]. signatureScopes[0]. content | Signature. SignatureScopes. SignatureScope. Content | + | String | Description of the scope. | -| signatures[0]. warnings | Signature.Warnings | - | Array | Block of validation warnings that do not affect the overall validation result. | -| signatures[0]. warnings[0] | Signature.Warnings. Warning | + | Object | Object containing the warning | -| signatures[0]. warnings[0]. content | Signature.Warnings. Warning.Description | + | String | Warning description, as retuned by the base library that was used for validation. | -| timeStampTokens | TimeStampTokens | - | Array | Array containing the time stamp tokens | -| timeStampTokens[0]. | TimeStampToken | + | Object | Object containing the time stamp token (TST) | -| timeStampTokens[0]. indication | TimeStampToken. Indication | + | String | Result of the time stamp token validation.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED | -| timeStampTokens[0]. signedBy | TimeStampToken. SignedBy | + | String | Signer of the time stamp token. | -| timeStampTokens[0]. signedTime | TimeStampToken. SignedTime | + | String | Time when the time stamp token was given. | -| timeStampTokens[0]. error | TimeStampToken. Errors| - | Array | Errors returned in time stamp token validation. | -| timeStampTokens[0]. error[0] | Errors. Error | + | Object | Object containing the error. | -| timeStampTokens[0]. error[0]. content | Error. Content | + | String | Error description. | - -#### Sample JSON response Simple Report (successful scenario) - -```json -{"validationReport": -{"validationConclusion": { - "validationTime": "2017-11-07T08:14:07Z", - "signaturesCount": 1, - "validationLevel": "ARCHIVAL_DATA", - "validatedDocument": { - "filename": "ValidLiveSignature.asice", - "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", - "hashAlgo": "SHA-256" - }, - "validSignaturesCount": 1, - "signatures": [{ - "signatureFormat": "XAdES_BASELINE_LT", - "signedBy": "NURM,AARE,38211015222", - "claimedSigningTime": "2016-10-11T09:35:48Z", - "signatureLevel": "QESIG", - "warnings": [{"content": "The trusted list is not fresh!"}], - "signatureScopes": [{ - "scope": "FullSignatureScope", - "name": "Tresting.txt", - "content": "Full document" - }], - "id": "S0", - "indication": "TOTAL-PASSED", - "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} - }], - "policy": { - "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", - "policyUrl": "http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4", - "policyName": "POLv4" - }, - "signatureForm": "ASiC_E" -}}} -``` - -#### Sample SOAP response Simple Report (successful scenario) - -```xml - - - - - - - - Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - POLv4 - http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 - - 2017-11-07T08:14:07Z - - ValidLiveSignature.asice - 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 - SHA-256 - - ARCHIVAL_DATA - - ASiC_E - - - S0 - XAdES_BASELINE_LT - QESIG - NURM,AARE,38211015222 - TOTAL-PASSED - - - - - Tresting.txt - FullSignatureScope - Full document - - - 2016-10-11T09:35:48Z - - - The trusted list is not fresh! - - - - 2016-10-11T09:36:10Z - - - - 1 - 1 - - - - - -``` - -### Validation response parameters Detailed Report (successful scenario) - -General structure of validation response. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-----------------|-------------| -| validationReport | ValidationReport | + | Object | Object containing SIVA validation report. | -| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report. | -| validationReport. validationProcess | ValidationReport. ValidationProcess | - | Object | Object containing information of the validation process. This block is present only on DSS library based validations and is built on DSS detailed report. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/dss-documentation.adoc#validation-process). | -| validationReportSignature | ValidationReportSignature | - | String | Base64 string of ASIC-E container that includes the detailed report and is signed by the validation service provider | - -#### Sample JSON response Detailed Report (successful scenario). The report is shortened but gives general overview of structure. - -```json -{ - "validationReport": { - "validationProcess": { - "qmatrixBlock": { - "tlanalysis": [{ - "conclusion": {"indication": "PASSED"}, - "countryCode": "EU", - "constraint": [ - { - "name": { - "nameId": "QUAL_TL_FRESH", - "value": "Is the trusted list fresh ?" - }, - "status": "OK" - }, - ... - ] - }, - { - "conclusion": {"indication": "PASSED"}, - "countryCode": "EE", - "constraint": [{ - "name": { - "nameId": "QUAL_TL_FRESH", - "value": "Is the trusted list fresh ?" - }, - "status": "OK" - }, - ... - ] - } - ], - "signatureAnalysis": [{ - "conclusion": {"indication": "PASSED"}, - "signatureQualification": "QESIG", - "constraint": [{ - "name": { - "nameId": "QUAL_IS_ADES", - "value": "Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ?" - }, - "status": "OK" - }, - ... - ], - "id": "S0" - }] - }, - "basicBuildingBlocks": [{ - "conclusion": {"indication": "PASSED"}, - "cv": { - "conclusion": {"indication": "PASSED"}, - "constraint": [{ - "name": { - "nameId": "BBB_CV_IRDOF", - "value": "Is the reference data object(s) found?" - }, - "status": "OK" - }, - ... - ]}, - ... - "id": "1561CD6BEA97B0A72664067021330509894BE1EBA586D3057D77787E5F4180A4", - "type": "TIMESTAMP" - }, - ... - "signatures": [{ - "validationProcessArchivalData": { - "conclusion": {"indication": "PASSED"}, - "constraint": [{ - "name": { - "nameId": "ARCH_LTVV", - "value": "Is the result of the LTV validation process acceptable?" - }, - "status": "OK" - }]}, - ... - }, - "id": "S0", - "validationProcessLongTermData": { - "conclusion": {"indication": "PASSED"}, - "constraint": [{ - "name": { - "nameId": "LTV_ABSV", - "value": "Is the result of the Basic Validation Process acceptable?"}, - "status": "OK" - }, - ... - }]}}] - }, - "validationConclusion": { - "validationTime": "2017-11-07T09:20:18Z", - "signaturesCount": 1, - "validationLevel": "ARCHIVAL_DATA", - "validatedDocument": { - "filename": "ValidLiveSignature.asice", - "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", - "hashAlgo": "SHA-256" - }, - "validSignaturesCount": 1, - "signatures": [{ - "signatureFormat": "XAdES_BASELINE_LT", - "signedBy": "NURM,AARE,38211015222", - "claimedSigningTime": "2016-10-11T09:35:48Z", - "signatureLevel": "QESIG", - "signatureScopes": [{ - "scope": "FullSignatureScope", - "name": "Tresting.txt", - "content": "Full document" - }], - "id": "S0", - "indication": "TOTAL-PASSED", - "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} - }], - "policy": { - "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", - "policyUrl": "http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4", - "policyName": "POLv4" - }, - "signatureForm": "ASiC_E" - } - }, - "validationReportSignature": "UEsDBBQACAgIAIlaZ0sAA..." -} - -``` - -#### Sample SOAP response Simple Report (successful scenario) - -```xml - - - - - - - - Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - POLv4 - http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 - - 2017-11-07T09:20:18Z - - ValidLiveSignature.asice - 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 - SHA-256 - - ARCHIVAL_DATA - - ASiC-E - - - S0 - XAdES_BASELINE_LT - QESIG - NURM,AARE,38211015222 - TOTAL-PASSED - - - - - Tresting.txt - FullSignatureScope - Full document - - - 2016-10-11T09:35:48Z - - - 2016-10-11T09:36:10Z - - - - 1 - 1 - - - - - - Is the result of the Basic Validation Process conclusive? - OK - - - PASSED - - - ... - - - Is the result of the LTV validation process acceptable? - OK - - - PASSED - - - - ... - - - - Is the expected format found? - OK - - ... - - - Can the certificate chain be built till the trust anchor? - OK - - - - - ... - - Is the trusted list well signed ? - OK - - - PASSED - - - ... - - - Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ? - OK - - ... - - PASSED - - - - - - UEsDBBQACAgIAIlaZ0s... - - - - -``` - -### Sample JSON response (error situation) -In case of error (when validation report is not returned) status code 400 is returned together with following message body: - -```json -{"requestErrors": [{ - "message": "Document malformed or not matching documentType", - "key": "document" -}]} -``` - -### Sample SOAP response (error situation) - -```xml - - - - - soap:Server - Document malformed or not matching documentType - - - -``` - -## Data files request interface - - -** REST JSON Endpoint ** - -``` -POST https:///getDataFiles -``` - -** SOAP Endpoint ** -``` -POST https:///soap/dataFilesWebService/getDocumentDataFiles -``` - -** SOAP WSDL ** -``` -POST https:///soap/dataFilesWebService/getDocumentDataFiles?wsdl -``` - -### Data files request parameters - -Data files request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|----------------|-------------| -| document | Document | + | String | Base64 encoded string of digitally signed DDOC document | -| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.ddoc), max length 255 characters. Currently only DDOC file format is supported for this operation| - -### Sample JSON request - -```json -{ - "filename":"sample.ddoc", - "document":"PD94bWwgdmVyc2lvbj0iMS4...." -} -``` - - -### Sample SOAP request - -```xml - - - - - - PD94bWwgdmVyc2lvbj0iMS4wI... - sample.ddoc - - - - -``` - - -## Data files response interface - -### Data files response parameters (successful scenario) - -The data file extraction report (i.e. the data files response) for JSON and SOAP interfaces is described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). -SiVa returns all data files as they are extracted by JDigiDoc library in an as is form. No extra operations or validations are done. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|----------------|-------------| -| dataFiles | DataFiles | - | Array | Collection of data files found in digitally signed document | -| dataFiles[0] | DataFile | + | Object | Extracted data file object | -| dataFiles[0].fileName | DataFile.FileName | - | String | File name of the extracted data file | -| dataFiles[0].size | DataFile.Size | - | Long | Extracted data file size in bytes | -| dataFiles[0].base64 | DataFile.Base64 | - |String | Base64 encoded string of extracted data file | -| dataFiles[0].mimeType | DataFile.MimeType | - | String | MIME type of the extracted data file | - -### Sample JSON response (successful scenario) - -```json -{ -"dataFiles": [{ - "fileName": "Glitter-rock-4_gallery.jpg", - "size": 41114, - "base64": "/9j/4AAQSkZJ...", - "mimeType": "application/octet-stream" }] -} -``` - -### Sample SOAP response (successful scenario) - -```xml - - - - - - - - UCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUH... - Glitter-rock-4_gallery.jpg - application/octet-stream - 41114 - - - - - - -``` - -### Sample JSON response (error situation) -In case of error (when datafiles are not returned) status code 400 is returned together with following message body: - -```json -{"requestErrors": [{ - "message": "Invalid document type. Can only return data files for DDOC type containers.", - "key": "documentType" -}]} -``` - -### Sample SOAP response (error situation) - -```xml - - - - - soap:Client - Invalid document type. Can only return data files for DDOC type containers. - - - -``` - - - -## Service health monitoring - -SiVa webapps provide an interface for external monitoring tools (to periodically check the generic service health status). - -### The request -The monitoring endpoint is accessible via HTTP GET at **/monitoring/health** or **/monitoring/health.json** url. - -Sample request: -``` -GET https:///monitoring/health -``` - -### The response - -As a response, a JSON object is returned with the following information: - -| Field | Description | -| ---------| --------------- | -| status | General status of the webapp.
Possible values:
  • **DOWN** - when some of the dependent indicators status are down (ie when `link{number}.status` is DOWN, the overall service status is DOWN)
  • **UP** - the default value.
| -| health.status | Status of current webapp - constant value **UP** | -| health.webappName | The artifact name of the webapp. Taken from the MANIFEST.MF file (inside the jar/war file). | -| health.version | The release version fo the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | -| health.buildTime | Build date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') of the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | -| health.startTime | Webapp startup date and time (format yyyy-MM-dd'T'HH:mm:ss'Z')| -| health.currentTime | Current server date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') | -| link{number}.status | (OPTIONAL) Represents the status of a link to the external system that the webapp depends on.
  • **DOWN** when the webapp does not respond (within a specified timeout limit - default 10 seconds) or the response is in invalid format (default Spring boot actuator /health endpoint format is expected).
  • **UP** if the service responds with HTTP status code 200 and returns a valid JSON object with status "UP"
|) | -| link{number}.name | (OPTIONAL) Descriptive name for the link to the external system | - -Sample response: - -```json -{ - "status":"UP", - "health":{ - "status":"UP", - "webappName":"siva-demo-application", - "version":"3.1.0", - "buildTime":"2016-10-21T15:56:21Z", - "startTime":"2016-10-21T15:57:48Z", - "currentTime":"2016-10-21T15:58:39Z" - }, - "link1":{ - "status":"UP", - "name":"sivaService" - } -} -``` + + +In this section the SiVa external interfaces are described. For information of internal components and their interfaces, please refer to [**Structure and activities**](structure_and_activities). + +SiVa service provides **REST JSON** and **SOAP** interfaces that enable the service users to: + +* Request validation of signatures in a digitally signed document (i.e. signature container like BDOC,ASiC-E/PDF/...); +* Request validation of signature with providing data file hashes. +* Receive a response with the validation result of all the signatures in the document. +* Request datafiles inside of DDOC container +* Receive datafiles from DDOC container + +SiVa service SOAP interface supports X-Road v6. However, it is optional whether to integrate SiVa service using X-Road or using "plain" SOAP interface. This document only describes the SiVa service part of the interface, for the X-Road specifics visit Riigi Infosüsteemi Amet [webpage](https://www.ria.ee/ee/x-tee.html). + +In the following subsections, the SiVa validation request and response interfaces are described in detail. + +## Validation request interface + + +** REST JSON Endpoint ** + +``` +POST https:///validate +``` + +** SOAP Endpoint ** +``` +POST https:///soap/validationWebService/validateDocument +``` + +** SOAP WSDL ** +``` +POST https:///soap/validationWebService/validateDocument?wsdl +``` + +### Validation request parameters + +Validation request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-------------|----------------| +| document | Document | + | String | Base64 encoded string of digitally signed document to be validated | +| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.bdoc), max length 255 characters. | +| documentType | DocumentType | - | String | If not present document type is determined automatically based on the file extension used in the filename. This parameter is necessary to differentiate XROAD ASIC-E containers from standard ASIC-E containers.
**Possible values:**
XROAD - for documents created in the [X-Road](https://www.ria.ee/en/x-road.html) information system, see also [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) of the signature format. | +| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | +| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | + +### Sample JSON request with mandatory parameters + +```json +{ + "filename":"sample.bdoc", + "document":"PD94bWwgdmVyc2lvbj0iMS4...." +} +``` +### Sample JSON request with all parameters + +```json +{ + "filename":"sample.asice", + "document":"PD94bWwgdmVyc2lvbj0iMS4....", + "documentType":"XROAD", + "signaturePolicy":"POLv3", + "reportType":"Detailed" +} +``` + +### Sample SOAP request + +```xml + + + + + + PD94bWwgdmVyc2lvbj0iMS4.... + sample.asice + XROAD + POLv3 + Detailed + + + + +``` + +## Validation request interface for hashcode + +Hashcode XAdES validation is supported for **REST JSON** and **SOAP** interfaces. + +** REST JSON Endpoint ** + +``` +POST https:///validateHashcode +``` + +** SOAP Endpoint ** +``` +POST https:///soap/hashcodeValidationWebService +``` + +** SOAP WSDL ** +``` +POST https:///soap/hashcodeValidationWebService?wsdl +``` + +### Validation request parameters + +Validation request parameters for JSON interface are described in the table below. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|----------------|-------------| +| signatureFile | SignatureFile | + | String | Base64 encoded string of XAdES document to be validated | +| filename | Filename | + | String | File name of the XAdES document (i.e. signature0.xml). Only XML files supported. | +| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | +| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | +| datafiles | DataFiles | + | Array | Array containing the information for datafiles that signature is covering | +| datafiles[0] | DataFile | + | Object | Object containing data file information | +| datafiles.filename | Filename | + | String | File name of the hashed data file, max length 255 characters. | +| datafiles.hashAlgo | HashAlgo | + | String | Hash algorithm used for hashing the data file (must match with algorithm in signature file). Accepted values are dependant of validation policy | +| datafiles.hash | Hash | + | String | Data file hash in Base64 encoded format. | + +### Sample JSON request with mandatory parameters + +```json +{ + "signatureFile": "PD94bWwgdmVyc2lvbj0iMS4...." + "filename": "signature0.xml", + "datafiles": [{ + "filename": "test.pdf", + "hashAlgo": "SHA256", + "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" + }] +} +``` +### Sample JSON request with all parameters and multiple datafiles + +```json +{ + "signatureFile":"sample.asice", + "filename":"PD94bWwgdmVyc2lvbj0iMS4....", + "signaturePolicy":"POLv3", + "reportType":"Detailed", + "datafiles": [{ + "filename": "test.pdf", + "hashAlgo": "SHA256", + "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" + }, + { + "filename": "test2.pdf", + "hashAlgo": "SHA256", + "hash": "IucjUcbRo9Rke0bZLiHc23SSasw9pSrSPr7LKln1EiI=" + }] +} +``` + +### Sample SOAP request with mandatory parameters + +```xml + + + + + PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... + signature.xml + + + test.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + + + + +``` +### Sample SOAP request with all parameters and multiple datafiles + +```xml + + + + + PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... + signature.xml + Simple + POLv4 + + + test.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + test2.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + test3.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + + + + +``` + +## Validation response interface +The signature validation report (i.e. the validation response) for JSON and SOAP interfaces depends on what type of validation report was requested. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva2/appendix/wsdl). + +### Validation response parameters Simple Report (successful scenario) + +General structure of validation response. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-----------------|-------------| +| validationReport | ValidationReport | + | Object | Object containing SIVA validation report | +| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion | + +Structure of validationConclusion block + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-----------------|-------------| +| policy | Policy | + | Object | Object containing information of the SiVa signature validation policy that was used for validation. | +| policy.policyName | Policy.PolicyName | + | String | Name of the validation policy | +| policy. policyDescription | Policy. PolicyDescription | + | String | Short description of the validation policy. | +| policy.policyUrl | Policy.PolicyUrl | + | String | URL where the signature validation policy document can be downloaded. The validation policy document shall include information about validation of all the document formats, including the different validation policies that are used in case of different file formats and base libraries. | +| signaturesCount | SignaturesCount | + | Number | Number of signatures found inside digitally signed file. | +| validSignaturesCount | ValidSignaturesCount | + | Number | Signatures count that have validated to `TOTAL-PASSED`. See also `Signature.Indication` field. | +| validationLevel | ValidationLevel | - | Date | Validation process against what the document is validated, only applicable on DSS based validations.
**Possible values:**
ARCHIVAL_DATA| +| validationTime | ValidationTime | + | Date | Time of validating the signature by the service. | +| validationWarnings | ValidationWarnings | - | Array | Array of SiVa validation warnings that do not affect the overall validation result. See also `signatures.warnings` parameter. | +| validationWarnings[0] | ValidationWarning | + | Object | Object containing the warning. | +| validationWarnings[0]. content | ValidationWarning. Content| + | String | Description of the warning. | +| validatedDocument | ValidatedDocument | + | Object | Object containing information about validated document. | +| validatedDocument. filename | ValidatedDocument. Filename | + | String | Digitally signed document's file name. | +| validatedDocument. fileHashInHex | ValidatedDocument. FileHashInHex | - | String | Calculated hash in hex of validated document. | +| validatedDocument. hashAlgo | ValidatedDocument. HashAlgo | - | String | Hash algorithm used. | +| signatureForm | SignatureForm | - | String | Format (and optionally version) of the digitally signed document container.
In case of documents in [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) format, the "hashcode" suffix is used to denote that the container was validated in [hashcode mode](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode), i.e. without original data files.
**Possible values:**
DIGIDOC_XML_1.0
DIGIDOC_XML_1.0_hashcode
DIGIDOC_XML_1.1
DIGIDOC_XML_1.1_hashcode
DIGIDOC_XML_1.2
DIGIDOC_XML_1.2_hashcode
DIGIDOC_XML_1.3
DIGIDOC_XML_1.3_hashcode
ASiC_E - used in case of all ASIC-E ([BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf)) documents and X-Road simple containers that don't use batch time-stamping (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_E_batchsignature - used in case of X-Road containers with batch signature (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_S - used in case of all ASIC-S documents | +| signatures | Signatures | - | Array | Collection of signatures found in digitally signed document | +| signatures[0] | Signature | + | Object | Signature information object | +| signatures[0]. claimedSigningTime | Signature. ClaimedSigningTime | + | Date | Claimed signing time, i.e. signer's computer time during signature creation | +| signatures[0].id | Signature.Id | + | String | Signature ID attribute | +| signatures[0].indication | Signature.Indication | + | String | Overall result of the signature's validation process, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 5: Status indications of the signature validation process".
Note that the validation results of different signatures in one signed document (signature container) may vary.
See also `validSignaturesCount` and `SignaturesCount` fields.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED
INDETERMINATE | +| signatures[0]. subIndication | Signature. SubIndication | - | String | Additional subindication in case of failed or indeterminate validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics" | +| signatures[0].errors | Signature.Errors | - | Array | Information about validation error(s), array of error messages. | +| signatures[0].errors[0] | Signature.Errors. Error | + | Object | Object containing the error | +| signatures[0].errors[0]. content | Signature.Errors. Error.Content | + | String | Error message, as returned by the base library that was used for signature validation. | +| signatures[0].info | Signature.Info | - | Object | Object containing trusted signing time information. | +| signatures[0].info. bestSignatureTime | Signature.Info. BestSignatureTime | + | Date | Time value that is regarded as trusted signing time, denoting the earliest time when it can be trusted by the validation application (because proven by some Proof-of-Existence present in the signature) that a signature has existed.
The source of the value depends on the signature profile (see also `SignatureFormat` parameter):
- Signature with time-mark (LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature.
- Signature with time-stamp (LT or LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature.
- Signature with BES or EPES level - the value is empty, i.e. there is no trusted signing time value available. | +| signatures[0]. signatureFormat | Signature. SignatureFormat | + | String | Format and profile (according to Baseline Profile) of the signature. See [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf), [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) and [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) for detailed description of the Baseline Profile levels. Levels that are accepted in SiVa validation policy are described in [SiVa signature validation policy](/siva/appendix/validation_policy)
**Possible values:**
XAdES_BASELINE_B
XAdES_BASELINE_B_BES
XAdES_BASELINE_B_EPES
XAdES_BASELINE_T
XAdES_BASELINE_LT - long-term level XAdES signature where time-stamp is used as a assertion of trusted signing time
XAdES_BASELINE_LT_TM - long-term level XAdES signature where time-mark is used as a assertion of trusted signing time. Used in case of [BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) signatures with time-mark profile and [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) signatures.
XAdES_BASELINE_LTA
CAdES_BASELINE_B
CAdES_BASELINE_T
CAdES_BASELINE_LT
CAdES_BASELINE_LTA
PAdES_BASELINE_B
PAdES_BASELINE_T
PAdES_BASELINE_LT
PAdES_BASELINE_LTA | +| signatures[0]. signatureLevel | Signature. SignatureLevel | - |String | Legal level of the signature, according to Regulation (EU) No 910/2014.
- **Possible values on positive validation result:**
QESIG
QESEAL
QES
ADESIG_QC
ADESEAL_QC
ADES_QC
ADESIG
ADESEAL
ADES
- **Possible values on indeterminate validation result:**
prefix INDETERMINATE is added to the level described in positive result. For example INDETERMINATE_QESIG
- **Possible values on negative validation result:**
In addition to abovementioned
NOT_ADES_QC_QSCD
NOT_ADES_QC
NOT_ADES
NA
- In case of DIGIDOC-XML 1.0..1.3 formats, value is missing as the signature level is not checked by the JDigiDoc base library that is used for validation. However, the signatures can be indirectly regarded as QES level signatures, see also [SiVa Validation Policy](/siva2/appendix/validation_policy)
- In case of XROAD ASICE containers the value is missing as the asicverifier base library do not check the signature level.| +| signatures[0].signedBy | Signature.SignedBy | + | String | Signers name and identification number, i.e. value of the CN field of the signer's certificate | +| signatures[0]. signatureScopes | Signature. SignatureScopes | - | Array | Contains information of the original data that is covered by the signature. | +| signatures[0]. signatureScopes[0]. name | Signature. SignatureScopes. SignatureScope.Name | + | String | Name of the signature scope. | +| signatures[0]. signatureScopes[0]. scope | Signature. SignatureScopes. SignatureScope. Scope | + | String | Type of the signature scope. | +| signatures[0]. signatureScopes[0]. content | Signature. SignatureScopes. SignatureScope. Content | + | String | Description of the scope. | +| signatures[0]. warnings | Signature.Warnings | - | Array | Block of validation warnings that do not affect the overall validation result. | +| signatures[0]. warnings[0] | Signature.Warnings. Warning | + | Object | Object containing the warning | +| signatures[0]. warnings[0]. content | Signature.Warnings. Warning.Description | + | String | Warning description, as retuned by the base library that was used for validation. | +| timeStampTokens | TimeStampTokens | - | Array | Array containing the time stamp tokens | +| timeStampTokens[0]. | TimeStampToken | + | Object | Object containing the time stamp token (TST) | +| timeStampTokens[0]. indication | TimeStampToken. Indication | + | String | Result of the time stamp token validation.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED | +| timeStampTokens[0]. signedBy | TimeStampToken. SignedBy | + | String | Signer of the time stamp token. | +| timeStampTokens[0]. signedTime | TimeStampToken. SignedTime | + | String | Time when the time stamp token was given. | +| timeStampTokens[0]. error | TimeStampToken. Errors| - | Array | Errors returned in time stamp token validation. | +| timeStampTokens[0]. error[0] | Errors. Error | + | Object | Object containing the error. | +| timeStampTokens[0]. error[0]. content | Error. Content | + | String | Error description. | + +#### Sample JSON response Simple Report (successful scenario) + +```json +{"validationReport": +{"validationConclusion": { + "validationTime": "2017-11-07T08:14:07Z", + "signaturesCount": 1, + "validationLevel": "ARCHIVAL_DATA", + "validatedDocument": { + "filename": "ValidLiveSignature.asice", + "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", + "hashAlgo": "SHA-256" + }, + "validSignaturesCount": 1, + "signatures": [{ + "signatureFormat": "XAdES_BASELINE_LT", + "signedBy": "NURM,AARE,38211015222", + "claimedSigningTime": "2016-10-11T09:35:48Z", + "signatureLevel": "QESIG", + "warnings": [{"content": "The trusted list is not fresh!"}], + "signatureScopes": [{ + "scope": "FullSignatureScope", + "name": "Tresting.txt", + "content": "Full document" + }], + "id": "S0", + "indication": "TOTAL-PASSED", + "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} + }], + "policy": { + "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", + "policyUrl": "http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4", + "policyName": "POLv4" + }, + "signatureForm": "ASiC_E" +}}} +``` + +#### Sample SOAP response Simple Report (successful scenario) + +```xml + + + + + + + + Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + POLv4 + http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 + + 2017-11-07T08:14:07Z + + ValidLiveSignature.asice + 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 + SHA-256 + + ARCHIVAL_DATA + + ASiC_E + + + S0 + XAdES_BASELINE_LT + QESIG + NURM,AARE,38211015222 + TOTAL-PASSED + + + + + Tresting.txt + FullSignatureScope + Full document + + + 2016-10-11T09:35:48Z + + + The trusted list is not fresh! + + + + 2016-10-11T09:36:10Z + + + + 1 + 1 + + + + + +``` + +### Validation response parameters Detailed Report (successful scenario) + +General structure of validation response. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-----------------|-------------| +| validationReport | ValidationReport | + | Object | Object containing SIVA validation report. | +| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report. | +| validationReport. validationProcess | ValidationReport. ValidationProcess | - | Object | Object containing information of the validation process. This block is present only on DSS library based validations and is built on DSS detailed report. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/dss-documentation.adoc#validation-process). | +| validationReportSignature | ValidationReportSignature | - | String | Base64 string of ASIC-E container that includes the detailed report and is signed by the validation service provider | + +#### Sample JSON response Detailed Report (successful scenario). The report is shortened but gives general overview of structure. + +```json +{ + "validationReport": { + "validationProcess": { + "qmatrixBlock": { + "tlanalysis": [{ + "conclusion": {"indication": "PASSED"}, + "countryCode": "EU", + "constraint": [ + { + "name": { + "nameId": "QUAL_TL_FRESH", + "value": "Is the trusted list fresh ?" + }, + "status": "OK" + }, + ... + ] + }, + { + "conclusion": {"indication": "PASSED"}, + "countryCode": "EE", + "constraint": [{ + "name": { + "nameId": "QUAL_TL_FRESH", + "value": "Is the trusted list fresh ?" + }, + "status": "OK" + }, + ... + ] + } + ], + "signatureAnalysis": [{ + "conclusion": {"indication": "PASSED"}, + "signatureQualification": "QESIG", + "constraint": [{ + "name": { + "nameId": "QUAL_IS_ADES", + "value": "Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ?" + }, + "status": "OK" + }, + ... + ], + "id": "S0" + }] + }, + "basicBuildingBlocks": [{ + "conclusion": {"indication": "PASSED"}, + "cv": { + "conclusion": {"indication": "PASSED"}, + "constraint": [{ + "name": { + "nameId": "BBB_CV_IRDOF", + "value": "Is the reference data object(s) found?" + }, + "status": "OK" + }, + ... + ]}, + ... + "id": "1561CD6BEA97B0A72664067021330509894BE1EBA586D3057D77787E5F4180A4", + "type": "TIMESTAMP" + }, + ... + "signatures": [{ + "validationProcessArchivalData": { + "conclusion": {"indication": "PASSED"}, + "constraint": [{ + "name": { + "nameId": "ARCH_LTVV", + "value": "Is the result of the LTV validation process acceptable?" + }, + "status": "OK" + }]}, + ... + }, + "id": "S0", + "validationProcessLongTermData": { + "conclusion": {"indication": "PASSED"}, + "constraint": [{ + "name": { + "nameId": "LTV_ABSV", + "value": "Is the result of the Basic Validation Process acceptable?"}, + "status": "OK" + }, + ... + }]}}] + }, + "validationConclusion": { + "validationTime": "2017-11-07T09:20:18Z", + "signaturesCount": 1, + "validationLevel": "ARCHIVAL_DATA", + "validatedDocument": { + "filename": "ValidLiveSignature.asice", + "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", + "hashAlgo": "SHA-256" + }, + "validSignaturesCount": 1, + "signatures": [{ + "signatureFormat": "XAdES_BASELINE_LT", + "signedBy": "NURM,AARE,38211015222", + "claimedSigningTime": "2016-10-11T09:35:48Z", + "signatureLevel": "QESIG", + "signatureScopes": [{ + "scope": "FullSignatureScope", + "name": "Tresting.txt", + "content": "Full document" + }], + "id": "S0", + "indication": "TOTAL-PASSED", + "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} + }], + "policy": { + "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", + "policyUrl": "http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4", + "policyName": "POLv4" + }, + "signatureForm": "ASiC_E" + } + }, + "validationReportSignature": "UEsDBBQACAgIAIlaZ0sAA..." +} + +``` + +#### Sample SOAP response Simple Report (successful scenario) + +```xml + + + + + + + + Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + POLv4 + http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 + + 2017-11-07T09:20:18Z + + ValidLiveSignature.asice + 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 + SHA-256 + + ARCHIVAL_DATA + + ASiC-E + + + S0 + XAdES_BASELINE_LT + QESIG + NURM,AARE,38211015222 + TOTAL-PASSED + + + + + Tresting.txt + FullSignatureScope + Full document + + + 2016-10-11T09:35:48Z + + + 2016-10-11T09:36:10Z + + + + 1 + 1 + + + + + + Is the result of the Basic Validation Process conclusive? + OK + + + PASSED + + + ... + + + Is the result of the LTV validation process acceptable? + OK + + + PASSED + + + + ... + + + + Is the expected format found? + OK + + ... + + + Can the certificate chain be built till the trust anchor? + OK + + + + + ... + + Is the trusted list well signed ? + OK + + + PASSED + + + ... + + + Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ? + OK + + ... + + PASSED + + + + + + UEsDBBQACAgIAIlaZ0s... + + + + +``` + +### Sample JSON response (error situation) +In case of error (when validation report is not returned) status code 400 is returned together with following message body: + +```json +{"requestErrors": [{ + "message": "Document malformed or not matching documentType", + "key": "document" +}]} +``` + +### Sample SOAP response (error situation) + +```xml + + + + + soap:Server + Document malformed or not matching documentType + + + +``` + +## Data files request interface + + +** REST JSON Endpoint ** + +``` +POST https:///getDataFiles +``` + +** SOAP Endpoint ** +``` +POST https:///soap/dataFilesWebService/getDocumentDataFiles +``` + +** SOAP WSDL ** +``` +POST https:///soap/dataFilesWebService/getDocumentDataFiles?wsdl +``` + +### Data files request parameters + +Data files request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|----------------|-------------| +| document | Document | + | String | Base64 encoded string of digitally signed DDOC document | +| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.ddoc), max length 255 characters. Currently only DDOC file format is supported for this operation| + +### Sample JSON request + +```json +{ + "filename":"sample.ddoc", + "document":"PD94bWwgdmVyc2lvbj0iMS4...." +} +``` + + +### Sample SOAP request + +```xml + + + + + + PD94bWwgdmVyc2lvbj0iMS4wI... + sample.ddoc + + + + +``` + + +## Data files response interface + +### Data files response parameters (successful scenario) + +The data file extraction report (i.e. the data files response) for JSON and SOAP interfaces is described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). +SiVa returns all data files as they are extracted by JDigiDoc library in an as is form. No extra operations or validations are done. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|----------------|-------------| +| dataFiles | DataFiles | - | Array | Collection of data files found in digitally signed document | +| dataFiles[0] | DataFile | + | Object | Extracted data file object | +| dataFiles[0].fileName | DataFile.FileName | - | String | File name of the extracted data file | +| dataFiles[0].size | DataFile.Size | - | Long | Extracted data file size in bytes | +| dataFiles[0].base64 | DataFile.Base64 | - |String | Base64 encoded string of extracted data file | +| dataFiles[0].mimeType | DataFile.MimeType | - | String | MIME type of the extracted data file | + +### Sample JSON response (successful scenario) + +```json +{ +"dataFiles": [{ + "fileName": "Glitter-rock-4_gallery.jpg", + "size": 41114, + "base64": "/9j/4AAQSkZJ...", + "mimeType": "application/octet-stream" }] +} +``` + +### Sample SOAP response (successful scenario) + +```xml + + + + + + + + UCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUH... + Glitter-rock-4_gallery.jpg + application/octet-stream + 41114 + + + + + + +``` + +### Sample JSON response (error situation) +In case of error (when datafiles are not returned) status code 400 is returned together with following message body: + +```json +{"requestErrors": [{ + "message": "Invalid document type. Can only return data files for DDOC type containers.", + "key": "documentType" +}]} +``` + +### Sample SOAP response (error situation) + +```xml + + + + + soap:Client + Invalid document type. Can only return data files for DDOC type containers. + + + +``` + + + +## Service health monitoring + +SiVa webapps provide an interface for external monitoring tools (to periodically check the generic service health status). + +### The request +The monitoring endpoint is accessible via HTTP GET at **/monitoring/health** or **/monitoring/health.json** url. + +Sample request: +``` +GET https:///monitoring/health +``` + +### The response + +As a response, a JSON object is returned with the following information: + +| Field | Description | +| ---------| --------------- | +| status | General status of the webapp.
Possible values:
  • **DOWN** - when some of the dependent indicators status are down (ie when `link{number}.status` is DOWN, the overall service status is DOWN)
  • **UP** - the default value.
| +| health.status | Status of current webapp - constant value **UP** | +| health.webappName | The artifact name of the webapp. Taken from the MANIFEST.MF file (inside the jar/war file). | +| health.version | The release version fo the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | +| health.buildTime | Build date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') of the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | +| health.startTime | Webapp startup date and time (format yyyy-MM-dd'T'HH:mm:ss'Z')| +| health.currentTime | Current server date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') | +| link{number}.status | (OPTIONAL) Represents the status of a link to the external system that the webapp depends on.
  • **DOWN** when the webapp does not respond (within a specified timeout limit - default 10 seconds) or the response is in invalid format (default Spring boot actuator /health endpoint format is expected).
  • **UP** if the service responds with HTTP status code 200 and returns a valid JSON object with status "UP"
|) | +| link{number}.name | (OPTIONAL) Descriptive name for the link to the external system | + +Sample response: + +```json +{ + "status":"UP", + "health":{ + "status":"UP", + "webappName":"siva-demo-application", + "version":"3.1.0", + "buildTime":"2016-10-21T15:56:21Z", + "startTime":"2016-10-21T15:57:48Z", + "currentTime":"2016-10-21T15:58:39Z" + }, + "link1":{ + "status":"UP", + "name":"sivaService" + } +} +``` diff --git a/docs/siva2/logging.md b/docs/siva2/logging.md index 15e2b75b5..39c30472d 100644 --- a/docs/siva2/logging.md +++ b/docs/siva2/logging.md @@ -1,93 +1,93 @@ - - -Logging functionality is handled by the **SLF4J** logging facade and on top -of it the **Logback** framework is used. As a result, logging can be -configured via the standard Logback configuration file. By default, -logging works on the `INFO` level and logs are directed to the system -console as well as a log file. - -The logback xml configuration file can be found at: -``` -pdfValidator/pdf-validator-webapp/src/main/resources/logback.xml -``` - -and when compiled the file will reside at  -``` -WEB-INF/classes/logback.xml -``` - -within the packaged war. There is also a possibility to set the location -of the default configuration file with a system -property `logback.configurationFile` as a JVM argument. The value of -this property can be a URL, a resource on the class path or a path to a -file external to the application. - -```bash -java -Dlogback.configurationFile=/path/to/config.xml -``` - -In this configuration file there are three appenders: `STDOUT` (logs to -standard output), `FILE` (logs to a file) and `SYSLOG` (logs to syslog -server over the network). To disable certain appender from logging, -commenting out its `appender-ref` is sufficient, but it is *recommended* -that the appender itself should also be commented out. For example to -disable `SYSLOG` appender (which is the default configuration), then one -can use following configuration: - -```xml - - - - - - - - -``` - -Logback configuration manual:  - -STDOUT appender ----------------- - -- Default the log level is set to DEBUG -- Appender output pattern is: `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L [%thread] - %msg%n` - -FILE appender -------------- - -- Default log level is set to `INFO` -- uses RollingFileAppender configured with `TimeBasedRollingPolicy`. - Current configuration makes a seperate logfile for each day and each - file is kept for *30 days*. - - *PS!* keep in mind when using relative - destination file path, then the path is added at the end of the - currently working directory, i.e. where the application was started. - (Current day's logfile path: `logs/pdf-validator-webapp.log`, - prievious days pattern:  - - logs/pdf-validator-webapp.%d{yyyy-MM-dd}.log) - -- Appender output pattern is:  `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L \[%thread\] - %msg%n` - - -Dlogback.configurationFile=config.xml - -SYSLOG appender ---------------- - -- Default log level is set to `INFO` -- Target's ip/hostname and port are configurable -- Syslog messsages' severity is configurable -- Syslog messages' payload's timestamp and hostname part are created - implicitly and the suffixpattern is:  `%-5level %logger{0}:%L \[%thread\] - %msg` + + +Logging functionality is handled by the **SLF4J** logging facade and on top +of it the **Logback** framework is used. As a result, logging can be +configured via the standard Logback configuration file. By default, +logging works on the `INFO` level and logs are directed to the system +console as well as a log file. + +The logback xml configuration file can be found at: +``` +pdfValidator/pdf-validator-webapp/src/main/resources/logback.xml +``` + +and when compiled the file will reside at  +``` +WEB-INF/classes/logback.xml +``` + +within the packaged war. There is also a possibility to set the location +of the default configuration file with a system +property `logback.configurationFile` as a JVM argument. The value of +this property can be a URL, a resource on the class path or a path to a +file external to the application. + +```bash +java -Dlogback.configurationFile=/path/to/config.xml +``` + +In this configuration file there are three appenders: `STDOUT` (logs to +standard output), `FILE` (logs to a file) and `SYSLOG` (logs to syslog +server over the network). To disable certain appender from logging, +commenting out its `appender-ref` is sufficient, but it is *recommended* +that the appender itself should also be commented out. For example to +disable `SYSLOG` appender (which is the default configuration), then one +can use following configuration: + +```xml + + + + + + + + +``` + +Logback configuration manual:  + +STDOUT appender +---------------- + +- Default the log level is set to DEBUG +- Appender output pattern is: `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L [%thread] - %msg%n` + +FILE appender +------------- + +- Default log level is set to `INFO` +- uses RollingFileAppender configured with `TimeBasedRollingPolicy`. + Current configuration makes a seperate logfile for each day and each + file is kept for *30 days*. + + *PS!* keep in mind when using relative + destination file path, then the path is added at the end of the + currently working directory, i.e. where the application was started. + (Current day's logfile path: `logs/pdf-validator-webapp.log`, + prievious days pattern:  + + logs/pdf-validator-webapp.%d{yyyy-MM-dd}.log) + +- Appender output pattern is:  `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L \[%thread\] - %msg%n` + + -Dlogback.configurationFile=config.xml + +SYSLOG appender +--------------- + +- Default log level is set to `INFO` +- Target's ip/hostname and port are configurable +- Syslog messsages' severity is configurable +- Syslog messages' payload's timestamp and hostname part are created + implicitly and the suffixpattern is:  `%-5level %logger{0}:%L \[%thread\] - %msg` diff --git a/docs/siva2/overview.md b/docs/siva2/overview.md index 0ed43ff08..9d7352e49 100644 --- a/docs/siva2/overview.md +++ b/docs/siva2/overview.md @@ -1,55 +1,55 @@ - - -## What is SiVa? - -SiVa (Signature Validation) web service provides JSON and SOAP based API web interface to validate digital signatures. -Please take a look in [Validation Policy](appendix/validation_policy) section for supported formats and applied constraints. - -SiVa uses following Java libraries and command line utilities: - -* DigiDoc4J Java library to validate BDOC containers. Supported signature - types are `TimeStamp` and `TimeMark` -* JDigiDoc Java library is used to validate DDOC containers. -* X-Road ASiCE containers are validated using X-Road security server project - provided command line utility -* EU DSS (Digital Signature Service) library is used to validate all other types of digital signatures that are not covered above. - -## Validation libraries - -### DigiDoc4j EU DSS fork - -[DigiDoc4J EU DSS fork](https://github.com/open-eid/sd-dss) is used as the main validation library. The fork includes [Estonian specific changes](https://github.com/open-eid/sd-dss/wiki/BDoc-specific-modifications) and may not be suitable for all signatures. - -**SiVa will use the following functionality of EU DSS library:** - -* XAdES/CAdES/PAdES Validation Functionality -* ASIC-E and ASIC-S container validation -* TSL loading functionality - -### DigiDoc4J - -DigiDoc4J is used to validate both `TimeMark` and `TimeStamp` based BDOC containers. For more information on DigiDoc4J visit [Github](https://github.com/open-eid/digidoc4j) - -SiVa will use the following functionality of DigiDoc4J: - -* BDOC validation functionality - -### JDigiDoc - -JDigiDoc is used to validate DDOC containers. For more information on JDigiDoc visit [GitHub](https://github.com/open-eid/jdigidoc) - -SiVa will use the following functionality of JDigiDoc: - -* DDOC validation functionality - -### X-Road signature validation utility - -X-Road signature validation utility is command line tool to validate X-Road Security server -generated ASiCe files. For more information on this utility visit [GitHub](https://github.com/ria-ee/X-Road) - -## Main features of SiVa validation service: - -- SOAP and REST/JSON API to validate signatures. -- SOAP and REST/JSON API to retrieve data files from DDOC containers. -- SOAP API is compadible with X-Road v6. + + +## What is SiVa? + +SiVa (Signature Validation) web service provides JSON and SOAP based API web interface to validate digital signatures. +Please take a look in [Validation Policy](appendix/validation_policy) section for supported formats and applied constraints. + +SiVa uses following Java libraries and command line utilities: + +* DigiDoc4J Java library to validate BDOC containers. Supported signature + types are `TimeStamp` and `TimeMark` +* JDigiDoc Java library is used to validate DDOC containers. +* X-Road ASiCE containers are validated using X-Road security server project + provided command line utility +* EU DSS (Digital Signature Service) library is used to validate all other types of digital signatures that are not covered above. + +## Validation libraries + +### DigiDoc4j EU DSS fork + +[DigiDoc4J EU DSS fork](https://github.com/open-eid/sd-dss) is used as the main validation library. The fork includes [Estonian specific changes](https://github.com/open-eid/sd-dss/wiki/BDoc-specific-modifications) and may not be suitable for all signatures. + +**SiVa will use the following functionality of EU DSS library:** + +* XAdES/CAdES/PAdES Validation Functionality +* ASIC-E and ASIC-S container validation +* TSL loading functionality + +### DigiDoc4J + +DigiDoc4J is used to validate both `TimeMark` and `TimeStamp` based BDOC containers. For more information on DigiDoc4J visit [Github](https://github.com/open-eid/digidoc4j) + +SiVa will use the following functionality of DigiDoc4J: + +* BDOC validation functionality + +### JDigiDoc + +JDigiDoc is used to validate DDOC containers. For more information on JDigiDoc visit [GitHub](https://github.com/open-eid/jdigidoc) + +SiVa will use the following functionality of JDigiDoc: + +* DDOC validation functionality + +### X-Road signature validation utility + +X-Road signature validation utility is command line tool to validate X-Road Security server +generated ASiCe files. For more information on this utility visit [GitHub](https://github.com/ria-ee/X-Road) + +## Main features of SiVa validation service: + +- SOAP and REST/JSON API to validate signatures. +- SOAP and REST/JSON API to retrieve data files from DDOC containers. +- SOAP API is compadible with X-Road v6. - Signing of validation report. \ No newline at end of file diff --git a/docs/siva2/qa_strategy.md b/docs/siva2/qa_strategy.md index 2262abaf9..853d8a322 100644 --- a/docs/siva2/qa_strategy.md +++ b/docs/siva2/qa_strategy.md @@ -1,156 +1,156 @@ - -## Introduction -The goal of this document is to give general overview of the used infrastructure, processes, schedule and actions to ensure good quality delivery. The document describes activities in the whole software development process. Analysis, development and testing are separated for the sake of structure and transparency although they are integral parts of the development cycle. -This is living document and will be constantly updated as the project evolves. -## Environments and infrastructure -![Enviroment](../img/siva/qa_strategy/siva2/Env.png) - -There are different test environments for quality assurance, depending on the nature and aim. - -1. TravisCI environment for public CI - Platform: Linux -2. Test environment for local test and load test - Platform: Linux - -Instructions how to set up test enviroment and run tests together with more info can be found in [SiVa GitHub page](https://github.com/open-eid/SiVa) - -System requirements: - -* At least 2GB of RAM on machine where the build is executed -* Minimum required Java version is Java 8 -* SiVa project provided Maven Wrapper (./mvnw) - -Tools used: - -* TravisCI – is a continuous integration service used to build and test software projects hosted at GitHub -* Jenkins – is an open source continuous integration tool written in Java. -* JMeter – tool for creating and running load tests. -* IntelliJ IDEA – is a Java integrated development environment(IDE) for developing and executing automated tests locally -* Apache Tomcat - is an open source servlet container developed by the Apache Software Foundation. -* Docker – is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux. -* Rest-Assured - is a Java DSL(Domain-specific language) for simplifying testing of REST based Services built on top of HTTP Builder. - -## Analysis -Analysis will be tagged with identificators to enable cross-reference between requirements and corresponding tests. This includes both functional and non-functional requirements. -See documents[(2) and (3) in References](/siva/references/) - -## Development -### Development process -Customized process based on Kanban is used in the development. The process consists of following elements: - -* Product backlog is maintained JIRA -* Tasks are maintained through JIRA Kanban board -* Daily team stand-ups are held -* Tasks marked done are developed, tested and ready to be shipped -* Bi-weekly meetings are held to give status on progress and discuss open questions -![Development process](../img/siva/qa_strategy/siva2/developmentProcess.png) - -### Issue lifecycle -Each ticket in JIRA Kanban board goes through the following states that correspond the development procedure described in previous chapter. -![Issue lifecycle](../img/siva/qa_strategy/siva2/taskWorkFlow.png) - -Description of states: - -* Awaiting analysis - ticket to be dealt with, product backlog. -* Awaiting implementation - ticket analysed and ready to be implemented. -* In progress - ticket is being handled (feature coding, document writing, ...). -* In Review - ticket is ready for review -* Resolved - ticket is ready for test -* Closed - ticket has been tested and found ready for release - -### QA activities and quality criterias in the development -**Process improvement** - -The development process is constantly monitored and adjusted to the changing situations. Retrospective meetings for process feedback are held. - -**Unit tests** - -It is responsibility of developer to write, maintain and execute the unit tests on developed features. The code must compile and pass unit tests before it is allowed to be submitted to the code repository. The code of the unit tests is integral part of the source code and is maintained on the same principles. -Unit tests are also automatically executed on each build, if the unit tests do not pass further test execution is stopped. - -**Static testing/code reviews** - -All changes (including changes in unit test code) are reviewed by another development team member using GitHub. The code must pass review before it is submitted to testing. -SonarLint is used to validate code automatically. It integrates both suggested tools mentioned in reference document [(3) References](/siva/references/) - -## Testing -### Approach -Testing follows the principles described in reference document [(1) in References](/siva/references/) -The goal is to automate as much of the testing process as possible, however some aspects of the testing will be carried out manually. -As the development is carried out by the backlog priority the testing follows the same principle. After each feature release test cases, test automation code and test results will be available through GitHub. -![Testing schedule](../img/siva/qa_strategy/siva2/testingFlow.png) -### Testing process - -All automatic tests, except load tests will follow the same execution process. The tests are ran automatically during the project build process by Travis CI after each push in GitHub. -![Testing process](../img/siva/qa_strategy/siva2/TestProcess.png) - -### Test case management -Test cases are handled as integral part of test automation code. The same applies on manual tests, in manual test cases some portion of automation may be used to execute the tests but the results are verified manually. All the test cases and test code will be maintained in the GitHub. -Test cases are developed and maintained together with test automation code by the QA specialist for Integration and System Testing. -Following elements will be present in test cases: - -* TestCaseID: unique ID that makes possible to identify specific test case -* TestType: Automated, Automated SoapUI or Manual -* Requirement: Reference to the requirement that is tested -* Title: Description of the test -* Expected Result: expected outcome of the test (pass criteria for the test) -* File: input test file that is used - - -**Test case sample** - -Automatic and manual test cases will have the same description principles (shown below). - -```bash -/** -* TestCaseID: Bdoc-ValidationFail-27 -* -* TestType: Automated -* -* Requirement: http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#common-validation-constraints-polv1-polv2 -* -* Title: Bdoc OCSP response doesn't correspond to the signers certificate -* -* Expected Result: The document should fail the validation -* -* File: NS28_WrongSignerCertInOCSPResp.bdoc -*/ -@Test -public void bdocWrongSignersCertInOcspResponse() { -setTestFilesDirectory("bdoc/live/timemark/"); -post(validationRequestFor("NS28_WrongSignerCertInOCSPResp.bdoc")) -.then() -.body("signatures[0].indication", Matchers.is("TOTAL-FAILED")) -.body("signatures[0].subIndication", Matchers.is("TRY_LATER")) -.body("signatures[0].errors.content", Matchers.hasItem("No revocation data for the certificate")) -.body("validSignaturesCount", Matchers.is(0)); -} -``` -### Defect management -All found defects will be reported and handled in Jira. The defect report will follow similar lifecycle in JIRA Kanban board as tasks. -The report will have at least the following elements: - -* Title: Short, precise description of the problem -* Details: Type, Priority, Epic Link -* Description: - * **Steps to reproduce bug** - sequence for reproduction, link to test case if applicable. - * **Expected behavior** - expected outcome of the test sequence. - * **Actual behavior** - actual result of the test sequence. The description should be thorough enough to enable the debugging of the problem and to give objective base for severity assessment. - * **File attachments** - Test files, logs, images, ... -### Test levels - -**Integration testing** - -The scope of the tests is illustrated on the image below. The goal is to test the SiVA application API (both X-Road and REST/JSON) and to test the independent module capability for validation of specific type of file. Both valid and invalid inputs are tested. More info about testing specifics can be found in Test Plan [Integration testing](/siva/test_plan/#integration-test-introduction) section. -![Integration testing](../img/siva/qa_strategy/IntegrationTest.png) - -**System testing** - -The scope of the tests is illustrated on the image below. The goal of the test is to test the entire length of signature validation process and to test supportive functions. In addition Demo application is tested. More info about testing specifics can be found in Test Plan [System testing](/siva/test_plan/#system-test-introduction) section. -![System testing](../img/siva/qa_strategy/SystemTest.png) - - -**Regression testing** - -Regression testing will consist of two parts: -Running all automated tests (unit, integration and system tests) -Manual testing of the areas that are not covered by automatic tests based on the regression test checklist + +## Introduction +The goal of this document is to give general overview of the used infrastructure, processes, schedule and actions to ensure good quality delivery. The document describes activities in the whole software development process. Analysis, development and testing are separated for the sake of structure and transparency although they are integral parts of the development cycle. +This is living document and will be constantly updated as the project evolves. +## Environments and infrastructure +![Enviroment](../img/siva/qa_strategy/siva2/Env.png) + +There are different test environments for quality assurance, depending on the nature and aim. + +1. TravisCI environment for public CI - Platform: Linux +2. Test environment for local test and load test - Platform: Linux + +Instructions how to set up test enviroment and run tests together with more info can be found in [SiVa GitHub page](https://github.com/open-eid/SiVa) + +System requirements: + +* At least 2GB of RAM on machine where the build is executed +* Minimum required Java version is Java 8 +* SiVa project provided Maven Wrapper (./mvnw) + +Tools used: + +* TravisCI – is a continuous integration service used to build and test software projects hosted at GitHub +* Jenkins – is an open source continuous integration tool written in Java. +* JMeter – tool for creating and running load tests. +* IntelliJ IDEA – is a Java integrated development environment(IDE) for developing and executing automated tests locally +* Apache Tomcat - is an open source servlet container developed by the Apache Software Foundation. +* Docker – is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux. +* Rest-Assured - is a Java DSL(Domain-specific language) for simplifying testing of REST based Services built on top of HTTP Builder. + +## Analysis +Analysis will be tagged with identificators to enable cross-reference between requirements and corresponding tests. This includes both functional and non-functional requirements. +See documents[(2) and (3) in References](/siva/references/) + +## Development +### Development process +Customized process based on Kanban is used in the development. The process consists of following elements: + +* Product backlog is maintained JIRA +* Tasks are maintained through JIRA Kanban board +* Daily team stand-ups are held +* Tasks marked done are developed, tested and ready to be shipped +* Bi-weekly meetings are held to give status on progress and discuss open questions +![Development process](../img/siva/qa_strategy/siva2/developmentProcess.png) + +### Issue lifecycle +Each ticket in JIRA Kanban board goes through the following states that correspond the development procedure described in previous chapter. +![Issue lifecycle](../img/siva/qa_strategy/siva2/taskWorkFlow.png) + +Description of states: + +* Awaiting analysis - ticket to be dealt with, product backlog. +* Awaiting implementation - ticket analysed and ready to be implemented. +* In progress - ticket is being handled (feature coding, document writing, ...). +* In Review - ticket is ready for review +* Resolved - ticket is ready for test +* Closed - ticket has been tested and found ready for release + +### QA activities and quality criterias in the development +**Process improvement** + +The development process is constantly monitored and adjusted to the changing situations. Retrospective meetings for process feedback are held. + +**Unit tests** + +It is responsibility of developer to write, maintain and execute the unit tests on developed features. The code must compile and pass unit tests before it is allowed to be submitted to the code repository. The code of the unit tests is integral part of the source code and is maintained on the same principles. +Unit tests are also automatically executed on each build, if the unit tests do not pass further test execution is stopped. + +**Static testing/code reviews** + +All changes (including changes in unit test code) are reviewed by another development team member using GitHub. The code must pass review before it is submitted to testing. +SonarLint is used to validate code automatically. It integrates both suggested tools mentioned in reference document [(3) References](/siva/references/) + +## Testing +### Approach +Testing follows the principles described in reference document [(1) in References](/siva/references/) +The goal is to automate as much of the testing process as possible, however some aspects of the testing will be carried out manually. +As the development is carried out by the backlog priority the testing follows the same principle. After each feature release test cases, test automation code and test results will be available through GitHub. +![Testing schedule](../img/siva/qa_strategy/siva2/testingFlow.png) +### Testing process + +All automatic tests, except load tests will follow the same execution process. The tests are ran automatically during the project build process by Travis CI after each push in GitHub. +![Testing process](../img/siva/qa_strategy/siva2/TestProcess.png) + +### Test case management +Test cases are handled as integral part of test automation code. The same applies on manual tests, in manual test cases some portion of automation may be used to execute the tests but the results are verified manually. All the test cases and test code will be maintained in the GitHub. +Test cases are developed and maintained together with test automation code by the QA specialist for Integration and System Testing. +Following elements will be present in test cases: + +* TestCaseID: unique ID that makes possible to identify specific test case +* TestType: Automated, Automated SoapUI or Manual +* Requirement: Reference to the requirement that is tested +* Title: Description of the test +* Expected Result: expected outcome of the test (pass criteria for the test) +* File: input test file that is used + + +**Test case sample** + +Automatic and manual test cases will have the same description principles (shown below). + +```bash +/** +* TestCaseID: Bdoc-ValidationFail-27 +* +* TestType: Automated +* +* Requirement: http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#common-validation-constraints-polv1-polv2 +* +* Title: Bdoc OCSP response doesn't correspond to the signers certificate +* +* Expected Result: The document should fail the validation +* +* File: NS28_WrongSignerCertInOCSPResp.bdoc +*/ +@Test +public void bdocWrongSignersCertInOcspResponse() { +setTestFilesDirectory("bdoc/live/timemark/"); +post(validationRequestFor("NS28_WrongSignerCertInOCSPResp.bdoc")) +.then() +.body("signatures[0].indication", Matchers.is("TOTAL-FAILED")) +.body("signatures[0].subIndication", Matchers.is("TRY_LATER")) +.body("signatures[0].errors.content", Matchers.hasItem("No revocation data for the certificate")) +.body("validSignaturesCount", Matchers.is(0)); +} +``` +### Defect management +All found defects will be reported and handled in Jira. The defect report will follow similar lifecycle in JIRA Kanban board as tasks. +The report will have at least the following elements: + +* Title: Short, precise description of the problem +* Details: Type, Priority, Epic Link +* Description: + * **Steps to reproduce bug** - sequence for reproduction, link to test case if applicable. + * **Expected behavior** - expected outcome of the test sequence. + * **Actual behavior** - actual result of the test sequence. The description should be thorough enough to enable the debugging of the problem and to give objective base for severity assessment. + * **File attachments** - Test files, logs, images, ... +### Test levels + +**Integration testing** + +The scope of the tests is illustrated on the image below. The goal is to test the SiVA application API (both X-Road and REST/JSON) and to test the independent module capability for validation of specific type of file. Both valid and invalid inputs are tested. More info about testing specifics can be found in Test Plan [Integration testing](/siva/test_plan/#integration-test-introduction) section. +![Integration testing](../img/siva/qa_strategy/IntegrationTest.png) + +**System testing** + +The scope of the tests is illustrated on the image below. The goal of the test is to test the entire length of signature validation process and to test supportive functions. In addition Demo application is tested. More info about testing specifics can be found in Test Plan [System testing](/siva/test_plan/#system-test-introduction) section. +![System testing](../img/siva/qa_strategy/SystemTest.png) + + +**Regression testing** + +Regression testing will consist of two parts: +Running all automated tests (unit, integration and system tests) +Manual testing of the areas that are not covered by automatic tests based on the regression test checklist \ No newline at end of file diff --git a/docs/siva2/references.md b/docs/siva2/references.md index 938b6d453..4d57fad84 100644 --- a/docs/siva2/references.md +++ b/docs/siva2/references.md @@ -1,8 +1,8 @@ -# References - - * (1) Lisa_6_Osa_I_SiVa_Testimise_korraldus.pdf - * (2) Lisa_4_Osa_I_SiVa_Valideerimisteenuse_analuus MUUDETUD.pdf - * (3) Lisa_3_RIA_Mittefunktsionaalsed_nouded.pdf - - - +# References + + * (1) Lisa_6_Osa_I_SiVa_Testimise_korraldus.pdf + * (2) Lisa_4_Osa_I_SiVa_Valideerimisteenuse_analuus MUUDETUD.pdf + * (3) Lisa_3_RIA_Mittefunktsionaalsed_nouded.pdf + + + diff --git a/docs/siva2/systemintegrators_guide.md b/docs/siva2/systemintegrators_guide.md index afd5f09be..fc706f33a 100644 --- a/docs/siva2/systemintegrators_guide.md +++ b/docs/siva2/systemintegrators_guide.md @@ -1,587 +1,587 @@ -This guide describes how to integrate SiVa service with other applications. -The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. - -### System requirements - -Following are the minimum requirements to build and deploy SiVa webapps as a service: - -* Java 8 or above Oracle JVM is supported -* Git version control system version 1.8 or above is recommended -* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM -* Minimum 1 processor core -* Open internet connection -* 2GB of free disk space -* Supported operating system is Ubuntu 16.04 LTS - -## Building - -### Building SiVa webapps on Ubuntu 16.04 - -First we need to install Git and Java SDK 8 by issuing below commands: - -```bash -sudo apt-get update -sudo apt-get install git -y -sudo apt-get install default-jdk -y -``` - -Next we need to clone the SiVa Github repository: - -```bash -git clone https://github.com/open-eid/SiVa.git --branch master -``` - -Final step is building the SiVa project using Maven Wrapper - -```bash -cd SiVa -./mvnw clean install -``` - -!!! note - The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the - required dependencies - -To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. -The last lines of build output should look very similar to below image: - -```text -[INFO] Reactor Summary: -[INFO] -[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 1.632 s] -[INFO] validation-services-parent ......................... SUCCESS [ 0.897 s] -[INFO] validation-commons ................................. SUCCESS [ 12.321 s] -[INFO] tsl-loader ......................................... SUCCESS [ 6.917 s] -[INFO] Generic Validation Service ......................... SUCCESS [ 27.919 s] -[INFO] TimeStampToken Validation Service .................. SUCCESS [ 7.046 s] -[INFO] BDOC Validation Service ............................ SUCCESS [ 50.087 s] -[INFO] DDOC Validation Service ............................ SUCCESS [ 16.712 s] -[INFO] SiVa webapp and other core modules ................. SUCCESS [ 0.653 s] -[INFO] siva-monitoring .................................... SUCCESS [ 9.736 s] -[INFO] xroad-validation-service ........................... SUCCESS [ 19.761 s] -[INFO] siva-statistics .................................... SUCCESS [ 13.734 s] -[INFO] SiVa validation service proxy ...................... SUCCESS [ 11.509 s] -[INFO] SiVa signature service ............................. SUCCESS [ 6.869 s] -[INFO] siva-webapp ........................................ SUCCESS [ 27.608 s] -[INFO] SiVa Web Service integration tests ................. SUCCESS [03:53 min] -[INFO] siva-distribution .................................. SUCCESS [ 10.818 s] -[INFO] ------------------------------------------------------------------------ -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 08:18 min -[INFO] Finished at: 2017-12-04T13:49:48+02:00 -[INFO] Final Memory: 113M/903M -[INFO] ------------------------------------------------------------------------ -``` - - -## Deploying - -### OPTION 1 - starting webapps from command line -SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the -project by issuing below commands: - -**First start the Siva webapp** - -```bash -./siva-parent/siva-webapp/target/siva-webapp-3.0.0.jar -``` - -**Second we need to start X-road validation webapp** - -```bash -./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.0.0.jar -``` - -The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. -Easiest way to test out validation is run [SiVa demo application](https://github.com/open-eid/SiVa-demo-application). - -### OPTION 2 - running webapps as systemd services - -Maven build generates executable JAR files. This means web container and all its dependencies are package inside -single JAR file. It makes a lot easier to deploy it into servers. - -Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. - -For that we first need to create service file: -```bash -vim siva-webapp.service -``` - -Inside it we need to paste below text. You need to change few things in service setup file. - -* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` -* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. -* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file - -```ini -[Unit] -Description=siva-webapp -After=syslog.target - -[Service] -User=root -ExecStart=/var/apps/siva-webapp.jar -Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 -SuccessExitStatus=143 - -[Install] -WantedBy=multi-user.target -``` - -Save and close the `siva-webapp.service` file. -Next we need to move `siva-webapp-3.0.0.jar` into newly created `/var/apps` directory and rename to -JAR file to `siva-webapp.jar`. match - -!!! note - The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file - -```bash -sudo mkdir /var/apps -sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.0.0.jar /var/apps/siva-webapp.jar -``` - -Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. -Then we are ready to start the `siva-webapp` service. - -```bash -sudo cp siva-webapp.service /lib/systemd/system -sudo systemctl start siva-webapp -``` - -Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below -command. - -```bash -systemctl status siva-webapp -``` - -It should print out similar to below picture: - -``` -● siva-webapp.service - siva-webapp - Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) - Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago - Main PID: 15965 (siva-webapp.jar) - Tasks: 34 - Memory: 429.6M - CPU: 2min 5.721s - CGroup: /system.slice/siva-webapp.service - ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar - └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar - -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -``` - -### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) - -> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet -> containers also possible container application libraries conflicts - -> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version -> conflicts. - -> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - -the http connector parameter `maxPostSize` should be configured with the desired limit. - -> **NOTE 4**: The war file must be deployed to Tomcat ROOT. - -First we need to download Tomcat web servlet container as of the writing latest version available in version 8 branch is 8.5.24. We will download it with `wget` - -```bash -wget http://www-eu.apache.org/dist/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gz -``` - -Unpack it somewhere: - -```bash -tar xf apache-tomcat-8.5.24.tar.gz -``` - -Now we should build the WAR file. We have created helper script with all the correct Maven parameters. - -```bash -./war-build.sh -``` - -> **NOTE** The script will skip running the integration tests when building WAR files - -Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. - -```bash -cp siva-parent/siva-webapp/target/siva-webapp-3.0.0.war apache-tomcat-8.5.24/webapps -./apache-tomcat-7.0.77/bin/catalina.sh run -``` - -> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates -> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change -> this default behavior you should set environment variable `DSS_DATA_FOLDER` - -### How-to set WAR deployed SiVa `application.properties` - -SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. -To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. - -Contents of the `setenv.sh` file should look like: - -```bash -export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" -``` - - -### Smoke testing your deployed system - -**Step 1**. Install HTTPIE -`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed -and started correctly on our server. - -If you have Python and its package manager `pip` installed. Then You can issue below command: - -```bash -pip install httpie -``` - -**Step 2**. Download a sample JSON request file. - -```bash -http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdocPass.json -``` - -**Step 3**. After successful download issue below command in same directory where you downloaded the file using -the command below. - -```bash -http POST http://localhost:8080/validate < bdocPass.json -``` -**Step 4**. Verify the output. The output of previous command should have similar data as below screenshot. Look for `signatureCount` and -`validSignatureCount`, they **must** be equal. - - -![HTTPIE output validation](../img/siva/siva2-output.png) - - -## Logging - -By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. - -For example, adding application.properties to classpath with the **logging.config** property -```bash -logging.config=/path/to/logback.xml -``` - -## Statistics - -For every report validated, a statistical report is composed that collects the following data: - -| Data | Description | -| ----- | ----- | -| Validation duration | The time it takes to process an incoming request - measured in milliseconds | -| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, ASiC-S or ASiC-E (BatchSignature) ) | -| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | -| Total signatures count | The value of the `signaturesCount` element in the validation report -| Valid signatures count | The value of the `validSignaturesCount` element in the validation report -| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | -| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | -| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | - -There are two channels where this information is sent: - -1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. - -2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. - -The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) - -## Monitoring - -SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. - -!!! note - Note that this endpoint is disabled by default. - - -The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. - -* **Enabling and disabling the monitoring endpoint** - -To enable the endpoint, use the following configuration parameter: -```bash -endpoints.health.enabled=true -``` - -* **Customizing external service health indicators** - -The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. - -Demo webapp and Siva webapp also include additional information about the health of their dependent services. -These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. - -However, using the following parameters, these links can be overridden: - -| Property | Description | -| -------- | ----------- | -|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| -|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| -|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| - -For example: -```bash -endpoints.health.links[0].name=linkToXroad -endpoints.health.links[0].url=http://localhost:7777/monitoring/health -endpoints.health.links[0].timeout=1000 -``` - -!!! note - The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . - - -## Validation Report Signature - -SiVa provides the ability to sign the validation report. The idea of supplementing the validation report with a validation report signature is to prove the authority's authenticity and integrity over the validation. - -!!! note - Signing of validation report is disabled by default - -To enable it, use the following configuration parameter: -```bash -siva.report.reportSignatureEnabled=true -``` - -When validation report signature is enabled, only detailed validation reports will be signed, simple reports will not be signed. -The validation report's digital signature is composed out of response's `validationReport` object. The target format of the signature is ASiC-E (signature level is configurable). The ASiC-E container contents are encoded into Base64 and put on the same level int the response as the validation report itself. - -!!! note - Enabling the validation report signing will affect the performance of the service. - -Example structure of the response containing report signature: - -```json -{ - "validationReport": { - ... - }, - "validationReportSignature": "ZHNmYmhkZmdoZGcgZmRmMTM0NTM..." -} -``` - -Supported interfaces for signature creation: - -* **PKCS#11** - a platform-independent API for cryptographic tokens, such as hardware security modules (HSM) and smart cards -* **PKCS#12** - for files bundled with private key and certificate - -Report signature configuration parameters: - -Property | Description | -| -------- | ----------- | -|**siva.report.reportSignatureEnabled**| Enables signing of the validation report. Validation report will only be signed when requesting detailed report.
  • Default: **false**
| -|**siva.signatureService.signatureLevel**| The level of the validation report signature.
**Example values:**
* XAdES_BASELINE_B
* XAdES_BASELINE_T
* XAdES_BASELINE_LT
* XAdES_BASELINE_LTA | -|**siva.signatureService.tspUrl**| URL of the timestamp provider.
Only needed when the configured signature level is at least XAdES_BASELINE_T | -|**siva.signatureService.ocspUrl**| URL of the OCSP provider.
Only needed when the configured signature level is at least XAdES_BASELINE_LT | -|**siva.signatureService.pkcs11.path**| path to PKCS#11 module (depends on your installed smart card or hardware token library, for example: /usr/local/lib/opensc-pkcs11.so) | -|**siva.signatureService.pkcs11.password**| pin/password of the smart card or hardware token | -|**siva.signatureService.pkcs11.slotIndex**| depends on the hardware token. E.g. Estonian Smart Card uses 2, USB eToken uses 0.
  • Default: **0**
| -|**siva.signatureService.pkcs12.path**| path to keystore file containing certificate and private key | -|**siva.signatureService.pkcs12.password**| password of the keystore file containing certificate and private key | - -!!! note - When configuring report signature, either PKCS#11 or PKCS#12 should be configured, no need to configure both. - --------------------------------------------------------------------------------------- -## Configuration parameters - -All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. -However, all the properties can be overridden on the service or embedded web server level, if necessary. - -By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. -Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. - -For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: -```bash -server.port=8080 -``` - -Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: -```bash -server.max-http-post-size: 13981016 -``` - -See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot - -### Siva webapp parameters - -* Updating TSL - -| Property | Description | -| -------- | ----------- | -| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| -| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| -| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| -| **siva.tsl.loader.trustedTerritories** | Sets the trusted territories by countries
  • Default: **"AT", "BE", "BG", "CY", "CZ", "DE", "DK", "EE", "ES", "FI", "FR", "GR", "HU", "HR", "IE", "IS", "IT", "LT", "LU", "LV", "LI", "MT", "NO", "NL", "PL", "PT", "RO", "SE", "SI", "SK", "UK"**
| -| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 \* * ?**
| -| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| -| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| -| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| - -!!! note - Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). - -!!! note - TSL is currently used only by Generic and BDOC validators - - -* Forward to custom X-road webapp instance - -| Property | Description | -| ------ | ----------- | -| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| - -* Collecting statistics with Google Analytics - -| Property | Description | -| -------- | ----------- | -| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| -| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| -| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| -| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| - -* BDOC validation parameters - -| Property | Description | -| -------- | ----------- | -| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| - -Customizing BDOC validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.bdoc.signaturePolicy.policies[0].name=POLv3 -siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml - -siva.bdoc.signaturePolicy.policies[1].name=POLv4 -siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 -siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml - -siva.bdoc.signaturePolicy.defaultPolicy=POLv4 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* Generic validation - customize validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.europe.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.europe.signaturePolicy.policies[0].name=POLv3 -siva.europe.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.europe.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.europe.signaturePolicy.policies[0].constraintPath=generic_constraint_ades.xml - -siva.europe.signaturePolicy.policies[1].name=POLv4 -siva.europe.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.europe.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 -siva.europe.signaturePolicy.policies[1].constraintPath=generic_constraint_qes.xml - -siva.europe.signaturePolicy.defaultPolicy=POLv4 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* DDOC validation - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| - -Customizing DDOC validation policies: - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.ddoc.signaturePolicy.policies[0].name=POLv3 -siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.ddoc.signaturePolicy.policies[0].constraintPath=ddoc_constraint_no_type.xml - -siva.ddoc.signaturePolicy.policies[1].name=POLv4 -siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 -siva.ddoc.signaturePolicy.policies[1].constraintPath=ddoc_constraint_qes.xml - -siva.ddoc.signaturePolicy.defaultPolicy=POLv4 -``` -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* X-road validation - -| Property | Description | -| -------- | ----------- | -|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| - - -| Property | Description | -| -------- | ----------- | -|**siva.xroad.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.xroad.signaturePolicy.policies[0].name=POLv3 -siva.xroad.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.xroad.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.xroad.signaturePolicy.policies[0].constraintPath=xroad_constraint_no_type.xml - -siva.xroad.signaturePolicy.defaultPolicy= POLv3 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) -!!! note - By default, X-road validation currently supports only POLv3 - -### Demo webapp parameters - -* Linking to SiVa webapp - -| Property | Description | -| -------- | ----------- | -|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| -|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| -|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| -|**siva.service.jsonDataFilesServicePath**| Data file service path in Siva webapp to access the REST/JSON API
  • Default: **/getDataFiles**
| -|**siva.service.soapDataFilesServicePath**| Data file service path in Siva webapp to access the SOAP API
  • Default: **/soap/dataFilesWebService/getDocumentDataFiles**
| - +This guide describes how to integrate SiVa service with other applications. +The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. + +### System requirements + +Following are the minimum requirements to build and deploy SiVa webapps as a service: + +* Java 8 or above Oracle JVM is supported +* Git version control system version 1.8 or above is recommended +* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM +* Minimum 1 processor core +* Open internet connection +* 2GB of free disk space +* Supported operating system is Ubuntu 16.04 LTS + +## Building + +### Building SiVa webapps on Ubuntu 16.04 + +First we need to install Git and Java SDK 8 by issuing below commands: + +```bash +sudo apt-get update +sudo apt-get install git -y +sudo apt-get install default-jdk -y +``` + +Next we need to clone the SiVa Github repository: + +```bash +git clone https://github.com/open-eid/SiVa.git --branch master +``` + +Final step is building the SiVa project using Maven Wrapper + +```bash +cd SiVa +./mvnw clean install +``` + +!!! note + The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the + required dependencies + +To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. +The last lines of build output should look very similar to below image: + +```text +[INFO] Reactor Summary: +[INFO] +[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 1.632 s] +[INFO] validation-services-parent ......................... SUCCESS [ 0.897 s] +[INFO] validation-commons ................................. SUCCESS [ 12.321 s] +[INFO] tsl-loader ......................................... SUCCESS [ 6.917 s] +[INFO] Generic Validation Service ......................... SUCCESS [ 27.919 s] +[INFO] TimeStampToken Validation Service .................. SUCCESS [ 7.046 s] +[INFO] BDOC Validation Service ............................ SUCCESS [ 50.087 s] +[INFO] DDOC Validation Service ............................ SUCCESS [ 16.712 s] +[INFO] SiVa webapp and other core modules ................. SUCCESS [ 0.653 s] +[INFO] siva-monitoring .................................... SUCCESS [ 9.736 s] +[INFO] xroad-validation-service ........................... SUCCESS [ 19.761 s] +[INFO] siva-statistics .................................... SUCCESS [ 13.734 s] +[INFO] SiVa validation service proxy ...................... SUCCESS [ 11.509 s] +[INFO] SiVa signature service ............................. SUCCESS [ 6.869 s] +[INFO] siva-webapp ........................................ SUCCESS [ 27.608 s] +[INFO] SiVa Web Service integration tests ................. SUCCESS [03:53 min] +[INFO] siva-distribution .................................. SUCCESS [ 10.818 s] +[INFO] ------------------------------------------------------------------------ +[INFO] BUILD SUCCESS +[INFO] ------------------------------------------------------------------------ +[INFO] Total time: 08:18 min +[INFO] Finished at: 2017-12-04T13:49:48+02:00 +[INFO] Final Memory: 113M/903M +[INFO] ------------------------------------------------------------------------ +``` + + +## Deploying + +### OPTION 1 - starting webapps from command line +SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the +project by issuing below commands: + +**First start the Siva webapp** + +```bash +./siva-parent/siva-webapp/target/siva-webapp-3.0.0.jar +``` + +**Second we need to start X-road validation webapp** + +```bash +./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.0.0.jar +``` + +The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. +Easiest way to test out validation is run [SiVa demo application](https://github.com/open-eid/SiVa-demo-application). + +### OPTION 2 - running webapps as systemd services + +Maven build generates executable JAR files. This means web container and all its dependencies are package inside +single JAR file. It makes a lot easier to deploy it into servers. + +Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. + +For that we first need to create service file: +```bash +vim siva-webapp.service +``` + +Inside it we need to paste below text. You need to change few things in service setup file. + +* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` +* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. +* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file + +```ini +[Unit] +Description=siva-webapp +After=syslog.target + +[Service] +User=root +ExecStart=/var/apps/siva-webapp.jar +Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 +SuccessExitStatus=143 + +[Install] +WantedBy=multi-user.target +``` + +Save and close the `siva-webapp.service` file. +Next we need to move `siva-webapp-3.0.0.jar` into newly created `/var/apps` directory and rename to +JAR file to `siva-webapp.jar`. match + +!!! note + The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file + +```bash +sudo mkdir /var/apps +sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.0.0.jar /var/apps/siva-webapp.jar +``` + +Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. +Then we are ready to start the `siva-webapp` service. + +```bash +sudo cp siva-webapp.service /lib/systemd/system +sudo systemctl start siva-webapp +``` + +Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below +command. + +```bash +systemctl status siva-webapp +``` + +It should print out similar to below picture: + +``` +● siva-webapp.service - siva-webapp + Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) + Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago + Main PID: 15965 (siva-webapp.jar) + Tasks: 34 + Memory: 429.6M + CPU: 2min 5.721s + CGroup: /system.slice/siva-webapp.service + ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar + └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar + +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +``` + +### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) + +> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet +> containers also possible container application libraries conflicts + +> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version +> conflicts. + +> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - +the http connector parameter `maxPostSize` should be configured with the desired limit. + +> **NOTE 4**: The war file must be deployed to Tomcat ROOT. + +First we need to download Tomcat web servlet container as of the writing latest version available in version 8 branch is 8.5.24. We will download it with `wget` + +```bash +wget http://www-eu.apache.org/dist/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gz +``` + +Unpack it somewhere: + +```bash +tar xf apache-tomcat-8.5.24.tar.gz +``` + +Now we should build the WAR file. We have created helper script with all the correct Maven parameters. + +```bash +./war-build.sh +``` + +> **NOTE** The script will skip running the integration tests when building WAR files + +Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. + +```bash +cp siva-parent/siva-webapp/target/siva-webapp-3.0.0.war apache-tomcat-8.5.24/webapps +./apache-tomcat-7.0.77/bin/catalina.sh run +``` + +> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates +> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change +> this default behavior you should set environment variable `DSS_DATA_FOLDER` + +### How-to set WAR deployed SiVa `application.properties` + +SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. +To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. + +Contents of the `setenv.sh` file should look like: + +```bash +export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" +``` + + +### Smoke testing your deployed system + +**Step 1**. Install HTTPIE +`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed +and started correctly on our server. + +If you have Python and its package manager `pip` installed. Then You can issue below command: + +```bash +pip install httpie +``` + +**Step 2**. Download a sample JSON request file. + +```bash +http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdocPass.json +``` + +**Step 3**. After successful download issue below command in same directory where you downloaded the file using +the command below. + +```bash +http POST http://localhost:8080/validate < bdocPass.json +``` +**Step 4**. Verify the output. The output of previous command should have similar data as below screenshot. Look for `signatureCount` and +`validSignatureCount`, they **must** be equal. + + +![HTTPIE output validation](../img/siva/siva2-output.png) + + +## Logging + +By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. + +For example, adding application.properties to classpath with the **logging.config** property +```bash +logging.config=/path/to/logback.xml +``` + +## Statistics + +For every report validated, a statistical report is composed that collects the following data: + +| Data | Description | +| ----- | ----- | +| Validation duration | The time it takes to process an incoming request - measured in milliseconds | +| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, ASiC-S or ASiC-E (BatchSignature) ) | +| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | +| Total signatures count | The value of the `signaturesCount` element in the validation report +| Valid signatures count | The value of the `validSignaturesCount` element in the validation report +| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | +| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | +| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | + +There are two channels where this information is sent: + +1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. + +2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. + +The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) + +## Monitoring + +SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. + +!!! note + Note that this endpoint is disabled by default. + + +The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. + +* **Enabling and disabling the monitoring endpoint** + +To enable the endpoint, use the following configuration parameter: +```bash +endpoints.health.enabled=true +``` + +* **Customizing external service health indicators** + +The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. + +Demo webapp and Siva webapp also include additional information about the health of their dependent services. +These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. + +However, using the following parameters, these links can be overridden: + +| Property | Description | +| -------- | ----------- | +|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| +|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| +|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| + +For example: +```bash +endpoints.health.links[0].name=linkToXroad +endpoints.health.links[0].url=http://localhost:7777/monitoring/health +endpoints.health.links[0].timeout=1000 +``` + +!!! note + The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . + + +## Validation Report Signature + +SiVa provides the ability to sign the validation report. The idea of supplementing the validation report with a validation report signature is to prove the authority's authenticity and integrity over the validation. + +!!! note + Signing of validation report is disabled by default + +To enable it, use the following configuration parameter: +```bash +siva.report.reportSignatureEnabled=true +``` + +When validation report signature is enabled, only detailed validation reports will be signed, simple reports will not be signed. +The validation report's digital signature is composed out of response's `validationReport` object. The target format of the signature is ASiC-E (signature level is configurable). The ASiC-E container contents are encoded into Base64 and put on the same level int the response as the validation report itself. + +!!! note + Enabling the validation report signing will affect the performance of the service. + +Example structure of the response containing report signature: + +```json +{ + "validationReport": { + ... + }, + "validationReportSignature": "ZHNmYmhkZmdoZGcgZmRmMTM0NTM..." +} +``` + +Supported interfaces for signature creation: + +* **PKCS#11** - a platform-independent API for cryptographic tokens, such as hardware security modules (HSM) and smart cards +* **PKCS#12** - for files bundled with private key and certificate + +Report signature configuration parameters: + +Property | Description | +| -------- | ----------- | +|**siva.report.reportSignatureEnabled**| Enables signing of the validation report. Validation report will only be signed when requesting detailed report.
  • Default: **false**
| +|**siva.signatureService.signatureLevel**| The level of the validation report signature.
**Example values:**
* XAdES_BASELINE_B
* XAdES_BASELINE_T
* XAdES_BASELINE_LT
* XAdES_BASELINE_LTA | +|**siva.signatureService.tspUrl**| URL of the timestamp provider.
Only needed when the configured signature level is at least XAdES_BASELINE_T | +|**siva.signatureService.ocspUrl**| URL of the OCSP provider.
Only needed when the configured signature level is at least XAdES_BASELINE_LT | +|**siva.signatureService.pkcs11.path**| path to PKCS#11 module (depends on your installed smart card or hardware token library, for example: /usr/local/lib/opensc-pkcs11.so) | +|**siva.signatureService.pkcs11.password**| pin/password of the smart card or hardware token | +|**siva.signatureService.pkcs11.slotIndex**| depends on the hardware token. E.g. Estonian Smart Card uses 2, USB eToken uses 0.
  • Default: **0**
| +|**siva.signatureService.pkcs12.path**| path to keystore file containing certificate and private key | +|**siva.signatureService.pkcs12.password**| password of the keystore file containing certificate and private key | + +!!! note + When configuring report signature, either PKCS#11 or PKCS#12 should be configured, no need to configure both. + +-------------------------------------------------------------------------------------- +## Configuration parameters + +All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. +However, all the properties can be overridden on the service or embedded web server level, if necessary. + +By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. +Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. + +For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: +```bash +server.port=8080 +``` + +Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: +```bash +server.max-http-post-size: 13981016 +``` + +See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot + +### Siva webapp parameters + +* Updating TSL + +| Property | Description | +| -------- | ----------- | +| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| +| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| +| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| +| **siva.tsl.loader.trustedTerritories** | Sets the trusted territories by countries
  • Default: **"AT", "BE", "BG", "CY", "CZ", "DE", "DK", "EE", "ES", "FI", "FR", "GR", "HU", "HR", "IE", "IS", "IT", "LT", "LU", "LV", "LI", "MT", "NO", "NL", "PL", "PT", "RO", "SE", "SI", "SK", "UK"**
| +| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 \* * ?**
| +| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| +| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| +| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| + +!!! note + Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). + +!!! note + TSL is currently used only by Generic and BDOC validators + + +* Forward to custom X-road webapp instance + +| Property | Description | +| ------ | ----------- | +| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| + +* Collecting statistics with Google Analytics + +| Property | Description | +| -------- | ----------- | +| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| +| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| +| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| +| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| + +* BDOC validation parameters + +| Property | Description | +| -------- | ----------- | +| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| + +Customizing BDOC validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.bdoc.signaturePolicy.policies[0].name=POLv3 +siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml + +siva.bdoc.signaturePolicy.policies[1].name=POLv4 +siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 +siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml + +siva.bdoc.signaturePolicy.defaultPolicy=POLv4 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* Generic validation - customize validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.europe.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.europe.signaturePolicy.policies[0].name=POLv3 +siva.europe.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.europe.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.europe.signaturePolicy.policies[0].constraintPath=generic_constraint_ades.xml + +siva.europe.signaturePolicy.policies[1].name=POLv4 +siva.europe.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.europe.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 +siva.europe.signaturePolicy.policies[1].constraintPath=generic_constraint_qes.xml + +siva.europe.signaturePolicy.defaultPolicy=POLv4 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* DDOC validation + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| + +Customizing DDOC validation policies: + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.ddoc.signaturePolicy.policies[0].name=POLv3 +siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.ddoc.signaturePolicy.policies[0].constraintPath=ddoc_constraint_no_type.xml + +siva.ddoc.signaturePolicy.policies[1].name=POLv4 +siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 +siva.ddoc.signaturePolicy.policies[1].constraintPath=ddoc_constraint_qes.xml + +siva.ddoc.signaturePolicy.defaultPolicy=POLv4 +``` +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* X-road validation + +| Property | Description | +| -------- | ----------- | +|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| + + +| Property | Description | +| -------- | ----------- | +|**siva.xroad.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.xroad.signaturePolicy.policies[0].name=POLv3 +siva.xroad.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.xroad.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.xroad.signaturePolicy.policies[0].constraintPath=xroad_constraint_no_type.xml + +siva.xroad.signaturePolicy.defaultPolicy= POLv3 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) +!!! note + By default, X-road validation currently supports only POLv3 + +### Demo webapp parameters + +* Linking to SiVa webapp + +| Property | Description | +| -------- | ----------- | +|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| +|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| +|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| +|**siva.service.jsonDataFilesServicePath**| Data file service path in Siva webapp to access the REST/JSON API
  • Default: **/getDataFiles**
| +|**siva.service.soapDataFilesServicePath**| Data file service path in Siva webapp to access the SOAP API
  • Default: **/soap/dataFilesWebService/getDocumentDataFiles**
| + diff --git a/docs/siva3/appendix/known_issues.md b/docs/siva3/appendix/known_issues.md index 3fcd1b2b4..fac0a7411 100644 --- a/docs/siva3/appendix/known_issues.md +++ b/docs/siva3/appendix/known_issues.md @@ -1,4 +1,4 @@ - - -## Known issues + + +## Known issues All known issues should be reported and managed under GitHub project [issues section](https://github.com/open-eid/SiVa/issues) \ No newline at end of file diff --git a/docs/siva3/appendix/validation_policy.md b/docs/siva3/appendix/validation_policy.md index a8a7020c0..df6b20e64 100644 --- a/docs/siva3/appendix/validation_policy.md +++ b/docs/siva3/appendix/validation_policy.md @@ -1,212 +1,212 @@ -# SiVa Signature Validation Policy - -## Introduction -This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). - -### Versioning - -Different policy versions may be used by the service in the following conditions: - -* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; -* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); -* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. -* for later reference, previous versions of validation policy documents should remain available for the Service's users. - -The following validation policy versions are supported in SiVa 2.0 and 3.0 service: - -1. [**SiVA Signature Validation Policy - Version 3 (POLv3)**](#POLv3) -2. [**SiVA Signature Validation Policy - Version 4 (POLv4)**](#POLv4) - -The following validation policy versions are marked as obsolete in SiVa 2.0 service: - -1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1) -2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2) - -### General principles of SiVa validation policies - -1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. -* All rules described for electronic signatures also apply for electronic seals and digital stamps if not explicitly stated otherwise. -* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: - * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#common_format) section). - * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](#common_libraries) section). - -!!! note - When no specific validation rule is set in the present document, the requirements and rules from the aforementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. - - -## SiVA Signature Validation Policy - Version 3 (POLv3) - - -### Description -Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. - -### URL - -``` -http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv3 -``` - -### POLv3 validation constraints -1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: - * Qualified Certificate (QC) requirement - * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * Signer certificate may or may not comply with SSCD/QSCD criteria. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. -* Constraints defined in the [Common validation constraints (POLv3, POLv4)](#common_POLv3_POLv4) section - - -## SiVA Signature Validation Policy - Version 4 (POLv4) - - -### Description -Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - -### URL - -``` -http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4 -``` - -### POLv4 validation constraints - -1. The requirements for the signature level depend on signature type. - * Qualified Certificate (QC) requirement - * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. - * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * In case of Signatures, signer certificate should comply with SSCD/QSCD criteria, otherwise warning is returned. - * In case of Seals, there is no requirement for SSCD/QSCD criteria. - * If it is not possible to determine the signature type, it must comply with SSCD/QSCD criteria. - * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. - * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: - * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://www.skidsolutions.eu/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://www.skidsolutions.eu/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). -* Constraints defined in the [Common validation constraints (POLv3, POLv4)](#common_POLv3_POLv4) section - - -## Common validation constraints (POLv3, POLv4) - - -### General constraints - -1. The validation result returned by SiVa determines whether a signature is technically valid and depending of a container type also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** -2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result corresponding to the collection of signatures is not determined. - -### Signature format constraints - - -1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: - - * [BDOC 2.1](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures - * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures - * [XAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf) signatures - * [CAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.01.01_60/en_31912201v010101p.pdf) signatures - * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures - * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](https://open-eid.github.io/allkirjastamisteenus/json-technical-description/#hashcode-container-form) - -### Base libraries' constraints - - -1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: - - * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate signatures in BDOC 2.1 and DDOC format - * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate all other signature formats than mentioned above - -### Baseline Profile constraints -1. The signature must comply with Baseline Profile of the respective signature format: - * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) - * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) - * [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) -2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. -3. The following table describes supported Baseline Profile levels, according to signature formats: - -| Signature format | BASELINE_B | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | -|--|--|--|--|--|--| -|**BDOC** | NOK | NOK| NOK | **OK** | NOK | -|**PAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**XAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**CAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**DIGIDOC-XML 1.0...1.3**| NOK | NOK | NOK | **OK** | NOK | -|**DIGIDOC-XML 1.0...1.3 hashcode**| NOK | NOK | NOK | **OK** | NOK | - -Legend: - -* OK - the respective Baseline Profile level is supported and acceptable. -* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. - - -### X.509 validation constraints - -1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). - - -### Cryptographic algorithm constraints -1. Hash algorithm constraints: - * In case of BDOC format: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. -2. Asymmetric cryptographic algorithm constraints: - * RSA and ECC cryptographic algorithms are supported - * In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key length must be at least 1024 bits and ECC key length at least 192 bits. - -### Trust anchor constraints -1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. -2. Trust Anchors are: - * In case of XAdES/CAdES/PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). - * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://www.skidsolutions.eu/en/repository/certs/), defined in local configuration file. - - -### Revocation data constraints -1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. -2. The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960) or as a Certificate Revocation List. -3. No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. -4. Checking revocation of certificates regarded as Trust Anchors: - * In case of DIGIDOC-XML 1.0...1.3 format: revocation of Trust Anchor certificates is not checked. - * In case of XAdES/CAdES/PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. - - -### Signer certificate's revocation freshness constraints -1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. -2. In case of XAdES/CAdES/PAdES BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: - * In case of Estonian signature's OCSP response, if the difference between signature's time-stamp's production time (genTime field) and signer certificate's OCSP confirmation’s production time (producedAt field) is more than 24 hours, then the signature is considered invalid. If the difference is more than 15 minutes and less than 24h, then a validation warning is returned. - * In case of Certificate Revocation List the signature time-stamp's production time (genTime field) must be within validity range of the CRL (between thisUpdate and nextUpdate) - - -### Trusted signing time constraints -1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: - * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. - * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. - * In case of basic signature (BASELINE_B) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. -2. In case of QES signature with (archive) time-stamp or ASiC-S with time stamp token, only qualified time-stamps are allowed (TSA/QTST services only). - - -### BDOC container specific requirements -The BDOC container must conform with [BDOC 2.1](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf) standard. - -1. File extension `.bdoc` is supported during signature validation. -2. Only one signature shall be stored in one `signatures.xml` file. -3. All signatures in the container must sign all of the data files. -4. All data files in the container must be signed, i.e. all files in the container, except of `mimetype` file and the files in `META-INF/` folder, must be signed. -5. Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. -6. Only relative file paths are supported, for example `META-INF/signatures.xml` and `document.txt` instead of `/META-INF/signatures.xml` and `/document.txt`. -7. `META-INF/manifest.xml` file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). - -### ASICE container specific requirements -The ASICE container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) standard. - -1. Warning is returned when signatures in the container do not sign all of the data files. -2. Manifest file must be present. - -### ASICS container specific requirements -The service supports both signature and time-stamp token (TST) based ASiC-S containers. Evidence record based containers are not supported. The ASiC-S container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) and [ETSI EN 319 162-2](http://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf) standards. - -1. Manifest file can not be present in case of signature-based ASiC-S containers. -2. Only one data file is present in an ASiC-S container. -3. One or more time-stamp tokens per container is supported: - - Only one `META-INF/timestamp.tst` can be present. - - In case of multiple timestamps, each following time-stamp token must have a unique name (e.g., `timestamp001.tst`). -4. There must not be any of the following files in the ASiC-S container: - - `META-INF/signature.p7s` - - `META-INF/signatures.xml` - - `META-INF/evidencerecord.ers` - - `META-INF/evidencerecord.xml` -5. Time-stamp tokens of ASiC-S containers are validated via DSS (TSL verification is performed). +# SiVa Signature Validation Policy + +## Introduction +This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). + +### Versioning + +Different policy versions may be used by the service in the following conditions: + +* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; +* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); +* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. +* for later reference, previous versions of validation policy documents should remain available for the Service's users. + +The following validation policy versions are supported in SiVa 2.0 and 3.0 service: + +1. [**SiVA Signature Validation Policy - Version 3 (POLv3)**](#POLv3) +2. [**SiVA Signature Validation Policy - Version 4 (POLv4)**](#POLv4) + +The following validation policy versions are marked as obsolete in SiVa 2.0 service: + +1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1) +2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2) + +### General principles of SiVa validation policies + +1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. +* All rules described for electronic signatures also apply for electronic seals and digital stamps if not explicitly stated otherwise. +* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: + * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#common_format) section). + * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](#common_libraries) section). + +!!! note + When no specific validation rule is set in the present document, the requirements and rules from the aforementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. + + +## SiVA Signature Validation Policy - Version 3 (POLv3) + + +### Description +Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. + +### URL + +``` +http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv3 +``` + +### POLv3 validation constraints +1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: + * Qualified Certificate (QC) requirement + * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * Signer certificate may or may not comply with SSCD/QSCD criteria. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. +* Constraints defined in the [Common validation constraints (POLv3, POLv4)](#common_POLv3_POLv4) section + + +## SiVA Signature Validation Policy - Version 4 (POLv4) + + +### Description +Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + +### URL + +``` +http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4 +``` + +### POLv4 validation constraints + +1. The requirements for the signature level depend on signature type. + * Qualified Certificate (QC) requirement + * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. + * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * In case of Signatures, signer certificate should comply with SSCD/QSCD criteria, otherwise warning is returned. + * In case of Seals, there is no requirement for SSCD/QSCD criteria. + * If it is not possible to determine the signature type, it must comply with SSCD/QSCD criteria. + * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. + * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: + * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://www.skidsolutions.eu/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://www.skidsolutions.eu/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). +* Constraints defined in the [Common validation constraints (POLv3, POLv4)](#common_POLv3_POLv4) section + + +## Common validation constraints (POLv3, POLv4) + + +### General constraints + +1. The validation result returned by SiVa determines whether a signature is technically valid and depending of a container type also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** +2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result corresponding to the collection of signatures is not determined. + +### Signature format constraints + + +1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: + + * [BDOC 2.1](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures + * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures + * [XAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf) signatures + * [CAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.01.01_60/en_31912201v010101p.pdf) signatures + * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures + * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](https://open-eid.github.io/allkirjastamisteenus/json-technical-description/#hashcode-container-form) + +### Base libraries' constraints + + +1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: + + * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate signatures in BDOC 2.1 and DDOC format + * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate all other signature formats than mentioned above + +### Baseline Profile constraints +1. The signature must comply with Baseline Profile of the respective signature format: + * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) + * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) + * [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) +2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. +3. The following table describes supported Baseline Profile levels, according to signature formats: + +| Signature format | BASELINE_B | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | +|--|--|--|--|--|--| +|**BDOC** | NOK | NOK| NOK | **OK** | NOK | +|**PAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**XAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**CAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**DIGIDOC-XML 1.0...1.3**| NOK | NOK | NOK | **OK** | NOK | +|**DIGIDOC-XML 1.0...1.3 hashcode**| NOK | NOK | NOK | **OK** | NOK | + +Legend: + +* OK - the respective Baseline Profile level is supported and acceptable. +* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. + + +### X.509 validation constraints + +1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). + + +### Cryptographic algorithm constraints +1. Hash algorithm constraints: + * In case of BDOC format: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. +2. Asymmetric cryptographic algorithm constraints: + * RSA and ECC cryptographic algorithms are supported + * In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key length must be at least 1024 bits and ECC key length at least 192 bits. + +### Trust anchor constraints +1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. +2. Trust Anchors are: + * In case of XAdES/CAdES/PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). + * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://www.skidsolutions.eu/en/repository/certs/), defined in local configuration file. + + +### Revocation data constraints +1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. +2. The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960) or as a Certificate Revocation List. +3. No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. +4. Checking revocation of certificates regarded as Trust Anchors: + * In case of DIGIDOC-XML 1.0...1.3 format: revocation of Trust Anchor certificates is not checked. + * In case of XAdES/CAdES/PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. + + +### Signer certificate's revocation freshness constraints +1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. +2. In case of XAdES/CAdES/PAdES BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: + * In case of Estonian signature's OCSP response, if the difference between signature's time-stamp's production time (genTime field) and signer certificate's OCSP confirmation’s production time (producedAt field) is more than 24 hours, then the signature is considered invalid. If the difference is more than 15 minutes and less than 24h, then a validation warning is returned. + * In case of Certificate Revocation List the signature time-stamp's production time (genTime field) must be within validity range of the CRL (between thisUpdate and nextUpdate) + + +### Trusted signing time constraints +1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: + * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. + * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. + * In case of basic signature (BASELINE_B) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. +2. In case of QES signature with (archive) time-stamp or ASiC-S with time stamp token, only qualified time-stamps are allowed (TSA/QTST services only). + + +### BDOC container specific requirements +The BDOC container must conform with [BDOC 2.1](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf) standard. + +1. File extension `.bdoc` is supported during signature validation. +2. Only one signature shall be stored in one `signatures.xml` file. +3. All signatures in the container must sign all of the data files. +4. All data files in the container must be signed, i.e. all files in the container, except of `mimetype` file and the files in `META-INF/` folder, must be signed. +5. Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. +6. Only relative file paths are supported, for example `META-INF/signatures.xml` and `document.txt` instead of `/META-INF/signatures.xml` and `/document.txt`. +7. `META-INF/manifest.xml` file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). + +### ASICE container specific requirements +The ASICE container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) standard. + +1. Warning is returned when signatures in the container do not sign all of the data files. +2. Manifest file must be present. + +### ASICS container specific requirements +The service supports both signature and time-stamp token (TST) based ASiC-S containers. Evidence record based containers are not supported. The ASiC-S container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) and [ETSI EN 319 162-2](http://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf) standards. + +1. Manifest file can not be present in case of signature-based ASiC-S containers. +2. Only one data file is present in an ASiC-S container. +3. One or more time-stamp tokens per container is supported: + - Only one `META-INF/timestamp.tst` can be present. + - In case of multiple timestamps, each following time-stamp token must have a unique name (e.g., `timestamp001.tst`). +4. There must not be any of the following files in the ASiC-S container: + - `META-INF/signature.p7s` + - `META-INF/signatures.xml` + - `META-INF/evidencerecord.ers` + - `META-INF/evidencerecord.xml` +5. Time-stamp tokens of ASiC-S containers are validated via DSS (TSL verification is performed). diff --git a/docs/siva3/definitions.md b/docs/siva3/definitions.md index 5757cc818..304c0db43 100644 --- a/docs/siva3/definitions.md +++ b/docs/siva3/definitions.md @@ -1,43 +1,43 @@ - - -BDOC -: A digital signature format that was created in order to replace the DDOC (DigiDoc) digital signature format that is specific to Estonia. - -DDOC -: A format of digitally signed files based on the ETSI TS 101 903 Standard that is called ‘XML Advanced Electronic Signatures (XAdES)’. The standard describes the structure of digitally signed documents on various levels of incorporation of additional validity verification information. DigiDoc corresponds to the XAdES profile ‘XAdES-X-L’. - -DSS -: Digital Signature Services is Java library to sign and validate European digital signature formats - -Fat JAR -: The fat JAR is the JAR, which contains classes from all the libraries, on which your project depends and, - the classes of built project. - -JAR -: Java Archive is a package file format typically used to aggregate many Java class files and associated metadata - and resources (text, images, etc.) into one file to distribute application software or libraries on the Java platform. - -JVM -: The Java Virtual Machine is the runtime engine of the Java Platform, which - allows any program written in Java or other language compiled into Java bytecode to run on any - computer that has a native JVM. - -Linux -: an operating system, based on UNIX, that runs on many different hardware platforms and whose source - code is available to the public. - -PDF -: Portable document format is a file format that provides an electronic image of text or text and graphics that - looks like a printed document and can be viewed, printed, and electronically transmitted. - -SiVa -: is RESTful web service providing digital signature validation services for BDOC, DDOC and PDF - files - -Spring Boot -: is a framework from the team at Pivotal, designed to simplify the bootstrapping and development of a new - Spring application. The framework takes an opinionated approach to configuration, freeing developers from the - need to define boilerplate configuration - -X-Road -: X-Road, the data exchange layer for information systems, is a technological and organizational environment enabling a secure Internet-based data exchange between information systems. + + +BDOC +: A digital signature format that was created in order to replace the DDOC (DigiDoc) digital signature format that is specific to Estonia. + +DDOC +: A format of digitally signed files based on the ETSI TS 101 903 Standard that is called ‘XML Advanced Electronic Signatures (XAdES)’. The standard describes the structure of digitally signed documents on various levels of incorporation of additional validity verification information. DigiDoc corresponds to the XAdES profile ‘XAdES-X-L’. + +DSS +: Digital Signature Services is Java library to sign and validate European digital signature formats + +Fat JAR +: The fat JAR is the JAR, which contains classes from all the libraries, on which your project depends and, + the classes of built project. + +JAR +: Java Archive is a package file format typically used to aggregate many Java class files and associated metadata + and resources (text, images, etc.) into one file to distribute application software or libraries on the Java platform. + +JVM +: The Java Virtual Machine is the runtime engine of the Java Platform, which + allows any program written in Java or other language compiled into Java bytecode to run on any + computer that has a native JVM. + +Linux +: an operating system, based on UNIX, that runs on many different hardware platforms and whose source + code is available to the public. + +PDF +: Portable document format is a file format that provides an electronic image of text or text and graphics that + looks like a printed document and can be viewed, printed, and electronically transmitted. + +SiVa +: is RESTful web service providing digital signature validation services for BDOC, DDOC and PDF + files + +Spring Boot +: is a framework from the team at Pivotal, designed to simplify the bootstrapping and development of a new + Spring application. The framework takes an opinionated approach to configuration, freeing developers from the + need to define boilerplate configuration + +X-Road +: X-Road, the data exchange layer for information systems, is a technological and organizational environment enabling a secure Internet-based data exchange between information systems. diff --git a/docs/siva3/deployment.md b/docs/siva3/deployment.md index 5b10c8a0d..c680bc57b 100644 --- a/docs/siva3/deployment.md +++ b/docs/siva3/deployment.md @@ -1,20 +1,20 @@ -The deployment view of the architecture describes the various physical nodes in the most typical configuration for SiVa service provider. - -![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) - -### Nodes - -In the following section, a description of each network node element is described in detail. - -| Node | Setup description | -|------|-------------| -| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used. | -| **Siva server** | The **SiVa webapp** service is set up to run on SiVa server.
SiVa web application is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.

There also should be separate user created to run executable JAR as Linux service.

Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service) | -| **X-road security server** | A standard X-road security server setup. SiVa validation service endpoints have to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentation (see the [official installation instructions](https://www.x-tee.ee/docs/live/xroad/ig-ss_x-road_v6_security_server_installation_guide.html)).| -| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation.
  • Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service.
| - -### Horizontal scaling - -Neither the **Siva webapp**, nor **Demo webapp** persist their state in sessions between requests. Therefore, it is possible to install multiple instances of these services behind respective load balancers. - - +The deployment view of the architecture describes the various physical nodes in the most typical configuration for SiVa service provider. + +![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) + +### Nodes + +In the following section, a description of each network node element is described in detail. + +| Node | Setup description | +|------|-------------| +| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used. | +| **Siva server** | The **SiVa webapp** service is set up to run on SiVa server.
SiVa web application is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.

There also should be separate user created to run executable JAR as Linux service.

Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service) | +| **X-road security server** | A standard X-road security server setup. SiVa validation service endpoints have to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentation (see the [official installation instructions](https://www.x-tee.ee/docs/live/xroad/ig-ss_x-road_v6_security_server_installation_guide.html)).| +| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation.
  • Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service.
| + +### Horizontal scaling + +Neither the **Siva webapp**, nor **Demo webapp** persist their state in sessions between requests. Therefore, it is possible to install multiple instances of these services behind respective load balancers. + + diff --git a/docs/siva3/deployment_guide.md b/docs/siva3/deployment_guide.md index 416fbaa45..24ee6a10f 100644 --- a/docs/siva3/deployment_guide.md +++ b/docs/siva3/deployment_guide.md @@ -1,548 +1,548 @@ -The following guide is for system integrators who need to set-up, configure, manage and troubleshoot SiVa service. - -### System requirements - -Following are the minimum requirements to build and deploy SiVa webapps as a service: - -* Java 11 or above is supported -* Git version control system version 1.8 or above is recommended -* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM -* Minimum 1 processor core -* Open internet connection -* 2GB of free disk space -* Supported operating system is Ubuntu 16.04 LTS - -## Building - -### Building SiVa webapps - -It is recommended to build the project with Maven Wrapper. Run following command in the projects main directory: - -```bash -./mvnw clean install -``` - -!!! note - The first time build can take up to **45 minutes** because of downloading the required dependencies, running vulnerability checks and unit tests. - -To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. -The last lines of build output should look very similar to below image: - -```text -[INFO] Reactor Summary: -[INFO] -[INFO] SiVa Digitally signed documents validation service X.X.X SUCCESS [ 2.089 s] -[INFO] validation-services-parent ......................... SUCCESS [ 0.380 s] -[INFO] validation-commons ................................. SUCCESS [ 13.782 s] -[INFO] tsl-loader ......................................... SUCCESS [ 9.372 s] -[INFO] Generic Validation Service ......................... SUCCESS [ 41.723 s] -[INFO] TimeStampToken Validation Service .................. SUCCESS [ 8.400 s] -[INFO] Time-mark container Validation Service ............. SUCCESS [ 36.508 s] -[INFO] SiVa webapp and other core modules ................. SUCCESS [ 0.374 s] -[INFO] siva-monitoring .................................... SUCCESS [ 11.982 s] -[INFO] siva-statistics .................................... SUCCESS [ 9.816 s] -[INFO] SiVa validation service proxy ...................... SUCCESS [ 14.861 s] -[INFO] SiVa signature service ............................. SUCCESS [ 7.801 s] -[INFO] siva-webapp ........................................ SUCCESS [ 42.451 s] -[INFO] SiVa Sample Web application ........................ SUCCESS [ 42.236 s] -[INFO] SiVa Web Service integration tests ................. SUCCESS [ 18.830 s] -[INFO] siva-distribution X.X.X ............................ SUCCESS [ 5.763 s] -[INFO] ------------------------------------------------------------------------ -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 04:46 min -[INFO] Finished at: 2020-07-03T14:22:02+03:00 -[INFO] ------------------------------------------------------------------------ - -``` - - -## Deploying - -### OPTION 1 - starting webapps from command line -SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the -project by issuing below commands: - -**First start the Siva webapp** - -```bash -./siva-parent/siva-webapp/target/siva-webapp-X.X.X.jar -``` - -The SiVa webapp by default runs on port **8080**. -Easiest way to test out the deployment is to run SiVa demo application and use it for validation. - -**Start the Demo webapp** - -```bash -./siva-parent/siva-sample-application/target/siva-sample-application-X.X.X.jar -``` - -Now point Your browser to URL: - - -### OPTION 2 - running webapps as systemd services - -Maven build generates executable JAR files. This means web container and all its dependencies are package inside -single JAR file. It makes a lot easier to deploy it into servers. - -Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. - -For that we first need to create service file: -```bash -vim siva-webapp.service -``` - -Inside it, we need to paste below text. You need to change few things in service setup file. - -* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` -* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. -* Also, You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file - -```ini -[Unit] -Description=siva-webapp -After=syslog.target - -[Service] -User=root -ExecStart=/var/apps/siva-webapp.jar -Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 -SuccessExitStatus=143 - -[Install] -WantedBy=multi-user.target -``` - -Save and close the `siva-webapp.service` file. -Next we need to move `siva-webapp-X.X.X.jar` into newly created `/var/apps` directory and rename to -JAR file to `siva-webapp.jar`. match - -!!! note - The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file - -```bash -sudo mkdir /var/apps -sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-X.X.X.jar /var/apps/siva-webapp.jar -``` - -Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. -Then we are ready to start the `siva-webapp` service. - -```bash -sudo cp siva-webapp.service /lib/systemd/system -sudo systemctl start siva-webapp -``` - -Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below -command. - -```bash -systemctl status siva-webapp -``` - -It should print out similar to below picture: - -``` -● siva-webapp.service - siva-webapp - Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) - Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago - Main PID: 15965 (siva-webapp.jar) - Tasks: 34 - Memory: 429.6M - CPU: 2min 5.721s - CGroup: /system.slice/siva-webapp.service - ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar - └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar - -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -``` - -### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) - -> **NOTE 1**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version -> conflicts. - -> **NOTE 2**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - -the http connector parameter `maxPostSize` should be configured with the desired limit. - -> **NOTE 3**: The war file must be deployed to Tomcat ROOT. - -First we need to download Tomcat web servlet container as of the writing latest version available in version 8 branch is 8.5.24. We will download it with `wget` - -```bash -wget http://www-eu.apache.org/dist/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gz -``` - -Unpack it somewhere: - -```bash -tar xf apache-tomcat-8.5.24.tar.gz -``` - -Now we should build the WAR file. We have created helper script with all the correct Maven parameters. - -```bash -./war-build.sh -``` - -Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. - -```bash -cp siva-parent/siva-webapp/target/siva-webapp-X.X.X.war apache-tomcat-8.5.24/webapps -./apache-tomcat-7.0.77/bin/catalina.sh run -``` - -> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validation certificates -> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change -> this default behavior you should set environment variable `DSS_DATA_FOLDER`. - -> **IMPORTANT** When updating the siva-keystore.jks it is needed to delete the "temp" keystore from default/specified location. -> Deleting the "temp" keystore is also needed when upgrading your deployment to newer SIVA version! - -### How-to set WAR deployed SiVa `application.properties` - -SiVa override properties can be set using `application.properties` file. The file can locate anywhere in the host system. -To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. - -Contents of the `setenv.sh` file should look like: - -```bash -export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" -``` - - -### Smoke testing your deployed system - -**Step 1**. Install HTTPIE -`httpie` is more user-friendly version of `curl` and we will use to verify that SiVa was installed -and started correctly on our server. - -If you have Python and its package manager `pip` installed. Then You can issue below command: - -```bash -pip install httpie -``` - -**Step 2**. Download a sample JSON request file. - -```bash -http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdocPass.json -``` - -**Step 3**. After successful download issue below command in same directory where you downloaded the file using -the command below. - -```bash -http POST http://localhost:8080/validate < bdocPass.json -``` -**Step 4**. Verify the output. Look for `signatureCount` and `validSignatureCount`, they **must** be equal. - -## Logging - -By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. - -For example, adding application.properties to classpath with the **logging.config** property -```bash -logging.config=/path/to/logback.xml -``` - -## Statistics - -For every validation a statistical report is composed that contains the following data: - -| Property | Type | Description | -|----------|------|-------------| -| stats | Object | Object containing statistic info | -| stats.type | String | Container type ( text value that identifies the container type) of the validated document: ASiC-E, ASIC-S, PAdES, DIGIDOC_XML, N/A | -| stats.sigType | String | Signature type in validated document: XAdES, CAdES, PAdES, N/A | -| stats.usrId | String | (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or N/A) | -| stats.dur | Number | The time it takes to process an incoming request - measured in milliseconds | -| stats.sigCt | Number | The value of the "signaturesCount" element in the validation report | -| stats.vSigCt | Number | The value of the "validSignaturesCount" element in the validation report | -| stats.sigRslt | Array | Array of signature statistic objects | -| stats.sigRslt[0] | Object | Object containing signature statistic info | -| stats.sigRslt[0].i | String | Value of signature indication field from the validation report | -| stats.sigRslt[0].si | String | Value of signature subindication field from the validation report. Element not present if not in validation report | -| stats.sigRslt[0].cc | String | Country code extracted from the signer cert subject field. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate or XX if the country cannot be determined. | -| stats.sigRslt[0].sf | String | Values of signatureFormat field from the validation report | - -Example of statistic -``` -{ - "stats": { - "type": "PAdES", - "sigType": "PAdES", - "usrId": "sample_user1", - "dur": 4021, - "sigCt": 2, - "vSigCt": 1, - "sigRslt": [ - {"i":"TOTAL-PASSED", "cc":"EE", "sf":"PAdES_BASELINE_LT"}, - {"i":"INDETERMINATE", "si":"NO_CERTIFICATE_CHAIN_FOUND", "cc":"EE", "sf":"PAdES_BASELINE_LT"} - ] - } -} -``` - -This information is sent to log feeds (at INFO level) which can be redirected to files or to a syslog feed. - - -## Monitoring - -SiVa webapps provide endpoints for external monitoring tools to periodically check the generic service health status. - -### Health Endpoint - -!!! note - Note that this endpoint is not exposed by default. - -The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` . See the [Interfaces section](../siva3/interfaces.md#service-health-monitoring) for response structure and details. - -* **Exposing the health monitoring endpoint** - -To expose the endpoint, use the following configuration parameter: -```bash -management.endpoints.web.exposure.include=health -``` - -* **External service health indicators** - -The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. - -Demo webapp and Siva webapp include additional information about the health of their dependent services. -These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health. - -### Heartbeat endpoint - -!!! note - Note that this endpoint is not enabled nor exposed by default. - -!!! note - Note that this endpoint requires the health endpoint to be enabled and exposed in order to function. - -The url for accessing JSON formatted heartbeat information with HTTP GET is `/monitoring/heartbeat`. See the [Interfaces section](../siva3/interfaces.md#simplified-health-monitoring) for response structure and details. - -* **Enabling and exposing the heartbeat monitoring endpoint** - -To enable and expose the endpoint, use the following configuration parameters: -```bash -management.endpoints.web.exposure.include=health,heartbeat -management.endpoint.heartbeat.enabled=true -``` - -* **Simplified service health indicator** - -The endpoint is implemented by polling the health information directly from the underlying health endpoint implementation, but exposing just the aggregated overall service status, hiding everything else. - -### Version information endpoint - -!!! note - Note that this endpoint is not enabled nor exposed by default. - -The url for accessing JSON formatted version information with HTTP GET is `/monitoring/version`. See the [Interfaces section](../siva3/interfaces.md#version-information) for response structure and details. - -* **Enabling and exposing the version information endpoint** - -To enable and expose the endpoint, use the following configuration parameters: -```bash -management.endpoints.web.exposure.include=version -management.endpoint.version.enabled=true -``` - - -## Validation Report Signature - -SiVa provides the ability to sign the validation report. The idea of supplementing the validation report with a validation report signature is to prove the authority's authenticity and integrity over the validation. - -!!! note - Signing of validation report is disabled by default - -To enable it, use the following configuration parameter: -```bash -siva.report.reportSignatureEnabled=true -``` - -When validation report signature is enabled, only detailed validation reports will be signed, simple reports will not be signed. -The validation report's digital signature is composed out of response's `validationReport` object. The target format of the signature is ASiC-E (signature level is configurable). The ASiC-E container contents are encoded into Base64 and put on the same level int the response as the validation report itself. - -!!! note - Enabling the validation report signing will affect the performance of the service. - -Example structure of the response containing report signature: - -```json -{ - "validationReport": { - ... - }, - "validationReportSignature": "ZHNmYmhkZmdoZGcgZmRmMTM0NTM..." -} -``` - -Supported interfaces for signature creation: - -* **PKCS#11** - a platform-independent API for cryptographic tokens, such as hardware security modules (HSM) and smart cards -* **PKCS#12** - for files bundled with private key and certificate - -Report signature configuration parameters: - -Property | Description | -| -------- | ----------- | -|**siva.report.reportSignatureEnabled**| Enables signing of the validation report. Validation report will only be signed when requesting detailed report.
  • Default: **false**
| -|**siva.signatureService.signatureLevel**| The level of the validation report signature.
**Example values:**
* XAdES_BASELINE_B
* XAdES_BASELINE_T
* XAdES_BASELINE_LT
* XAdES_BASELINE_LTA | -|**siva.signatureService.tspUrl**| URL of the timestamp provider.
Only needed when the configured signature level is at least XAdES_BASELINE_T | -|**siva.signatureService.ocspUrl**| URL of the OCSP provider.
Only needed when the configured signature level is at least XAdES_BASELINE_LT | -|**siva.signatureService.pkcs11.path**| path to PKCS#11 module (depends on your installed smart card or hardware token library, for example: /usr/local/lib/opensc-pkcs11.so) | -|**siva.signatureService.pkcs11.password**| pin/password of the smart card or hardware token | -|**siva.signatureService.pkcs11.slotIndex**| depends on the hardware token. E.g. Estonian Smart Card uses 2, USB eToken uses 0.
  • Default: **0**
| -|**siva.signatureService.pkcs12.path**| path to keystore file containing certificate and private key | -|**siva.signatureService.pkcs12.password**| password of the keystore file containing certificate and private key | - -!!! note - When configuring report signature, either PKCS#11 or PKCS#12 should be configured, no need to configure both. - --------------------------------------------------------------------------------------- -## Configuration parameters - -All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. -However, all the properties can be overridden on the service or embedded web server level, if necessary. - -By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. -Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. - -For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: -```bash -server.port=8080 -``` - -Or to increase or modify the default http request limit, override the **siva.http.request.max-request-size-limit** property: -```bash -siva.http.request.max-request-size-limit: 15MB -``` - -See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot - -### Siva webapp parameters - -* Updating TSL - -| Property | Description | -| -------- | ----------- | -| **siva.tsl.loader.loadFromCache** | A boolean value that determines whether the TSL is loaded from disk cache instead of by downloading a new TSL in a predetermined interval.

Note that the cache files are by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`; make sure the application has both read and write permissions in that folder).
  • When set to **false**, the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`.
  • When set to **true**, SiVa uses existing cache as it's TSL. No direct polling for updates is performed, so all the files (LOTL and TSL files) must be present in system temporary directory. The cache files must have the same filenames as their URLs, but special characters need to be replaced with underscores. For example, the file downloaded from https://sr.riik.ee/tsl/estonian-tsl.xml must be named `https___sr_riik_ee_tsl_estonian_tsl_xml`
  • Default: **false**
| -| **siva.tsl.loader.onlineCacheExpirationTime** | A string value in a [format based on ISO-8601 duration format PnDTnHnMn.nS](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/Duration.html#parse(java.lang.CharSequence)) that determines the expiration time of TSL disk cache in case `siva.tsl.loader.loadFromCache` is set to `false`. The default is 1 hour.

Note that the expiration time only determines, for each cached file, the minimum time that must have been passed since their last update before that file is considered expired and is susceptible to an update. The actual update is performed periodically by SiVa (specified by `siva.tsl.loader.schedulerCron`) or when the application is (re)started.
  • Default: **PT1H**
| -| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| -| **siva.tsl.loader.ojUrl** | A url value that points to the legal act in Official Journal of the European Union
  • Default: **https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.276.01.0001.01.ENG**
| -| **siva.tsl.loader.lotlRootSchemeInfoUri** | A url value that points to the European Unions' disclaimer regarding LOTL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl-legalnotice.html**
| -| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| -| **siva.tsl.loader.trustedTerritories** | Sets the trusted territories by countries
  • Default: **"AT", "BE", "BG", "CY", "CZ", "DE", "DK", "EE", "ES", "FI", "FR", "GR", "HU", "HR", "IE", "IS", "IT", "LT", "LU", "LV", "LI", "MT", "NO", "NL", "PL", "PT", "RO", "SE", "SI", "SK", "UK"**
| -| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 \* * ?**
| -| **siva.tsl.loader.sslTruststorePath** | Path to truststore containing trusted CA certificates used in HTTPS connection to retrieve member states TSLs
  • Default: **classpath:tsl-ssl-truststore.p12**
| -| **siva.tsl.loader.sslTruststoreType** | Truststore type
  • Default: **PKCS12**
| -| **siva.tsl.loader.sslTruststorePassword** | Truststore password
  • Default: **digidoc4j-password**
| -| **siva.tsl.loader.LotlPivotSupportEnabled** | A boolean value that determines, whether LOTL pivot mode should be used or not
  • Default: **true**
| -| **siva.keystore.type** | Keystore type
  • Default: **JKS**
| -| **siva.keystore.filename** | Keystore that contains public keys of trusted LOTL signers for LOTL signature validation
  • Default: **siva-keystore.jks**
| -| **siva.keystore.password** | Keystore password
  • Default: **siva-keystore-password**
| - -!!! note - Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). - -!!! note - When updating the siva-keystore.jks it is needed to delete the "temp" keystore from default/specified location. Deleting the "temp" keystore is also needed when upgrading your deployment to newer SIVA version! - -!!! note - TSL is currently used only by Generic and BDOC validators - - -* TimeMark validation - customizing policies - -| Property | Description | -| -------- | ----------- | -| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| - -| Property | Description | -| -------- | ----------- | -|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.bdoc.signaturePolicy.policies[0].name=POLv3 -siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv3 -siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_ades.xml - -siva.bdoc.signaturePolicy.policies[1].name=POLv4 -siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4 -siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* Generic validation - customize validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.europe.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.europe.signaturePolicy.policies[0].name=POLv3 -siva.europe.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.europe.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv3 -siva.europe.signaturePolicy.policies[0].constraintPath=generic_constraint_ades.xml - -siva.europe.signaturePolicy.policies[1].name=POLv4 -siva.europe.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.europe.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4 -siva.europe.signaturePolicy.policies[1].constraintPath=generic_constraint_qes.xml -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* Configure SiVa to request revocation status for T level signatures - -By default, T level signatures do not contain revocation data. -It is possible to configure SiVa to use OnlineOCSPSource in order to request revocation status during the validation process for T level signatures. - -An example of configuring SiVa to request an OCSP response only for certificates issued by Latvian and Lithuanian service providers: -```text -t-level-signature-filter.filter-type = ALLOWED_COUNTRIES -t-level-signature-filter.countries[0] = LV -t-level-signature-filter.countries[1] = LT -``` - -!!! note - If enabled, the revocation request is made for every signature level for given countries, not only T level signatures. - -| Property | Description | -| -------- |-------------| -|**t-level-signature-filter.filter-type**| A string value that determines, which filter is being used. There are two available options: ALLOWED_COUNTRIES or NOT_ALLOWED_COUNTRIES
  • When set to **ALLOWED_COUNTRIES** SiVa uses OnlineOCSPSource to request revocation status for the list of provided countries. If the list of countries is left empty, no OCSP requests are made
  • When set to **NOT_ALLOWED_COUNTRIES** SiVa uses OnlineOCSPSource to request revocation status for all the countries that are not on the list. If the list of countries is left empty, it makes an OCSP request for every country
  • Default: **N/A**
| -|**t-level-signature-filter.countries**| A list of countries to be provided to the filter. For example: EE, LV, BE
  • Default: **N/A**
| - -### Demo webapp parameters - -* Linking to SiVa webapp - -| Property | Description | -| -------- | ----------- | -|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| -|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| -|**siva.service.jsonDataFilesServicePath**| Data file service path in Siva webapp to access the REST/JSON API
  • Default: **/getDataFiles**
| -|**siva.service.trustStore**| Path to Siva webapp truststore on classpath
  • Default: **siva_server_truststore.p12**
| -|**siva.service.trustStorePassword**| Siva webapp truststore password
  • Default: **password**
| +The following guide is for system integrators who need to set-up, configure, manage and troubleshoot SiVa service. + +### System requirements + +Following are the minimum requirements to build and deploy SiVa webapps as a service: + +* Java 11 or above is supported +* Git version control system version 1.8 or above is recommended +* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM +* Minimum 1 processor core +* Open internet connection +* 2GB of free disk space +* Supported operating system is Ubuntu 16.04 LTS + +## Building + +### Building SiVa webapps + +It is recommended to build the project with Maven Wrapper. Run following command in the projects main directory: + +```bash +./mvnw clean install +``` + +!!! note + The first time build can take up to **45 minutes** because of downloading the required dependencies, running vulnerability checks and unit tests. + +To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. +The last lines of build output should look very similar to below image: + +```text +[INFO] Reactor Summary: +[INFO] +[INFO] SiVa Digitally signed documents validation service X.X.X SUCCESS [ 2.089 s] +[INFO] validation-services-parent ......................... SUCCESS [ 0.380 s] +[INFO] validation-commons ................................. SUCCESS [ 13.782 s] +[INFO] tsl-loader ......................................... SUCCESS [ 9.372 s] +[INFO] Generic Validation Service ......................... SUCCESS [ 41.723 s] +[INFO] TimeStampToken Validation Service .................. SUCCESS [ 8.400 s] +[INFO] Time-mark container Validation Service ............. SUCCESS [ 36.508 s] +[INFO] SiVa webapp and other core modules ................. SUCCESS [ 0.374 s] +[INFO] siva-monitoring .................................... SUCCESS [ 11.982 s] +[INFO] siva-statistics .................................... SUCCESS [ 9.816 s] +[INFO] SiVa validation service proxy ...................... SUCCESS [ 14.861 s] +[INFO] SiVa signature service ............................. SUCCESS [ 7.801 s] +[INFO] siva-webapp ........................................ SUCCESS [ 42.451 s] +[INFO] SiVa Sample Web application ........................ SUCCESS [ 42.236 s] +[INFO] SiVa Web Service integration tests ................. SUCCESS [ 18.830 s] +[INFO] siva-distribution X.X.X ............................ SUCCESS [ 5.763 s] +[INFO] ------------------------------------------------------------------------ +[INFO] BUILD SUCCESS +[INFO] ------------------------------------------------------------------------ +[INFO] Total time: 04:46 min +[INFO] Finished at: 2020-07-03T14:22:02+03:00 +[INFO] ------------------------------------------------------------------------ + +``` + + +## Deploying + +### OPTION 1 - starting webapps from command line +SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the +project by issuing below commands: + +**First start the Siva webapp** + +```bash +./siva-parent/siva-webapp/target/siva-webapp-X.X.X.jar +``` + +The SiVa webapp by default runs on port **8080**. +Easiest way to test out the deployment is to run SiVa demo application and use it for validation. + +**Start the Demo webapp** + +```bash +./siva-parent/siva-sample-application/target/siva-sample-application-X.X.X.jar +``` + +Now point Your browser to URL: + + +### OPTION 2 - running webapps as systemd services + +Maven build generates executable JAR files. This means web container and all its dependencies are package inside +single JAR file. It makes a lot easier to deploy it into servers. + +Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. + +For that we first need to create service file: +```bash +vim siva-webapp.service +``` + +Inside it, we need to paste below text. You need to change few things in service setup file. + +* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` +* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. +* Also, You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file + +```ini +[Unit] +Description=siva-webapp +After=syslog.target + +[Service] +User=root +ExecStart=/var/apps/siva-webapp.jar +Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 +SuccessExitStatus=143 + +[Install] +WantedBy=multi-user.target +``` + +Save and close the `siva-webapp.service` file. +Next we need to move `siva-webapp-X.X.X.jar` into newly created `/var/apps` directory and rename to +JAR file to `siva-webapp.jar`. match + +!!! note + The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file + +```bash +sudo mkdir /var/apps +sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-X.X.X.jar /var/apps/siva-webapp.jar +``` + +Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. +Then we are ready to start the `siva-webapp` service. + +```bash +sudo cp siva-webapp.service /lib/systemd/system +sudo systemctl start siva-webapp +``` + +Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below +command. + +```bash +systemctl status siva-webapp +``` + +It should print out similar to below picture: + +``` +● siva-webapp.service - siva-webapp + Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) + Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago + Main PID: 15965 (siva-webapp.jar) + Tasks: 34 + Memory: 429.6M + CPU: 2min 5.721s + CGroup: /system.slice/siva-webapp.service + ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar + └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar + +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +``` + +### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) + +> **NOTE 1**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version +> conflicts. + +> **NOTE 2**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - +the http connector parameter `maxPostSize` should be configured with the desired limit. + +> **NOTE 3**: The war file must be deployed to Tomcat ROOT. + +First we need to download Tomcat web servlet container as of the writing latest version available in version 8 branch is 8.5.24. We will download it with `wget` + +```bash +wget http://www-eu.apache.org/dist/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gz +``` + +Unpack it somewhere: + +```bash +tar xf apache-tomcat-8.5.24.tar.gz +``` + +Now we should build the WAR file. We have created helper script with all the correct Maven parameters. + +```bash +./war-build.sh +``` + +Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. + +```bash +cp siva-parent/siva-webapp/target/siva-webapp-X.X.X.war apache-tomcat-8.5.24/webapps +./apache-tomcat-7.0.77/bin/catalina.sh run +``` + +> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validation certificates +> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change +> this default behavior you should set environment variable `DSS_DATA_FOLDER`. + +> **IMPORTANT** When updating the siva-keystore.jks it is needed to delete the "temp" keystore from default/specified location. +> Deleting the "temp" keystore is also needed when upgrading your deployment to newer SIVA version! + +### How-to set WAR deployed SiVa `application.properties` + +SiVa override properties can be set using `application.properties` file. The file can locate anywhere in the host system. +To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. + +Contents of the `setenv.sh` file should look like: + +```bash +export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" +``` + + +### Smoke testing your deployed system + +**Step 1**. Install HTTPIE +`httpie` is more user-friendly version of `curl` and we will use to verify that SiVa was installed +and started correctly on our server. + +If you have Python and its package manager `pip` installed. Then You can issue below command: + +```bash +pip install httpie +``` + +**Step 2**. Download a sample JSON request file. + +```bash +http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdocPass.json +``` + +**Step 3**. After successful download issue below command in same directory where you downloaded the file using +the command below. + +```bash +http POST http://localhost:8080/validate < bdocPass.json +``` +**Step 4**. Verify the output. Look for `signatureCount` and `validSignatureCount`, they **must** be equal. + +## Logging + +By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. + +For example, adding application.properties to classpath with the **logging.config** property +```bash +logging.config=/path/to/logback.xml +``` + +## Statistics + +For every validation a statistical report is composed that contains the following data: + +| Property | Type | Description | +|----------|------|-------------| +| stats | Object | Object containing statistic info | +| stats.type | String | Container type ( text value that identifies the container type) of the validated document: ASiC-E, ASIC-S, PAdES, DIGIDOC_XML, N/A | +| stats.sigType | String | Signature type in validated document: XAdES, CAdES, PAdES, N/A | +| stats.usrId | String | (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or N/A) | +| stats.dur | Number | The time it takes to process an incoming request - measured in milliseconds | +| stats.sigCt | Number | The value of the "signaturesCount" element in the validation report | +| stats.vSigCt | Number | The value of the "validSignaturesCount" element in the validation report | +| stats.sigRslt | Array | Array of signature statistic objects | +| stats.sigRslt[0] | Object | Object containing signature statistic info | +| stats.sigRslt[0].i | String | Value of signature indication field from the validation report | +| stats.sigRslt[0].si | String | Value of signature subindication field from the validation report. Element not present if not in validation report | +| stats.sigRslt[0].cc | String | Country code extracted from the signer cert subject field. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate or XX if the country cannot be determined. | +| stats.sigRslt[0].sf | String | Values of signatureFormat field from the validation report | + +Example of statistic +``` +{ + "stats": { + "type": "PAdES", + "sigType": "PAdES", + "usrId": "sample_user1", + "dur": 4021, + "sigCt": 2, + "vSigCt": 1, + "sigRslt": [ + {"i":"TOTAL-PASSED", "cc":"EE", "sf":"PAdES_BASELINE_LT"}, + {"i":"INDETERMINATE", "si":"NO_CERTIFICATE_CHAIN_FOUND", "cc":"EE", "sf":"PAdES_BASELINE_LT"} + ] + } +} +``` + +This information is sent to log feeds (at INFO level) which can be redirected to files or to a syslog feed. + + +## Monitoring + +SiVa webapps provide endpoints for external monitoring tools to periodically check the generic service health status. + +### Health Endpoint + +!!! note + Note that this endpoint is not exposed by default. + +The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` . See the [Interfaces section](../siva3/interfaces.md#service-health-monitoring) for response structure and details. + +* **Exposing the health monitoring endpoint** + +To expose the endpoint, use the following configuration parameter: +```bash +management.endpoints.web.exposure.include=health +``` + +* **External service health indicators** + +The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. + +Demo webapp and Siva webapp include additional information about the health of their dependent services. +These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health. + +### Heartbeat endpoint + +!!! note + Note that this endpoint is not enabled nor exposed by default. + +!!! note + Note that this endpoint requires the health endpoint to be enabled and exposed in order to function. + +The url for accessing JSON formatted heartbeat information with HTTP GET is `/monitoring/heartbeat`. See the [Interfaces section](../siva3/interfaces.md#simplified-health-monitoring) for response structure and details. + +* **Enabling and exposing the heartbeat monitoring endpoint** + +To enable and expose the endpoint, use the following configuration parameters: +```bash +management.endpoints.web.exposure.include=health,heartbeat +management.endpoint.heartbeat.enabled=true +``` + +* **Simplified service health indicator** + +The endpoint is implemented by polling the health information directly from the underlying health endpoint implementation, but exposing just the aggregated overall service status, hiding everything else. + +### Version information endpoint + +!!! note + Note that this endpoint is not enabled nor exposed by default. + +The url for accessing JSON formatted version information with HTTP GET is `/monitoring/version`. See the [Interfaces section](../siva3/interfaces.md#version-information) for response structure and details. + +* **Enabling and exposing the version information endpoint** + +To enable and expose the endpoint, use the following configuration parameters: +```bash +management.endpoints.web.exposure.include=version +management.endpoint.version.enabled=true +``` + + +## Validation Report Signature + +SiVa provides the ability to sign the validation report. The idea of supplementing the validation report with a validation report signature is to prove the authority's authenticity and integrity over the validation. + +!!! note + Signing of validation report is disabled by default + +To enable it, use the following configuration parameter: +```bash +siva.report.reportSignatureEnabled=true +``` + +When validation report signature is enabled, only detailed validation reports will be signed, simple reports will not be signed. +The validation report's digital signature is composed out of response's `validationReport` object. The target format of the signature is ASiC-E (signature level is configurable). The ASiC-E container contents are encoded into Base64 and put on the same level int the response as the validation report itself. + +!!! note + Enabling the validation report signing will affect the performance of the service. + +Example structure of the response containing report signature: + +```json +{ + "validationReport": { + ... + }, + "validationReportSignature": "ZHNmYmhkZmdoZGcgZmRmMTM0NTM..." +} +``` + +Supported interfaces for signature creation: + +* **PKCS#11** - a platform-independent API for cryptographic tokens, such as hardware security modules (HSM) and smart cards +* **PKCS#12** - for files bundled with private key and certificate + +Report signature configuration parameters: + +Property | Description | +| -------- | ----------- | +|**siva.report.reportSignatureEnabled**| Enables signing of the validation report. Validation report will only be signed when requesting detailed report.
  • Default: **false**
| +|**siva.signatureService.signatureLevel**| The level of the validation report signature.
**Example values:**
* XAdES_BASELINE_B
* XAdES_BASELINE_T
* XAdES_BASELINE_LT
* XAdES_BASELINE_LTA | +|**siva.signatureService.tspUrl**| URL of the timestamp provider.
Only needed when the configured signature level is at least XAdES_BASELINE_T | +|**siva.signatureService.ocspUrl**| URL of the OCSP provider.
Only needed when the configured signature level is at least XAdES_BASELINE_LT | +|**siva.signatureService.pkcs11.path**| path to PKCS#11 module (depends on your installed smart card or hardware token library, for example: /usr/local/lib/opensc-pkcs11.so) | +|**siva.signatureService.pkcs11.password**| pin/password of the smart card or hardware token | +|**siva.signatureService.pkcs11.slotIndex**| depends on the hardware token. E.g. Estonian Smart Card uses 2, USB eToken uses 0.
  • Default: **0**
| +|**siva.signatureService.pkcs12.path**| path to keystore file containing certificate and private key | +|**siva.signatureService.pkcs12.password**| password of the keystore file containing certificate and private key | + +!!! note + When configuring report signature, either PKCS#11 or PKCS#12 should be configured, no need to configure both. + +-------------------------------------------------------------------------------------- +## Configuration parameters + +All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. +However, all the properties can be overridden on the service or embedded web server level, if necessary. + +By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. +Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. + +For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: +```bash +server.port=8080 +``` + +Or to increase or modify the default http request limit, override the **siva.http.request.max-request-size-limit** property: +```bash +siva.http.request.max-request-size-limit: 15MB +``` + +See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot + +### Siva webapp parameters + +* Updating TSL + +| Property | Description | +| -------- | ----------- | +| **siva.tsl.loader.loadFromCache** | A boolean value that determines whether the TSL is loaded from disk cache instead of by downloading a new TSL in a predetermined interval.

Note that the cache files are by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`; make sure the application has both read and write permissions in that folder).
  • When set to **false**, the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`.
  • When set to **true**, SiVa uses existing cache as it's TSL. No direct polling for updates is performed, so all the files (LOTL and TSL files) must be present in system temporary directory. The cache files must have the same filenames as their URLs, but special characters need to be replaced with underscores. For example, the file downloaded from https://sr.riik.ee/tsl/estonian-tsl.xml must be named `https___sr_riik_ee_tsl_estonian_tsl_xml`
  • Default: **false**
| +| **siva.tsl.loader.onlineCacheExpirationTime** | A string value in a [format based on ISO-8601 duration format PnDTnHnMn.nS](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/Duration.html#parse(java.lang.CharSequence)) that determines the expiration time of TSL disk cache in case `siva.tsl.loader.loadFromCache` is set to `false`. The default is 1 hour.

Note that the expiration time only determines, for each cached file, the minimum time that must have been passed since their last update before that file is considered expired and is susceptible to an update. The actual update is performed periodically by SiVa (specified by `siva.tsl.loader.schedulerCron`) or when the application is (re)started.
  • Default: **PT1H**
| +| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| +| **siva.tsl.loader.ojUrl** | A url value that points to the legal act in Official Journal of the European Union
  • Default: **https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.276.01.0001.01.ENG**
| +| **siva.tsl.loader.lotlRootSchemeInfoUri** | A url value that points to the European Unions' disclaimer regarding LOTL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl-legalnotice.html**
| +| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| +| **siva.tsl.loader.trustedTerritories** | Sets the trusted territories by countries
  • Default: **"AT", "BE", "BG", "CY", "CZ", "DE", "DK", "EE", "ES", "FI", "FR", "GR", "HU", "HR", "IE", "IS", "IT", "LT", "LU", "LV", "LI", "MT", "NO", "NL", "PL", "PT", "RO", "SE", "SI", "SK", "UK"**
| +| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 \* * ?**
| +| **siva.tsl.loader.sslTruststorePath** | Path to truststore containing trusted CA certificates used in HTTPS connection to retrieve member states TSLs
  • Default: **classpath:tsl-ssl-truststore.p12**
| +| **siva.tsl.loader.sslTruststoreType** | Truststore type
  • Default: **PKCS12**
| +| **siva.tsl.loader.sslTruststorePassword** | Truststore password
  • Default: **digidoc4j-password**
| +| **siva.tsl.loader.LotlPivotSupportEnabled** | A boolean value that determines, whether LOTL pivot mode should be used or not
  • Default: **true**
| +| **siva.keystore.type** | Keystore type
  • Default: **JKS**
| +| **siva.keystore.filename** | Keystore that contains public keys of trusted LOTL signers for LOTL signature validation
  • Default: **siva-keystore.jks**
| +| **siva.keystore.password** | Keystore password
  • Default: **siva-keystore-password**
| + +!!! note + Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). + +!!! note + When updating the siva-keystore.jks it is needed to delete the "temp" keystore from default/specified location. Deleting the "temp" keystore is also needed when upgrading your deployment to newer SIVA version! + +!!! note + TSL is currently used only by Generic and BDOC validators + + +* TimeMark validation - customizing policies + +| Property | Description | +| -------- | ----------- | +| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| + +| Property | Description | +| -------- | ----------- | +|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.bdoc.signaturePolicy.policies[0].name=POLv3 +siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv3 +siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_ades.xml + +siva.bdoc.signaturePolicy.policies[1].name=POLv4 +siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4 +siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* Generic validation - customize validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.europe.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.europe.signaturePolicy.policies[0].name=POLv3 +siva.europe.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.europe.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv3 +siva.europe.signaturePolicy.policies[0].constraintPath=generic_constraint_ades.xml + +siva.europe.signaturePolicy.policies[1].name=POLv4 +siva.europe.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.europe.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4 +siva.europe.signaturePolicy.policies[1].constraintPath=generic_constraint_qes.xml +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* Configure SiVa to request revocation status for T level signatures + +By default, T level signatures do not contain revocation data. +It is possible to configure SiVa to use OnlineOCSPSource in order to request revocation status during the validation process for T level signatures. + +An example of configuring SiVa to request an OCSP response only for certificates issued by Latvian and Lithuanian service providers: +```text +t-level-signature-filter.filter-type = ALLOWED_COUNTRIES +t-level-signature-filter.countries[0] = LV +t-level-signature-filter.countries[1] = LT +``` + +!!! note + If enabled, the revocation request is made for every signature level for given countries, not only T level signatures. + +| Property | Description | +| -------- |-------------| +|**t-level-signature-filter.filter-type**| A string value that determines, which filter is being used. There are two available options: ALLOWED_COUNTRIES or NOT_ALLOWED_COUNTRIES
  • When set to **ALLOWED_COUNTRIES** SiVa uses OnlineOCSPSource to request revocation status for the list of provided countries. If the list of countries is left empty, no OCSP requests are made
  • When set to **NOT_ALLOWED_COUNTRIES** SiVa uses OnlineOCSPSource to request revocation status for all the countries that are not on the list. If the list of countries is left empty, it makes an OCSP request for every country
  • Default: **N/A**
| +|**t-level-signature-filter.countries**| A list of countries to be provided to the filter. For example: EE, LV, BE
  • Default: **N/A**
| + +### Demo webapp parameters + +* Linking to SiVa webapp + +| Property | Description | +| -------- | ----------- | +|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| +|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| +|**siva.service.jsonDataFilesServicePath**| Data file service path in Siva webapp to access the REST/JSON API
  • Default: **/getDataFiles**
| +|**siva.service.trustStore**| Path to Siva webapp truststore on classpath
  • Default: **siva_server_truststore.p12**
| +|**siva.service.trustStorePassword**| Siva webapp truststore password
  • Default: **password**
| diff --git a/docs/siva3/interfaces.md b/docs/siva3/interfaces.md index 20f7faf8c..6cbe70065 100644 --- a/docs/siva3/interfaces.md +++ b/docs/siva3/interfaces.md @@ -1,718 +1,718 @@ - - -In this section the SiVa external interfaces are described. For information of internal components and their interfaces, please refer to [**Structure and activities**](../siva3/structure_and_activities.md). - -SiVa service provides **REST JSON** interface that enable the service users to: - -* Request validation of signatures in a digitally signed document (i.e. signature container like BDOC,ASiC-E/PDF/...). -* Request validation of ASiC-S containers with time stamp tokens (i.e. Estonian ASiC-S with encapsulated container inside) -* Request validation of XAdES signature without datafiles. -* Request datafiles inside of DDOC container. - -SiVa service REST JSON interface supports X-Road v6. However, it is optional whether to integrate SiVa service using X-Road or using "plain" REST interface. This document only describes the SiVa service part of the interface, for the X-Road specifics visit Riigi Infosüsteemi Amet [webpage](https://www.ria.ee/en/state-information-system/data-exchange-platforms/data-exchange-layer-x-tee). - -In the following subsections, the SiVa validation request and response interfaces are described in detail. - -## Validation request interface - - -** REST JSON Endpoint ** - -``` -POST https:///validate -``` - -### Validation request parameters - -Validation request parameters for JSON interface are described in the table below. - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|-------------|----------------| -| document | + | String | Base64 encoded string of digitally signed document to be validated | -| filename | + | String | File name of the digitally signed document (i.e. sample.bdoc), max length 255 characters. | -| signaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](../siva3/appendix/validation_policy.md) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | -| reportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present).
Diagnostic - returns diagnostic data about the information contained in the signature itself, it's revocation data and mathematical validity (validationConclusion, diagnosticData block) | - -### Sample JSON request with mandatory parameters - -```json -{ - "filename":"sample.bdoc", - "document":"PD94bWwgdmVyc2lvbj0iMS4...." -} -``` -### Sample JSON request with all parameters - -```json -{ - "filename":"sample.asice", - "document":"PD94bWwgdmVyc2lvbj0iMS4....", - "signaturePolicy":"POLv3", - "reportType":"Detailed" -} -``` - -## Validation request interface for hashcode - -Hashcode XAdES validation is supported for **REST JSON** interface. - -** REST JSON Endpoint ** - -``` -POST https:///validateHashcode -``` - -### Validation request parameters - -Two different use cases are supported for the hashcode validation. -1) Providing the data file name, hash algorithm and hash on validation. -2) Providing only signature file. **NB! This method requires validation result change on integrator side when the local datafile hashes do not match with hashes returned in validation result!** - -Validation request parameters for JSON interface are described in the table below. - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|----------------|-------------| -| signatureFiles | + | Array | Array containing the signature objects. | -| signatureFiles[0] | + | Object | Object containing one signature file. | -| signatureFiles[0].signature | + | String | Base64 encoded string of signature file | -| signatureFiles[0].datafiles | - | Array | Array containing the information for datafiles that signature is covering | -| signatureFiles[0].datafiles[0] | + | Object | Object containing data file information | -| signatureFiles[0].datafiles[0].filename | + | String | File name of the hashed data file, max length 255 characters. | -| signatureFiles[0].datafiles[0].hashAlgo | + | String | Hash algorithm used for hashing the data file (must match with algorithm in signature file). Accepted values are dependant of validation policy | -| signatureFiles[0].datafiles[0].hash | + | String | Data file hash in Base64 encoded format. | -| signaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](../siva3/appendix/validation_policy.md) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | -| reportType | - | String |
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are not supported for hashcode).
Diagnostic - returns diagnostic data about the information contained in the signature itself, it's revocation data and mathematical validity (validationConclusion, diagnosticData block. Last one is not support for hashcode) | - -### Sample JSON request with mandatory parameters (datafile hashcode match verification done on integrators side) - -```json -{ - "signatureFiles": [ - { - "signature": "PD9094wskjd..." - }, - { - "signature": "AD9sa4wsfsd..." - } - ] -} -``` -### Sample JSON request with all parameters (datafile hashcode match verification done on SIVA side) - -```json -{ - "signatureFiles": [ - { - "signature": "PD94bWwgdmVyc2lvbj...", - "datafiles": [ - { - "filename": "leping.pdf", - "hashAlgo": "SHA256", - "hash": "WRlczpSZXZvY2F0aW9uVmFsd..." - }, - { - "filename": "leping2.pdf", - "hashAlgo": "SHA256", - "hash": "WRlpzaF0F0sda2vaW9uVmFsd..." - } - ] - }, - { - "signature": "PDadw4mVyc2lvbj...", - "datafiles": [ - { - "filename": "leping.pdf", - "hashAlgo": "SHA256", - "hash": "WRlczpSZXZvY2F0aW9uVmFsd..." - }, - { - "filename": "leping2.pdf", - "hashAlgo": "SHA256", - "hash": "WRlpzaF0F0sda2vaW9uVmFsd..." - } - ] - } - ], - "reportType": "Simple", - "signaturePolicy": "POLv4" -} -``` - -## Validation response interface -The signature validation report (i.e. the validation response) for JSON interface depends on what type of validation report was requested. - -### Validation response parameters Simple Report (successful scenario) - -General structure of validation response. - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|-----------------|-------------| -| validationReport | + | Object | Object containing SIVA validation report | -| validationReport. validationConclusion | + | Object | Object containing information of the validation conclusion | - -Structure of validationConclusion block - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|-----------------|-------------| -| policy | + | Object | Object containing information of the SiVa signature validation policy that was used for validation. | -| policy.policyName | + | String | Name of the validation policy | -| policy. policyDescription | + | String | Short description of the validation policy. | -| policy.policyUrl | + | String | URL where the signature validation policy document can be downloaded. The validation policy document shall include information about validation of all the document formats, including the different validation policies that are used in case of different file formats and base libraries. | -| signaturesCount | + | Number | Number of signatures found inside digitally signed file. | -| validSignaturesCount | + | Number | Signatures count that have validated to `TOTAL-PASSED`. See also `Signature.Indication` field. | -| validationLevel | - | String | Validation process against what the document is validated, only applicable on DSS based validations.
**Possible values:**
ARCHIVAL_DATA| -| validationTime | + | Date | Time of validating the signature by the service. | -| validationWarnings | - | Array | Array of SiVa validation warnings that do not affect the overall validation result. See also `signatures.warnings` parameter. | -| validationWarnings[0] | + | Object | Object containing the warning. | -| validationWarnings[0]. content | + | String | Description of the warning. | -| validatedDocument | - | Object | Object containing information about validated document. | -| validatedDocument. filename | - | String | Digitally signed document's file name. Not present for hashcode validation. | -| validatedDocument. fileHash | - | String | Calculated hash for validated document in Base64. Present when report signing is enabled. | -| validatedDocument. hashAlgo | - | String | Hash algorithm used. Present when report signing is enabled. | -| signatureForm | - | String | Format (and optionally version) of the digitally signed document container.
In case of documents in [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) format, the "hashcode" suffix is used to denote that the container was validated in [hashcode mode](https://open-eid.github.io/allkirjastamisteenus/json-technical-description/#hashcode-container-form), i.e. without original data files.
**Possible values:**
DIGIDOC_XML_1.0
DIGIDOC_XML_1.0_hashcode
DIGIDOC_XML_1.1
DIGIDOC_XML_1.1_hashcode
DIGIDOC_XML_1.2
DIGIDOC_XML_1.2_hashcode
DIGIDOC_XML_1.3
DIGIDOC_XML_1.3_hashcode
ASiC-E - used in case of all ASiC-E (and [BDOC](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf)) documents
ASiC-S - used in case of all ASiC-S documents | -| signatures | - | Array | Collection of signatures found in digitally signed document | -| signatures[0] | + | Object | Signature information object | -| signatures[0]. claimedSigningTime | + | Date | Claimed signing time, i.e. signer's computer time during signature creation | -| signatures[0].id | + | String | Signature ID attribute | -| signatures[0].indication | + | String | Overall result of the signature's validation process, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 5: Status indications of the signature validation process".
Note that the validation results of different signatures in one signed document (signature container) may vary.
See also `validSignaturesCount` and `SignaturesCount` fields.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED
INDETERMINATE | -| signatures[0]. subIndication | - | String | Additional subindication in case of failed or indeterminate validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics" | -| signatures[0].errors | - | Array | Information about validation error(s), array of error messages. | -| signatures[0].errors[0] | + | Object | Object containing the error | -| signatures[0].errors[0]. content | + | String | Error message, as returned by the base library that was used for signature validation. | -| signatures[0].info | - | Object | Object containing trusted signing time information and user added additional signing info. | -| signatures[0].info. bestSignatureTime | + | Date | Time value that is regarded as trusted signing time, denoting the earliest time when it can be trusted by the validation application (because proven by some Proof-of-Existence present in the signature) that a signature has existed.
The source of the value depends on the signature profile (see also `SignatureFormat` parameter):
- Signature with time-mark (LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature.
- Signature with time-stamp (LT or LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature.
- Signature with BES or EPES level - the value is empty, i.e. there is no trusted signing time value available. | -| signatures[0].info. timeAssertionMessageImprint | - | String | Base64 encoded value of message imprint retrieved from time assertion. In case of LT_TM (TimeMark) signatures, OCSP nonce value is returned. In case of T, LT or LTA (TimeStamp) signatures, TimeStamp message imprint is returned. | -| signatures[0].info. ocspResponseCreationTime | - | Date | Time value that is regarded as the original OCSP response creation time. | -| signatures[0].info. timestampCreationTime | - | Date | Time value of the timestamp creation | -| signatures[0].info. signerRole | - | Array | Array of roles attached to the signature. | -| signatures[0].info. signerRole[0] | + | Object | Object containing claimed roles. | -| signatures[0].info. signerRole[0]. claimedRole | + | String | Role stated by signer on signing. | -| signatures[0].info. signatureProductionPlace | - | Object | Object containing stated signing location info. | -| signatures[0].info. signatureProductionPlace.countryName | - | String | Stated signing country. | -| signatures[0].info. signatureProductionPlace.stateOrProvince | - | String | Stated state or province. | -| signatures[0].info. signatureProductionPlace.city | - | String | Stated city. | -| signatures[0].info. signatureProductionPlace.postalCode | - | String | Stated postal code. | -| signatures[0].info. signingReason | - | String | Free text field for PAdES type signatures for stating the signing reason | -| signatures[0].info. archiveTimestamps | - | Array | Array containing archive time-stamp tokens if present. | -| signatures[0].info. archiveTimestamps[0]. signedTime | + | String | Time when the archive time-stamp token was created. | -| signatures[0].info. archiveTimestamps[0]. indication | + | Object | Result of the archive time-stamp token validation.
**Possible values:**
PASSED
FAILED
NO_SIGNATURE_FOUND | -| signatures[0].info. archiveTimestamps[0]. subIndication | - | String | Additional subindication in case of failed or indeterminate validation result. | -| signatures[0].info. archiveTimestamps[0]. signedBy | + | String | Signer of the archive time-stamp token. | -| signatures[0].info. archiveTimestamps[0]. country | + | String | Issuer country of the archive time-stamp token. | -| signatures[0].info. archiveTimestamps[0]. content | + | String | Archive time-stamp token encoded in base64. | -| signatures[0]. signatureFormat | + | String | Format and profile (according to Baseline Profile) of the signature. See [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf), [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) and [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) for detailed description of the Baseline Profile levels. Levels that are accepted in SiVa validation policy are described in [SiVa signature validation policy](../siva3/appendix/validation_policy.md)
**Possible values:**
XAdES_BASELINE_B
XAdES_BASELINE_B_BES
XAdES_BASELINE_B_EPES
XAdES_BASELINE_T
XAdES_BASELINE_LT - long-term level XAdES signature where time-stamp is used as a assertion of trusted signing time
XAdES_BASELINE_LT_TM - long-term level XAdES signature where time-mark is used as a assertion of trusted signing time. Used in case of [BDOC](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf) signatures with time-mark profile and [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) signatures.
XAdES_BASELINE_LTA
CAdES_BASELINE_B
CAdES_BASELINE_T
CAdES_BASELINE_LT
CAdES_BASELINE_LTA
PAdES_BASELINE_B
PAdES_BASELINE_T
PAdES_BASELINE_LT
PAdES_BASELINE_LTA | -| signatures[0]. signatureMethod | + | String | Signature method specification URI used in signature creation. | -| signatures[0]. signatureLevel | - |String | Legal level of the signature, according to Regulation (EU) No 910/2014.
- **Possible values on positive validation result:**
QESIG
QESEAL
QES
ADESIG_QC
ADESEAL_QC
ADES_QC
ADESIG
ADESEAL
ADES
- **Possible values on indeterminate validation result:**
prefix INDETERMINATE is added to the level described in positive result. For example INDETERMINATE_QESIG
- **Possible values on negative validation result:**
In addition to abovementioned
NOT_ADES_QC_QSCD
NOT_ADES_QC
NOT_ADES
NA
- In case of DIGIDOC-XML 1.0..1.3 formats, value is missing as the signature level is not checked by the JDigiDoc base library that is used for validation. However, the signatures can be indirectly regarded as QES level signatures, see also [SiVa Validation Policy](../siva3/appendix/validation_policy.md)
| -| signatures[0].signedBy | + | String | In format of "surname, givenName, serialNumber" if these fields are present in subject distinguished name field. In other cases, value of common name field. | -| signatures[0]. subjectDistinguishedName | - | Object | Object containing subject's distinguished name information. | -| signatures[0]. subjectDistinguishedName .serialNumber | - | String | SERIALNUMBER value portion in signer's certificate's subject distinguished name | -| signatures[0]. subjectDistinguishedName .commonName | - | String | CN (common name) value portion in signer's certificate's subject distinguished name | -| signatures[0]. subjectDistinguishedName .givenName | - | String | Given name value portion in signer's certificate's subject distinguished name | -| signatures[0]. subjectDistinguishedName .surname | - | String | Surname value portion in signer's certificate's subject distinguished name | -| signatures[0]. signatureScopes | - | Array | Contains information of the original data that is covered by the signature. | -| signatures[0]. signatureScopes[0]. name | + | String | Name of the signature scope. | -| signatures[0]. signatureScopes[0]. scope | + | String | Type of the signature scope. | -| signatures[0]. signatureScopes[0]. content | + | String | Description of the scope. | -| signatures[0]. signatureScopes[0]. hashAlgo | - | String | Hash algorithm used for datafile hash calculation. Present for hashcode validation. | -| signatures[0]. signatureScopes[0]. hash | - | String | Hash of data file encoded in Base64. Present for hashcode validation. | -| signatures[0]. warnings | - | Array | Block of validation warnings that do not affect the overall validation result. | -| signatures[0]. warnings[0] | + | Object | Object containing the warning | -| signatures[0]. warnings[0]. content | + | String | Warning description, as returned by the base library that was used for validation. | -| signatures[0]. certificates | - | Array | Array containing certificates that are present in the signature or can be fetched from TSL. | -| signatures[0]. certificates[0] | + | Object | Object containing certificate type, common name and certificate. Minimal object is signer certificate. If present contains certificates for TimeStamps and OCSP as well. | -| signatures[0]. certificates[0].commonName | + | String | CN (common name) value in certificate. | -| signatures[0]. certificates[0].type | + | String | Type of the certificate. Can be SIGNING, REVOCATION, SIGNATURE_TIMESTAMP, ARCHIVE_TIMESTAMP or CONTENT_TIMESTAMP. | -| signatures[0]. certificates[0].content | + | String | DER encoded X.509 certificate in Base64. | -| signatures[0]. certificates[0].issuer | - | Object | Object containing issuer certificate information. Can create chain til the trust anchor. | -| signatures[0]. certificates[0].issuer.commonName | + | String | CN (common name) value in certificate. | -| signatures[0]. certificates[0].issuer.content | + | String | DER encoded X.509 certificate in Base64. | -| timeStampTokens | - | Array | Array containing the time stamp tokens | -| timeStampTokens[0] | + | Object | Object containing the time stamp token (TST) | -| timeStampTokens[0]. indication | + | String | Result of the time stamp token validation.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED | -| timeStampTokens[0]. subIndication | - | String | Additional subindication in case of failed validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics". | -| timeStampTokens[0]. signedBy | + | String | Signer of the time stamp token. | -| timeStampTokens[0]. signedTime | + | String | Time when the time stamp token was given. | -| timeStampTokens[0]. certificates | + | Array | Array containing certificates that are present in the timestamp. | -| timeStampTokens[0]. certificates[0] | + | Object | Object containing certificate type, common name and certificate. | -| timeStampTokens[0]. certificates[0].commonName | + | String | CN (common name) value in certificate. | -| timeStampTokens[0]. certificates[0].type | + | String | Type of the certificate. Possible value is CONTENT_TIMESTAMP. | -| timeStampTokens[0]. certificates[0].content | + | String | DER encoded X.509 certificate in Base64. | -| timeStampTokens[0]. error | - | Array | Errors returned in time stamp token validation. | -| timeStampTokens[0]. error[0] | + | Object | Object containing the error. | -| timeStampTokens[0]. error[0]. content | + | String | Error description. | -| timeStampTokens[0]. warning | - | Array | Block of validation warnings that do not affect the overall validation result.

Aside from warnings produced by DSS, an additional warning may be issued if a timestamp token does not cover the datafile (`The time-stamp token does not cover container datafile!`). | -| timeStampTokens[0]. warning[0] | + | Object | Object containing the warning. | -| timeStampTokens[0]. warning[0]. content | + | String | Warning description. | -| timeStampTokens[0]. timestampScopes | - | Array | Contains information of the original data that is covered by the timestamp. | -| timeStampTokens[0]. timestampScopes[0]. name | + | String | Name of the timestamp scope. | -| timeStampTokens[0]. timestampScopes[0]. scope | + | String | Type of the timestamp scope. | -| timeStampTokens[0]. timestampScopes[0]. content | + | String | Description of the timestamp scope. | -| timeStampTokens[0]. timestampLevel | - |String | Legal level of the timestamp.
- **Possible values:**
QTSA
TSA
N/A
| - -#### Sample JSON response Simple Report (successful scenario) - -```json -{"validationReport": {"validationConclusion": { - "validationTime": "2020-06-15T11:45:52Z", - "signaturesCount": 1, - "validationLevel": "ARCHIVAL_DATA", - "validatedDocument": {"filename": "singleValidSignatureTS.asice"}, - "validSignaturesCount": 1, - "signatures": [{ - "signatureFormat": "XAdES_BASELINE_LT", - "subjectDistinguishedName": { - "commonName": "JÕEORG,JAAK-KRISTJAN,38001085718", - "serialNumber": "PNOEE-38001085718" - }, - "certificates": [ - { - "commonName": "DEMO of SK TSA 2014", - "type": "SIGNATURE_TIMESTAMP", - "content": "MII..." - }, - { - "commonName": "JÕEORG,JAAK-KRISTJAN,38001085718", - "type": "SIGNING", - "content": "MII...", - "issuer": { - "commonName": "TEST of ESTEID2018", - "content": "MII..." - } - }, - { - "commonName": "TEST of SK OCSP RESPONDER 2011", - "type": "REVOCATION", - "content": "MII..." - } - ], - "signedBy": "JÕEORG,JAAK-KRISTJAN,38001085718", - "claimedSigningTime": "2020-05-21T13:56:52Z", - "signatureLevel": "QESIG", - "signatureScopes": [{ - "scope": "FULL", - "name": "test.txt", - "content": "Full document" - }], - "signatureMethod": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256", - "id": "id-a9ce7f66cff1d17ddaab37c46a88f5f4", - "indication": "TOTAL-PASSED", - "info": { - "timestampCreationTime": "2020-05-21T13:56:48Z", - "timeAssertionMessageImprint": "MDEwDQYJYIZIAWUDBAIBBQAEID3j1ceryQp4ZNP8iVfd50l/0JXvpry+XS+ajiAUA+Su", - "bestSignatureTime": "2020-05-21T13:56:48Z", - "ocspResponseCreationTime": "2020-05-21T13:56:49Z" - } - }], - "policy": { - "policyDescription": "Policy according most common requirements of Estonian Public Administration, to validate Qualified Electronic Signatures and Electronic Seals with Qualified Certificates (according to Regulation (EU) No 910/2014, aka eIDAS). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result, with exception for seals, where AdES/QC and above will produce positive result. Signatures and Seals which are not compliant with ETSI standards (referred by eIDAS) may produce unknown or invalid validation result. Validation process is based on eIDAS Article 32 and referred ETSI standards.", - "policyUrl": "http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4", - "policyName": "POLv4" - }, - "signatureForm": "ASiC-E" -}}} -``` - -#### Sample JSON response Simple Report (ASiC-S with 2 timestamps) - -```json -{"validationReport": {"validationConclusion": { - "validationTime": "2024-10-31T11:37:06Z", - "signaturesCount": 0, - "validatedDocument": {"filename": "2xTST-valid-bdoc-data-file-1st-tst-invalid-2nd-tst-no-coverage.asics"}, - "validSignaturesCount": 0, - "timeStampTokens": [ - { - "signedTime": "2024-03-27T12:42:57Z", - "certificates": [ - { - "commonName": "DEMO SK TIMESTAMPING AUTHORITY 2023E", - "type": "CONTENT_TIMESTAMP", - "content": "MII..." - }, - { - "commonName": "TEST of SK TSA CA 2023E", - "type": "CONTENT_TIMESTAMP", - "content": "MII..." - }, - { - "commonName": "TEST of SK ID Solutions ROOT G1E", - "type": "CONTENT_TIMESTAMP", - "content": "MII..." - } - ], - "signedBy": "DEMO SK TIMESTAMPING AUTHORITY 2023E", - "indication": "TOTAL-FAILED", - "error": [{"content": "The time-stamp message imprint is not intact!"}], - "subIndication": "HASH_FAILURE", - "timestampLevel": "QTSA" - }, - { - "signedTime": "2024-09-11T06:03:34Z", - "certificates": [ - { - "commonName": "DEMO SK TIMESTAMPING AUTHORITY 2023E", - "type": "CONTENT_TIMESTAMP", - "content": "MII..." - }, - { - "commonName": "TEST of SK TSA CA 2023E", - "type": "CONTENT_TIMESTAMP", - "content": "MII..." - }, - { - "commonName": "TEST of SK ID Solutions ROOT G1E", - "type": "CONTENT_TIMESTAMP", - "content": "MII..." - } - ], - "signedBy": "DEMO SK TIMESTAMPING AUTHORITY 2023E", - "warning": [{"content": "The time-stamp token does not cover container datafile!"}], - "indication": "TOTAL-PASSED", - "timestampScopes": [ - { - "scope": "FULL", - "name": "META-INF/ASiCArchiveManifest.xml", - "content": "Manifest document" - }, - { - "scope": "FULL", - "name": "META-INF/timestamp.tst", - "content": "Full document" - } - ], - "timestampLevel": "QTSA" - } - ], - "policy": { - "policyDescription": "Policy according most common requirements of Estonian Public Administration, to validate Qualified Electronic Signatures and Electronic Seals with Qualified Certificates (according to Regulation (EU) No 910/2014, aka eIDAS). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result, with exception for seals, where AdES/QC and above will produce positive result. Signatures and Seals which are not compliant with ETSI standards (referred by eIDAS) may produce unknown or invalid validation result. Validation process is based on eIDAS Article 32 and referred ETSI standards.", - "policyUrl": "http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4", - "policyName": "POLv4" - }, - "signatureForm": "ASiC-S" -}}} -``` - -#### Warning/error messages filtered out in Simple Report - -From Simple Report following messages, that are considered false-positive in Estonian context, are filtered out: -* Warning: _The organization name is missing in the trusted certificate!_ -* Warning: _The trusted certificate does not match the trust service!_ -* Error: _The certificate is not related to a granted status at time-stamp lowest POE time!_ (only in case of signatures) - * In case of time stamp token in ASiC-S, the error is moved under warnings and additional warning is added: - * "_Found a timestamp token not related to granted status. If not yet covered with a fresh timestamp token, this container might become invalid in the future._" - -Above messages are filtered out only in Simple Report. - -### Validation response parameters Detailed Report (successful scenario) - -General structure of validation response. - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|-----------------|-------------| -| validationReport | + | Object | Object containing SIVA validation report. | -| validationReport. validationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report. | -| validationReport. validationProcess | - | Object | Object containing information of the validation process. This block is present only on DSS library based validations and is built on DSS detailed report. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/_chapters/signature-validation.adoc). | -| validationReportSignature | - | String | Base64 string of ASIC-E container that includes the detailed report and is signed by the validation service provider | - -### Validation response parameters for Diagnostic Data Report (successful scenario) - -General structure of validation response. - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|-----------------|-------------| -| validationReport | + | Object | Object containing SIVA validation report. | -| validationReport. validationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report and Detailed Report. | -| validationReport. diagnosticData | - | Object | Object containing diagnostic data about the information contained in the signature itself, it's revocation data and mathematical validity. This block is present only on DSS library based validations (excluding hashcode validation) and is built on DSS diagnostic data. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/dss-documentation.adoc#validation-process). | - -### Sample JSON response (error situation) -In case of error (when validation report is not returned) status code 400 is returned together with following message body: - -```json -{"requestErrors": [{ - "message": "Document malformed or not matching documentType", - "key": "document" -}]} -``` - -## Data files request interface - - -** REST JSON Endpoint ** - -``` -POST https:///getDataFiles -``` - -### Data files request parameters - -Data files request parameters for JSON interface are described in the table below. - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|----------------|-------------| -| document | + | String | Base64 encoded string of digitally signed DDOC document | -| filename | + | String | File name of the digitally signed document (i.e. sample.ddoc), max length 255 characters. Currently only DDOC file format is supported for this operation| - -### Sample JSON request - -```json -{ - "filename":"sample.ddoc", - "document":"PD94bWwgdmVyc2lvbj0iMS4...." -} -``` - -## Data files response interface - -### Data files response parameters (successful scenario) - -The data file extraction report (i.e. the data files response) for JSON interface is described in the table below. -SiVa returns all data files as they are extracted by JDigiDoc library in an as is form. No extra operations or validations are done. - -| JSON parameter | Mandatory | JSON data type | Description | -|----------------|-----------|----------------|-------------| -| dataFiles | - | Array | Collection of data files found in digitally signed document | -| dataFiles[0] | + | Object | Extracted data file object | -| dataFiles[0].fileName | - | String | File name of the extracted data file | -| dataFiles[0].size | - | Long | Extracted data file size in bytes | -| dataFiles[0].base64 | - |String | Base64 encoded string of extracted data file | -| dataFiles[0].mimeType | - | String | MIME type of the extracted data file | - -### Sample JSON response (successful scenario) - -```json -{ -"dataFiles": [{ - "fileName": "Glitter-rock-4_gallery.jpg", - "size": 41114, - "base64": "/9j/4AAQSkZJ...", - "mimeType": "application/octet-stream" }] -} -``` - -### Sample JSON response (error situation) -In case of error (when datafiles are not returned) status code 400 is returned together with following message body: - -```json -{"requestErrors": [{ - "message": "Invalid document type. Can only return data files for DDOC type containers.", - "key": "documentType" -}]} -``` - - - -## Service health monitoring - -SiVa webapps provide an interface for external monitoring tools (to periodically check the generic service health status). - -### The request -The monitoring endpoint is accessible via HTTP GET at **/monitoring/health** or **/monitoring/health.json** url. - -Sample request: -``` -GET https:///monitoring/health -``` - -### The response - -As a response, a JSON object is returned with the following information: - -| Field | Description | -| ---------| --------------- | -| status | General status of the webapp.
Possible values:
  • **DOWN** - when some of the dependent indicators status are down (ie when `link{number}.status` is DOWN, the overall service status is DOWN)
  • **UP** - the default value.
| -| components.health.status | Status of current webapp - constant value **UP** | -| components.health.details.webappName | The artifact name of the webapp. Taken from the MANIFEST.MF file (inside the jar/war file). | -| components.health.details.version | The release version fo the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | -| components.health.details.buildTime | Build date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') of the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | -| components.health.details.startTime | Webapp startup date and time (format yyyy-MM-dd'T'HH:mm:ss'Z')| -| components.health.details.currentTime | Current server date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') | -| components.link{number}.status | (OPTIONAL) Represents the status of a link to the external system that the webapp depends on.
  • **DOWN** when the webapp does not respond (within a specified timeout limit - default 10 seconds) or the response is in invalid format (default Spring boot actuator /health endpoint format is expected).
  • **UP** if the service responds with HTTP status code 200 and returns a valid JSON object with status "UP"
|) | -| components.link{number}.details.name | (OPTIONAL) Descriptive name for the link to the external system | - -Sample response: - -```json -{ - "status": "UP", - "components": { - "health": { - "details": { - "webappName":"siva-sample-application", - "version":"3.3.0", - "buildTime":"2016-10-21T15:56:21Z", - "startTime":"2016-10-21T15:57:48Z", - "currentTime":"2016-10-21T15:58:39Z" - }, - "status": "UP" - }, - "link1": { - "details": { - "name": "sivaService" - }, - "status": "UP" - } - } -} -``` - -## Simplified health monitoring - -SiVa webapps provide a simple interface for external monitoring tools (to periodically check the generic service health status). - -### The request -The simplified monitoring endpoint is accessible via HTTP GET at **/monitoring/heartbeat** url. - -Sample request: -``` -GET https:///monitoring/heartbeat -``` - -### The response - -As a response, a JSON object is returned with the following information: - -| Field | Description | -| ---------| --------------- | -| status | General status of the webapp.
Possible values:
  • **DOWN** - when the webapp or any of its dependencies down.
  • **UP** - the default value.
| - -Sample response: - -```json -{ - "status": "UP" -} -``` - -## Version information - -SiVa webapps provide a simple interface for querying the application version information. - -### The request -The version information endpoint is accessible via HTTP GET at **/monitoring/version** url. - -Sample request: -``` -GET https:///monitoring/version -``` - -### The response - -As a response, a JSON object is returned with the following information: - -| Field | Description | -| ---------| --------------- | -| version | Version string of the webapp | - -Sample response: - -```json -{ - "version": "3.5.0" -} -``` - -## Changes in API compared to V3 v3.8.1 - -#### SOAP interface removed. -Discontinued support for following endpoints (incl. respective WSDL definitions): -``` -https:///soap/validationWebService/validateDocument -https:///soap/hashcodeValidationWebService -https:///soap/dataFilesWebService/getDocumentDataFiles - -https:///soap/validationWebService/validateDocument?wsdl -https:///soap/hashcodeValidationWebService?wsdl -https:///soap/dataFilesWebService/getDocumentDataFiles?wsdl -``` -#### Changes in validating ASiC-S containers -- Logic for ASiC-S container timestamp token validation is removed and delegated to DSS. -- POE time is taken into account during validation of the time-stamped ASiC-S nested container. - - Added support for defining custom constraint files to be used for validation. -- ASiC-S nested container validation is now triggered when at least one valid timestamp is present. -- Added new fields into ASiC-S container validation response (see next section). - -### Changes in validation response (non-breaking additions to protocol) - -Changes are described using notation from REST endpoint. - -| Report | Parameter | Change | Link | Comment | -|---------------|-----------|--------|------|---------| -| validationConclusion | timeStampTokens[0]. certificates | Parameter block added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Array containing certificates that are present in the timestamp. | -| validationConclusion | timeStampTokens[0]. certificates[0] | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Object containing certificate type, common name and certificate. | -| validationConclusion | timeStampTokens[0]. certificates[0].commonName | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | CN (common name) value in certificate. | -| validationConclusion | timeStampTokens[0]. certificates[0].type | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Type of the certificate. Can be CONTENT_TIMESTAMP or ARCHIVE_TIMESTAMP. | -| validationConclusion | timeStampTokens[0]. certificates[0].content | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | DER encoded X.509 certificate in Base64. | -| validationConclusion | timeStampTokens[0]. subIndication | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Additional subindication in case of failed or indeterminate validation result. | -| validationConclusion | timeStampTokens[0]. warning | Parameter block added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Block of validation warnings. | -| validationConclusion | timeStampTokens[0]. warning[0] | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Object containing the warning. | -| validationConclusion | timeStampTokens[0]. warning[0]. content | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Warning description. | -| validationConclusion | timeStampTokens[0]. timestampScopes | Parameter block added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Object containing information of the original data that is covered by the timestamp. | -| validationConclusion | timeStampTokens[0]. timestampScopes[0]. name | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Name of the timestamp scope. | -| validationConclusion | timeStampTokens[0]. timestampScopes[0]. scope | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Type of the timestamp scope. | -| validationConclusion | timeStampTokens[0]. timestampScopes[0]. content | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Description of the timestamp scope. | -| validationConclusion | timeStampTokens[0]. timestampLevel | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Legal level of the timestamp. | - -## Changes in API compared to V3 v3.4.0 - -Changes are described using notation from REST endpoint. - -### New endpoints - -| Endpoint | HTTP Method | Link | Comment | -|----------|-----------|------|---------| -| /monitoring/heartbeat | GET | [Link](../interfaces/#simplified-health-monitoring) | New monitoring endpoint | -| /monitoring/version | GET | [Link](../interfaces/#version-information) | New monitoring endpoint | - - -## Changes in API compared to V3 v3.3.0 - -Changes are described using notation from REST endpoint. - -### Changes in response - -| Report | Parameter | Change | Link | Comment | -|---------------|-----------|--------|------|---------| -| validationConclusion | signatures[0].info.timestampCreationTime | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Date containing timestamp creation time added | -| validationConclusion | signatures[0].info.ocspResponseCreationTime | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Date containing OCSP response creation time added | -| validationConclusion | signatures[0].info.signingReason | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | String containing signing reason for PAdES added | - -## Changes in API compared to V3 v3.2.0 (non-breaking additions to protocol) - -Changes are described using notation from REST endpoint. - -### Changes in response - -| Report | Parameter | Change | Link | Comment | -|---------------|-----------|--------|------|---------| -| validationConclusion | signatures[0].signatureMethod | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Used signature method is now returned | -| validationConclusion | signatures[0].info.timeAssertionMessageImprint | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Base64 encoded value of message imprint retrieved from time assertion. In case of LT_TM (TimeMark) signatures, OCSP nonce value is returned. In case of T, LT or LTA (TimeStamp) signatures, TimeStamp message imprint is returned. | -| validationConclusion | signatures[0].info.signatureProductionPlace | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Object containing optional signing location info added | -| validationConclusion | signatures[0].info.signerRole | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Array containing optional signer roles added | -| validationConclusion | signatures[0].certificates | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Array containing certificates that are present in the signature or in TSL. | - -## Changes in API compared to V2 - -Changes are described using notation from REST endpoint. - -### Changes in request - -| Endpoint | Parameter | Change | Link | Comment | -|----------|-----------|--------|------|---------| -| /validateDocument | reportType | parameter added | [Link](../interfaces/#validation-request-parameters) | Diagnostic report type added | -| /validateHashcode | whole request | request changed | [Link](../interfaces/#validation-request-parameters_1) | Request changed to support validation of multiple signatures with one request | - -### Changes in response - -| Response type | Parameter | Change | Link | Comment | -|---------------|-----------|--------|------|-----------------------------------------------------------------------| -| Simple | validatedDocument | now optional | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Object now optional | -| Simple | validatedDocument.filename | now optional | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | String now optional | -| Simple | validatedDocument.fileHash | changed | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Previously validatedDocument.fileHashInHex. Now contains Base64 value | -| Simple | signatures[0].subjectDistinguishedName.serialNumber | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers serial number field | -| Simple | signatures[0].subjectDistinguishedName.commonName | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers common name field | -| Simple | signatures[0].subjectDistinguishedName.givenName | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers given name from SubjectDistinguishedName field | -| Simple | signatures[0].subjectDistinguishedName.surname | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers surname from SubjectDistinguishedName field | -| Simple | signatures[0].signatureScopes[0].hashAlgo | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added datafile hash algo field for hashcode validation | -| Simple | signatures[0].signatureScopes[0].hash | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added datafile hash field for hashcode validation | -| Diagnostic | whole response | added | [Link](../interfaces/#validation-response-parameters-for-diagnostic-data-report-successful-scenario) | New report type added | - + + +In this section the SiVa external interfaces are described. For information of internal components and their interfaces, please refer to [**Structure and activities**](../siva3/structure_and_activities.md). + +SiVa service provides **REST JSON** interface that enable the service users to: + +* Request validation of signatures in a digitally signed document (i.e. signature container like BDOC,ASiC-E/PDF/...). +* Request validation of ASiC-S containers with time stamp tokens (i.e. Estonian ASiC-S with encapsulated container inside) +* Request validation of XAdES signature without datafiles. +* Request datafiles inside of DDOC container. + +SiVa service REST JSON interface supports X-Road v6. However, it is optional whether to integrate SiVa service using X-Road or using "plain" REST interface. This document only describes the SiVa service part of the interface, for the X-Road specifics visit Riigi Infosüsteemi Amet [webpage](https://www.ria.ee/en/state-information-system/data-exchange-platforms/data-exchange-layer-x-tee). + +In the following subsections, the SiVa validation request and response interfaces are described in detail. + +## Validation request interface + + +** REST JSON Endpoint ** + +``` +POST https:///validate +``` + +### Validation request parameters + +Validation request parameters for JSON interface are described in the table below. + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|-------------|----------------| +| document | + | String | Base64 encoded string of digitally signed document to be validated | +| filename | + | String | File name of the digitally signed document (i.e. sample.bdoc), max length 255 characters. | +| signaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](../siva3/appendix/validation_policy.md) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | +| reportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present).
Diagnostic - returns diagnostic data about the information contained in the signature itself, it's revocation data and mathematical validity (validationConclusion, diagnosticData block) | + +### Sample JSON request with mandatory parameters + +```json +{ + "filename":"sample.bdoc", + "document":"PD94bWwgdmVyc2lvbj0iMS4...." +} +``` +### Sample JSON request with all parameters + +```json +{ + "filename":"sample.asice", + "document":"PD94bWwgdmVyc2lvbj0iMS4....", + "signaturePolicy":"POLv3", + "reportType":"Detailed" +} +``` + +## Validation request interface for hashcode + +Hashcode XAdES validation is supported for **REST JSON** interface. + +** REST JSON Endpoint ** + +``` +POST https:///validateHashcode +``` + +### Validation request parameters + +Two different use cases are supported for the hashcode validation. +1) Providing the data file name, hash algorithm and hash on validation. +2) Providing only signature file. **NB! This method requires validation result change on integrator side when the local datafile hashes do not match with hashes returned in validation result!** + +Validation request parameters for JSON interface are described in the table below. + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|----------------|-------------| +| signatureFiles | + | Array | Array containing the signature objects. | +| signatureFiles[0] | + | Object | Object containing one signature file. | +| signatureFiles[0].signature | + | String | Base64 encoded string of signature file | +| signatureFiles[0].datafiles | - | Array | Array containing the information for datafiles that signature is covering | +| signatureFiles[0].datafiles[0] | + | Object | Object containing data file information | +| signatureFiles[0].datafiles[0].filename | + | String | File name of the hashed data file, max length 255 characters. | +| signatureFiles[0].datafiles[0].hashAlgo | + | String | Hash algorithm used for hashing the data file (must match with algorithm in signature file). Accepted values are dependant of validation policy | +| signatureFiles[0].datafiles[0].hash | + | String | Data file hash in Base64 encoded format. | +| signaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](../siva3/appendix/validation_policy.md) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | +| reportType | - | String |
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are not supported for hashcode).
Diagnostic - returns diagnostic data about the information contained in the signature itself, it's revocation data and mathematical validity (validationConclusion, diagnosticData block. Last one is not support for hashcode) | + +### Sample JSON request with mandatory parameters (datafile hashcode match verification done on integrators side) + +```json +{ + "signatureFiles": [ + { + "signature": "PD9094wskjd..." + }, + { + "signature": "AD9sa4wsfsd..." + } + ] +} +``` +### Sample JSON request with all parameters (datafile hashcode match verification done on SIVA side) + +```json +{ + "signatureFiles": [ + { + "signature": "PD94bWwgdmVyc2lvbj...", + "datafiles": [ + { + "filename": "leping.pdf", + "hashAlgo": "SHA256", + "hash": "WRlczpSZXZvY2F0aW9uVmFsd..." + }, + { + "filename": "leping2.pdf", + "hashAlgo": "SHA256", + "hash": "WRlpzaF0F0sda2vaW9uVmFsd..." + } + ] + }, + { + "signature": "PDadw4mVyc2lvbj...", + "datafiles": [ + { + "filename": "leping.pdf", + "hashAlgo": "SHA256", + "hash": "WRlczpSZXZvY2F0aW9uVmFsd..." + }, + { + "filename": "leping2.pdf", + "hashAlgo": "SHA256", + "hash": "WRlpzaF0F0sda2vaW9uVmFsd..." + } + ] + } + ], + "reportType": "Simple", + "signaturePolicy": "POLv4" +} +``` + +## Validation response interface +The signature validation report (i.e. the validation response) for JSON interface depends on what type of validation report was requested. + +### Validation response parameters Simple Report (successful scenario) + +General structure of validation response. + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|-----------------|-------------| +| validationReport | + | Object | Object containing SIVA validation report | +| validationReport. validationConclusion | + | Object | Object containing information of the validation conclusion | + +Structure of validationConclusion block + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|-----------------|-------------| +| policy | + | Object | Object containing information of the SiVa signature validation policy that was used for validation. | +| policy.policyName | + | String | Name of the validation policy | +| policy. policyDescription | + | String | Short description of the validation policy. | +| policy.policyUrl | + | String | URL where the signature validation policy document can be downloaded. The validation policy document shall include information about validation of all the document formats, including the different validation policies that are used in case of different file formats and base libraries. | +| signaturesCount | + | Number | Number of signatures found inside digitally signed file. | +| validSignaturesCount | + | Number | Signatures count that have validated to `TOTAL-PASSED`. See also `Signature.Indication` field. | +| validationLevel | - | String | Validation process against what the document is validated, only applicable on DSS based validations.
**Possible values:**
ARCHIVAL_DATA| +| validationTime | + | Date | Time of validating the signature by the service. | +| validationWarnings | - | Array | Array of SiVa validation warnings that do not affect the overall validation result. See also `signatures.warnings` parameter. | +| validationWarnings[0] | + | Object | Object containing the warning. | +| validationWarnings[0]. content | + | String | Description of the warning. | +| validatedDocument | - | Object | Object containing information about validated document. | +| validatedDocument. filename | - | String | Digitally signed document's file name. Not present for hashcode validation. | +| validatedDocument. fileHash | - | String | Calculated hash for validated document in Base64. Present when report signing is enabled. | +| validatedDocument. hashAlgo | - | String | Hash algorithm used. Present when report signing is enabled. | +| signatureForm | - | String | Format (and optionally version) of the digitally signed document container.
In case of documents in [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) format, the "hashcode" suffix is used to denote that the container was validated in [hashcode mode](https://open-eid.github.io/allkirjastamisteenus/json-technical-description/#hashcode-container-form), i.e. without original data files.
**Possible values:**
DIGIDOC_XML_1.0
DIGIDOC_XML_1.0_hashcode
DIGIDOC_XML_1.1
DIGIDOC_XML_1.1_hashcode
DIGIDOC_XML_1.2
DIGIDOC_XML_1.2_hashcode
DIGIDOC_XML_1.3
DIGIDOC_XML_1.3_hashcode
ASiC-E - used in case of all ASiC-E (and [BDOC](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf)) documents
ASiC-S - used in case of all ASiC-S documents | +| signatures | - | Array | Collection of signatures found in digitally signed document | +| signatures[0] | + | Object | Signature information object | +| signatures[0]. claimedSigningTime | + | Date | Claimed signing time, i.e. signer's computer time during signature creation | +| signatures[0].id | + | String | Signature ID attribute | +| signatures[0].indication | + | String | Overall result of the signature's validation process, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 5: Status indications of the signature validation process".
Note that the validation results of different signatures in one signed document (signature container) may vary.
See also `validSignaturesCount` and `SignaturesCount` fields.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED
INDETERMINATE | +| signatures[0]. subIndication | - | String | Additional subindication in case of failed or indeterminate validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics" | +| signatures[0].errors | - | Array | Information about validation error(s), array of error messages. | +| signatures[0].errors[0] | + | Object | Object containing the error | +| signatures[0].errors[0]. content | + | String | Error message, as returned by the base library that was used for signature validation. | +| signatures[0].info | - | Object | Object containing trusted signing time information and user added additional signing info. | +| signatures[0].info. bestSignatureTime | + | Date | Time value that is regarded as trusted signing time, denoting the earliest time when it can be trusted by the validation application (because proven by some Proof-of-Existence present in the signature) that a signature has existed.
The source of the value depends on the signature profile (see also `SignatureFormat` parameter):
- Signature with time-mark (LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature.
- Signature with time-stamp (LT or LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature.
- Signature with BES or EPES level - the value is empty, i.e. there is no trusted signing time value available. | +| signatures[0].info. timeAssertionMessageImprint | - | String | Base64 encoded value of message imprint retrieved from time assertion. In case of LT_TM (TimeMark) signatures, OCSP nonce value is returned. In case of T, LT or LTA (TimeStamp) signatures, TimeStamp message imprint is returned. | +| signatures[0].info. ocspResponseCreationTime | - | Date | Time value that is regarded as the original OCSP response creation time. | +| signatures[0].info. timestampCreationTime | - | Date | Time value of the timestamp creation | +| signatures[0].info. signerRole | - | Array | Array of roles attached to the signature. | +| signatures[0].info. signerRole[0] | + | Object | Object containing claimed roles. | +| signatures[0].info. signerRole[0]. claimedRole | + | String | Role stated by signer on signing. | +| signatures[0].info. signatureProductionPlace | - | Object | Object containing stated signing location info. | +| signatures[0].info. signatureProductionPlace.countryName | - | String | Stated signing country. | +| signatures[0].info. signatureProductionPlace.stateOrProvince | - | String | Stated state or province. | +| signatures[0].info. signatureProductionPlace.city | - | String | Stated city. | +| signatures[0].info. signatureProductionPlace.postalCode | - | String | Stated postal code. | +| signatures[0].info. signingReason | - | String | Free text field for PAdES type signatures for stating the signing reason | +| signatures[0].info. archiveTimestamps | - | Array | Array containing archive time-stamp tokens if present. | +| signatures[0].info. archiveTimestamps[0]. signedTime | + | String | Time when the archive time-stamp token was created. | +| signatures[0].info. archiveTimestamps[0]. indication | + | Object | Result of the archive time-stamp token validation.
**Possible values:**
PASSED
FAILED
NO_SIGNATURE_FOUND | +| signatures[0].info. archiveTimestamps[0]. subIndication | - | String | Additional subindication in case of failed or indeterminate validation result. | +| signatures[0].info. archiveTimestamps[0]. signedBy | + | String | Signer of the archive time-stamp token. | +| signatures[0].info. archiveTimestamps[0]. country | + | String | Issuer country of the archive time-stamp token. | +| signatures[0].info. archiveTimestamps[0]. content | + | String | Archive time-stamp token encoded in base64. | +| signatures[0]. signatureFormat | + | String | Format and profile (according to Baseline Profile) of the signature. See [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf), [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) and [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) for detailed description of the Baseline Profile levels. Levels that are accepted in SiVa validation policy are described in [SiVa signature validation policy](../siva3/appendix/validation_policy.md)
**Possible values:**
XAdES_BASELINE_B
XAdES_BASELINE_B_BES
XAdES_BASELINE_B_EPES
XAdES_BASELINE_T
XAdES_BASELINE_LT - long-term level XAdES signature where time-stamp is used as a assertion of trusted signing time
XAdES_BASELINE_LT_TM - long-term level XAdES signature where time-mark is used as a assertion of trusted signing time. Used in case of [BDOC](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf) signatures with time-mark profile and [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) signatures.
XAdES_BASELINE_LTA
CAdES_BASELINE_B
CAdES_BASELINE_T
CAdES_BASELINE_LT
CAdES_BASELINE_LTA
PAdES_BASELINE_B
PAdES_BASELINE_T
PAdES_BASELINE_LT
PAdES_BASELINE_LTA | +| signatures[0]. signatureMethod | + | String | Signature method specification URI used in signature creation. | +| signatures[0]. signatureLevel | - |String | Legal level of the signature, according to Regulation (EU) No 910/2014.
- **Possible values on positive validation result:**
QESIG
QESEAL
QES
ADESIG_QC
ADESEAL_QC
ADES_QC
ADESIG
ADESEAL
ADES
- **Possible values on indeterminate validation result:**
prefix INDETERMINATE is added to the level described in positive result. For example INDETERMINATE_QESIG
- **Possible values on negative validation result:**
In addition to abovementioned
NOT_ADES_QC_QSCD
NOT_ADES_QC
NOT_ADES
NA
- In case of DIGIDOC-XML 1.0..1.3 formats, value is missing as the signature level is not checked by the JDigiDoc base library that is used for validation. However, the signatures can be indirectly regarded as QES level signatures, see also [SiVa Validation Policy](../siva3/appendix/validation_policy.md)
| +| signatures[0].signedBy | + | String | In format of "surname, givenName, serialNumber" if these fields are present in subject distinguished name field. In other cases, value of common name field. | +| signatures[0]. subjectDistinguishedName | - | Object | Object containing subject's distinguished name information. | +| signatures[0]. subjectDistinguishedName .serialNumber | - | String | SERIALNUMBER value portion in signer's certificate's subject distinguished name | +| signatures[0]. subjectDistinguishedName .commonName | - | String | CN (common name) value portion in signer's certificate's subject distinguished name | +| signatures[0]. subjectDistinguishedName .givenName | - | String | Given name value portion in signer's certificate's subject distinguished name | +| signatures[0]. subjectDistinguishedName .surname | - | String | Surname value portion in signer's certificate's subject distinguished name | +| signatures[0]. signatureScopes | - | Array | Contains information of the original data that is covered by the signature. | +| signatures[0]. signatureScopes[0]. name | + | String | Name of the signature scope. | +| signatures[0]. signatureScopes[0]. scope | + | String | Type of the signature scope. | +| signatures[0]. signatureScopes[0]. content | + | String | Description of the scope. | +| signatures[0]. signatureScopes[0]. hashAlgo | - | String | Hash algorithm used for datafile hash calculation. Present for hashcode validation. | +| signatures[0]. signatureScopes[0]. hash | - | String | Hash of data file encoded in Base64. Present for hashcode validation. | +| signatures[0]. warnings | - | Array | Block of validation warnings that do not affect the overall validation result. | +| signatures[0]. warnings[0] | + | Object | Object containing the warning | +| signatures[0]. warnings[0]. content | + | String | Warning description, as returned by the base library that was used for validation. | +| signatures[0]. certificates | - | Array | Array containing certificates that are present in the signature or can be fetched from TSL. | +| signatures[0]. certificates[0] | + | Object | Object containing certificate type, common name and certificate. Minimal object is signer certificate. If present contains certificates for TimeStamps and OCSP as well. | +| signatures[0]. certificates[0].commonName | + | String | CN (common name) value in certificate. | +| signatures[0]. certificates[0].type | + | String | Type of the certificate. Can be SIGNING, REVOCATION, SIGNATURE_TIMESTAMP, ARCHIVE_TIMESTAMP or CONTENT_TIMESTAMP. | +| signatures[0]. certificates[0].content | + | String | DER encoded X.509 certificate in Base64. | +| signatures[0]. certificates[0].issuer | - | Object | Object containing issuer certificate information. Can create chain til the trust anchor. | +| signatures[0]. certificates[0].issuer.commonName | + | String | CN (common name) value in certificate. | +| signatures[0]. certificates[0].issuer.content | + | String | DER encoded X.509 certificate in Base64. | +| timeStampTokens | - | Array | Array containing the time stamp tokens | +| timeStampTokens[0] | + | Object | Object containing the time stamp token (TST) | +| timeStampTokens[0]. indication | + | String | Result of the time stamp token validation.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED | +| timeStampTokens[0]. subIndication | - | String | Additional subindication in case of failed validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics". | +| timeStampTokens[0]. signedBy | + | String | Signer of the time stamp token. | +| timeStampTokens[0]. signedTime | + | String | Time when the time stamp token was given. | +| timeStampTokens[0]. certificates | + | Array | Array containing certificates that are present in the timestamp. | +| timeStampTokens[0]. certificates[0] | + | Object | Object containing certificate type, common name and certificate. | +| timeStampTokens[0]. certificates[0].commonName | + | String | CN (common name) value in certificate. | +| timeStampTokens[0]. certificates[0].type | + | String | Type of the certificate. Possible value is CONTENT_TIMESTAMP. | +| timeStampTokens[0]. certificates[0].content | + | String | DER encoded X.509 certificate in Base64. | +| timeStampTokens[0]. error | - | Array | Errors returned in time stamp token validation. | +| timeStampTokens[0]. error[0] | + | Object | Object containing the error. | +| timeStampTokens[0]. error[0]. content | + | String | Error description. | +| timeStampTokens[0]. warning | - | Array | Block of validation warnings that do not affect the overall validation result.

Aside from warnings produced by DSS, an additional warning may be issued if a timestamp token does not cover the datafile (`The time-stamp token does not cover container datafile!`). | +| timeStampTokens[0]. warning[0] | + | Object | Object containing the warning. | +| timeStampTokens[0]. warning[0]. content | + | String | Warning description. | +| timeStampTokens[0]. timestampScopes | - | Array | Contains information of the original data that is covered by the timestamp. | +| timeStampTokens[0]. timestampScopes[0]. name | + | String | Name of the timestamp scope. | +| timeStampTokens[0]. timestampScopes[0]. scope | + | String | Type of the timestamp scope. | +| timeStampTokens[0]. timestampScopes[0]. content | + | String | Description of the timestamp scope. | +| timeStampTokens[0]. timestampLevel | - |String | Legal level of the timestamp.
- **Possible values:**
QTSA
TSA
N/A
| + +#### Sample JSON response Simple Report (successful scenario) + +```json +{"validationReport": {"validationConclusion": { + "validationTime": "2020-06-15T11:45:52Z", + "signaturesCount": 1, + "validationLevel": "ARCHIVAL_DATA", + "validatedDocument": {"filename": "singleValidSignatureTS.asice"}, + "validSignaturesCount": 1, + "signatures": [{ + "signatureFormat": "XAdES_BASELINE_LT", + "subjectDistinguishedName": { + "commonName": "JÕEORG,JAAK-KRISTJAN,38001085718", + "serialNumber": "PNOEE-38001085718" + }, + "certificates": [ + { + "commonName": "DEMO of SK TSA 2014", + "type": "SIGNATURE_TIMESTAMP", + "content": "MII..." + }, + { + "commonName": "JÕEORG,JAAK-KRISTJAN,38001085718", + "type": "SIGNING", + "content": "MII...", + "issuer": { + "commonName": "TEST of ESTEID2018", + "content": "MII..." + } + }, + { + "commonName": "TEST of SK OCSP RESPONDER 2011", + "type": "REVOCATION", + "content": "MII..." + } + ], + "signedBy": "JÕEORG,JAAK-KRISTJAN,38001085718", + "claimedSigningTime": "2020-05-21T13:56:52Z", + "signatureLevel": "QESIG", + "signatureScopes": [{ + "scope": "FULL", + "name": "test.txt", + "content": "Full document" + }], + "signatureMethod": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256", + "id": "id-a9ce7f66cff1d17ddaab37c46a88f5f4", + "indication": "TOTAL-PASSED", + "info": { + "timestampCreationTime": "2020-05-21T13:56:48Z", + "timeAssertionMessageImprint": "MDEwDQYJYIZIAWUDBAIBBQAEID3j1ceryQp4ZNP8iVfd50l/0JXvpry+XS+ajiAUA+Su", + "bestSignatureTime": "2020-05-21T13:56:48Z", + "ocspResponseCreationTime": "2020-05-21T13:56:49Z" + } + }], + "policy": { + "policyDescription": "Policy according most common requirements of Estonian Public Administration, to validate Qualified Electronic Signatures and Electronic Seals with Qualified Certificates (according to Regulation (EU) No 910/2014, aka eIDAS). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result, with exception for seals, where AdES/QC and above will produce positive result. Signatures and Seals which are not compliant with ETSI standards (referred by eIDAS) may produce unknown or invalid validation result. Validation process is based on eIDAS Article 32 and referred ETSI standards.", + "policyUrl": "http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4", + "policyName": "POLv4" + }, + "signatureForm": "ASiC-E" +}}} +``` + +#### Sample JSON response Simple Report (ASiC-S with 2 timestamps) + +```json +{"validationReport": {"validationConclusion": { + "validationTime": "2024-10-31T11:37:06Z", + "signaturesCount": 0, + "validatedDocument": {"filename": "2xTST-valid-bdoc-data-file-1st-tst-invalid-2nd-tst-no-coverage.asics"}, + "validSignaturesCount": 0, + "timeStampTokens": [ + { + "signedTime": "2024-03-27T12:42:57Z", + "certificates": [ + { + "commonName": "DEMO SK TIMESTAMPING AUTHORITY 2023E", + "type": "CONTENT_TIMESTAMP", + "content": "MII..." + }, + { + "commonName": "TEST of SK TSA CA 2023E", + "type": "CONTENT_TIMESTAMP", + "content": "MII..." + }, + { + "commonName": "TEST of SK ID Solutions ROOT G1E", + "type": "CONTENT_TIMESTAMP", + "content": "MII..." + } + ], + "signedBy": "DEMO SK TIMESTAMPING AUTHORITY 2023E", + "indication": "TOTAL-FAILED", + "error": [{"content": "The time-stamp message imprint is not intact!"}], + "subIndication": "HASH_FAILURE", + "timestampLevel": "QTSA" + }, + { + "signedTime": "2024-09-11T06:03:34Z", + "certificates": [ + { + "commonName": "DEMO SK TIMESTAMPING AUTHORITY 2023E", + "type": "CONTENT_TIMESTAMP", + "content": "MII..." + }, + { + "commonName": "TEST of SK TSA CA 2023E", + "type": "CONTENT_TIMESTAMP", + "content": "MII..." + }, + { + "commonName": "TEST of SK ID Solutions ROOT G1E", + "type": "CONTENT_TIMESTAMP", + "content": "MII..." + } + ], + "signedBy": "DEMO SK TIMESTAMPING AUTHORITY 2023E", + "warning": [{"content": "The time-stamp token does not cover container datafile!"}], + "indication": "TOTAL-PASSED", + "timestampScopes": [ + { + "scope": "FULL", + "name": "META-INF/ASiCArchiveManifest.xml", + "content": "Manifest document" + }, + { + "scope": "FULL", + "name": "META-INF/timestamp.tst", + "content": "Full document" + } + ], + "timestampLevel": "QTSA" + } + ], + "policy": { + "policyDescription": "Policy according most common requirements of Estonian Public Administration, to validate Qualified Electronic Signatures and Electronic Seals with Qualified Certificates (according to Regulation (EU) No 910/2014, aka eIDAS). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result, with exception for seals, where AdES/QC and above will produce positive result. Signatures and Seals which are not compliant with ETSI standards (referred by eIDAS) may produce unknown or invalid validation result. Validation process is based on eIDAS Article 32 and referred ETSI standards.", + "policyUrl": "http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4", + "policyName": "POLv4" + }, + "signatureForm": "ASiC-S" +}}} +``` + +#### Warning/error messages filtered out in Simple Report + +From Simple Report following messages, that are considered false-positive in Estonian context, are filtered out: +* Warning: _The organization name is missing in the trusted certificate!_ +* Warning: _The trusted certificate does not match the trust service!_ +* Error: _The certificate is not related to a granted status at time-stamp lowest POE time!_ (only in case of signatures) + * In case of time stamp token in ASiC-S, the error is moved under warnings and additional warning is added: + * "_Found a timestamp token not related to granted status. If not yet covered with a fresh timestamp token, this container might become invalid in the future._" + +Above messages are filtered out only in Simple Report. + +### Validation response parameters Detailed Report (successful scenario) + +General structure of validation response. + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|-----------------|-------------| +| validationReport | + | Object | Object containing SIVA validation report. | +| validationReport. validationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report. | +| validationReport. validationProcess | - | Object | Object containing information of the validation process. This block is present only on DSS library based validations and is built on DSS detailed report. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/_chapters/signature-validation.adoc). | +| validationReportSignature | - | String | Base64 string of ASIC-E container that includes the detailed report and is signed by the validation service provider | + +### Validation response parameters for Diagnostic Data Report (successful scenario) + +General structure of validation response. + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|-----------------|-------------| +| validationReport | + | Object | Object containing SIVA validation report. | +| validationReport. validationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report and Detailed Report. | +| validationReport. diagnosticData | - | Object | Object containing diagnostic data about the information contained in the signature itself, it's revocation data and mathematical validity. This block is present only on DSS library based validations (excluding hashcode validation) and is built on DSS diagnostic data. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/dss-documentation.adoc#validation-process). | + +### Sample JSON response (error situation) +In case of error (when validation report is not returned) status code 400 is returned together with following message body: + +```json +{"requestErrors": [{ + "message": "Document malformed or not matching documentType", + "key": "document" +}]} +``` + +## Data files request interface + + +** REST JSON Endpoint ** + +``` +POST https:///getDataFiles +``` + +### Data files request parameters + +Data files request parameters for JSON interface are described in the table below. + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|----------------|-------------| +| document | + | String | Base64 encoded string of digitally signed DDOC document | +| filename | + | String | File name of the digitally signed document (i.e. sample.ddoc), max length 255 characters. Currently only DDOC file format is supported for this operation| + +### Sample JSON request + +```json +{ + "filename":"sample.ddoc", + "document":"PD94bWwgdmVyc2lvbj0iMS4...." +} +``` + +## Data files response interface + +### Data files response parameters (successful scenario) + +The data file extraction report (i.e. the data files response) for JSON interface is described in the table below. +SiVa returns all data files as they are extracted by JDigiDoc library in an as is form. No extra operations or validations are done. + +| JSON parameter | Mandatory | JSON data type | Description | +|----------------|-----------|----------------|-------------| +| dataFiles | - | Array | Collection of data files found in digitally signed document | +| dataFiles[0] | + | Object | Extracted data file object | +| dataFiles[0].fileName | - | String | File name of the extracted data file | +| dataFiles[0].size | - | Long | Extracted data file size in bytes | +| dataFiles[0].base64 | - |String | Base64 encoded string of extracted data file | +| dataFiles[0].mimeType | - | String | MIME type of the extracted data file | + +### Sample JSON response (successful scenario) + +```json +{ +"dataFiles": [{ + "fileName": "Glitter-rock-4_gallery.jpg", + "size": 41114, + "base64": "/9j/4AAQSkZJ...", + "mimeType": "application/octet-stream" }] +} +``` + +### Sample JSON response (error situation) +In case of error (when datafiles are not returned) status code 400 is returned together with following message body: + +```json +{"requestErrors": [{ + "message": "Invalid document type. Can only return data files for DDOC type containers.", + "key": "documentType" +}]} +``` + + + +## Service health monitoring + +SiVa webapps provide an interface for external monitoring tools (to periodically check the generic service health status). + +### The request +The monitoring endpoint is accessible via HTTP GET at **/monitoring/health** or **/monitoring/health.json** url. + +Sample request: +``` +GET https:///monitoring/health +``` + +### The response + +As a response, a JSON object is returned with the following information: + +| Field | Description | +| ---------| --------------- | +| status | General status of the webapp.
Possible values:
  • **DOWN** - when some of the dependent indicators status are down (ie when `link{number}.status` is DOWN, the overall service status is DOWN)
  • **UP** - the default value.
| +| components.health.status | Status of current webapp - constant value **UP** | +| components.health.details.webappName | The artifact name of the webapp. Taken from the MANIFEST.MF file (inside the jar/war file). | +| components.health.details.version | The release version fo the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | +| components.health.details.buildTime | Build date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') of the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | +| components.health.details.startTime | Webapp startup date and time (format yyyy-MM-dd'T'HH:mm:ss'Z')| +| components.health.details.currentTime | Current server date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') | +| components.link{number}.status | (OPTIONAL) Represents the status of a link to the external system that the webapp depends on.
  • **DOWN** when the webapp does not respond (within a specified timeout limit - default 10 seconds) or the response is in invalid format (default Spring boot actuator /health endpoint format is expected).
  • **UP** if the service responds with HTTP status code 200 and returns a valid JSON object with status "UP"
|) | +| components.link{number}.details.name | (OPTIONAL) Descriptive name for the link to the external system | + +Sample response: + +```json +{ + "status": "UP", + "components": { + "health": { + "details": { + "webappName":"siva-sample-application", + "version":"3.3.0", + "buildTime":"2016-10-21T15:56:21Z", + "startTime":"2016-10-21T15:57:48Z", + "currentTime":"2016-10-21T15:58:39Z" + }, + "status": "UP" + }, + "link1": { + "details": { + "name": "sivaService" + }, + "status": "UP" + } + } +} +``` + +## Simplified health monitoring + +SiVa webapps provide a simple interface for external monitoring tools (to periodically check the generic service health status). + +### The request +The simplified monitoring endpoint is accessible via HTTP GET at **/monitoring/heartbeat** url. + +Sample request: +``` +GET https:///monitoring/heartbeat +``` + +### The response + +As a response, a JSON object is returned with the following information: + +| Field | Description | +| ---------| --------------- | +| status | General status of the webapp.
Possible values:
  • **DOWN** - when the webapp or any of its dependencies down.
  • **UP** - the default value.
| + +Sample response: + +```json +{ + "status": "UP" +} +``` + +## Version information + +SiVa webapps provide a simple interface for querying the application version information. + +### The request +The version information endpoint is accessible via HTTP GET at **/monitoring/version** url. + +Sample request: +``` +GET https:///monitoring/version +``` + +### The response + +As a response, a JSON object is returned with the following information: + +| Field | Description | +| ---------| --------------- | +| version | Version string of the webapp | + +Sample response: + +```json +{ + "version": "3.5.0" +} +``` + +## Changes in API compared to V3 v3.8.1 + +#### SOAP interface removed. +Discontinued support for following endpoints (incl. respective WSDL definitions): +``` +https:///soap/validationWebService/validateDocument +https:///soap/hashcodeValidationWebService +https:///soap/dataFilesWebService/getDocumentDataFiles + +https:///soap/validationWebService/validateDocument?wsdl +https:///soap/hashcodeValidationWebService?wsdl +https:///soap/dataFilesWebService/getDocumentDataFiles?wsdl +``` +#### Changes in validating ASiC-S containers +- Logic for ASiC-S container timestamp token validation is removed and delegated to DSS. +- POE time is taken into account during validation of the time-stamped ASiC-S nested container. + - Added support for defining custom constraint files to be used for validation. +- ASiC-S nested container validation is now triggered when at least one valid timestamp is present. +- Added new fields into ASiC-S container validation response (see next section). + +### Changes in validation response (non-breaking additions to protocol) + +Changes are described using notation from REST endpoint. + +| Report | Parameter | Change | Link | Comment | +|---------------|-----------|--------|------|---------| +| validationConclusion | timeStampTokens[0]. certificates | Parameter block added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Array containing certificates that are present in the timestamp. | +| validationConclusion | timeStampTokens[0]. certificates[0] | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Object containing certificate type, common name and certificate. | +| validationConclusion | timeStampTokens[0]. certificates[0].commonName | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | CN (common name) value in certificate. | +| validationConclusion | timeStampTokens[0]. certificates[0].type | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Type of the certificate. Can be CONTENT_TIMESTAMP or ARCHIVE_TIMESTAMP. | +| validationConclusion | timeStampTokens[0]. certificates[0].content | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | DER encoded X.509 certificate in Base64. | +| validationConclusion | timeStampTokens[0]. subIndication | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Additional subindication in case of failed or indeterminate validation result. | +| validationConclusion | timeStampTokens[0]. warning | Parameter block added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Block of validation warnings. | +| validationConclusion | timeStampTokens[0]. warning[0] | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Object containing the warning. | +| validationConclusion | timeStampTokens[0]. warning[0]. content | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Warning description. | +| validationConclusion | timeStampTokens[0]. timestampScopes | Parameter block added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Object containing information of the original data that is covered by the timestamp. | +| validationConclusion | timeStampTokens[0]. timestampScopes[0]. name | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Name of the timestamp scope. | +| validationConclusion | timeStampTokens[0]. timestampScopes[0]. scope | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Type of the timestamp scope. | +| validationConclusion | timeStampTokens[0]. timestampScopes[0]. content | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Description of the timestamp scope. | +| validationConclusion | timeStampTokens[0]. timestampLevel | Parameter added | [Link](#sample-json-response-simple-report-asic-s-with-2-timestamps) | Legal level of the timestamp. | + +## Changes in API compared to V3 v3.4.0 + +Changes are described using notation from REST endpoint. + +### New endpoints + +| Endpoint | HTTP Method | Link | Comment | +|----------|-----------|------|---------| +| /monitoring/heartbeat | GET | [Link](../interfaces/#simplified-health-monitoring) | New monitoring endpoint | +| /monitoring/version | GET | [Link](../interfaces/#version-information) | New monitoring endpoint | + + +## Changes in API compared to V3 v3.3.0 + +Changes are described using notation from REST endpoint. + +### Changes in response + +| Report | Parameter | Change | Link | Comment | +|---------------|-----------|--------|------|---------| +| validationConclusion | signatures[0].info.timestampCreationTime | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Date containing timestamp creation time added | +| validationConclusion | signatures[0].info.ocspResponseCreationTime | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Date containing OCSP response creation time added | +| validationConclusion | signatures[0].info.signingReason | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | String containing signing reason for PAdES added | + +## Changes in API compared to V3 v3.2.0 (non-breaking additions to protocol) + +Changes are described using notation from REST endpoint. + +### Changes in response + +| Report | Parameter | Change | Link | Comment | +|---------------|-----------|--------|------|---------| +| validationConclusion | signatures[0].signatureMethod | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Used signature method is now returned | +| validationConclusion | signatures[0].info.timeAssertionMessageImprint | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Base64 encoded value of message imprint retrieved from time assertion. In case of LT_TM (TimeMark) signatures, OCSP nonce value is returned. In case of T, LT or LTA (TimeStamp) signatures, TimeStamp message imprint is returned. | +| validationConclusion | signatures[0].info.signatureProductionPlace | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Object containing optional signing location info added | +| validationConclusion | signatures[0].info.signerRole | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Array containing optional signer roles added | +| validationConclusion | signatures[0].certificates | Parameter added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Array containing certificates that are present in the signature or in TSL. | + +## Changes in API compared to V2 + +Changes are described using notation from REST endpoint. + +### Changes in request + +| Endpoint | Parameter | Change | Link | Comment | +|----------|-----------|--------|------|---------| +| /validateDocument | reportType | parameter added | [Link](../interfaces/#validation-request-parameters) | Diagnostic report type added | +| /validateHashcode | whole request | request changed | [Link](../interfaces/#validation-request-parameters_1) | Request changed to support validation of multiple signatures with one request | + +### Changes in response + +| Response type | Parameter | Change | Link | Comment | +|---------------|-----------|--------|------|-----------------------------------------------------------------------| +| Simple | validatedDocument | now optional | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Object now optional | +| Simple | validatedDocument.filename | now optional | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | String now optional | +| Simple | validatedDocument.fileHash | changed | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Previously validatedDocument.fileHashInHex. Now contains Base64 value | +| Simple | signatures[0].subjectDistinguishedName.serialNumber | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers serial number field | +| Simple | signatures[0].subjectDistinguishedName.commonName | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers common name field | +| Simple | signatures[0].subjectDistinguishedName.givenName | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers given name from SubjectDistinguishedName field | +| Simple | signatures[0].subjectDistinguishedName.surname | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added signers surname from SubjectDistinguishedName field | +| Simple | signatures[0].signatureScopes[0].hashAlgo | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added datafile hash algo field for hashcode validation | +| Simple | signatures[0].signatureScopes[0].hash | added | [Link](../interfaces/#validation-response-parameters-simple-report-successful-scenario) | Added datafile hash field for hashcode validation | +| Diagnostic | whole response | added | [Link](../interfaces/#validation-response-parameters-for-diagnostic-data-report-successful-scenario) | New report type added | + diff --git a/docs/siva3/qa_strategy.md b/docs/siva3/qa_strategy.md index 5fe85c8b9..8ecb5b8cb 100644 --- a/docs/siva3/qa_strategy.md +++ b/docs/siva3/qa_strategy.md @@ -1,107 +1,107 @@ - -## Introduction -The goal of this document is to give general overview of the used infrastructure, processes, schedule and actions to ensure good quality delivery. The document describes activities in the whole software development process. Analysis, development and testing are separated for the sake of structure and transparency although they are integral parts of the development cycle. -This is living document and will be constantly updated as the project evolves. -## Environments and infrastructure - -There are different test environments for quality assurance, depending on the nature and aim. - -1. GitHub Actions environment for public CI - Platform: Linux -2. Test environment for local test and load test - Platform: Linux - -Instructions how to set up test environment and run tests together with more info can be found in [SiVa GitHub page](https://github.com/open-eid/SiVa). - -System requirements: - -* At least 4GB of RAM on machine where the build is executed -* Minimum required Java version is Java 11 -* SiVa project provided Maven Wrapper (./mvnw) - -Tools used: - -* GitHub Actions – is a continuous integration service used to build and test software projects hosted at GitHub -* IntelliJ IDEA – is a Java integrated development environment(IDE) for developing and executing automated tests locally -* Apache Tomcat - is an open source servlet container developed by the Apache Software Foundation. -* Rest-Assured - is a Java DSL(Domain-specific language) for simplifying testing of REST based Services built on top of HTTP Builder. -* Docker - is an open platform for developing, shipping, and running applications. - -## Analysis -Analysis will be tagged with identificators to enable cross-reference between requirements and corresponding tests. This includes both functional and non-functional requirements. - -## Development -### Development process -Customized process based on Kanban is used in the development. The process consists of following elements: - -* Product backlog is maintained in JIRA -* Tasks are maintained through JIRA Kanban board -* Daily team stand-ups are held -* Tasks marked done are developed, tested and ready to be shipped -* Weekly meetings are held to give status on progress and discuss open questions -![Development process](../img/siva/qa_strategy/siva3/developmentProcess.png) - -### Issue lifecycle -Each ticket in JIRA Kanban board goes through the following states that correspond the development procedure described in previous chapter. -![Issue lifecycle](../img/siva/qa_strategy/siva3/taskWorkFlow.png) - -Description of states: - -* Awaiting analysis - ticket to be dealt with, product backlog. -* Awaiting implementation - ticket analysed and ready to be implemented. -* In progress - ticket is being handled (feature coding, document writing, ...). -* In Review - ticket is ready for review -* Resolved - ticket is ready for test -* Closed - ticket has been tested and found ready for release - -### QA activities and quality criterias in the development -**Process improvement** - -The development process is constantly monitored and adjusted to the changing situations. Retrospective meetings for process feedback are held. - -**Unit tests** - -It is responsibility of developer to write, maintain and execute the unit tests on developed features. The code must compile and pass unit tests before it is allowed to be submitted to the code repository. The code of the unit tests is integral part of the source code and is maintained on the same principles. -Unit tests are also automatically executed on each build, if the unit tests do not pass further test execution is stopped. - -**Static testing/code reviews** - -All changes (including changes in unit test code) are reviewed by another development team member using GitHub. The code must pass review before it is submitted to testing. -SonarLint is used to validate code automatically. - -## Testing -### Approach -The goal is to automate as much of the testing process as possible, however some aspects of the testing will be carried out manually. -As the development is carried out by the backlog priority the testing follows the same principle. After each feature release test cases, test automation code and test results will be available through GitHub. -![Testing schedule](../img/siva/qa_strategy/siva3/testingFlow.png) - -### Testing process -Automatic system tests are run against deployed SiVa instance (deployed either locally or through CI). - -### Defect management -All found defects will be reported and handled in Jira. The defect report will follow similar lifecycle in JIRA Kanban board as tasks. -The report will have at least the following elements: - -* Title: Short, precise description of the problem -* Details: Type, Priority, Epic Link -* Description: - * **Steps to reproduce bug** - sequence for reproduction, link to test case if applicable. - * **Expected behavior** - expected outcome of the test sequence. - * **Actual behavior** - actual result of the test sequence. The description should be thorough enough to enable the debugging of the problem and to give objective base for severity assessment. - * **File attachments** - Test files, logs, images, ... - -### Test levels - -**System testing** - -The scope of the tests is illustrated on the image below. The goal of the test is to test the entire length of signature validation process and to test supportive functions. In addition SiVa Demo application is tested. More info about testing specifics can be found in Test Plan [System testing](../test_plan/#system-test-introduction) section. -![System testing](../img/siva/qa_strategy/siva3/systemTest.png) - -**Regression testing** - -Regression testing will consist of two parts: -Running all automated tests (unit and system tests) -Manual testing of the areas that are not covered by automatic tests based on the regression test checklist - -**Performance testing** - -The scope of the load testing is to determine the throughput capabilities of a single SiVa node and how it handles requests under increasing load. -Gatling is used for load testing and the tests can be found in [SiVa-perftests GitHub page](https://github.com/open-eid/SiVa-perftests/tree/master). + +## Introduction +The goal of this document is to give general overview of the used infrastructure, processes, schedule and actions to ensure good quality delivery. The document describes activities in the whole software development process. Analysis, development and testing are separated for the sake of structure and transparency although they are integral parts of the development cycle. +This is living document and will be constantly updated as the project evolves. +## Environments and infrastructure + +There are different test environments for quality assurance, depending on the nature and aim. + +1. GitHub Actions environment for public CI - Platform: Linux +2. Test environment for local test and load test - Platform: Linux + +Instructions how to set up test environment and run tests together with more info can be found in [SiVa GitHub page](https://github.com/open-eid/SiVa). + +System requirements: + +* At least 4GB of RAM on machine where the build is executed +* Minimum required Java version is Java 11 +* SiVa project provided Maven Wrapper (./mvnw) + +Tools used: + +* GitHub Actions – is a continuous integration service used to build and test software projects hosted at GitHub +* IntelliJ IDEA – is a Java integrated development environment(IDE) for developing and executing automated tests locally +* Apache Tomcat - is an open source servlet container developed by the Apache Software Foundation. +* Rest-Assured - is a Java DSL(Domain-specific language) for simplifying testing of REST based Services built on top of HTTP Builder. +* Docker - is an open platform for developing, shipping, and running applications. + +## Analysis +Analysis will be tagged with identificators to enable cross-reference between requirements and corresponding tests. This includes both functional and non-functional requirements. + +## Development +### Development process +Customized process based on Kanban is used in the development. The process consists of following elements: + +* Product backlog is maintained in JIRA +* Tasks are maintained through JIRA Kanban board +* Daily team stand-ups are held +* Tasks marked done are developed, tested and ready to be shipped +* Weekly meetings are held to give status on progress and discuss open questions +![Development process](../img/siva/qa_strategy/siva3/developmentProcess.png) + +### Issue lifecycle +Each ticket in JIRA Kanban board goes through the following states that correspond the development procedure described in previous chapter. +![Issue lifecycle](../img/siva/qa_strategy/siva3/taskWorkFlow.png) + +Description of states: + +* Awaiting analysis - ticket to be dealt with, product backlog. +* Awaiting implementation - ticket analysed and ready to be implemented. +* In progress - ticket is being handled (feature coding, document writing, ...). +* In Review - ticket is ready for review +* Resolved - ticket is ready for test +* Closed - ticket has been tested and found ready for release + +### QA activities and quality criterias in the development +**Process improvement** + +The development process is constantly monitored and adjusted to the changing situations. Retrospective meetings for process feedback are held. + +**Unit tests** + +It is responsibility of developer to write, maintain and execute the unit tests on developed features. The code must compile and pass unit tests before it is allowed to be submitted to the code repository. The code of the unit tests is integral part of the source code and is maintained on the same principles. +Unit tests are also automatically executed on each build, if the unit tests do not pass further test execution is stopped. + +**Static testing/code reviews** + +All changes (including changes in unit test code) are reviewed by another development team member using GitHub. The code must pass review before it is submitted to testing. +SonarLint is used to validate code automatically. + +## Testing +### Approach +The goal is to automate as much of the testing process as possible, however some aspects of the testing will be carried out manually. +As the development is carried out by the backlog priority the testing follows the same principle. After each feature release test cases, test automation code and test results will be available through GitHub. +![Testing schedule](../img/siva/qa_strategy/siva3/testingFlow.png) + +### Testing process +Automatic system tests are run against deployed SiVa instance (deployed either locally or through CI). + +### Defect management +All found defects will be reported and handled in Jira. The defect report will follow similar lifecycle in JIRA Kanban board as tasks. +The report will have at least the following elements: + +* Title: Short, precise description of the problem +* Details: Type, Priority, Epic Link +* Description: + * **Steps to reproduce bug** - sequence for reproduction, link to test case if applicable. + * **Expected behavior** - expected outcome of the test sequence. + * **Actual behavior** - actual result of the test sequence. The description should be thorough enough to enable the debugging of the problem and to give objective base for severity assessment. + * **File attachments** - Test files, logs, images, ... + +### Test levels + +**System testing** + +The scope of the tests is illustrated on the image below. The goal of the test is to test the entire length of signature validation process and to test supportive functions. In addition SiVa Demo application is tested. More info about testing specifics can be found in Test Plan [System testing](../test_plan/#system-test-introduction) section. +![System testing](../img/siva/qa_strategy/siva3/systemTest.png) + +**Regression testing** + +Regression testing will consist of two parts: +Running all automated tests (unit and system tests) +Manual testing of the areas that are not covered by automatic tests based on the regression test checklist + +**Performance testing** + +The scope of the load testing is to determine the throughput capabilities of a single SiVa node and how it handles requests under increasing load. +Gatling is used for load testing and the tests can be found in [SiVa-perftests GitHub page](https://github.com/open-eid/SiVa-perftests/tree/master). diff --git a/mkdocs.yml b/mkdocs.yml index 440730dc9..6be6c4198 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,78 +1,78 @@ -site_name: SiVa 3.9 - Signature Validation Service Documentation -theme: - name: material - include_sidebar: false -repo_url: https://github.com/open-eid/SiVa -extra: - font: - code: 'Roboto Mono' - palette: - primary: 'Cyan' - accent: 'Light Blue' -extra_css: - - override.css - -markdown_extensions: - - codehilite - - admonition - - def_list -nav: -- VERSION HISTORY: version_info.md -- INTRODUCTION: index.md -- 1. DEFINITIONS: siva3/definitions.md -- 2. BACKGROUND: siva3/background.md -- 3. STRUCTURE & ACTIVITIES: - - 3.1 Component model: siva3/structure_and_activities.md - - 3.2 Use cases: siva3/use_cases.md -- 4. INTERFACES: siva3/interfaces.md -- 5. DEPLOYMENT: - - 5.1 Deployment model: siva3/deployment.md - - 5.2 Deployment guide: siva3/deployment_guide.md -- 6. QUALITY ASSURANCE: - - 6.1 QA Strategy: siva3/qa_strategy.md - - 6.2 Test Plan: siva3/test_plan.md -- 7. ROADMAP: siva3/roadmap.md -- 8. APPENDICES: - - Appendix 1 - Validation Policy: siva3/appendix/validation_policy.md - - Appendix 2 - Test Case Descriptions: siva3/appendix/test_cases.md - - Appendix 3 - Known Issues : siva3/appendix/known_issues.md -- 9. SIVA 2.0 (Deprecated): - - 9.1. DEFINITIONS: siva2/definitions.md - - 9.2. BACKGROUND: siva2/background.md - - 9.3. STRUCTURE & ACTIVITIES: - - 9.3.1 Component model: siva2/structure_and_activities.md - - 9.3.2 Use cases: siva2/use_cases.md - - 9.4. INTERFACES: siva2/interfaces.md - - 9.5. DEPLOYMENT: - - 9.5.1 Deployment model: siva2/deployment.md - - 9.5.2 System integrator's guide: siva2/systemintegrators_guide.md - - 9.6. QUALITY ASSURANCE: - - 9.6.1 QA Strategy: siva2/qa_strategy.md - - 9.6.2 Test Plan: siva2/test_plan.md - - 9.7. REFERENCES: siva2/references.md - - 9.8. APPENDICES: - - Appendix 1 - Validation Policy: siva2/appendix/validation_policy.md - - Appendix 2 - Test Case Descriptions: siva2/appendix/test_cases.md - - Appendix 3 - WSDL/XSD of SOAP Interface : siva2/appendix/wsdl.md - - Appendix 4 - Known Issues : siva2/appendix/known_issues.md -- 10. SIVA 1.1 (Deprecated): - - 10.1. DEFINITIONS: siva/definitions.md - - 10.2. BACKGROUND: siva/background.md - - 10.3. STRUCTURE & ACTIVITIES: - - 10.3.1 Component model: siva/v2/structure_and_activities.md - - 10.3.2 Use cases: siva/v2/use_cases.md - - 10.4. INTERFACES: siva/v2/interfaces.md - - 10.5. DEPLOYMENT: - - 10.5.1 Deployment model: siva/v2/deployment.md - - 10.5.2 System integrator's guide: siva/v2/systemintegrators_guide.md - - 10.6. QUALITY ASSURANCE: - - 10.6.1 QA Strategy: siva/qa_strategy.md - - 10.6.2 Test Plan: siva/test_plan.md - - 10.7. REFERENCES: siva/references.md - - 10.8. APPENDICES: - - Appendix 1 - Validation Policy: siva/appendix/validation_policy.md - - Appendix 2 - Test Case Descriptions: siva/appendix/test_cases.md - - Appendix 3 - WSDL of SOAP Interface : siva/appendix/wsdl.md - - Appendix 4 - Known Issues : siva/appendix/known_issues.md - - +site_name: SiVa 3.9 - Signature Validation Service Documentation +theme: + name: material + include_sidebar: false +repo_url: https://github.com/open-eid/SiVa +extra: + font: + code: 'Roboto Mono' + palette: + primary: 'Cyan' + accent: 'Light Blue' +extra_css: + - override.css + +markdown_extensions: + - codehilite + - admonition + - def_list +nav: +- VERSION HISTORY: version_info.md +- INTRODUCTION: index.md +- 1. DEFINITIONS: siva3/definitions.md +- 2. BACKGROUND: siva3/background.md +- 3. STRUCTURE & ACTIVITIES: + - 3.1 Component model: siva3/structure_and_activities.md + - 3.2 Use cases: siva3/use_cases.md +- 4. INTERFACES: siva3/interfaces.md +- 5. DEPLOYMENT: + - 5.1 Deployment model: siva3/deployment.md + - 5.2 Deployment guide: siva3/deployment_guide.md +- 6. QUALITY ASSURANCE: + - 6.1 QA Strategy: siva3/qa_strategy.md + - 6.2 Test Plan: siva3/test_plan.md +- 7. ROADMAP: siva3/roadmap.md +- 8. APPENDICES: + - Appendix 1 - Validation Policy: siva3/appendix/validation_policy.md + - Appendix 2 - Test Case Descriptions: siva3/appendix/test_cases.md + - Appendix 3 - Known Issues : siva3/appendix/known_issues.md +- 9. SIVA 2.0 (Deprecated): + - 9.1. DEFINITIONS: siva2/definitions.md + - 9.2. BACKGROUND: siva2/background.md + - 9.3. STRUCTURE & ACTIVITIES: + - 9.3.1 Component model: siva2/structure_and_activities.md + - 9.3.2 Use cases: siva2/use_cases.md + - 9.4. INTERFACES: siva2/interfaces.md + - 9.5. DEPLOYMENT: + - 9.5.1 Deployment model: siva2/deployment.md + - 9.5.2 System integrator's guide: siva2/systemintegrators_guide.md + - 9.6. QUALITY ASSURANCE: + - 9.6.1 QA Strategy: siva2/qa_strategy.md + - 9.6.2 Test Plan: siva2/test_plan.md + - 9.7. REFERENCES: siva2/references.md + - 9.8. APPENDICES: + - Appendix 1 - Validation Policy: siva2/appendix/validation_policy.md + - Appendix 2 - Test Case Descriptions: siva2/appendix/test_cases.md + - Appendix 3 - WSDL/XSD of SOAP Interface : siva2/appendix/wsdl.md + - Appendix 4 - Known Issues : siva2/appendix/known_issues.md +- 10. SIVA 1.1 (Deprecated): + - 10.1. DEFINITIONS: siva/definitions.md + - 10.2. BACKGROUND: siva/background.md + - 10.3. STRUCTURE & ACTIVITIES: + - 10.3.1 Component model: siva/v2/structure_and_activities.md + - 10.3.2 Use cases: siva/v2/use_cases.md + - 10.4. INTERFACES: siva/v2/interfaces.md + - 10.5. DEPLOYMENT: + - 10.5.1 Deployment model: siva/v2/deployment.md + - 10.5.2 System integrator's guide: siva/v2/systemintegrators_guide.md + - 10.6. QUALITY ASSURANCE: + - 10.6.1 QA Strategy: siva/qa_strategy.md + - 10.6.2 Test Plan: siva/test_plan.md + - 10.7. REFERENCES: siva/references.md + - 10.8. APPENDICES: + - Appendix 1 - Validation Policy: siva/appendix/validation_policy.md + - Appendix 2 - Test Case Descriptions: siva/appendix/test_cases.md + - Appendix 3 - WSDL of SOAP Interface : siva/appendix/wsdl.md + - Appendix 4 - Known Issues : siva/appendix/known_issues.md + + diff --git a/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/configuration/MonitoringConfiguration.java b/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/configuration/MonitoringConfiguration.java index 8fe6b5b92..b40a41e3c 100644 --- a/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/configuration/MonitoringConfiguration.java +++ b/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/configuration/MonitoringConfiguration.java @@ -1,56 +1,56 @@ -/* - * Copyright 2016 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.siva.monitoring.configuration; - -import ee.openeid.siva.monitoring.enpoint.HeartbeatEndpoint; -import ee.openeid.siva.monitoring.enpoint.VersionEndpoint; -import ee.openeid.siva.monitoring.indicator.ApplicationHealthIndicator; -import ee.openeid.siva.monitoring.util.ManifestReader; -import org.springframework.boot.actuate.autoconfigure.endpoint.condition.ConditionalOnAvailableEndpoint; -import org.springframework.boot.actuate.health.HealthEndpoint; -import org.springframework.context.annotation.Bean; - -import jakarta.servlet.ServletContext; - -public abstract class MonitoringConfiguration { - - public static final String DEFAULT_MONITORING_ENDPOINT = "/monitoring/health"; - public static final int DEFAULT_TIMEOUT = 10000; - - @Bean - public ManifestReader manifestReader() { - return new ManifestReader(); - } - - @Bean - public ApplicationHealthIndicator health(ManifestReader manifestReader) { - return new ApplicationHealthIndicator(manifestReader); - } - - @Bean - @ConditionalOnAvailableEndpoint(endpoint = HeartbeatEndpoint.class) - public HeartbeatEndpoint heartbeatEndpoint(HealthEndpoint healthEndpoint) { - return new HeartbeatEndpoint(healthEndpoint); - } - - @Bean - @ConditionalOnAvailableEndpoint(endpoint = VersionEndpoint.class) - public VersionEndpoint versionEndpoint(ManifestReader manifestReader) { - return new VersionEndpoint(manifestReader); - } - -} +/* + * Copyright 2016 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.siva.monitoring.configuration; + +import ee.openeid.siva.monitoring.enpoint.HeartbeatEndpoint; +import ee.openeid.siva.monitoring.enpoint.VersionEndpoint; +import ee.openeid.siva.monitoring.indicator.ApplicationHealthIndicator; +import ee.openeid.siva.monitoring.util.ManifestReader; +import org.springframework.boot.actuate.autoconfigure.endpoint.condition.ConditionalOnAvailableEndpoint; +import org.springframework.boot.actuate.health.HealthEndpoint; +import org.springframework.context.annotation.Bean; + +import jakarta.servlet.ServletContext; + +public abstract class MonitoringConfiguration { + + public static final String DEFAULT_MONITORING_ENDPOINT = "/monitoring/health"; + public static final int DEFAULT_TIMEOUT = 10000; + + @Bean + public ManifestReader manifestReader() { + return new ManifestReader(); + } + + @Bean + public ApplicationHealthIndicator health(ManifestReader manifestReader) { + return new ApplicationHealthIndicator(manifestReader); + } + + @Bean + @ConditionalOnAvailableEndpoint(endpoint = HeartbeatEndpoint.class) + public HeartbeatEndpoint heartbeatEndpoint(HealthEndpoint healthEndpoint) { + return new HeartbeatEndpoint(healthEndpoint); + } + + @Bean + @ConditionalOnAvailableEndpoint(endpoint = VersionEndpoint.class) + public VersionEndpoint versionEndpoint(ManifestReader manifestReader) { + return new VersionEndpoint(manifestReader); + } + +} diff --git a/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicator.java b/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicator.java index 66c03a0ea..7e9628981 100644 --- a/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicator.java +++ b/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicator.java @@ -1,96 +1,96 @@ -/* - * Copyright 2016 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.siva.monitoring.indicator; - -import ee.openeid.siva.monitoring.util.ManifestReader; -import lombok.extern.slf4j.Slf4j; -import org.springframework.boot.actuate.health.Health; -import org.springframework.boot.actuate.health.HealthIndicator; - -import java.time.Instant; -import java.time.LocalDateTime; -import java.time.ZoneOffset; -import java.time.ZonedDateTime; -import java.time.format.DateTimeFormatter; -import java.time.format.DateTimeParseException; - -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_BUILD_TIME; -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_NAME; -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_VERSION; -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.NOT_AVAILABLE; - -@Slf4j -public class ApplicationHealthIndicator implements HealthIndicator { - - public static final String DEFAULT_DATE_TIME_FORMAT = "yyyy-MM-dd'T'HH:mm:ss'Z'"; - public static final DateTimeFormatter DEFAULT_DATE_TIME_FORMATTER = DateTimeFormatter.ofPattern(DEFAULT_DATE_TIME_FORMAT); - - public static final String RESPONSE_PARAM_WEBAPP_NAME = "webappName"; - public static final String RESPONSE_PARAM_VERSION = "version"; - public static final String RESPONSE_PARAM_BUILD_TIME = "buildTime"; - public static final String RESPONSE_PARAM_START_TIME = "startTime"; - public static final String RESPONSE_PARAM_CURRENT_TIME = "currentTime"; - - private final ZonedDateTime instanceStarted; - private final ZonedDateTime built; - private final String name; - private final String version; - - public ApplicationHealthIndicator(ManifestReader manifestReader) { - instanceStarted = Instant.now().atZone(ZoneOffset.UTC); - built = getInstanceBuilt(manifestReader); - name = manifestReader.readFromManifest(MANIFEST_PARAM_APP_NAME); - version = manifestReader.readFromManifest(MANIFEST_PARAM_APP_VERSION); - } - - @Override - public Health health() { - return Health.up() - .withDetail(RESPONSE_PARAM_WEBAPP_NAME, formatValue(name)) - .withDetail(RESPONSE_PARAM_VERSION, formatValue(version)) - .withDetail(RESPONSE_PARAM_BUILD_TIME, formatValue(getFormattedTime(built))) - .withDetail(RESPONSE_PARAM_START_TIME, formatValue(getFormattedTime(instanceStarted))) - .withDetail(RESPONSE_PARAM_CURRENT_TIME, formatValue(getFormattedTime(Instant.now().atZone(ZoneOffset.UTC)))) - .build(); - } - - private static ZonedDateTime getInstanceBuilt(ManifestReader manifestReader) { - String buildTime = manifestReader.readFromManifest(MANIFEST_PARAM_APP_BUILD_TIME); - - if (buildTime == null) { - return null; - } - - try { - return LocalDateTime.parse(buildTime, DEFAULT_DATE_TIME_FORMATTER).atZone(ZoneOffset.UTC); - } catch (DateTimeParseException e) { - log.error("Could not parse the build time! ", e); - return null; - } - } - - private static String getFormattedTime(ZonedDateTime zonedDateTime) { - return (zonedDateTime != null) - ? zonedDateTime.format(DEFAULT_DATE_TIME_FORMATTER) - : null; - } - - private static Object formatValue(String value) { - return value == null ? NOT_AVAILABLE : value; - } - -} +/* + * Copyright 2016 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.siva.monitoring.indicator; + +import ee.openeid.siva.monitoring.util.ManifestReader; +import lombok.extern.slf4j.Slf4j; +import org.springframework.boot.actuate.health.Health; +import org.springframework.boot.actuate.health.HealthIndicator; + +import java.time.Instant; +import java.time.LocalDateTime; +import java.time.ZoneOffset; +import java.time.ZonedDateTime; +import java.time.format.DateTimeFormatter; +import java.time.format.DateTimeParseException; + +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_BUILD_TIME; +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_NAME; +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_VERSION; +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.NOT_AVAILABLE; + +@Slf4j +public class ApplicationHealthIndicator implements HealthIndicator { + + public static final String DEFAULT_DATE_TIME_FORMAT = "yyyy-MM-dd'T'HH:mm:ss'Z'"; + public static final DateTimeFormatter DEFAULT_DATE_TIME_FORMATTER = DateTimeFormatter.ofPattern(DEFAULT_DATE_TIME_FORMAT); + + public static final String RESPONSE_PARAM_WEBAPP_NAME = "webappName"; + public static final String RESPONSE_PARAM_VERSION = "version"; + public static final String RESPONSE_PARAM_BUILD_TIME = "buildTime"; + public static final String RESPONSE_PARAM_START_TIME = "startTime"; + public static final String RESPONSE_PARAM_CURRENT_TIME = "currentTime"; + + private final ZonedDateTime instanceStarted; + private final ZonedDateTime built; + private final String name; + private final String version; + + public ApplicationHealthIndicator(ManifestReader manifestReader) { + instanceStarted = Instant.now().atZone(ZoneOffset.UTC); + built = getInstanceBuilt(manifestReader); + name = manifestReader.readFromManifest(MANIFEST_PARAM_APP_NAME); + version = manifestReader.readFromManifest(MANIFEST_PARAM_APP_VERSION); + } + + @Override + public Health health() { + return Health.up() + .withDetail(RESPONSE_PARAM_WEBAPP_NAME, formatValue(name)) + .withDetail(RESPONSE_PARAM_VERSION, formatValue(version)) + .withDetail(RESPONSE_PARAM_BUILD_TIME, formatValue(getFormattedTime(built))) + .withDetail(RESPONSE_PARAM_START_TIME, formatValue(getFormattedTime(instanceStarted))) + .withDetail(RESPONSE_PARAM_CURRENT_TIME, formatValue(getFormattedTime(Instant.now().atZone(ZoneOffset.UTC)))) + .build(); + } + + private static ZonedDateTime getInstanceBuilt(ManifestReader manifestReader) { + String buildTime = manifestReader.readFromManifest(MANIFEST_PARAM_APP_BUILD_TIME); + + if (buildTime == null) { + return null; + } + + try { + return LocalDateTime.parse(buildTime, DEFAULT_DATE_TIME_FORMATTER).atZone(ZoneOffset.UTC); + } catch (DateTimeParseException e) { + log.error("Could not parse the build time! ", e); + return null; + } + } + + private static String getFormattedTime(ZonedDateTime zonedDateTime) { + return (zonedDateTime != null) + ? zonedDateTime.format(DEFAULT_DATE_TIME_FORMATTER) + : null; + } + + private static Object formatValue(String value) { + return value == null ? NOT_AVAILABLE : value; + } + +} diff --git a/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/UrlHealthIndicator.java b/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/UrlHealthIndicator.java index 10e7c2d5e..58ccff9f5 100644 --- a/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/UrlHealthIndicator.java +++ b/siva-parent/siva-monitoring/src/main/java/ee/openeid/siva/monitoring/indicator/UrlHealthIndicator.java @@ -1,140 +1,140 @@ -/* - * Copyright 2017 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ -package ee.openeid.siva.monitoring.indicator; - -import com.fasterxml.jackson.annotation.JsonIgnoreProperties; -import io.micrometer.core.lang.Nullable; -import org.slf4j.Logger; -import org.slf4j.LoggerFactory; -import org.springframework.boot.actuate.health.AbstractHealthIndicator; -import org.springframework.boot.actuate.health.Health; -import org.springframework.boot.actuate.health.Status; -import org.springframework.web.client.RestTemplate; - -import java.util.Optional; - -public class UrlHealthIndicator extends AbstractHealthIndicator { - - private static final Logger LOGGER = LoggerFactory.getLogger(UrlHealthIndicator.class); - public static final String RESPONSE_PARAM_NAME = "name"; - - private ExternalLink externalLink; - - private RestTemplate restTemplate; - - @Override - protected void doHealthCheck(Health.Builder builder) throws Exception { - try { - builder.withDetail(RESPONSE_PARAM_NAME, externalLink.getName()); - HealthStatus response = restTemplate.getForObject(externalLink.getUrl(), UrlHealthIndicator.HealthStatus.class); - LOGGER.debug("{}", response); - setHealtStatus(builder, response); - } catch (Exception e) { - LOGGER.error("Failed to establish connection to '{}' > {}", externalLink.getUrl(), e.getMessage()); - builder.down(); - } - } - - private void setHealtStatus(Health.Builder builder,@Nullable HealthStatus health) { - Optional - .ofNullable(health) - .map(HealthStatus::getStatus) - .filter(Status.UP.toString()::equals) - .ifPresentOrElse( - up -> builder.up(), - builder::down - ); - } - - public void setExternalLink(ExternalLink externalLink) { - this.externalLink = externalLink; - } - - public void setRestTemplate(RestTemplate restTemplate) { - this.restTemplate = restTemplate; - } - - public RestTemplate getRestTemplate() { - return restTemplate; - } - - public ExternalLink getExternalLink() { - return externalLink; - } - - @JsonIgnoreProperties(ignoreUnknown = true) - public static class HealthStatus { - private String status; - - public HealthStatus() { } - - public HealthStatus(String status) { - this.status = status; - } - - public String getStatus() { - return status; - } - - public void setStatus(String status) { - this.status = status; - } - } - - public static class ExternalLink { - - private String name; - - private String url; - - private int timeout; - - public ExternalLink() { - } - - public ExternalLink(String name, String url, int timeout) { - this.name = name; - this.url = url; - this.timeout = timeout; - } - - public int getTimeout() { - return timeout; - } - - public void setTimeout(int timeout) { - this.timeout = timeout; - } - - public String getUrl() { - return url; - } - - public void setUrl(String url) { - this.url = url; - } - - public String getName() { - return name; - } - - public void setName(String name) { - this.name = name; - } - } -} - - +/* + * Copyright 2017 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ +package ee.openeid.siva.monitoring.indicator; + +import com.fasterxml.jackson.annotation.JsonIgnoreProperties; +import io.micrometer.core.lang.Nullable; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; +import org.springframework.boot.actuate.health.AbstractHealthIndicator; +import org.springframework.boot.actuate.health.Health; +import org.springframework.boot.actuate.health.Status; +import org.springframework.web.client.RestTemplate; + +import java.util.Optional; + +public class UrlHealthIndicator extends AbstractHealthIndicator { + + private static final Logger LOGGER = LoggerFactory.getLogger(UrlHealthIndicator.class); + public static final String RESPONSE_PARAM_NAME = "name"; + + private ExternalLink externalLink; + + private RestTemplate restTemplate; + + @Override + protected void doHealthCheck(Health.Builder builder) throws Exception { + try { + builder.withDetail(RESPONSE_PARAM_NAME, externalLink.getName()); + HealthStatus response = restTemplate.getForObject(externalLink.getUrl(), UrlHealthIndicator.HealthStatus.class); + LOGGER.debug("{}", response); + setHealtStatus(builder, response); + } catch (Exception e) { + LOGGER.error("Failed to establish connection to '{}' > {}", externalLink.getUrl(), e.getMessage()); + builder.down(); + } + } + + private void setHealtStatus(Health.Builder builder,@Nullable HealthStatus health) { + Optional + .ofNullable(health) + .map(HealthStatus::getStatus) + .filter(Status.UP.toString()::equals) + .ifPresentOrElse( + up -> builder.up(), + builder::down + ); + } + + public void setExternalLink(ExternalLink externalLink) { + this.externalLink = externalLink; + } + + public void setRestTemplate(RestTemplate restTemplate) { + this.restTemplate = restTemplate; + } + + public RestTemplate getRestTemplate() { + return restTemplate; + } + + public ExternalLink getExternalLink() { + return externalLink; + } + + @JsonIgnoreProperties(ignoreUnknown = true) + public static class HealthStatus { + private String status; + + public HealthStatus() { } + + public HealthStatus(String status) { + this.status = status; + } + + public String getStatus() { + return status; + } + + public void setStatus(String status) { + this.status = status; + } + } + + public static class ExternalLink { + + private String name; + + private String url; + + private int timeout; + + public ExternalLink() { + } + + public ExternalLink(String name, String url, int timeout) { + this.name = name; + this.url = url; + this.timeout = timeout; + } + + public int getTimeout() { + return timeout; + } + + public void setTimeout(int timeout) { + this.timeout = timeout; + } + + public String getUrl() { + return url; + } + + public void setUrl(String url) { + this.url = url; + } + + public String getName() { + return name; + } + + public void setName(String name) { + this.name = name; + } + } +} + + diff --git a/siva-parent/siva-monitoring/src/test/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicatorTest.java b/siva-parent/siva-monitoring/src/test/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicatorTest.java index d49bd717a..6ec63e354 100644 --- a/siva-parent/siva-monitoring/src/test/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicatorTest.java +++ b/siva-parent/siva-monitoring/src/test/java/ee/openeid/siva/monitoring/indicator/ApplicationHealthIndicatorTest.java @@ -1,134 +1,134 @@ -/* - * Copyright 2016 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.siva.monitoring.indicator; - -import ee.openeid.siva.monitoring.util.ManifestReader; -import org.junit.jupiter.api.Test; -import org.junit.jupiter.api.extension.ExtendWith; -import org.mockito.Mock; -import org.mockito.Mockito; -import org.mockito.junit.jupiter.MockitoExtension; -import org.springframework.boot.actuate.health.Health; -import org.springframework.boot.actuate.health.Status; - -import java.time.Instant; -import java.time.format.DateTimeParseException; -import java.time.temporal.ChronoUnit; -import java.util.LinkedHashSet; -import java.util.stream.Collectors; -import java.util.stream.Stream; - -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_BUILD_TIME; -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_NAME; -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_VERSION; -import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.NOT_AVAILABLE; -import static org.junit.jupiter.api.Assertions.assertEquals; -import static org.junit.jupiter.api.Assertions.assertFalse; -import static org.junit.jupiter.api.Assertions.assertNotNull; -import static org.junit.jupiter.api.Assertions.fail; - -@ExtendWith(MockitoExtension.class) -class ApplicationHealthIndicatorTest { - - public static final String TEST_WEBAPP = "TEST_WEBAPP"; - public static final String TEST_BUILD_TIME_IN_UTC = "2016-10-21T11:35:23Z"; - public static final String TEST_VERSION = "TEST_VERSION"; - - @Mock - private ManifestReader manifestReader; - - @Test - void whenParametersMissingInManifestFile() { - Instant earliestStartTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); - ApplicationHealthIndicator applicationHealthIndicator = new ApplicationHealthIndicator(manifestReader); - Instant latestStartTime = Instant.now(); - - Instant earliestCurrentTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); - Health health = applicationHealthIndicator.health(); - Instant latestCurrentTime = Instant.now(); - - assertEquals(Status.UP, health.getStatus()); - assertEquals( - Stream.of( - ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME, - ApplicationHealthIndicator.RESPONSE_PARAM_VERSION, - ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME, - ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME, - ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME - ).collect(Collectors.toCollection(LinkedHashSet::new)), health.getDetails().keySet()); - assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME)); - assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_VERSION)); - assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME)); - verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME), earliestStartTime, latestStartTime); - verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME), earliestCurrentTime, latestCurrentTime); - } - - @Test - void whenParametersFoundInManifestFile() { - Mockito.doReturn(TEST_WEBAPP).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_NAME); - Mockito.doReturn(TEST_BUILD_TIME_IN_UTC).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_BUILD_TIME); - Mockito.doReturn(TEST_VERSION).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_VERSION); - Instant earliestStartTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); - ApplicationHealthIndicator applicationHealthIndicator = new ApplicationHealthIndicator(manifestReader); - Instant latestStartTime = Instant.now(); - - Instant earliestCurrentTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); - Health health = applicationHealthIndicator.health(); - Instant latestCurrentTime = Instant.now(); - - assertEquals(Status.UP, health.getStatus()); - assertEquals(TEST_WEBAPP, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME)); - assertEquals(TEST_VERSION, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_VERSION)); - assertEquals(TEST_BUILD_TIME_IN_UTC, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME)); - verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME), earliestStartTime, latestStartTime); - verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME), earliestCurrentTime, latestCurrentTime); - } - - @Test - void whenBuildTimeHasInvalidFormatInManifestFile() { - Mockito.doReturn(TEST_WEBAPP).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_NAME); - Mockito.doReturn("ABCDEFG1234").when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_BUILD_TIME); - Mockito.doReturn(TEST_VERSION).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_VERSION); - Instant earliestStartTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); - ApplicationHealthIndicator applicationHealthIndicator = new ApplicationHealthIndicator(manifestReader); - Instant latestStartTime = Instant.now(); - - Instant earliestCurrentTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); - Health health = applicationHealthIndicator.health(); - Instant latestCurrentTime = Instant.now(); - - assertEquals(Status.UP, health.getStatus()); - assertEquals(TEST_WEBAPP, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME)); - assertEquals(TEST_VERSION, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_VERSION)); - assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME)); - verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME), earliestStartTime, latestStartTime); - verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME), earliestCurrentTime, latestCurrentTime); - } - - private static void verifyTime(Object time, Instant earliest, Instant latest) { - assertNotNull(time); - Instant parsedTime = null; - try { - parsedTime = Instant.parse(time.toString()); - } catch (DateTimeParseException e) { - fail("Failed to parse time", e); - } - assertFalse(parsedTime.isBefore(earliest), String.format("Time (%s) must not be before %s", parsedTime, earliest)); - assertFalse(parsedTime.isAfter(latest), String.format("Time (%s) must not be after %s", parsedTime, latest)); - } - -} +/* + * Copyright 2016 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.siva.monitoring.indicator; + +import ee.openeid.siva.monitoring.util.ManifestReader; +import org.junit.jupiter.api.Test; +import org.junit.jupiter.api.extension.ExtendWith; +import org.mockito.Mock; +import org.mockito.Mockito; +import org.mockito.junit.jupiter.MockitoExtension; +import org.springframework.boot.actuate.health.Health; +import org.springframework.boot.actuate.health.Status; + +import java.time.Instant; +import java.time.format.DateTimeParseException; +import java.time.temporal.ChronoUnit; +import java.util.LinkedHashSet; +import java.util.stream.Collectors; +import java.util.stream.Stream; + +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_BUILD_TIME; +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_NAME; +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.MANIFEST_PARAM_APP_VERSION; +import static ee.openeid.siva.monitoring.util.ApplicationInfoConstants.NOT_AVAILABLE; +import static org.junit.jupiter.api.Assertions.assertEquals; +import static org.junit.jupiter.api.Assertions.assertFalse; +import static org.junit.jupiter.api.Assertions.assertNotNull; +import static org.junit.jupiter.api.Assertions.fail; + +@ExtendWith(MockitoExtension.class) +class ApplicationHealthIndicatorTest { + + public static final String TEST_WEBAPP = "TEST_WEBAPP"; + public static final String TEST_BUILD_TIME_IN_UTC = "2016-10-21T11:35:23Z"; + public static final String TEST_VERSION = "TEST_VERSION"; + + @Mock + private ManifestReader manifestReader; + + @Test + void whenParametersMissingInManifestFile() { + Instant earliestStartTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); + ApplicationHealthIndicator applicationHealthIndicator = new ApplicationHealthIndicator(manifestReader); + Instant latestStartTime = Instant.now(); + + Instant earliestCurrentTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); + Health health = applicationHealthIndicator.health(); + Instant latestCurrentTime = Instant.now(); + + assertEquals(Status.UP, health.getStatus()); + assertEquals( + Stream.of( + ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME, + ApplicationHealthIndicator.RESPONSE_PARAM_VERSION, + ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME, + ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME, + ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME + ).collect(Collectors.toCollection(LinkedHashSet::new)), health.getDetails().keySet()); + assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME)); + assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_VERSION)); + assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME)); + verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME), earliestStartTime, latestStartTime); + verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME), earliestCurrentTime, latestCurrentTime); + } + + @Test + void whenParametersFoundInManifestFile() { + Mockito.doReturn(TEST_WEBAPP).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_NAME); + Mockito.doReturn(TEST_BUILD_TIME_IN_UTC).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_BUILD_TIME); + Mockito.doReturn(TEST_VERSION).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_VERSION); + Instant earliestStartTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); + ApplicationHealthIndicator applicationHealthIndicator = new ApplicationHealthIndicator(manifestReader); + Instant latestStartTime = Instant.now(); + + Instant earliestCurrentTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); + Health health = applicationHealthIndicator.health(); + Instant latestCurrentTime = Instant.now(); + + assertEquals(Status.UP, health.getStatus()); + assertEquals(TEST_WEBAPP, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME)); + assertEquals(TEST_VERSION, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_VERSION)); + assertEquals(TEST_BUILD_TIME_IN_UTC, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME)); + verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME), earliestStartTime, latestStartTime); + verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME), earliestCurrentTime, latestCurrentTime); + } + + @Test + void whenBuildTimeHasInvalidFormatInManifestFile() { + Mockito.doReturn(TEST_WEBAPP).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_NAME); + Mockito.doReturn("ABCDEFG1234").when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_BUILD_TIME); + Mockito.doReturn(TEST_VERSION).when(manifestReader).readFromManifest(MANIFEST_PARAM_APP_VERSION); + Instant earliestStartTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); + ApplicationHealthIndicator applicationHealthIndicator = new ApplicationHealthIndicator(manifestReader); + Instant latestStartTime = Instant.now(); + + Instant earliestCurrentTime = Instant.now().truncatedTo(ChronoUnit.SECONDS); + Health health = applicationHealthIndicator.health(); + Instant latestCurrentTime = Instant.now(); + + assertEquals(Status.UP, health.getStatus()); + assertEquals(TEST_WEBAPP, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_WEBAPP_NAME)); + assertEquals(TEST_VERSION, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_VERSION)); + assertEquals(NOT_AVAILABLE, health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_BUILD_TIME)); + verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_START_TIME), earliestStartTime, latestStartTime); + verifyTime(health.getDetails().get(ApplicationHealthIndicator.RESPONSE_PARAM_CURRENT_TIME), earliestCurrentTime, latestCurrentTime); + } + + private static void verifyTime(Object time, Instant earliest, Instant latest) { + assertNotNull(time); + Instant parsedTime = null; + try { + parsedTime = Instant.parse(time.toString()); + } catch (DateTimeParseException e) { + fail("Failed to parse time", e); + } + assertFalse(parsedTime.isBefore(earliest), String.format("Time (%s) must not be before %s", parsedTime, earliest)); + assertFalse(parsedTime.isAfter(latest), String.format("Time (%s) must not be after %s", parsedTime, latest)); + } + +} diff --git a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/exception/ContainerMimetypeFileException.java b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/exception/ContainerMimetypeFileException.java index 55ef5dccb..cfddb1c07 100644 --- a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/exception/ContainerMimetypeFileException.java +++ b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/exception/ContainerMimetypeFileException.java @@ -1,23 +1,23 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.siva.proxy.exception; - -public class ContainerMimetypeFileException extends RuntimeException { - public ContainerMimetypeFileException(String message) { - super(message); - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.siva.proxy.exception; + +public class ContainerMimetypeFileException extends RuntimeException { + public ContainerMimetypeFileException(String message) { + super(message); + } +} diff --git a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/validation/ZipMimetypeValidator.java b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/validation/ZipMimetypeValidator.java index a89f7f38b..9e9a8d283 100644 --- a/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/validation/ZipMimetypeValidator.java +++ b/siva-parent/siva-validation-proxy/src/main/java/ee/openeid/siva/proxy/validation/ZipMimetypeValidator.java @@ -1,128 +1,128 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.siva.proxy.validation; - -import ee.openeid.siva.proxy.document.ProxyDocument; -import ee.openeid.siva.proxy.exception.ContainerMimetypeFileException; -import org.apache.commons.lang3.ArrayUtils; - -import java.nio.ByteBuffer; -import java.nio.ByteOrder; -import java.nio.charset.StandardCharsets; -import java.util.Arrays; -import java.util.List; -import java.util.stream.Collectors; -import java.util.stream.Stream; - -import static eu.europa.esig.dss.asic.common.ASiCUtils.MIME_TYPE; - -public class ZipMimetypeValidator { - private static final int LOCAL_FILE_HEADER_SIGNATURE = 0x04034b50; - private static final int FILE_NAME_LENGTH_OFFSET = 26; - private static final int FILE_NAME_OFFSET = 30; - private static final int COMPRESSION_METHOD_OFFSET = 8; - private static final int EXTRA_FIELD_LENGTH_OFFSET = 28; - private static final int UNCOMPRESSED_SIZE_OFFSET = 22; - private static final int MIMETYPE_CONTENT_OFFSET = 38; - private static final byte[] MIMETYPE_NAME_BYTES = MIME_TYPE.getBytes(StandardCharsets.US_ASCII); - - private final List allowedMimetypeBytes; - private final String unexpectedMimetypeMessage; - - public ZipMimetypeValidator(String... allowedMimetypes) { - allowedMimetypeBytes = Stream.of(allowedMimetypes) - .distinct() - .map(m -> m.getBytes(StandardCharsets.US_ASCII)) - .collect(Collectors.toList()); - unexpectedMimetypeMessage = Stream.of(allowedMimetypes) - .distinct() - .map(m -> '"' + m + '"') - .collect(Collectors.joining( - ", ", - "Container should have one of the expected mimetypes: ", - "" - )); - } - - public void validateZipContainerMimetype(ProxyDocument proxyDocument) { - byte[] documentBytes = proxyDocument.getBytes(); - - if (ArrayUtils.getLength(documentBytes) < FILE_NAME_OFFSET) { - return; - } - - ByteBuffer byteBuffer = ByteBuffer.wrap(documentBytes).order(ByteOrder.LITTLE_ENDIAN); - - if (byteBuffer.getInt(0) != LOCAL_FILE_HEADER_SIGNATURE) { - return; - } - - validateMimetypeName(byteBuffer); - validateMimetypeCompression(byteBuffer); - validateMimetypeExtraFieldLength(byteBuffer); - validateMimetypeContent(byteBuffer); - } - - private static void validateMimetypeName(ByteBuffer byteBuffer) { - int fileNameLength = byteBuffer.getShort(FILE_NAME_LENGTH_OFFSET); - - if (fileNameLength == MIMETYPE_NAME_BYTES.length) { - int fileNameOffset = byteBuffer.arrayOffset() + FILE_NAME_OFFSET; - byte[] byteBufferArray = byteBuffer.array(); - - if (byteBufferArray.length >= fileNameOffset + fileNameLength && Arrays.equals( - byteBufferArray, fileNameOffset, fileNameOffset + fileNameLength, - MIMETYPE_NAME_BYTES, 0, MIMETYPE_NAME_BYTES.length - )) { - return; - } - } - - throw new ContainerMimetypeFileException("\"mimetype\" should be the first file in the container"); - } - - private static void validateMimetypeCompression(ByteBuffer byteBuffer) { - if (byteBuffer.getShort(COMPRESSION_METHOD_OFFSET) != 0) { - throw new ContainerMimetypeFileException("Container \"mimetype\" file must not be compressed"); - } - } - - private static void validateMimetypeExtraFieldLength(ByteBuffer byteBuffer) { - if (byteBuffer.getShort(EXTRA_FIELD_LENGTH_OFFSET) != 0) { - throw new ContainerMimetypeFileException("Container \"mimetype\" file must not contain \"Extra fields\" in its ZIP header"); - } - } - - private void validateMimetypeContent(ByteBuffer byteBuffer) { - int fileContentSize = byteBuffer.getInt(UNCOMPRESSED_SIZE_OFFSET); - int fileContentOffset = byteBuffer.arrayOffset() + MIMETYPE_CONTENT_OFFSET; - byte[] byteBufferArray = byteBuffer.array(); - - if (byteBufferArray.length >= fileContentOffset + fileContentSize) { - for (byte[] expectedBytes : allowedMimetypeBytes) { - if (fileContentSize == expectedBytes.length && Arrays.equals( - byteBufferArray, fileContentOffset, fileContentOffset + fileContentSize, - expectedBytes, 0, expectedBytes.length - )) { - return; - } - } - } - - throw new ContainerMimetypeFileException(unexpectedMimetypeMessage); - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.siva.proxy.validation; + +import ee.openeid.siva.proxy.document.ProxyDocument; +import ee.openeid.siva.proxy.exception.ContainerMimetypeFileException; +import org.apache.commons.lang3.ArrayUtils; + +import java.nio.ByteBuffer; +import java.nio.ByteOrder; +import java.nio.charset.StandardCharsets; +import java.util.Arrays; +import java.util.List; +import java.util.stream.Collectors; +import java.util.stream.Stream; + +import static eu.europa.esig.dss.asic.common.ASiCUtils.MIME_TYPE; + +public class ZipMimetypeValidator { + private static final int LOCAL_FILE_HEADER_SIGNATURE = 0x04034b50; + private static final int FILE_NAME_LENGTH_OFFSET = 26; + private static final int FILE_NAME_OFFSET = 30; + private static final int COMPRESSION_METHOD_OFFSET = 8; + private static final int EXTRA_FIELD_LENGTH_OFFSET = 28; + private static final int UNCOMPRESSED_SIZE_OFFSET = 22; + private static final int MIMETYPE_CONTENT_OFFSET = 38; + private static final byte[] MIMETYPE_NAME_BYTES = MIME_TYPE.getBytes(StandardCharsets.US_ASCII); + + private final List allowedMimetypeBytes; + private final String unexpectedMimetypeMessage; + + public ZipMimetypeValidator(String... allowedMimetypes) { + allowedMimetypeBytes = Stream.of(allowedMimetypes) + .distinct() + .map(m -> m.getBytes(StandardCharsets.US_ASCII)) + .collect(Collectors.toList()); + unexpectedMimetypeMessage = Stream.of(allowedMimetypes) + .distinct() + .map(m -> '"' + m + '"') + .collect(Collectors.joining( + ", ", + "Container should have one of the expected mimetypes: ", + "" + )); + } + + public void validateZipContainerMimetype(ProxyDocument proxyDocument) { + byte[] documentBytes = proxyDocument.getBytes(); + + if (ArrayUtils.getLength(documentBytes) < FILE_NAME_OFFSET) { + return; + } + + ByteBuffer byteBuffer = ByteBuffer.wrap(documentBytes).order(ByteOrder.LITTLE_ENDIAN); + + if (byteBuffer.getInt(0) != LOCAL_FILE_HEADER_SIGNATURE) { + return; + } + + validateMimetypeName(byteBuffer); + validateMimetypeCompression(byteBuffer); + validateMimetypeExtraFieldLength(byteBuffer); + validateMimetypeContent(byteBuffer); + } + + private static void validateMimetypeName(ByteBuffer byteBuffer) { + int fileNameLength = byteBuffer.getShort(FILE_NAME_LENGTH_OFFSET); + + if (fileNameLength == MIMETYPE_NAME_BYTES.length) { + int fileNameOffset = byteBuffer.arrayOffset() + FILE_NAME_OFFSET; + byte[] byteBufferArray = byteBuffer.array(); + + if (byteBufferArray.length >= fileNameOffset + fileNameLength && Arrays.equals( + byteBufferArray, fileNameOffset, fileNameOffset + fileNameLength, + MIMETYPE_NAME_BYTES, 0, MIMETYPE_NAME_BYTES.length + )) { + return; + } + } + + throw new ContainerMimetypeFileException("\"mimetype\" should be the first file in the container"); + } + + private static void validateMimetypeCompression(ByteBuffer byteBuffer) { + if (byteBuffer.getShort(COMPRESSION_METHOD_OFFSET) != 0) { + throw new ContainerMimetypeFileException("Container \"mimetype\" file must not be compressed"); + } + } + + private static void validateMimetypeExtraFieldLength(ByteBuffer byteBuffer) { + if (byteBuffer.getShort(EXTRA_FIELD_LENGTH_OFFSET) != 0) { + throw new ContainerMimetypeFileException("Container \"mimetype\" file must not contain \"Extra fields\" in its ZIP header"); + } + } + + private void validateMimetypeContent(ByteBuffer byteBuffer) { + int fileContentSize = byteBuffer.getInt(UNCOMPRESSED_SIZE_OFFSET); + int fileContentOffset = byteBuffer.arrayOffset() + MIMETYPE_CONTENT_OFFSET; + byte[] byteBufferArray = byteBuffer.array(); + + if (byteBufferArray.length >= fileContentOffset + fileContentSize) { + for (byte[] expectedBytes : allowedMimetypeBytes) { + if (fileContentSize == expectedBytes.length && Arrays.equals( + byteBufferArray, fileContentOffset, fileContentOffset + fileContentSize, + expectedBytes, 0, expectedBytes.length + )) { + return; + } + } + } + + throw new ContainerMimetypeFileException(unexpectedMimetypeMessage); + } +} diff --git a/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/ZipMimetypeValidatorTest.java b/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/ZipMimetypeValidatorTest.java index 4676aeaa8..c24400c48 100644 --- a/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/ZipMimetypeValidatorTest.java +++ b/siva-parent/siva-validation-proxy/src/test/java/ee/openeid/siva/proxy/ZipMimetypeValidatorTest.java @@ -1,183 +1,183 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.siva.proxy; - -import ee.openeid.siva.proxy.document.ProxyDocument; -import ee.openeid.siva.proxy.exception.ContainerMimetypeFileException; -import ee.openeid.siva.proxy.validation.ZipMimetypeValidator; -import eu.europa.esig.dss.asic.common.ASiCUtils; -import lombok.AccessLevel; -import lombok.Builder; -import lombok.NonNull; -import org.junit.jupiter.api.Test; - -import java.nio.ByteBuffer; -import java.nio.ByteOrder; -import java.nio.charset.StandardCharsets; - -import static org.junit.jupiter.api.Assertions.assertEquals; -import static org.junit.jupiter.api.Assertions.assertThrows; - -class ZipMimetypeValidatorTest { - - @Test - void validMimetypeOfSingleExpectedValueShouldNotThrowException() { - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .fileContent("valid-mimetype") - .build(); - - zipMimetypeValidator.validateZipContainerMimetype(proxyDocument); - } - - @Test - void validMimetypeOfMultipleExpectedValuesShouldNotThrowException() { - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype1", "valid-mimetype2"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .fileContent("valid-mimetype2") - .build(); - - zipMimetypeValidator.validateZipContainerMimetype(proxyDocument); - } - - @Test - void invalidMimetypeLengthThrowsException() { - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .fileName("mimetyp") - .fileContent("valid-mimetype") - .build(); - - ContainerMimetypeFileException caughtException = assertThrows( - ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) - ); - assertEquals("\"mimetype\" should be the first file in the container", caughtException.getMessage()); - } - - @Test - void invalidMimetypeFileNameThrowsException() { - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .fileName("mimetipe") - .fileContent("valid-mimetype") - .build(); - - ContainerMimetypeFileException caughtException = assertThrows( - ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) - ); - assertEquals("\"mimetype\" should be the first file in the container", caughtException.getMessage()); - } - - @Test - void invalidMimetypeCompressionTypeThrowsException() { - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .compressed(true) - .fileContent("valid-mimetype") - .build(); - - ContainerMimetypeFileException caughtException = assertThrows( - ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) - ); - assertEquals("Container \"mimetype\" file must not be compressed", caughtException.getMessage()); - } - - @Test - void invalidMimetypeExtraFieldLengthThrowsException() { - short invalidExtraFieldLength = 1; - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .fileContent("valid-mimetype") - .extraFieldLength(invalidExtraFieldLength) - .build(); - - ContainerMimetypeFileException caughtException = assertThrows( - ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) - ); - assertEquals("Container \"mimetype\" file must not contain \"Extra fields\" in its ZIP header", caughtException.getMessage()); - } - - @Test - void invalidMimetypeUncompressedSizeThrowsException() { - int invalidUncompressedSize = 20; - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .uncompressedSize(invalidUncompressedSize) - .fileContent("valid-mimetype") - .build(); - - ContainerMimetypeFileException caughtException = assertThrows( - ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) - ); - assertEquals( - "Container should have one of the expected mimetypes: \"valid-mimetype\"", caughtException.getMessage() - ); - } - - @Test - void invalidMimetypeFileContentThrowsException() { - ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); - ProxyDocument proxyDocument = proxyDocumentBuilder() - .fileContent("invalid-mimetype") - .build(); - - ContainerMimetypeFileException caughtException = assertThrows( - ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) - ); - assertEquals( - "Container should have one of the expected mimetypes: \"valid-mimetype\"", caughtException.getMessage() - ); - } - - @Builder( - access = AccessLevel.PRIVATE, - builderClassName = "ProxyDocumentBuilder", - builderMethodName = "proxyDocumentBuilder" - ) - private static ProxyDocument createProxyDocument( - Integer localFileHeaderSignature, - boolean compressed, - Integer uncompressedSize, - String fileName, - @NonNull String fileContent, - short extraFieldLength - ) { - if (fileName == null) { - fileName = ASiCUtils.MIME_TYPE; - } - - byte[] fileNameBytes = fileName.getBytes(StandardCharsets.UTF_8); - byte[] fileContentBytes = fileContent.getBytes(StandardCharsets.UTF_8); - - byte[] documentBytes = new byte[30 + fileNameBytes.length + fileContentBytes.length]; - ByteBuffer byteBuffer = ByteBuffer.wrap(documentBytes).order(ByteOrder.LITTLE_ENDIAN); - - byteBuffer.putInt(0, localFileHeaderSignature != null ? localFileHeaderSignature : 0x04034b50); - byteBuffer.putShort(8, (short) (compressed ? 8 : 0)); - byteBuffer.putInt(18, fileContentBytes.length); - byteBuffer.putInt(22, uncompressedSize != null ? uncompressedSize : fileContentBytes.length); - byteBuffer.putShort(26, (short) fileNameBytes.length); - byteBuffer.putShort(28, extraFieldLength); - - System.arraycopy(fileNameBytes, 0, documentBytes, 30, fileNameBytes.length); - System.arraycopy(fileContentBytes, 0, documentBytes, 30 + fileNameBytes.length, fileContentBytes.length); - - ProxyDocument proxyDocument = new ProxyDocument(); - proxyDocument.setBytes(documentBytes); - return proxyDocument; - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.siva.proxy; + +import ee.openeid.siva.proxy.document.ProxyDocument; +import ee.openeid.siva.proxy.exception.ContainerMimetypeFileException; +import ee.openeid.siva.proxy.validation.ZipMimetypeValidator; +import eu.europa.esig.dss.asic.common.ASiCUtils; +import lombok.AccessLevel; +import lombok.Builder; +import lombok.NonNull; +import org.junit.jupiter.api.Test; + +import java.nio.ByteBuffer; +import java.nio.ByteOrder; +import java.nio.charset.StandardCharsets; + +import static org.junit.jupiter.api.Assertions.assertEquals; +import static org.junit.jupiter.api.Assertions.assertThrows; + +class ZipMimetypeValidatorTest { + + @Test + void validMimetypeOfSingleExpectedValueShouldNotThrowException() { + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .fileContent("valid-mimetype") + .build(); + + zipMimetypeValidator.validateZipContainerMimetype(proxyDocument); + } + + @Test + void validMimetypeOfMultipleExpectedValuesShouldNotThrowException() { + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype1", "valid-mimetype2"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .fileContent("valid-mimetype2") + .build(); + + zipMimetypeValidator.validateZipContainerMimetype(proxyDocument); + } + + @Test + void invalidMimetypeLengthThrowsException() { + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .fileName("mimetyp") + .fileContent("valid-mimetype") + .build(); + + ContainerMimetypeFileException caughtException = assertThrows( + ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) + ); + assertEquals("\"mimetype\" should be the first file in the container", caughtException.getMessage()); + } + + @Test + void invalidMimetypeFileNameThrowsException() { + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .fileName("mimetipe") + .fileContent("valid-mimetype") + .build(); + + ContainerMimetypeFileException caughtException = assertThrows( + ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) + ); + assertEquals("\"mimetype\" should be the first file in the container", caughtException.getMessage()); + } + + @Test + void invalidMimetypeCompressionTypeThrowsException() { + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .compressed(true) + .fileContent("valid-mimetype") + .build(); + + ContainerMimetypeFileException caughtException = assertThrows( + ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) + ); + assertEquals("Container \"mimetype\" file must not be compressed", caughtException.getMessage()); + } + + @Test + void invalidMimetypeExtraFieldLengthThrowsException() { + short invalidExtraFieldLength = 1; + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .fileContent("valid-mimetype") + .extraFieldLength(invalidExtraFieldLength) + .build(); + + ContainerMimetypeFileException caughtException = assertThrows( + ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) + ); + assertEquals("Container \"mimetype\" file must not contain \"Extra fields\" in its ZIP header", caughtException.getMessage()); + } + + @Test + void invalidMimetypeUncompressedSizeThrowsException() { + int invalidUncompressedSize = 20; + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .uncompressedSize(invalidUncompressedSize) + .fileContent("valid-mimetype") + .build(); + + ContainerMimetypeFileException caughtException = assertThrows( + ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) + ); + assertEquals( + "Container should have one of the expected mimetypes: \"valid-mimetype\"", caughtException.getMessage() + ); + } + + @Test + void invalidMimetypeFileContentThrowsException() { + ZipMimetypeValidator zipMimetypeValidator = new ZipMimetypeValidator("valid-mimetype"); + ProxyDocument proxyDocument = proxyDocumentBuilder() + .fileContent("invalid-mimetype") + .build(); + + ContainerMimetypeFileException caughtException = assertThrows( + ContainerMimetypeFileException.class, () -> zipMimetypeValidator.validateZipContainerMimetype(proxyDocument) + ); + assertEquals( + "Container should have one of the expected mimetypes: \"valid-mimetype\"", caughtException.getMessage() + ); + } + + @Builder( + access = AccessLevel.PRIVATE, + builderClassName = "ProxyDocumentBuilder", + builderMethodName = "proxyDocumentBuilder" + ) + private static ProxyDocument createProxyDocument( + Integer localFileHeaderSignature, + boolean compressed, + Integer uncompressedSize, + String fileName, + @NonNull String fileContent, + short extraFieldLength + ) { + if (fileName == null) { + fileName = ASiCUtils.MIME_TYPE; + } + + byte[] fileNameBytes = fileName.getBytes(StandardCharsets.UTF_8); + byte[] fileContentBytes = fileContent.getBytes(StandardCharsets.UTF_8); + + byte[] documentBytes = new byte[30 + fileNameBytes.length + fileContentBytes.length]; + ByteBuffer byteBuffer = ByteBuffer.wrap(documentBytes).order(ByteOrder.LITTLE_ENDIAN); + + byteBuffer.putInt(0, localFileHeaderSignature != null ? localFileHeaderSignature : 0x04034b50); + byteBuffer.putShort(8, (short) (compressed ? 8 : 0)); + byteBuffer.putInt(18, fileContentBytes.length); + byteBuffer.putInt(22, uncompressedSize != null ? uncompressedSize : fileContentBytes.length); + byteBuffer.putShort(26, (short) fileNameBytes.length); + byteBuffer.putShort(28, extraFieldLength); + + System.arraycopy(fileNameBytes, 0, documentBytes, 30, fileNameBytes.length); + System.arraycopy(fileContentBytes, 0, documentBytes, 30 + fileNameBytes.length, fileContentBytes.length); + + ProxyDocument proxyDocument = new ProxyDocument(); + proxyDocument.setBytes(documentBytes); + return proxyDocument; + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/PolicyUtil.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/PolicyUtil.java index 55e8c3574..048113d81 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/PolicyUtil.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/PolicyUtil.java @@ -1,54 +1,54 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic; - -import ee.openeid.siva.validation.service.signature.policy.properties.ConstraintDefinedPolicy; -import eu.europa.esig.dss.exception.IllegalInputException; -import eu.europa.esig.dss.policy.ValidationPolicy; -import eu.europa.esig.dss.policy.ValidationPolicyFacade; -import jakarta.xml.bind.JAXBException; -import lombok.AccessLevel; -import lombok.NoArgsConstructor; -import org.xml.sax.SAXException; - -import javax.xml.stream.XMLStreamException; -import java.io.IOException; -import java.util.List; -import java.util.stream.Collectors; - -import static eu.europa.esig.dss.policy.ValidationPolicyFacade.newFacade; - -@NoArgsConstructor(access = AccessLevel.PRIVATE) -public final class PolicyUtil { - - public static List getTLevelSignatures(ConstraintDefinedPolicy policy) { - List signatureLevels = getValidationPolicy(policy).getSignatureConstraints().getAcceptableFormats().getId(); - - return signatureLevels.stream() - .filter(string -> string.endsWith("BASELINE-T")) - .collect(Collectors.toList()); - } - - public static ValidationPolicy getValidationPolicy(ConstraintDefinedPolicy policy) { - ValidationPolicyFacade validationPolicyFacade = newFacade(); - try { - return validationPolicyFacade.getValidationPolicy(policy.getConstraintDataStream()); - } catch (JAXBException | XMLStreamException | IOException | SAXException e) { - throw new IllegalInputException("Unable to load the policy", e); - } - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic; + +import ee.openeid.siva.validation.service.signature.policy.properties.ConstraintDefinedPolicy; +import eu.europa.esig.dss.exception.IllegalInputException; +import eu.europa.esig.dss.policy.ValidationPolicy; +import eu.europa.esig.dss.policy.ValidationPolicyFacade; +import jakarta.xml.bind.JAXBException; +import lombok.AccessLevel; +import lombok.NoArgsConstructor; +import org.xml.sax.SAXException; + +import javax.xml.stream.XMLStreamException; +import java.io.IOException; +import java.util.List; +import java.util.stream.Collectors; + +import static eu.europa.esig.dss.policy.ValidationPolicyFacade.newFacade; + +@NoArgsConstructor(access = AccessLevel.PRIVATE) +public final class PolicyUtil { + + public static List getTLevelSignatures(ConstraintDefinedPolicy policy) { + List signatureLevels = getValidationPolicy(policy).getSignatureConstraints().getAcceptableFormats().getId(); + + return signatureLevels.stream() + .filter(string -> string.endsWith("BASELINE-T")) + .collect(Collectors.toList()); + } + + public static ValidationPolicy getValidationPolicy(ConstraintDefinedPolicy policy) { + ValidationPolicyFacade validationPolicyFacade = newFacade(); + try { + return validationPolicyFacade.getValidationPolicy(policy.getConstraintDataStream()); + } catch (JAXBException | XMLStreamException | IOException | SAXException e) { + throw new IllegalInputException("Unable to load the policy", e); + } + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/configuration/properties/TLevelSignatureFilterProperties.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/configuration/properties/TLevelSignatureFilterProperties.java index 33f9127f5..07e3e1a9c 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/configuration/properties/TLevelSignatureFilterProperties.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/configuration/properties/TLevelSignatureFilterProperties.java @@ -1,50 +1,50 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.configuration.properties; - -import lombok.Getter; -import lombok.Setter; -import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty; -import org.springframework.boot.context.properties.ConfigurationProperties; -import org.springframework.context.annotation.Configuration; -import org.springframework.validation.annotation.Validated; - -import jakarta.validation.constraints.NotBlank; -import jakarta.validation.constraints.NotNull; -import java.util.ArrayList; -import java.util.List; - -import static ee.openeid.validation.service.generic.configuration.properties.TLevelSignatureFilterProperties.PROPERTIES_PREFIX; - -@Getter -@Setter -@Validated -@ConditionalOnProperty(prefix = PROPERTIES_PREFIX, name = "filter-type") -@Configuration -@ConfigurationProperties(prefix = PROPERTIES_PREFIX) -public class TLevelSignatureFilterProperties { - static final String PROPERTIES_PREFIX = "t-level-signature-filter"; - - @NotNull - private CountryFilterType filterType; - @NotNull - private List<@NotBlank String> countries = new ArrayList<>(); - - public enum CountryFilterType { - ALLOWED_COUNTRIES, NOT_ALLOWED_COUNTRIES; - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.configuration.properties; + +import lombok.Getter; +import lombok.Setter; +import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty; +import org.springframework.boot.context.properties.ConfigurationProperties; +import org.springframework.context.annotation.Configuration; +import org.springframework.validation.annotation.Validated; + +import jakarta.validation.constraints.NotBlank; +import jakarta.validation.constraints.NotNull; +import java.util.ArrayList; +import java.util.List; + +import static ee.openeid.validation.service.generic.configuration.properties.TLevelSignatureFilterProperties.PROPERTIES_PREFIX; + +@Getter +@Setter +@Validated +@ConditionalOnProperty(prefix = PROPERTIES_PREFIX, name = "filter-type") +@Configuration +@ConfigurationProperties(prefix = PROPERTIES_PREFIX) +public class TLevelSignatureFilterProperties { + static final String PROPERTIES_PREFIX = "t-level-signature-filter"; + + @NotNull + private CountryFilterType filterType; + @NotNull + private List<@NotBlank String> countries = new ArrayList<>(); + + public enum CountryFilterType { + ALLOWED_COUNTRIES, NOT_ALLOWED_COUNTRIES; + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/RevocationFreshnessValidatorFactory.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/RevocationFreshnessValidatorFactory.java index 07ac22a7e..824bcf882 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/RevocationFreshnessValidatorFactory.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/RevocationFreshnessValidatorFactory.java @@ -1,25 +1,25 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator; - -import ee.openeid.siva.validation.service.signature.policy.properties.ConstraintDefinedPolicy; -import eu.europa.esig.dss.validation.reports.Reports; - -@FunctionalInterface -public interface RevocationFreshnessValidatorFactory { - RevocationFreshnessValidator create(Reports reports, ConstraintDefinedPolicy policy); -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator; + +import ee.openeid.siva.validation.service.signature.policy.properties.ConstraintDefinedPolicy; +import eu.europa.esig.dss.validation.reports.Reports; + +@FunctionalInterface +public interface RevocationFreshnessValidatorFactory { + RevocationFreshnessValidator create(Reports reports, ConstraintDefinedPolicy policy); +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/TLevelSignatureOfNonListedCountryPredicate.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/TLevelSignatureOfNonListedCountryPredicate.java index cb600abbb..eab0422f8 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/TLevelSignatureOfNonListedCountryPredicate.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/TLevelSignatureOfNonListedCountryPredicate.java @@ -1,51 +1,51 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator; - -import ee.openeid.validation.service.generic.validator.filter.CountryFilter; -import eu.europa.esig.dss.diagnostic.CertificateWrapper; -import eu.europa.esig.dss.diagnostic.SignatureWrapper; -import eu.europa.esig.dss.enumerations.SignatureLevel; -import lombok.NonNull; -import lombok.RequiredArgsConstructor; - -import java.util.List; -import java.util.Optional; -import java.util.function.Predicate; - -@RequiredArgsConstructor -public class TLevelSignatureOfNonListedCountryPredicate implements Predicate { - - @NonNull - private final CountryFilter countryFilter; - @NonNull - private final List tLevelSignatures; - - @Override - public boolean test(SignatureWrapper signatureWrapper) { - String countryName = Optional - .ofNullable(signatureWrapper.getSigningCertificate()) - .map(CertificateWrapper::getCountryName) - .orElse(null); - - return countryFilter.filter(countryName) && Optional - .ofNullable(signatureWrapper.getSignatureFormat()) - .map(SignatureLevel::toString) - .map(tLevelSignatures::contains) - .orElse(false); - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator; + +import ee.openeid.validation.service.generic.validator.filter.CountryFilter; +import eu.europa.esig.dss.diagnostic.CertificateWrapper; +import eu.europa.esig.dss.diagnostic.SignatureWrapper; +import eu.europa.esig.dss.enumerations.SignatureLevel; +import lombok.NonNull; +import lombok.RequiredArgsConstructor; + +import java.util.List; +import java.util.Optional; +import java.util.function.Predicate; + +@RequiredArgsConstructor +public class TLevelSignatureOfNonListedCountryPredicate implements Predicate { + + @NonNull + private final CountryFilter countryFilter; + @NonNull + private final List tLevelSignatures; + + @Override + public boolean test(SignatureWrapper signatureWrapper) { + String countryName = Optional + .ofNullable(signatureWrapper.getSigningCertificate()) + .map(CertificateWrapper::getCountryName) + .orElse(null); + + return countryFilter.filter(countryName) && Optional + .ofNullable(signatureWrapper.getSignatureFormat()) + .map(SignatureLevel::toString) + .map(tLevelSignatures::contains) + .orElse(false); + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/AllowedCountriesFilter.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/AllowedCountriesFilter.java index afb0dc930..f416c07c6 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/AllowedCountriesFilter.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/AllowedCountriesFilter.java @@ -1,34 +1,34 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator.filter; - -import lombok.NonNull; -import lombok.RequiredArgsConstructor; - -import java.util.List; - -@RequiredArgsConstructor -public class AllowedCountriesFilter implements CountryFilter { - - @NonNull - private final List countries; - - @Override - public boolean filter(String country) { - return (country != null) && countries.contains(country); - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator.filter; + +import lombok.NonNull; +import lombok.RequiredArgsConstructor; + +import java.util.List; + +@RequiredArgsConstructor +public class AllowedCountriesFilter implements CountryFilter { + + @NonNull + private final List countries; + + @Override + public boolean filter(String country) { + return (country != null) && countries.contains(country); + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/CountryFilter.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/CountryFilter.java index 32df25295..7eed7187d 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/CountryFilter.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/CountryFilter.java @@ -1,22 +1,22 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator.filter; - -@FunctionalInterface -public interface CountryFilter { - boolean filter(String country); -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator.filter; + +@FunctionalInterface +public interface CountryFilter { + boolean filter(String country); +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/NotAllowedCountriesFilter.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/NotAllowedCountriesFilter.java index 80ffd3d88..1265d2815 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/NotAllowedCountriesFilter.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/filter/NotAllowedCountriesFilter.java @@ -1,34 +1,34 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator.filter; - -import lombok.NonNull; -import lombok.RequiredArgsConstructor; - -import java.util.List; - -@RequiredArgsConstructor -public class NotAllowedCountriesFilter implements CountryFilter { - - @NonNull - private final List countries; - - @Override - public boolean filter(String country) { - return country == null || !countries.contains(country); - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator.filter; + +import lombok.NonNull; +import lombok.RequiredArgsConstructor; + +import java.util.List; + +@RequiredArgsConstructor +public class NotAllowedCountriesFilter implements CountryFilter { + + @NonNull + private final List countries; + + @Override + public boolean filter(String country) { + return country == null || !countries.contains(country); + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/CompositeOCSPSource.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/CompositeOCSPSource.java index f5b63a578..3ba90e3ff 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/CompositeOCSPSource.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/CompositeOCSPSource.java @@ -1,42 +1,42 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator.ocsp; - -import eu.europa.esig.dss.model.x509.CertificateToken; -import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPSource; -import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPToken; -import lombok.NonNull; -import lombok.RequiredArgsConstructor; - -import java.util.function.BiPredicate; - -@RequiredArgsConstructor -public class CompositeOCSPSource implements OCSPSource { - @NonNull - private final OCSPSource ocspSource; - @NonNull - private final BiPredicate ocspRequestRequirementPredicate; - - @Override - public OCSPToken getRevocationToken(CertificateToken certificateToken, CertificateToken issuerCertificateToken) { - if (ocspRequestRequirementPredicate.test(certificateToken, issuerCertificateToken)) { - return ocspSource.getRevocationToken(certificateToken, issuerCertificateToken); - } else { - return null; - } - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator.ocsp; + +import eu.europa.esig.dss.model.x509.CertificateToken; +import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPSource; +import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPToken; +import lombok.NonNull; +import lombok.RequiredArgsConstructor; + +import java.util.function.BiPredicate; + +@RequiredArgsConstructor +public class CompositeOCSPSource implements OCSPSource { + @NonNull + private final OCSPSource ocspSource; + @NonNull + private final BiPredicate ocspRequestRequirementPredicate; + + @Override + public OCSPToken getRevocationToken(CertificateToken certificateToken, CertificateToken issuerCertificateToken) { + if (ocspRequestRequirementPredicate.test(certificateToken, issuerCertificateToken)) { + return ocspSource.getRevocationToken(certificateToken, issuerCertificateToken); + } else { + return null; + } + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/LoggingOSCPSourceWrapper.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/LoggingOSCPSourceWrapper.java index c4d690dda..d2f20b58a 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/LoggingOSCPSourceWrapper.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/LoggingOSCPSourceWrapper.java @@ -1,70 +1,70 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator.ocsp; - -import eu.europa.esig.dss.model.x509.CertificateToken; -import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPSource; -import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPToken; -import lombok.NonNull; -import lombok.RequiredArgsConstructor; -import lombok.extern.slf4j.Slf4j; - -@Slf4j -@RequiredArgsConstructor -public class LoggingOSCPSourceWrapper implements OCSPSource { - @NonNull - private final OCSPSource ocspSource; - - @Override - public OCSPToken getRevocationToken(CertificateToken certificateToken, CertificateToken issuerCertificateToken) { - - OCSPToken ocspToken; - - try { - ocspToken = ocspSource.getRevocationToken(certificateToken, issuerCertificateToken); - } catch (Exception e) { - log.warn( - "Failed to perform OCSP request for certificate token '{}': {}", - certificateToken.getDSSIdAsString(), - e.getMessage() - ); - return null; - } - - if (ocspToken != null) { - return processOcspToken(ocspToken, certificateToken); - } else { - return handleMissingOcspToken(certificateToken); - } - } - - private OCSPToken processOcspToken(OCSPToken ocspToken, CertificateToken certificateToken) { - log.info( - "Performed OCSP request for certificate token '{}' from '{}', status: '{}'", - certificateToken.getDSSIdAsString(), - ocspToken.getSourceURL(), - ocspToken.getStatus() - ); - - return ocspToken; - } - - private OCSPToken handleMissingOcspToken(CertificateToken certificateToken) { - log.warn("No OCSP token found for certificate token '{}'", certificateToken.getDSSIdAsString()); - return null; - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator.ocsp; + +import eu.europa.esig.dss.model.x509.CertificateToken; +import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPSource; +import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPToken; +import lombok.NonNull; +import lombok.RequiredArgsConstructor; +import lombok.extern.slf4j.Slf4j; + +@Slf4j +@RequiredArgsConstructor +public class LoggingOSCPSourceWrapper implements OCSPSource { + @NonNull + private final OCSPSource ocspSource; + + @Override + public OCSPToken getRevocationToken(CertificateToken certificateToken, CertificateToken issuerCertificateToken) { + + OCSPToken ocspToken; + + try { + ocspToken = ocspSource.getRevocationToken(certificateToken, issuerCertificateToken); + } catch (Exception e) { + log.warn( + "Failed to perform OCSP request for certificate token '{}': {}", + certificateToken.getDSSIdAsString(), + e.getMessage() + ); + return null; + } + + if (ocspToken != null) { + return processOcspToken(ocspToken, certificateToken); + } else { + return handleMissingOcspToken(certificateToken); + } + } + + private OCSPToken processOcspToken(OCSPToken ocspToken, CertificateToken certificateToken) { + log.info( + "Performed OCSP request for certificate token '{}' from '{}', status: '{}'", + certificateToken.getDSSIdAsString(), + ocspToken.getSourceURL(), + ocspToken.getStatus() + ); + + return ocspToken; + } + + private OCSPToken handleMissingOcspToken(CertificateToken certificateToken) { + log.warn("No OCSP token found for certificate token '{}'", certificateToken.getDSSIdAsString()); + return null; + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPRequestPredicate.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPRequestPredicate.java index 3850d446e..99ccb9bd6 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPRequestPredicate.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPRequestPredicate.java @@ -1,43 +1,43 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator.ocsp; - -import ee.openeid.validation.service.generic.validator.filter.CountryFilter; -import eu.europa.esig.dss.model.x509.CertificateToken; -import lombok.NonNull; -import lombok.RequiredArgsConstructor; -import org.bouncycastle.asn1.ASN1ObjectIdentifier; -import org.bouncycastle.asn1.x500.style.BCStyle; - -import java.security.cert.X509Certificate; -import java.util.function.BiFunction; -import java.util.function.BiPredicate; - -@RequiredArgsConstructor -public class OCSPRequestPredicate implements BiPredicate { - - @NonNull - private final BiFunction subjectDnAttributeExtractor; - @NonNull - private CountryFilter countryFilter; - - @Override - public boolean test(CertificateToken certificateToken, CertificateToken issuerCertificateToken) { - String country = subjectDnAttributeExtractor.apply(certificateToken.getCertificate(), BCStyle.C); - return countryFilter.filter(country); - } -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator.ocsp; + +import ee.openeid.validation.service.generic.validator.filter.CountryFilter; +import eu.europa.esig.dss.model.x509.CertificateToken; +import lombok.NonNull; +import lombok.RequiredArgsConstructor; +import org.bouncycastle.asn1.ASN1ObjectIdentifier; +import org.bouncycastle.asn1.x500.style.BCStyle; + +import java.security.cert.X509Certificate; +import java.util.function.BiFunction; +import java.util.function.BiPredicate; + +@RequiredArgsConstructor +public class OCSPRequestPredicate implements BiPredicate { + + @NonNull + private final BiFunction subjectDnAttributeExtractor; + @NonNull + private CountryFilter countryFilter; + + @Override + public boolean test(CertificateToken certificateToken, CertificateToken issuerCertificateToken) { + String country = subjectDnAttributeExtractor.apply(certificateToken.getCertificate(), BCStyle.C); + return countryFilter.filter(country); + } +} diff --git a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPSourceFactory.java b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPSourceFactory.java index d822b45d7..23a94d9ab 100644 --- a/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPSourceFactory.java +++ b/validation-services-parent/generic-validation-service/src/main/java/ee/openeid/validation/service/generic/validator/ocsp/OCSPSourceFactory.java @@ -1,24 +1,24 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.validation.service.generic.validator.ocsp; - -import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPSource; - -@FunctionalInterface -public interface OCSPSourceFactory { - OCSPSource create(); -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.validation.service.generic.validator.ocsp; + +import eu.europa.esig.dss.spi.x509.revocation.ocsp.OCSPSource; + +@FunctionalInterface +public interface OCSPSourceFactory { + OCSPSource create(); +} diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EECCRCA.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EECCRCA.crt index 76344b76b..a7526114e 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EECCRCA.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EECCRCA.crt @@ -1,24 +1,24 @@ ------BEGIN CERTIFICATE----- -MIIEEzCCAvugAwIBAgIQc/jtqiMEFERMtVvsSsH7sjANBgkqhkiG9w0BAQUFADB9 -MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 -czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 -IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwIhgPMjAxMDEwMDcxMjM0NTZa -GA8yMDMwMTIxNzIzNTk1OVowfTELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNl -cnRpZml0c2VlcmltaXNrZXNrdXMxMDAuBgNVBAMMJ1RFU1Qgb2YgRUUgQ2VydGlm -aWNhdGlvbiBDZW50cmUgUm9vdCBDQTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVl -MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1gGpqCtDmNNEHUjC8LXq -xRdC1kpjDgkzOTxQynzDxw/xCjy5hhyG3xX4RPrW9Z6k5ZNTNS+xzrZgQ9m5U6uM -ywYpx3F3DVgbdQLd8DsLmuVOz02k/TwoRt1uP6xtV9qG0HsGvN81q3HvPR/zKtA7 -MmNZuwuDFQwsguKgDR2Jfk44eKmLfyzvh+Xe6Cr5+zRnsVYwMA9bgBaOZMv1TwTT -VNi9H1ltK32Z+IhUX8W5f2qVP33R1wWCKapK1qTX/baXFsBJj++F8I8R6+gSyC3D -kV5N/pOlWPzZYx+kHRkRe/oddURA9InJwojbnsH+zJOa2VrNKakNv2HnuYCIonzu -pwIDAQABo4GKMIGHMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0G -A1UdDgQWBBS1NAqdpS8QxechDr7EsWVHGwN2/jBFBgNVHSUEPjA8BggrBgEFBQcD -AgYIKwYBBQUHAwEGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgGCCsGAQUF -BwMJMA0GCSqGSIb3DQEBBQUAA4IBAQAj72VtxIw6p5lqeNmWoQ48j8HnUBM+6mI0 -I+VkQr0EfQhfmQ5KFaZwnIqxWrEPaxRjYwV0xKa1AixVpFOb1j+XuVmgf7khxXTy -Bmd8JRLwl7teCkD1SDnU/yHmwY7MV9FbFBd+5XK4teHVvEVRsJ1oFwgcxVhyoviR -SnbIPaOvk+0nxKClrlS6NW5TWZ+yG55z8OCESHaL6JcimkLFjRjSsQDWIEtDvP4S -tH3vIMUPPiKdiNkGjVLSdChwkW3z+m0EvAjyD9rnGCmjeEm5diLFu7VMNVqupsbZ -SfDzzBLc5+6TqgQTOG7GaZk2diMkn03iLdHGFrh8ML+mXG9SjEPI ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIIEEzCCAvugAwIBAgIQc/jtqiMEFERMtVvsSsH7sjANBgkqhkiG9w0BAQUFADB9 +MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 +czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 +IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwIhgPMjAxMDEwMDcxMjM0NTZa +GA8yMDMwMTIxNzIzNTk1OVowfTELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNl +cnRpZml0c2VlcmltaXNrZXNrdXMxMDAuBgNVBAMMJ1RFU1Qgb2YgRUUgQ2VydGlm +aWNhdGlvbiBDZW50cmUgUm9vdCBDQTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVl +MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1gGpqCtDmNNEHUjC8LXq +xRdC1kpjDgkzOTxQynzDxw/xCjy5hhyG3xX4RPrW9Z6k5ZNTNS+xzrZgQ9m5U6uM +ywYpx3F3DVgbdQLd8DsLmuVOz02k/TwoRt1uP6xtV9qG0HsGvN81q3HvPR/zKtA7 +MmNZuwuDFQwsguKgDR2Jfk44eKmLfyzvh+Xe6Cr5+zRnsVYwMA9bgBaOZMv1TwTT +VNi9H1ltK32Z+IhUX8W5f2qVP33R1wWCKapK1qTX/baXFsBJj++F8I8R6+gSyC3D +kV5N/pOlWPzZYx+kHRkRe/oddURA9InJwojbnsH+zJOa2VrNKakNv2HnuYCIonzu +pwIDAQABo4GKMIGHMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0G +A1UdDgQWBBS1NAqdpS8QxechDr7EsWVHGwN2/jBFBgNVHSUEPjA8BggrBgEFBQcD +AgYIKwYBBQUHAwEGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgGCCsGAQUF +BwMJMA0GCSqGSIb3DQEBBQUAA4IBAQAj72VtxIw6p5lqeNmWoQ48j8HnUBM+6mI0 +I+VkQr0EfQhfmQ5KFaZwnIqxWrEPaxRjYwV0xKa1AixVpFOb1j+XuVmgf7khxXTy +Bmd8JRLwl7teCkD1SDnU/yHmwY7MV9FbFBd+5XK4teHVvEVRsJ1oFwgcxVhyoviR +SnbIPaOvk+0nxKClrlS6NW5TWZ+yG55z8OCESHaL6JcimkLFjRjSsQDWIEtDvP4S +tH3vIMUPPiKdiNkGjVLSdChwkW3z+m0EvAjyD9rnGCmjeEm5diLFu7VMNVqupsbZ +SfDzzBLc5+6TqgQTOG7GaZk2diMkn03iLdHGFrh8ML+mXG9SjEPI +-----END CERTIFICATE----- diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EID-SK 2011.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EID-SK 2011.crt index 5cdba66e2..54087de8f 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EID-SK 2011.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST EID-SK 2011.crt @@ -1,28 +1,28 @@ ------BEGIN CERTIFICATE----- -MIIEuDCCA6CgAwIBAgIQWwOHv2K/GORNdNgZblP5YDANBgkqhkiG9w0BAQUFADB9 -MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 -czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 -IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMwNTI5WhcN -MjMwOTA3MTIwNTI5WjBpMQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlm -aXRzZWVyaW1pc2tlc2t1czEcMBoGA1UEAwwTVEVTVCBvZiBFSUQtU0sgMjAxMTEY -MBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A -MIIBCgKCAQEAr5TNCQvKX1IApzLX5KLWSIOhyueYlpc5WKsFLdMWWG40QwJpHm0c -dudK51IIvdoDX5/uJlyf6/wd4NNSOF5rCogfkzD696NFuiplvXBYKZdshXqsxRhM -9mcp+9NqND5AGK4BtuUK2S83cxIRUiOxf7O43QxX3py5MDJRNa+kUOHBic8ekvR+ -MsdVpF+3A5V6WE6DNzxecBP6TF1+l/3B7L1Hz8hsaJ6QTsc6/O011WXG9y23dMpb -ho+JMyy9y3fe791sP87rqWhaFNT5kTnH3JOHK9fxgx0TDP66dde4nvnykRCadEmq -bOGLEar0xmnirAJgO/yrGrQ/A7gmDdhomwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/ -BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZkGA1UdIASBkTCBjjCBiwYKKwYBBAHO -HwMBATB9MFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQAaQBt -AGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4AZwAu -MCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5zay5lZS9DUFMwHQYDVR0OBBYEFNQi -siFrcquz1GPk1pe0bVcUzgEuMB8GA1UdIwQYMBaAFLU0Cp2lLxDF5yEOvsSxZUcb -A3b+MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHBzOi8vd3d3LnNrLmVlL3JlcG9zaXRv -cnkvY3Jscy90ZXN0X2VlY2NyY2EuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8uY6L -qaZKfLx6iKpoAEGxbuFwzrT4BVGqEzpZJNVkM2hhoS9qrttzUrC2hLmfWBbbsScV -GvcWNV7GIcHLYBioZV+ostku/jXXxzhNVhVvX5B8X10uKQDtcrkGbjUpF1JSes8T -9EsUBSIh5MmpNKc1IP8FfvL3qMU2mxU30KQdQy4IjM4Pv7T+MAWMqjrn6txfOZDu -5k6Sak/NBn4cozX0HenY/7301snxAT3BaWhwMKqleCyM7w3wfnFGevEs/4C7qn3S -QncgCEZlvL3lYxSIJ697LyZo0Lsc3s8+gXPT4Q/V8UqjmecgzZWHvyxCrf02iAqU -YRawXmDuuoGMwwlJ ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIIEuDCCA6CgAwIBAgIQWwOHv2K/GORNdNgZblP5YDANBgkqhkiG9w0BAQUFADB9 +MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 +czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 +IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMwNTI5WhcN +MjMwOTA3MTIwNTI5WjBpMQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlm +aXRzZWVyaW1pc2tlc2t1czEcMBoGA1UEAwwTVEVTVCBvZiBFSUQtU0sgMjAxMTEY +MBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A +MIIBCgKCAQEAr5TNCQvKX1IApzLX5KLWSIOhyueYlpc5WKsFLdMWWG40QwJpHm0c +dudK51IIvdoDX5/uJlyf6/wd4NNSOF5rCogfkzD696NFuiplvXBYKZdshXqsxRhM +9mcp+9NqND5AGK4BtuUK2S83cxIRUiOxf7O43QxX3py5MDJRNa+kUOHBic8ekvR+ +MsdVpF+3A5V6WE6DNzxecBP6TF1+l/3B7L1Hz8hsaJ6QTsc6/O011WXG9y23dMpb +ho+JMyy9y3fe791sP87rqWhaFNT5kTnH3JOHK9fxgx0TDP66dde4nvnykRCadEmq +bOGLEar0xmnirAJgO/yrGrQ/A7gmDdhomwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/ +BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZkGA1UdIASBkTCBjjCBiwYKKwYBBAHO +HwMBATB9MFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQAaQBt +AGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4AZwAu +MCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5zay5lZS9DUFMwHQYDVR0OBBYEFNQi +siFrcquz1GPk1pe0bVcUzgEuMB8GA1UdIwQYMBaAFLU0Cp2lLxDF5yEOvsSxZUcb +A3b+MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHBzOi8vd3d3LnNrLmVlL3JlcG9zaXRv +cnkvY3Jscy90ZXN0X2VlY2NyY2EuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8uY6L +qaZKfLx6iKpoAEGxbuFwzrT4BVGqEzpZJNVkM2hhoS9qrttzUrC2hLmfWBbbsScV +GvcWNV7GIcHLYBioZV+ostku/jXXxzhNVhVvX5B8X10uKQDtcrkGbjUpF1JSes8T +9EsUBSIh5MmpNKc1IP8FfvL3qMU2mxU30KQdQy4IjM4Pv7T+MAWMqjrn6txfOZDu +5k6Sak/NBn4cozX0HenY/7301snxAT3BaWhwMKqleCyM7w3wfnFGevEs/4C7qn3S +QncgCEZlvL3lYxSIJ697LyZo0Lsc3s8+gXPT4Q/V8UqjmecgzZWHvyxCrf02iAqU +YRawXmDuuoGMwwlJ +-----END CERTIFICATE----- diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST ESTEID-SK 2011.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST ESTEID-SK 2011.crt index 9ef251e6d..f48bf6d6d 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST ESTEID-SK 2011.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST ESTEID-SK 2011.crt @@ -1,28 +1,28 @@ ------BEGIN CERTIFICATE----- -MIIEuzCCA6OgAwIBAgIQSxRID7FoIaNNdNhBeucLvDANBgkqhkiG9w0BAQUFADB9 -MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 -czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 -IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMwNjA5WhcN -MjMwOTA3MTIwNjA5WjBsMQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlm -aXRzZWVyaW1pc2tlc2t1czEfMB0GA1UEAwwWVEVTVCBvZiBFU1RFSUQtU0sgMjAx -MTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlMIIBIjANBgkqhkiG9w0BAQEFAAOC -AQ8AMIIBCgKCAQEA0SMr+A2QGMJuNpu60MgqKG0yLL7JfvjNtgs2hqWADDn1AQeD -79o+8r4SRYp9kowSFA8E1v38XXTHRq3nSZeToOC5DMAWjsKlm4x8hwwp31BXCs/H -rl9VmikIgAlaHvv3Z+MzS6qeLdzyYi/glPVrY42A6/kBApOJlOVLvAFdySNmFkY+ -Ky7MZ9jbBr+Nx4py/V7xm9VD62Oe1lku4S4qd+VYcQ5jftbr4OFjBp9Nn58/5svQ -xrLjv3B67i19d7sNh7UPnMiO6BeBb6yb3P1lqdHofE1lElStIPViJlzjPOh4puxW -adHDvVYUCJgW2aM58mTfjFhZbVfcrVn5OyIiTQIDAQABo4IBRjCCAUIwDwYDVR0T -AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZkGA1UdIASBkTCBjjCBiwYKKwYB -BAHOHwMBATB9MFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQA -aQBtAGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4A -ZwAuMCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5zay5lZS9DUFMwHQYDVR0OBBYE -FEG2/sWxsbRTE4z6+mLQNG1tIjQKMB8GA1UdIwQYMBaAFLU0Cp2lLxDF5yEOvsSx -ZUcbA3b+MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHBzOi8vd3d3LnNrLmVlL3JlcG9z -aXRvcnkvY3Jscy90ZXN0X2VlY2NyY2EuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBd -h5R23K7qkrO78j51xN6CR2qwxUcK/cgcTLWv0obPmJ7jRax3PX0pFhaUE6EhAR0d -gS4u6XZrjPgVrt/mwq1h8lJP1MF2ueAHKyS0SGj7aFLkcC+ULwu1k6yiortFJ0Ds -49ZGA+ioGzYWPQ+g1Zl4wSDIz52ot0cHUijnf39Szq7E2z7MDfZkYg8HZeHrO493 -EFghXcnSH7J7z47cgP3GWFNUKv1V2c0eVE4OxRulZ3KmBLPWbJKZ0TyGa/Aooc+T -orEjxz//WzcF/Sklp4FeD0MU39UURIlg7LfEcm832bPzZzVGFd4drBd5Dy0Uquu6 -3kW7RDqr+wQFSxKr9DIH ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIIEuzCCA6OgAwIBAgIQSxRID7FoIaNNdNhBeucLvDANBgkqhkiG9w0BAQUFADB9 +MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 +czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 +IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMwNjA5WhcN +MjMwOTA3MTIwNjA5WjBsMQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlm +aXRzZWVyaW1pc2tlc2t1czEfMB0GA1UEAwwWVEVTVCBvZiBFU1RFSUQtU0sgMjAx +MTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVlMIIBIjANBgkqhkiG9w0BAQEFAAOC +AQ8AMIIBCgKCAQEA0SMr+A2QGMJuNpu60MgqKG0yLL7JfvjNtgs2hqWADDn1AQeD +79o+8r4SRYp9kowSFA8E1v38XXTHRq3nSZeToOC5DMAWjsKlm4x8hwwp31BXCs/H +rl9VmikIgAlaHvv3Z+MzS6qeLdzyYi/glPVrY42A6/kBApOJlOVLvAFdySNmFkY+ +Ky7MZ9jbBr+Nx4py/V7xm9VD62Oe1lku4S4qd+VYcQ5jftbr4OFjBp9Nn58/5svQ +xrLjv3B67i19d7sNh7UPnMiO6BeBb6yb3P1lqdHofE1lElStIPViJlzjPOh4puxW +adHDvVYUCJgW2aM58mTfjFhZbVfcrVn5OyIiTQIDAQABo4IBRjCCAUIwDwYDVR0T +AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZkGA1UdIASBkTCBjjCBiwYKKwYB +BAHOHwMBATB9MFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQA +aQBtAGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4A +ZwAuMCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5zay5lZS9DUFMwHQYDVR0OBBYE +FEG2/sWxsbRTE4z6+mLQNG1tIjQKMB8GA1UdIwQYMBaAFLU0Cp2lLxDF5yEOvsSx +ZUcbA3b+MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHBzOi8vd3d3LnNrLmVlL3JlcG9z +aXRvcnkvY3Jscy90ZXN0X2VlY2NyY2EuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBd +h5R23K7qkrO78j51xN6CR2qwxUcK/cgcTLWv0obPmJ7jRax3PX0pFhaUE6EhAR0d +gS4u6XZrjPgVrt/mwq1h8lJP1MF2ueAHKyS0SGj7aFLkcC+ULwu1k6yiortFJ0Ds +49ZGA+ioGzYWPQ+g1Zl4wSDIz52ot0cHUijnf39Szq7E2z7MDfZkYg8HZeHrO493 +EFghXcnSH7J7z47cgP3GWFNUKv1V2c0eVE4OxRulZ3KmBLPWbJKZ0TyGa/Aooc+T +orEjxz//WzcF/Sklp4FeD0MU39UURIlg7LfEcm832bPzZzVGFd4drBd5Dy0Uquu6 +3kW7RDqr+wQFSxKr9DIH +-----END CERTIFICATE----- diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST Juur-SK.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST Juur-SK.crt index c0c6a3059..f4433f556 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST Juur-SK.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST Juur-SK.crt @@ -1,23 +1,23 @@ ------BEGIN CERTIFICATE----- -MIID5TCCAs2gAwIBAgIEO43dLzANBgkqhkiG9w0BAQUFADBiMRgwFgYJKoZIhvcN -AQkBFglwa2lAc2suZWUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKExlBUyBTZXJ0aWZp -dHNlZXJpbWlza2Vza3VzMRUwEwYDVQQDEwxURVNUIEp1dXItU0swHhcNMDEwODMw -MDYyOTA0WhcNMTYwODI3MDUyOTA0WjBiMRgwFgYJKoZIhvcNAQkBFglwa2lAc2su -ZWUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKExlBUyBTZXJ0aWZpdHNlZXJpbWlza2Vz -a3VzMRUwEwYDVQQDEwxURVNUIEp1dXItU0swggEiMA0GCSqGSIb3DQEBAQUAA4IB -DwAwggEKAoIBAQDJIyr2hhDhkZgOJnsFv8VHQJGGK+vld0kGRvpl9Bx81/ZFvEwO -LDfiReuHlTXCOin2FU3f+UJ2TriA+7K4jMCrkXW4oL9vmy99JmZY3esOSzMoAGvJ -XTkSN3/U99LajIzZ718e1kslmxgjVrlmlWI2VR/dPNkZN2KVuT4s9zYHzM3frPsa -DqFd7yMnuqF4YP4yt6DHtqaF+R4vgP/mPRsusoN4NJBiEin6Sm/8me3MS0y8o0qY -fOw+wYgFM2o/XTsu3B7drY/9AoTCVTSp5Lo6xw33yxgVrtKqOSPeV6YBy8lgs8kl -75BaEt+zJ06b/aD8JB81Mtn65Tfq1rMK/HrnAgMBAAGjgaIwgZ8wDwYDVR0TAQH/ -BAUwAwEB/zA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vd3d3LnNrLmVlL2NybHMv -dGVzdC90ZXN0LWp1dXItc2suY3JsMB0GA1UdDgQWBBSBwuAMBRryEG40E0wsjD7c -iCkyeDAfBgNVHSMEGDAWgBSBwuAMBRryEG40E0wsjD7ciCkyeDAOBgNVHQ8BAf8E -BAMCAeYwDQYJKoZIhvcNAQEFBQADggEBAAvvh+xwmeD8wk2Fq0SycwqMXcVw8lFf -osXCIhw/CKpnIzJUrYLyoonNatT7XLt/nmduewUrl3GzKSdTovJA2k1d4srJvU9s -9AEyMJysgD/hwxBYfAThrxMsYV4NwLdQAv5AAgL3NNH/qpFZacDpGonJXH0jLE/M -9r/rHI52nlkLQEfnwx5Abjq+xowzf9o1NiFUhYP8u4Fmie5EvnFnEn9S/X1aPNBU -nH1C2jC3rLqca0qv4fj52w3iYRSwrg30saZA6/VFDXVNV7sCsdWDDQU6AYvonXf0 -mqWg61UrLBc0E0GtCW4vijVXotjpf517Au/9SIhdtDZ3cY+rfsU1sqw= ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIID5TCCAs2gAwIBAgIEO43dLzANBgkqhkiG9w0BAQUFADBiMRgwFgYJKoZIhvcN +AQkBFglwa2lAc2suZWUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKExlBUyBTZXJ0aWZp +dHNlZXJpbWlza2Vza3VzMRUwEwYDVQQDEwxURVNUIEp1dXItU0swHhcNMDEwODMw +MDYyOTA0WhcNMTYwODI3MDUyOTA0WjBiMRgwFgYJKoZIhvcNAQkBFglwa2lAc2su +ZWUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKExlBUyBTZXJ0aWZpdHNlZXJpbWlza2Vz +a3VzMRUwEwYDVQQDEwxURVNUIEp1dXItU0swggEiMA0GCSqGSIb3DQEBAQUAA4IB +DwAwggEKAoIBAQDJIyr2hhDhkZgOJnsFv8VHQJGGK+vld0kGRvpl9Bx81/ZFvEwO +LDfiReuHlTXCOin2FU3f+UJ2TriA+7K4jMCrkXW4oL9vmy99JmZY3esOSzMoAGvJ +XTkSN3/U99LajIzZ718e1kslmxgjVrlmlWI2VR/dPNkZN2KVuT4s9zYHzM3frPsa +DqFd7yMnuqF4YP4yt6DHtqaF+R4vgP/mPRsusoN4NJBiEin6Sm/8me3MS0y8o0qY +fOw+wYgFM2o/XTsu3B7drY/9AoTCVTSp5Lo6xw33yxgVrtKqOSPeV6YBy8lgs8kl +75BaEt+zJ06b/aD8JB81Mtn65Tfq1rMK/HrnAgMBAAGjgaIwgZ8wDwYDVR0TAQH/ +BAUwAwEB/zA8BgNVHR8ENTAzMDGgL6AthitodHRwOi8vd3d3LnNrLmVlL2NybHMv +dGVzdC90ZXN0LWp1dXItc2suY3JsMB0GA1UdDgQWBBSBwuAMBRryEG40E0wsjD7c +iCkyeDAfBgNVHSMEGDAWgBSBwuAMBRryEG40E0wsjD7ciCkyeDAOBgNVHQ8BAf8E +BAMCAeYwDQYJKoZIhvcNAQEFBQADggEBAAvvh+xwmeD8wk2Fq0SycwqMXcVw8lFf +osXCIhw/CKpnIzJUrYLyoonNatT7XLt/nmduewUrl3GzKSdTovJA2k1d4srJvU9s +9AEyMJysgD/hwxBYfAThrxMsYV4NwLdQAv5AAgL3NNH/qpFZacDpGonJXH0jLE/M +9r/rHI52nlkLQEfnwx5Abjq+xowzf9o1NiFUhYP8u4Fmie5EvnFnEn9S/X1aPNBU +nH1C2jC3rLqca0qv4fj52w3iYRSwrg30saZA6/VFDXVNV7sCsdWDDQU6AYvonXf0 +mqWg61UrLBc0E0GtCW4vijVXotjpf517Au/9SIhdtDZ3cY+rfsU1sqw= +-----END CERTIFICATE----- diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST KLASS3 2010.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST KLASS3 2010.crt index 19fd37385..f3a1b6af6 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST KLASS3 2010.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST KLASS3 2010.crt @@ -1,28 +1,28 @@ ------BEGIN CERTIFICATE----- -MIIExzCCA6+gAwIBAgIQIrzOHDuBOQRPabRVIaWqEzANBgkqhkiG9w0BAQUFADB9 -MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 -czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 -IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTIwMzIxMTA1ODI5WhcN -MjUwMzIxMTA1ODI5WjB1MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlm -aXRzZWVyaW1pc2tlc2t1czEhMB8GA1UECwwYU2VydGlmaXRzZWVyaW1pc3RlZW51 -c2VkMR8wHQYDVQQDDBZURVNUIG9mIEtMQVNTMy1TSyAyMDEwMIIBIjANBgkqhkiG -9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7Ua/6IAAqXvy2COvRLW9yCSeImQ23XRAzf/x -HmJ6fYiSs0LaR8c19IOSOkOarAgUrt0XDG5KWBdE5qwuVc0gQN9ZjYwmDg3dq4LV -o89FdvATKk2Tao01Iu1N+2eGSEifgGBH5iWfYqu1hGJ2nJPHIG9bKXZXfw+ET2gy -mO5bHnt8iOJmq+YynMXEvxtUTl2hKh0o6m28i3YKXru0jm5qe5/YCJ9HFw9yKn8e -LnI2/9Jfruxe5F1AMOkVXhVtA57yeQARv18a8uEQZV0CS/WDmCPi+hl6GqSwhWZB -dB9igOMsnZdNS1s7kr2/46doZQVPa2X3vJyYMTl/oaWB++VfAQIDAQABo4IBSTCC -AUUwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAcYwgZkGA1UdIASB -kTCBjjCBiwYKKwYBBAHOHwMBATB9MCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5z -ay5lZS9jcHMwWAYIKwYBBQUHAgIwTB5KAEEAaQBuAHUAbAB0ACAAdABlAHMAdABp -AG0AaQBzAGUAawBzAC4AIABPAG4AbAB5ACAAZgBvAHIAIAB0AGUAcwB0AGkAbgBn -AC4wHQYDVR0OBBYEFNFoQ5JN1Wc5Ii9tzYgGEg662Wp2MB8GA1UdIwQYMBaAFLU0 -Cp2lLxDF5yEOvsSxZUcbA3b+MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHBzOi8vd3d3 -LnNrLmVlL3JlcG9zaXRvcnkvY3Jscy90ZXN0X2VlY2NyY2EuY3JsMA0GCSqGSIb3 -DQEBBQUAA4IBAQCiE8G8gwZpeeHm0PoqHd54/KbfH2cAklqO5rcg2m9fhhvPNtMQ -9Wc19JWauE2YuNsnJNKetglUAnA/yd64DhQKBf+2JUgYJas4dTscRgXXlz8huuve -nNUpfPd3iispVc2WNBQ2qjBEZXdqhbkG0/RgM42Hb28+1v23HsoLhCGY2YjHhYyn -mOk/8BULI/ArsgA7FJflXi5Xp/cdC8BJQ87vtPlAnxm0axZMvASNXMUvvQTUjCTg -0yczX3d8+I3EBNBlzfPMsyU1LCn6Opbs2/DGF/4enhRGk/49L6ltfOyOA73buSog -S2JkvCweSx6Y2cs1fXVyFszm2HJmQgwbZYfR ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIIExzCCA6+gAwIBAgIQIrzOHDuBOQRPabRVIaWqEzANBgkqhkiG9w0BAQUFADB9 +MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 +czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 +IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTIwMzIxMTA1ODI5WhcN +MjUwMzIxMTA1ODI5WjB1MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlm +aXRzZWVyaW1pc2tlc2t1czEhMB8GA1UECwwYU2VydGlmaXRzZWVyaW1pc3RlZW51 +c2VkMR8wHQYDVQQDDBZURVNUIG9mIEtMQVNTMy1TSyAyMDEwMIIBIjANBgkqhkiG +9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7Ua/6IAAqXvy2COvRLW9yCSeImQ23XRAzf/x +HmJ6fYiSs0LaR8c19IOSOkOarAgUrt0XDG5KWBdE5qwuVc0gQN9ZjYwmDg3dq4LV +o89FdvATKk2Tao01Iu1N+2eGSEifgGBH5iWfYqu1hGJ2nJPHIG9bKXZXfw+ET2gy +mO5bHnt8iOJmq+YynMXEvxtUTl2hKh0o6m28i3YKXru0jm5qe5/YCJ9HFw9yKn8e +LnI2/9Jfruxe5F1AMOkVXhVtA57yeQARv18a8uEQZV0CS/WDmCPi+hl6GqSwhWZB +dB9igOMsnZdNS1s7kr2/46doZQVPa2X3vJyYMTl/oaWB++VfAQIDAQABo4IBSTCC +AUUwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAcYwgZkGA1UdIASB +kTCBjjCBiwYKKwYBBAHOHwMBATB9MCEGCCsGAQUFBwIBFhVodHRwczovL3d3dy5z +ay5lZS9jcHMwWAYIKwYBBQUHAgIwTB5KAEEAaQBuAHUAbAB0ACAAdABlAHMAdABp +AG0AaQBzAGUAawBzAC4AIABPAG4AbAB5ACAAZgBvAHIAIAB0AGUAcwB0AGkAbgBn +AC4wHQYDVR0OBBYEFNFoQ5JN1Wc5Ii9tzYgGEg662Wp2MB8GA1UdIwQYMBaAFLU0 +Cp2lLxDF5yEOvsSxZUcbA3b+MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHBzOi8vd3d3 +LnNrLmVlL3JlcG9zaXRvcnkvY3Jscy90ZXN0X2VlY2NyY2EuY3JsMA0GCSqGSIb3 +DQEBBQUAA4IBAQCiE8G8gwZpeeHm0PoqHd54/KbfH2cAklqO5rcg2m9fhhvPNtMQ +9Wc19JWauE2YuNsnJNKetglUAnA/yd64DhQKBf+2JUgYJas4dTscRgXXlz8huuve +nNUpfPd3iispVc2WNBQ2qjBEZXdqhbkG0/RgM42Hb28+1v23HsoLhCGY2YjHhYyn +mOk/8BULI/ArsgA7FJflXi5Xp/cdC8BJQ87vtPlAnxm0axZMvASNXMUvvQTUjCTg +0yczX3d8+I3EBNBlzfPMsyU1LCn6Opbs2/DGF/4enhRGk/49L6ltfOyOA73buSog +S2JkvCweSx6Y2cs1fXVyFszm2HJmQgwbZYfR +-----END CERTIFICATE----- diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST SK OCSP 2011.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST SK OCSP 2011.crt index 8aef6b5f6..d9b6863da 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST SK OCSP 2011.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST SK OCSP 2011.crt @@ -1,27 +1,27 @@ ------BEGIN CERTIFICATE----- -MIIEijCCA3KgAwIBAgIQaI8x6BnacYdNdNwlYnn/mzANBgkqhkiG9w0BAQUFADB9 -MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 -czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 -IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMyMjQ1WhcN -MjQwOTA3MTIyMjQ1WjCBgzELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRp -Zml0c2VlcmltaXNrZXNrdXMxDTALBgNVBAsMBE9DU1AxJzAlBgNVBAMMHlRFU1Qg -b2YgU0sgT0NTUCBSRVNQT05ERVIgMjAxMTEYMBYGCSqGSIb3DQEJARYJcGtpQHNr -LmVlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0cw6Cja17BbYbHi6 -frwccDI4BIQLk/fiCE8L45os0xhPgEGR+EHE8LPCIqofPgf4gwN1vDE6cQNUlK0O -d+Ush39i9Z45esnfpGq+2HsDJaFmFr5+uC1MEz5Kn1TazEvKbRjkGnSQ9BertlGe -r2BlU/kqOk5qA5RtJfhT0psc1ixKdPipv59wnf+nHx1+T+fPWndXVZLoDg4t3w8l -IvIE/KhOSMlErvBIHIAKV7yH1hOxyeGLghqzMiAn3UeTEOgoOS9URv0C/T5C3mH+ -Y/uakMSxjNuz41PneimCzbEJZJRiEaMIj8qPAubcbL8GtY03MWmfNtX6/wh6u6TM -fW8S2wIDAQABo4H+MIH7MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMJMB0GA1UdDgQW -BBR9/5CuRokEgGiqSzYuZGYAogl8TzCBoAYDVR0gBIGYMIGVMIGSBgorBgEEAc4f -AwEBMIGDMFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQAaQBt -AGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4AZwAu -MCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LnNrLmVlL2FqYXRlbXBlbC8wHwYDVR0j -BBgwFoAUtTQKnaUvEMXnIQ6+xLFlRxsDdv4wDQYJKoZIhvcNAQEFBQADggEBAAba -j7kTruTAPHqToye9ZtBdaJ3FZjiKug9/5RjsMwDpOeqFDqCorLd+DBI4tgdu0g4l -haI3aVnKdRBkGV18kqp84uU97JRFWQEf6H8hpJ9k/LzAACkP3tD+0ym+md532mV+ -nRz1Jj+RPLAUk9xYMV7KPczZN1xnl2wZDJwBbQpcSVH1DjlZv3tFLHBLIYTS6qOK -4SxStcgRq7KdRczfW6mfXzTCRWM3G9nmDei5Q3+XTED41j8szRWglzYf6zOv4djk -ja64WYraQ5zb4x8Xh7qTCk6UupZ7je+0oRfuz0h/3zyRdjcRPkjloSpQp/NG8Rmr -cnr874p8d9fdwCrRI7U= ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIIEijCCA3KgAwIBAgIQaI8x6BnacYdNdNwlYnn/mzANBgkqhkiG9w0BAQUFADB9 +MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1 +czEwMC4GA1UEAwwnVEVTVCBvZiBFRSBDZXJ0aWZpY2F0aW9uIENlbnRyZSBSb290 +IENBMRgwFgYJKoZIhvcNAQkBFglwa2lAc2suZWUwHhcNMTEwMzA3MTMyMjQ1WhcN +MjQwOTA3MTIyMjQ1WjCBgzELMAkGA1UEBhMCRUUxIjAgBgNVBAoMGUFTIFNlcnRp +Zml0c2VlcmltaXNrZXNrdXMxDTALBgNVBAsMBE9DU1AxJzAlBgNVBAMMHlRFU1Qg +b2YgU0sgT0NTUCBSRVNQT05ERVIgMjAxMTEYMBYGCSqGSIb3DQEJARYJcGtpQHNr +LmVlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0cw6Cja17BbYbHi6 +frwccDI4BIQLk/fiCE8L45os0xhPgEGR+EHE8LPCIqofPgf4gwN1vDE6cQNUlK0O +d+Ush39i9Z45esnfpGq+2HsDJaFmFr5+uC1MEz5Kn1TazEvKbRjkGnSQ9BertlGe +r2BlU/kqOk5qA5RtJfhT0psc1ixKdPipv59wnf+nHx1+T+fPWndXVZLoDg4t3w8l +IvIE/KhOSMlErvBIHIAKV7yH1hOxyeGLghqzMiAn3UeTEOgoOS9URv0C/T5C3mH+ +Y/uakMSxjNuz41PneimCzbEJZJRiEaMIj8qPAubcbL8GtY03MWmfNtX6/wh6u6TM +fW8S2wIDAQABo4H+MIH7MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMJMB0GA1UdDgQW +BBR9/5CuRokEgGiqSzYuZGYAogl8TzCBoAYDVR0gBIGYMIGVMIGSBgorBgEEAc4f +AwEBMIGDMFgGCCsGAQUFBwICMEweSgBBAGkAbgB1AGwAdAAgAHQAZQBzAHQAaQBt +AGkAcwBlAGsAcwAuACAATwBuAGwAeQAgAGYAbwByACAAdABlAHMAdABpAG4AZwAu +MCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LnNrLmVlL2FqYXRlbXBlbC8wHwYDVR0j +BBgwFoAUtTQKnaUvEMXnIQ6+xLFlRxsDdv4wDQYJKoZIhvcNAQEFBQADggEBAAba +j7kTruTAPHqToye9ZtBdaJ3FZjiKug9/5RjsMwDpOeqFDqCorLd+DBI4tgdu0g4l +haI3aVnKdRBkGV18kqp84uU97JRFWQEf6H8hpJ9k/LzAACkP3tD+0ym+md532mV+ +nRz1Jj+RPLAUk9xYMV7KPczZN1xnl2wZDJwBbQpcSVH1DjlZv3tFLHBLIYTS6qOK +4SxStcgRq7KdRczfW6mfXzTCRWM3G9nmDei5Q3+XTED41j8szRWglzYf6zOv4djk +ja64WYraQ5zb4x8Xh7qTCk6UupZ7je+0oRfuz0h/3zyRdjcRPkjloSpQp/NG8Rmr +cnr874p8d9fdwCrRI7U= +-----END CERTIFICATE----- diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK OCSP 2005.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK OCSP 2005.crt index 9f5266e0d..3c8aac7ef 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK OCSP 2005.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK OCSP 2005.crt @@ -1,17 +1,17 @@ ------BEGIN CERTIFICATE----- -MIIDKDCCAhCgAwIBAgIEQi1s4zANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJFRTEiMCAGA1UE -ChMZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEaMBgGA1UECxMRVGVzdHNlcnRpZmlrYWFkaWQx -EDAOBgNVBAMTB1RFU1QtU0swHhcNMDUwMzA4MDkxNDEwWhcNMTIwNDA2MjEwMDAwWjB4MQswCQYD -VQQGEwJFRTEaMBgGA1UECgwRVGVzdHNlcnRpZmlrYWFkaWQxDTALBgNVBAsMBE9DU1AxJDAiBgNV -BAMMG1RFU1QtU0sgT0NTUCBSRVNQT05ERVIgMjAwNTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVl -MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2RdrY11V9ekC7Injanf4RshjWp6jf51tGOvzE -cbG2Tmyo66H7AR6hauoUygIYrbEjAVXhIznnffngJtrG69I+6cGgCNHguPlpdyAwexUPi36cfJw2 -FKv9bbxyIqtxo+1uZ1XZWgcua6OXMLh0T0aZWglJ1OiAlZys6hxbOg1G8wIDAQABo1cwVTATBgNV -HSUEDDAKBggrBgEFBQcDCTAfBgNVHSMEGDAWgBQCBSfdqHKHt4LAWzkqf+M48vpSCTAdBgNVHQ4E -FgQUK9Rcl4ROS8UmFo8JH8ep5oRSJFgwDQYJKoZIhvcNAQEFBQADggEBAHZd/Bqzc7FsC05Hq8Zh -PxK4lJVMwuC+mO843jsX8cWaGMBOYWqD96gFduMjiIXVIWFpiZ1o6q+JuRbPTRhpzRvv0Yc9oMaq -j7sBhYr8mqcu0FOOMD8wlJzqFr9TZZ58ba9e/UDZPDUYvEfWEuW6giwSkPLuu0Jbz94QqmG0ErG8 -8h6B14Nge7P1pR4hZfvm4I2PX8sX619OdHRf7kxS+ZXve5BHGHX5YXSPreRAvriJc/cgRFokcPyt -v7y+tebcqB+1/Dj7o2brNr+dKxIL5IseBeQD4lJ5UtvuPE7pZexUSt2EOcDAAMtHsUB30cIVwPw8 -/CwfT9FBP9H3tUUCtOQ= ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIIDKDCCAhCgAwIBAgIEQi1s4zANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJFRTEiMCAGA1UE +ChMZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1czEaMBgGA1UECxMRVGVzdHNlcnRpZmlrYWFkaWQx +EDAOBgNVBAMTB1RFU1QtU0swHhcNMDUwMzA4MDkxNDEwWhcNMTIwNDA2MjEwMDAwWjB4MQswCQYD +VQQGEwJFRTEaMBgGA1UECgwRVGVzdHNlcnRpZmlrYWFkaWQxDTALBgNVBAsMBE9DU1AxJDAiBgNV +BAMMG1RFU1QtU0sgT0NTUCBSRVNQT05ERVIgMjAwNTEYMBYGCSqGSIb3DQEJARYJcGtpQHNrLmVl +MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2RdrY11V9ekC7Injanf4RshjWp6jf51tGOvzE +cbG2Tmyo66H7AR6hauoUygIYrbEjAVXhIznnffngJtrG69I+6cGgCNHguPlpdyAwexUPi36cfJw2 +FKv9bbxyIqtxo+1uZ1XZWgcua6OXMLh0T0aZWglJ1OiAlZys6hxbOg1G8wIDAQABo1cwVTATBgNV +HSUEDDAKBggrBgEFBQcDCTAfBgNVHSMEGDAWgBQCBSfdqHKHt4LAWzkqf+M48vpSCTAdBgNVHQ4E +FgQUK9Rcl4ROS8UmFo8JH8ep5oRSJFgwDQYJKoZIhvcNAQEFBQADggEBAHZd/Bqzc7FsC05Hq8Zh +PxK4lJVMwuC+mO843jsX8cWaGMBOYWqD96gFduMjiIXVIWFpiZ1o6q+JuRbPTRhpzRvv0Yc9oMaq +j7sBhYr8mqcu0FOOMD8wlJzqFr9TZZ58ba9e/UDZPDUYvEfWEuW6giwSkPLuu0Jbz94QqmG0ErG8 +8h6B14Nge7P1pR4hZfvm4I2PX8sX619OdHRf7kxS+ZXve5BHGHX5YXSPreRAvriJc/cgRFokcPyt +v7y+tebcqB+1/Dj7o2brNr+dKxIL5IseBeQD4lJ5UtvuPE7pZexUSt2EOcDAAMtHsUB30cIVwPw8 +/CwfT9FBP9H3tUUCtOQ= +-----END CERTIFICATE----- diff --git a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK.crt b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK.crt index 75c525148..8bd84b132 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK.crt +++ b/validation-services-parent/timemark-container-validation-service/src/main/resources/test-certs/TEST-SK.crt @@ -1,29 +1,29 @@ ------BEGIN CERTIFICATE----- -MIIFDDCCA/SgAwIBAgIEPLQlGTANBgkqhkiG9w0BAQUFADBdMRgwFgYJKoZIhvcN -AQkBFglwa2lAc2suZWUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKExlBUyBTZXJ0aWZp -dHNlZXJpbWlza2Vza3VzMRAwDgYDVQQDEwdKdXVyLVNLMB4XDTAyMDQxMDExNDIx -N1oXDTEyMDQwNzExNDIxN1owXzELMAkGA1UEBhMCRUUxIjAgBgNVBAoTGUFTIFNl -cnRpZml0c2VlcmltaXNrZXNrdXMxGjAYBgNVBAsTEVRlc3RzZXJ0aWZpa2FhZGlk -MRAwDgYDVQQDEwdURVNULVNLMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC -AQEAqRBRliE/OtzE35NjaEVEWYj+NAEgBHMquQqJURZCtPJnSe7mrjt56/b/GnNd -fywiT6xV2++ZFbe710bEftcDNo2CiFnrsFAfOAcnzzhqiTLNp1/pibfhWyiKUyEt -Tyi9UVisNZTsynbev2k3bzGzaOCDxzL9Cq/8mGjspufoX2AYIfbS0NZ44DmyUy0b -hUnOyhN6BzirAdA8UXizLQ7xcjCzNjG7eyn/EiMViWI81XNk8QNn4ZZw5X8qWZny -Wml3Or43wm1W1IhDC/gFWlWwRQAZiM036rOViyleaK7y2XL2a/jcQHUyyvjGnLVB -J2DXevsfpPEz9fXSB8rXBYhDRQIDAQABo4IB0DCCAcwwDAYDVR0TBAUwAwEB/zAO -BgNVHQ8BAf8EBAMCAf4wJQYIKwYBBQUHAQEEGTAXMBUGCCsGAQUFBzACgQlwa2lA -c2suZWUwKwYDVR0fBCQwIjAgoB6gHIYaaHR0cDovL3d3dy5zay5lZS9qdXVyL2Ny -bC8wggEWBgNVHSAEggENMIIBCTCCAQUGCisGAQQBzh8BAQEwgfYwgdAGCCsGAQUF -BwICMIHDHoHAAFMAZQBlACAAcwBlAHIAdABpAGYAaQBrAGEAYQB0ACAAbwBuACAA -dgDkAGwAagBhAHMAdABhAHQAdQBkACAAQQBTAC0AaQBzACAAUwBlAHIAdABpAGYA -aQB0AHMAZQBlAHIAaQBtAGkAcwBrAGUAcwBrAHUAcwAgAGEAbABhAG0ALQBTAEsA -IABzAGUAcgB0AGkAZgBpAGsAYQBhAHQAaQBkAGUAIABrAGkAbgBuAGkAdABhAG0A -aQBzAGUAawBzMCEGCCsGAQUFBwIBFhVodHRwOi8vd3d3LnNrLmVlL2Nwcy8wHwYD -VR0jBBgwFoAUBKp6R6Pkia8azwpApxg/b+/pfb4wHQYDVR0OBBYEFAIFJ92ocoe3 -gsBbOSp/4zjy+lIJMA0GCSqGSIb3DQEBBQUAA4IBAQB3J6VyP1vBjbW3jvUVk53a -2CyGLIobRSO4Voom+AaWyNJ32Q1LM2qpJkLEwC2/9Akp8t4A/iCRLcVhJWnDWPRG -Dm3YAuDEktvcU6DMSBiEw3iA7s/9Hq3QzRLLPNLT1LCE2dkzg5Y1J33pkrq3fFUy -nS9VWRwnujOhBC+njEnb3cD+sgCSphEBvRVMuqDQXGFJxuFbTZ7ydr2diOucJG1n -uxjwnDR2iigE3pucGjX0EH6P/8itFtL41mRniT9SesDb2v5mt5y/yrdJNrEGtV+s -LAr5QPBjoqvoY5L9H966SmbXiGjX5zqWHM4pYZAQ6dKbf4Dviqa1oKbcQx6ERCHA ------END CERTIFICATE----- +-----BEGIN CERTIFICATE----- +MIIFDDCCA/SgAwIBAgIEPLQlGTANBgkqhkiG9w0BAQUFADBdMRgwFgYJKoZIhvcN +AQkBFglwa2lAc2suZWUxCzAJBgNVBAYTAkVFMSIwIAYDVQQKExlBUyBTZXJ0aWZp +dHNlZXJpbWlza2Vza3VzMRAwDgYDVQQDEwdKdXVyLVNLMB4XDTAyMDQxMDExNDIx +N1oXDTEyMDQwNzExNDIxN1owXzELMAkGA1UEBhMCRUUxIjAgBgNVBAoTGUFTIFNl +cnRpZml0c2VlcmltaXNrZXNrdXMxGjAYBgNVBAsTEVRlc3RzZXJ0aWZpa2FhZGlk +MRAwDgYDVQQDEwdURVNULVNLMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC +AQEAqRBRliE/OtzE35NjaEVEWYj+NAEgBHMquQqJURZCtPJnSe7mrjt56/b/GnNd +fywiT6xV2++ZFbe710bEftcDNo2CiFnrsFAfOAcnzzhqiTLNp1/pibfhWyiKUyEt +Tyi9UVisNZTsynbev2k3bzGzaOCDxzL9Cq/8mGjspufoX2AYIfbS0NZ44DmyUy0b +hUnOyhN6BzirAdA8UXizLQ7xcjCzNjG7eyn/EiMViWI81XNk8QNn4ZZw5X8qWZny +Wml3Or43wm1W1IhDC/gFWlWwRQAZiM036rOViyleaK7y2XL2a/jcQHUyyvjGnLVB +J2DXevsfpPEz9fXSB8rXBYhDRQIDAQABo4IB0DCCAcwwDAYDVR0TBAUwAwEB/zAO +BgNVHQ8BAf8EBAMCAf4wJQYIKwYBBQUHAQEEGTAXMBUGCCsGAQUFBzACgQlwa2lA +c2suZWUwKwYDVR0fBCQwIjAgoB6gHIYaaHR0cDovL3d3dy5zay5lZS9qdXVyL2Ny +bC8wggEWBgNVHSAEggENMIIBCTCCAQUGCisGAQQBzh8BAQEwgfYwgdAGCCsGAQUF +BwICMIHDHoHAAFMAZQBlACAAcwBlAHIAdABpAGYAaQBrAGEAYQB0ACAAbwBuACAA +dgDkAGwAagBhAHMAdABhAHQAdQBkACAAQQBTAC0AaQBzACAAUwBlAHIAdABpAGYA +aQB0AHMAZQBlAHIAaQBtAGkAcwBrAGUAcwBrAHUAcwAgAGEAbABhAG0ALQBTAEsA +IABzAGUAcgB0AGkAZgBpAGsAYQBhAHQAaQBkAGUAIABrAGkAbgBuAGkAdABhAG0A +aQBzAGUAawBzMCEGCCsGAQUFBwIBFhVodHRwOi8vd3d3LnNrLmVlL2Nwcy8wHwYD +VR0jBBgwFoAUBKp6R6Pkia8azwpApxg/b+/pfb4wHQYDVR0OBBYEFAIFJ92ocoe3 +gsBbOSp/4zjy+lIJMA0GCSqGSIb3DQEBBQUAA4IBAQB3J6VyP1vBjbW3jvUVk53a +2CyGLIobRSO4Voom+AaWyNJ32Q1LM2qpJkLEwC2/9Akp8t4A/iCRLcVhJWnDWPRG +Dm3YAuDEktvcU6DMSBiEw3iA7s/9Hq3QzRLLPNLT1LCE2dkzg5Y1J33pkrq3fFUy +nS9VWRwnujOhBC+njEnb3cD+sgCSphEBvRVMuqDQXGFJxuFbTZ7ydr2diOucJG1n +uxjwnDR2iigE3pucGjX0EH6P/8itFtL41mRniT9SesDb2v5mt5y/yrdJNrEGtV+s +LAr5QPBjoqvoY5L9H966SmbXiGjX5zqWHM4pYZAQ6dKbf4Dviqa1oKbcQx6ERCHA +-----END CERTIFICATE----- diff --git a/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/constant/AsicContainerConstants.java b/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/constant/AsicContainerConstants.java index 3a2080395..42eb8b43e 100644 --- a/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/constant/AsicContainerConstants.java +++ b/validation-services-parent/validation-commons/src/main/java/ee/openeid/siva/validation/constant/AsicContainerConstants.java @@ -1,26 +1,26 @@ -/* - * Copyright 2023 - 2025 Riigi Infosüsteemi Amet - * - * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by - * the European Commission - subsequent versions of the EUPL (the "Licence"); - * You may not use this work except in compliance with the Licence. - * You may obtain a copy of the Licence at: - * - * https://joinup.ec.europa.eu/software/page/eupl - * - * Unless required by applicable law or agreed to in writing, software distributed under the Licence is - * distributed on an "AS IS" basis, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the Licence for the specific language governing permissions and limitations under the Licence. - */ - -package ee.openeid.siva.validation.constant; - -import lombok.AccessLevel; -import lombok.NoArgsConstructor; - -@NoArgsConstructor(access = AccessLevel.PRIVATE) -public final class AsicContainerConstants { - public static final String ASICS_MIME_TYPE = "application/vnd.etsi.asic-s+zip"; - public static final String ASICE_MIME_TYPE = "application/vnd.etsi.asic-e+zip"; -} +/* + * Copyright 2023 - 2025 Riigi Infosüsteemi Amet + * + * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by + * the European Commission - subsequent versions of the EUPL (the "Licence"); + * You may not use this work except in compliance with the Licence. + * You may obtain a copy of the Licence at: + * + * https://joinup.ec.europa.eu/software/page/eupl + * + * Unless required by applicable law or agreed to in writing, software distributed under the Licence is + * distributed on an "AS IS" basis, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the Licence for the specific language governing permissions and limitations under the Licence. + */ + +package ee.openeid.siva.validation.constant; + +import lombok.AccessLevel; +import lombok.NoArgsConstructor; + +@NoArgsConstructor(access = AccessLevel.PRIVATE) +public final class AsicContainerConstants { + public static final String ASICS_MIME_TYPE = "application/vnd.etsi.asic-s+zip"; + public static final String ASICE_MIME_TYPE = "application/vnd.etsi.asic-e+zip"; +} From a53f0afd88226a34b6bfeaf74276c63ee91f3556 Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 10:38:17 +0300 Subject: [PATCH 03/11] Normalize line endings --- docs/siva2/appendix/known_issues.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/docs/siva2/appendix/known_issues.md b/docs/siva2/appendix/known_issues.md index fac0a7411..9ab52efc2 100644 --- a/docs/siva2/appendix/known_issues.md +++ b/docs/siva2/appendix/known_issues.md @@ -1,4 +1 @@ - - -## Known issues - All known issues should be reported and managed under GitHub project [issues section](https://github.com/open-eid/SiVa/issues) \ No newline at end of file + ## Known issues All known issues should be reported and managed under GitHub project [issues section](https://github.com/open-eid/SiVa/issues) \ No newline at end of file From 307ea3dd2d3ffcc240b4ccaad798c058f4891585 Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 10:39:09 +0300 Subject: [PATCH 04/11] Normalize line endings --- docs/siva2/appendix/known_issues.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/siva2/appendix/known_issues.md b/docs/siva2/appendix/known_issues.md index 9ab52efc2..fac0a7411 100644 --- a/docs/siva2/appendix/known_issues.md +++ b/docs/siva2/appendix/known_issues.md @@ -1 +1,4 @@ - ## Known issues All known issues should be reported and managed under GitHub project [issues section](https://github.com/open-eid/SiVa/issues) \ No newline at end of file + + +## Known issues + All known issues should be reported and managed under GitHub project [issues section](https://github.com/open-eid/SiVa/issues) \ No newline at end of file From 50d335fd7dc16492ae078c216e83e202375ef9be Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 10:41:40 +0300 Subject: [PATCH 05/11] Normalize line endings --- docs/siva2/appendix/known_issues.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/siva2/appendix/known_issues.md b/docs/siva2/appendix/known_issues.md index fac0a7411..3fcd1b2b4 100644 --- a/docs/siva2/appendix/known_issues.md +++ b/docs/siva2/appendix/known_issues.md @@ -1,4 +1,4 @@ - - -## Known issues + + +## Known issues All known issues should be reported and managed under GitHub project [issues section](https://github.com/open-eid/SiVa/issues) \ No newline at end of file From 7c421cfc213b80169bdeaa0fa5b1d43b89afe76a Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 10:46:29 +0300 Subject: [PATCH 06/11] Revert unintended changes in documentation files --- docs/siva/appendix/validation_policy.md | 372 ++--- docs/siva/v2/systemintegrators_guide.md | 1100 +++++++------- docs/siva2/appendix/validation_policy.md | 422 +++--- docs/siva2/component_diagram.md | 188 +-- docs/siva2/definitions.md | 84 +- docs/siva2/deployment.md | 40 +- docs/siva2/deployment_view.md | 68 +- docs/siva2/interfaces.md | 1658 +++++++++++----------- docs/siva2/logging.md | 186 +-- docs/siva2/overview.md | 108 +- docs/siva2/qa_strategy.md | 310 ++-- docs/siva2/references.md | 16 +- docs/siva2/systemintegrators_guide.md | 1174 +++++++-------- 13 files changed, 2863 insertions(+), 2863 deletions(-) diff --git a/docs/siva/appendix/validation_policy.md b/docs/siva/appendix/validation_policy.md index 46cbd2c27..b139e1e60 100644 --- a/docs/siva/appendix/validation_policy.md +++ b/docs/siva/appendix/validation_policy.md @@ -1,186 +1,186 @@ -# SiVa Signature Validation Policy - -## Introduction -This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). - -### Versioning - -Different policy versions may be used by the service in the following conditions: - -* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; -* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); -* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. -* for later reference, previous versions of validation policy documents should remain available for the Service's users. - -The following validation policy versions are supported in SiVa service: - -1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](validation_policy/#POLv1) -2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](validation_policy/#POLv2) - -### General principles of SiVa validation policies - -1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. -* All rules described for electronic signatures also apply for electronic seals and digital stamps. -* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: - * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). - * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). - -!!! note - When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. - - -## SiVA Signature Validation Policy - Version 1 (POLv1) - - -### Description -Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -``` - -### POLv1 validation constraints -1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: - * Qualified Certificate (QC) requirement - * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * Signer certificate may or may not comply with SSCD/QSCD criteria. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. -* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section - - -## SiVA Signature Validation Policy - Version 2 (POLv2) - - -### Description -Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -``` - -### POLv2 validation constraints - -1. The signature must be a Qualified Electronic Signature (QES), taking account of the following requirements: - * Qualified Certificate (QC) requirement - * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. - * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * Signer certificate must comply with SSCD/QSCD criteria. - * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. - * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: - * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). -* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section - - -## Common validation constraints (POLv1, POLv2) - - -### General constraints - -1. The validation result returned by SiVa determines whether a signature is technically valid and also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** -2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. - -### Signature format constraints - - -1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: - - * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures - * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures - * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures - * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures - * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) - -### Base libraries' constraints - -1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: - - * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. - * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate ASiC-E/XAdES signatures that conform with BDOC 2.1 digital signature format - * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate PAdES signatures - * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. - -### Baseline Profile constraints -1. The signature must comply with Baseline Profile of the respective signature format: - * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) - * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) -2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. -3. The following table describes supported Baseline Profile levels, according to signature formats: - -| Signature format | BASELINE_B_BES | BASELINE_B_EPES | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | -|--|--|--|--|--|--|--| -|**BDOC** | NOK | NOK | NOK| **OK** | **OK** | **OK** | -|**X-Road signature (simple form)** | NOK | NOK | NOK | **OK** | NOK | NOK | -|**X-Road signature (batch signature)** | **OK** | **OK** | NOK | NOK | NOK | NOK | -|**PAdES** | NOK | NOK | NOK | **OK** | NOK | **OK** | -|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | NOK | **OK** | NOK | -|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | NOK | **OK** | NOK | - -Legend: - -* OK - the respective Baseline Profile level is supported and acceptable. -* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. - - -### X.509 validation constraints - -1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). - - -### Cryptographic algorithm constraints -1. Hash algorithm constraints: - * In case of BDOC and PAdES formats: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. -* Asymmetric cryptographic algorithm contraints: - * RSA and ECC cryptographic algorithms are supported - * In case of BDOC and PAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. - -### Trust anchor constraints -1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. -* Trust Anchors are: - * In case of BDOC, PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). - * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. - * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. - - -### Revocation data constraints -1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. -* The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960). -* No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. -* Checking revocation of certificates regarded as Trust Anchors: - * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. - * In case of BDOC, PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. - - -### Signer certificate's revocation freshness constraints -1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. -* In case of BDOC 2.1 BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: - * The revocation data must be issued after the signature time-stamp production time. - * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 15 minutes then a validation warning is returned. - * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. -* In case of PAdES signatures, the default DSS base library's revocation freshness check is used. - - -### Trusted signing time constraints -1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: - * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. - * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. - * In case of basic signature (BASELINE_B_BES or BASELINE_B_EPES level) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. - - -### BDOC/ASiC-E container spceific requirements -1. File extension - * ".asice", ".sce" and ".bdoc" file extensions are supported during signature validation. -* Only one signature shall be stored in one signatures.xml file. -* All signatures in the container must sign all of the data files. -* All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. -* Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. -* Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". -* "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). - - +# SiVa Signature Validation Policy + +## Introduction +This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). + +### Versioning + +Different policy versions may be used by the service in the following conditions: + +* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; +* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); +* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. +* for later reference, previous versions of validation policy documents should remain available for the Service's users. + +The following validation policy versions are supported in SiVa service: + +1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](validation_policy/#POLv1) +2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](validation_policy/#POLv2) + +### General principles of SiVa validation policies + +1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. +* All rules described for electronic signatures also apply for electronic seals and digital stamps. +* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: + * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). + * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). + +!!! note + When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. + + +## SiVA Signature Validation Policy - Version 1 (POLv1) + + +### Description +Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +``` + +### POLv1 validation constraints +1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: + * Qualified Certificate (QC) requirement + * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * Signer certificate may or may not comply with SSCD/QSCD criteria. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. +* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section + + +## SiVA Signature Validation Policy - Version 2 (POLv2) + + +### Description +Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +``` + +### POLv2 validation constraints + +1. The signature must be a Qualified Electronic Signature (QES), taking account of the following requirements: + * Qualified Certificate (QC) requirement + * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. + * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * Signer certificate must comply with SSCD/QSCD criteria. + * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. + * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: + * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). +* Constraints defined in the [Common validation constraints (POLv1, POLv2)](validation_policy/#common_POLv1_POLv2) section + + +## Common validation constraints (POLv1, POLv2) + + +### General constraints + +1. The validation result returned by SiVa determines whether a signature is technically valid and also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** +2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. + +### Signature format constraints + + +1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: + + * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures + * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures + * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures + * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures + * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) + +### Base libraries' constraints + +1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: + + * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. + * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate ASiC-E/XAdES signatures that conform with BDOC 2.1 digital signature format + * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate PAdES signatures + * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. + +### Baseline Profile constraints +1. The signature must comply with Baseline Profile of the respective signature format: + * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) + * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) +2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. +3. The following table describes supported Baseline Profile levels, according to signature formats: + +| Signature format | BASELINE_B_BES | BASELINE_B_EPES | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | +|--|--|--|--|--|--|--| +|**BDOC** | NOK | NOK | NOK| **OK** | **OK** | **OK** | +|**X-Road signature (simple form)** | NOK | NOK | NOK | **OK** | NOK | NOK | +|**X-Road signature (batch signature)** | **OK** | **OK** | NOK | NOK | NOK | NOK | +|**PAdES** | NOK | NOK | NOK | **OK** | NOK | **OK** | +|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | NOK | **OK** | NOK | +|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | NOK | **OK** | NOK | + +Legend: + +* OK - the respective Baseline Profile level is supported and acceptable. +* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. + + +### X.509 validation constraints + +1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). + + +### Cryptographic algorithm constraints +1. Hash algorithm constraints: + * In case of BDOC and PAdES formats: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. +* Asymmetric cryptographic algorithm contraints: + * RSA and ECC cryptographic algorithms are supported + * In case of BDOC and PAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. + +### Trust anchor constraints +1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. +* Trust Anchors are: + * In case of BDOC, PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). + * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. + * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. + + +### Revocation data constraints +1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. +* The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960). +* No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. +* Checking revocation of certificates regarded as Trust Anchors: + * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. + * In case of BDOC, PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. + + +### Signer certificate's revocation freshness constraints +1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. +* In case of BDOC 2.1 BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: + * The revocation data must be issued after the signature time-stamp production time. + * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 15 minutes then a validation warning is returned. + * If difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. +* In case of PAdES signatures, the default DSS base library's revocation freshness check is used. + + +### Trusted signing time constraints +1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: + * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. + * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. + * In case of basic signature (BASELINE_B_BES or BASELINE_B_EPES level) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. + + +### BDOC/ASiC-E container spceific requirements +1. File extension + * ".asice", ".sce" and ".bdoc" file extensions are supported during signature validation. +* Only one signature shall be stored in one signatures.xml file. +* All signatures in the container must sign all of the data files. +* All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. +* Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. +* Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". +* "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). + + diff --git a/docs/siva/v2/systemintegrators_guide.md b/docs/siva/v2/systemintegrators_guide.md index c587a53fa..91129356c 100644 --- a/docs/siva/v2/systemintegrators_guide.md +++ b/docs/siva/v2/systemintegrators_guide.md @@ -1,550 +1,550 @@ -This guide describes how to integrate SiVa service with other applications. -The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. - -### System requirements - -Following are the minimum requirements to build and deploy SiVa webapps as a service: - -* Java 8 or above Oracle JVM is supported -* Git version control system version 1.8 or above is recommended -* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM -* Minimum 1 processor core -* Open internet connection -* 1GB of free disk space -* Supported operating system is Ubuntu 14.04 LTS - -## Building - -### Building SiVa webapps on Ubuntu 16.04 - -First we need to install Git and Java SDK 8 by issuing below commands: - -```bash -sudo apt-get update -sudo apt-get install git -y -sudo apt-get install default-jdk -y -``` - -Next we need to clone the SiVa Github repository: - -```bash -git clone https://github.com/open-eid/SiVa.git --branch master -``` - -Final step is building the SiVa project using Maven Wrapper - -```bash -cd SiVa -./mvnw clean install -``` - -!!! note - The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the - required dependencies - -To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. -The last lines of build output should look very similar to below image: - -```text -[INFO] Reactor Summary: -[INFO] -[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 25.258 s] -[INFO] validation-services-parent ......................... SUCCESS [ 0.479 s] -[INFO] validation-commons ................................. SUCCESS [01:45 min] -[INFO] tsl-loader ......................................... SUCCESS [ 16.507 s] -[INFO] PDF Validation Service ............................. SUCCESS [ 42.263 s] -[INFO] BDOC Validation Service ............................ SUCCESS [ 58.864 s] -[INFO] DDOC Validation Service ............................ SUCCESS [ 9.929 s] -[INFO] xroad-validation-service ........................... SUCCESS [ 5.664 s] -[INFO] SIVa webapp and other core modules ................. SUCCESS [ 0.315 s] -[INFO] SiVa validation service proxy ...................... SUCCESS [ 43.098 s] -[INFO] siva-webapp ........................................ SUCCESS [04:06 min] -[INFO] SiVa Web Service integration tests ................. SUCCESS [03:41 min] -[INFO] siva-distribution .................................. SUCCESS [ 56.941 s] -[INFO] ------------------------------------------------------------------------ -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 18:30 min -[INFO] Finished at: 2016-07-22T13:40:31+00:00 -[INFO] Final Memory: 80M/250M -[INFO] ------------------------------------------------------------------------ -``` - - -## Deploying - -### OPTION 1 - starting webapps from command line -SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the -project by issuing below commands: - -**First start the Siva webapp** - -```bash -./siva-parent/siva-webapp/target/siva-webapp-3.1.0.jar -``` - -**Second we need to start X-road validation webapp** - -```bash -./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.1.0.jar -``` - -The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. -Easiest way to test out validation is run SiVa demo application. - -**Start the [SiVa Demo Application](https://github.com/open-eid/SiVa-demo-application)** - -```bash -./target/siva-demo-application-3.1.0.jar -``` - -Now point Your browser to URL: - - -### OPTION 2 - running webapps as systemd services - -Maven build generates executable JAR files. This means web container and all its dependencies are package inside -single JAR file. It makes a lot easier to deploy it into servers. - -Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. - -For that we first need to create service file: -```bash -vim siva-webapp.service -``` - -Inside it we need to paste below text. You need to change few things in service setup file. - -* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` -* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. -* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file - -```ini -[Unit] -Description=siva-webapp -After=syslog.target - -[Service] -User=root -ExecStart=/var/apps/siva-webapp.jar -Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 -SuccessExitStatus=143 - -[Install] -WantedBy=multi-user.target -``` - -Save and close the `siva-webapp.service` file. -Next we need to move `siva-webapp-3.1.0.jar` into newly created `/var/apps` directory and rename to -JAR file to `siva-webapp.jar`. match - -!!! note - The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file - -```bash -sudo mkdir /var/apps -sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.1.0.jar /var/apps/siva-webapp.jar -``` - -Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. -Then we are ready to start the `siva-webapp` service. - -```bash -sudo cp siva-webapp.service /lib/systemd/system -sudo systemctl start siva-webapp -``` - -Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below -command. - -```bash -systemctl status siva-webapp -``` - -It should print out similar to below picture: - -``` -● siva-webapp.service - siva-webapp - Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) - Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago - Main PID: 15965 (siva-webapp.jar) - Tasks: 34 - Memory: 429.6M - CPU: 2min 5.721s - CGroup: /system.slice/siva-webapp.service - ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar - └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar - -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -``` - -### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) - -> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet -> containers also possible container application libraries conflicts - -> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version -> conflicts. - -> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - -the http connector parameter `maxPostSize` should be configured with the desired limit. - -> **NOTE 4**: The war file must be deployed to Tomcat ROOT. - -First we need to download Tomcat web servlet container as of the writing latest version available in version 7 branch is 7.0.77. We will download it with `wget` - -```bash -wget http://www-eu.apache.org/dist/tomcat/tomcat-7/v7.0.70/bin/apache-tomcat-7.0.70.tar.gz -``` - -Unpack it somewhere: - -```bash -tar xf apache-tomcat-7.0.70.tar.gz -``` - -Now we should build the WAR file. We have created helper script with all the correct Maven parameters. - -```bash -./war-build.sh -``` - -> **NOTE** The script will skip running the integration tests when building WAR files - -Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. - -```bash -cp siva-parent/siva-webapp/target/siva-webapp-3.1.0.war apache-tomcat-7.0.70/webapps -./apache-tomcat-7.0.77/bin/catalina.sh run -``` - -> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates -> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change -> this default behavior you should set environment variable `DSS_DATA_FOLDER` - -### How-to set WAR deployed SiVa `application.properties` - -SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. -To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. - -Contents of the `setenv.sh` file should look like: - -```bash -export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" -``` - - -### Smoke testing your deployed system - -**Step 1**. Install HTTPIE -`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed -and started correctly on our server. - -If you have Python and its package manager `pip` installed. Then You can issue below command: - -```bash -pip install httpie -``` - -**Step 2**. Download a sample JSON request file. - -```bash -http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdoc_pass.json -``` - -**Step 3**. After successful download issue below command in same directory where you downloaded the file using -the command below. - -```bash -http POST http://10.211.55.9:8080/validate < bdoc_pass.json -``` -**Step 4**. Verify the output. The output of previous command should look like below screenshot. Look for `signatureCount` and -`validSignatureCount` they **must** be equal. - - -![HTTPIE output validation](../../img/siva/siva-output.png) - - -## Logging - -By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. - -For example, adding application.properties to classpath with the **logging.config** property -```bash -logging.config=/path/to/logback.xml -``` - -## Statistics - -For every report validated, a statistical report is composed that collects the following data: - -| Data | Description | -| ----- | ----- | -| Validation duration | The time it takes to process an incoming request - measured in milliseconds | -| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, PAdES or ASiC-E (BatchSignature) ) | -| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | -| Total signatures count | The value of the `signaturesCount` element in the validation report -| Valid signatures count | The value of the `validSignaturesCount` element in the validation report -| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | -| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | -| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | - -There are two channels where this information is sent: - -1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. - -2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. - -The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) - -## Monitoring - -SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. - -!!! note - Note that this endpoint is disabled by default. - - -The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. - -* **Enabling and disabling the monitoring endpoint** - -To enable the endpoint, use the following configuration parameter: -```bash -endpoints.health.enabled=true -``` - -* **Customizing external service health indicators** - -The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. - -Demo webapp and Siva webapp also include additional information about the health of their dependent services. -These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. - -However, using the following parameters, these links can be overridden: - -| Property | Description | -| -------- | ----------- | -|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| -|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| -|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| - -For example: -```bash -endpoints.health.links[0].name=linkToXroad -endpoints.health.links[0].url=http://localhost:7777/monitoring/health -endpoints.health.links[0].timeout=1000 -``` - -!!! note - The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . - - --------------------------------------------------------------------------------------- -## Configuration parameters - -All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. -However, all the properties can be overridden on the service or embedded web server level, if necessary. - -By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. -Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. - -For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: -```bash -server.port=8080 -``` - -Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: -```bash -server.max-http-post-size: 13981016 -``` - -See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot - -### Siva webapp parameters - -* Updating TSL - -| Property | Description | -| -------- | ----------- | -| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| -| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| -| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| -| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 * * ?**
| -| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| -| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| -| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| - -!!! note - Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). - -!!! note - TSL is currently used only by PDF and BDOC validators - - -* Forward to custom X-road webapp instance - -| Property | Description | -| ------ | ----------- | -| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| - -* Collecting statistics with Google Analytics - -| Property | Description | -| -------- | ----------- | -| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| -| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| -| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| -| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| - -* BDOC validation parameters - -| Property | Description | -| -------- | ----------- | -| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| - -Customizing BDOC validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.bdoc.signaturePolicy.policies[0].name=POLv1 -siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml - -siva.bdoc.signaturePolicy.policies[1].name=POLv2 -siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml - -siva.bdoc.signaturePolicy.defaultPolicy=POLv1 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* PadES validation - customize validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.pdf.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.pdf.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.pdf.signaturePolicy.policies[0].name=POLv1 -siva.pdf.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.pdf.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.pdf.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml - -siva.pdf.signaturePolicy.policies[1].name=POLv2 -siva.pdf.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.pdf.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -siva.pdf.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml - -siva.pdf.signaturePolicy.defaultPolicy=POLv1 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* DDOC validation - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| - -Customizing DDOC validation policies: - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.ddoc.signaturePolicy.policies[0].name=POLv1 -siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml - -siva.ddoc.signaturePolicy.policies[1].name=POLv2 -siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 -siva.ddoc.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml - -siva.ddoc.signaturePolicy.defaultPolicy=POLv1 -``` -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -### X-road validation webapp parameters - -* X-road validation - -| Property | Description | -| -------- | ----------- | -|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| - - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.ddoc.signaturePolicy.policies[0].name=POLv1 -siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 -siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml - -siva.ddoc.signaturePolicy.defaultPolicy= POLv1 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) -!!! note - By default, X-road validation currently supports only POLv1 - - -### Demo webapp parameters - -* Linking to SiVa webapp - -| Property | Description | -| -------- | ----------- | -|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| -|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| -|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| - - -## FAQ - ---------------------------------------------------- -Q: SiVa webapp API-s require that you specify the document type? Is it possible to detect the container/file type automatically based on the provided file. - -A: There is a demo webapp that provides a reference solution. See `ee.openeid.siva.sample.siva.ValidationRequestUtils` for reference. - ---------------------------------------------------- +This guide describes how to integrate SiVa service with other applications. +The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. + +### System requirements + +Following are the minimum requirements to build and deploy SiVa webapps as a service: + +* Java 8 or above Oracle JVM is supported +* Git version control system version 1.8 or above is recommended +* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM +* Minimum 1 processor core +* Open internet connection +* 1GB of free disk space +* Supported operating system is Ubuntu 14.04 LTS + +## Building + +### Building SiVa webapps on Ubuntu 16.04 + +First we need to install Git and Java SDK 8 by issuing below commands: + +```bash +sudo apt-get update +sudo apt-get install git -y +sudo apt-get install default-jdk -y +``` + +Next we need to clone the SiVa Github repository: + +```bash +git clone https://github.com/open-eid/SiVa.git --branch master +``` + +Final step is building the SiVa project using Maven Wrapper + +```bash +cd SiVa +./mvnw clean install +``` + +!!! note + The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the + required dependencies + +To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. +The last lines of build output should look very similar to below image: + +```text +[INFO] Reactor Summary: +[INFO] +[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 25.258 s] +[INFO] validation-services-parent ......................... SUCCESS [ 0.479 s] +[INFO] validation-commons ................................. SUCCESS [01:45 min] +[INFO] tsl-loader ......................................... SUCCESS [ 16.507 s] +[INFO] PDF Validation Service ............................. SUCCESS [ 42.263 s] +[INFO] BDOC Validation Service ............................ SUCCESS [ 58.864 s] +[INFO] DDOC Validation Service ............................ SUCCESS [ 9.929 s] +[INFO] xroad-validation-service ........................... SUCCESS [ 5.664 s] +[INFO] SIVa webapp and other core modules ................. SUCCESS [ 0.315 s] +[INFO] SiVa validation service proxy ...................... SUCCESS [ 43.098 s] +[INFO] siva-webapp ........................................ SUCCESS [04:06 min] +[INFO] SiVa Web Service integration tests ................. SUCCESS [03:41 min] +[INFO] siva-distribution .................................. SUCCESS [ 56.941 s] +[INFO] ------------------------------------------------------------------------ +[INFO] BUILD SUCCESS +[INFO] ------------------------------------------------------------------------ +[INFO] Total time: 18:30 min +[INFO] Finished at: 2016-07-22T13:40:31+00:00 +[INFO] Final Memory: 80M/250M +[INFO] ------------------------------------------------------------------------ +``` + + +## Deploying + +### OPTION 1 - starting webapps from command line +SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the +project by issuing below commands: + +**First start the Siva webapp** + +```bash +./siva-parent/siva-webapp/target/siva-webapp-3.1.0.jar +``` + +**Second we need to start X-road validation webapp** + +```bash +./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.1.0.jar +``` + +The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. +Easiest way to test out validation is run SiVa demo application. + +**Start the [SiVa Demo Application](https://github.com/open-eid/SiVa-demo-application)** + +```bash +./target/siva-demo-application-3.1.0.jar +``` + +Now point Your browser to URL: + + +### OPTION 2 - running webapps as systemd services + +Maven build generates executable JAR files. This means web container and all its dependencies are package inside +single JAR file. It makes a lot easier to deploy it into servers. + +Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. + +For that we first need to create service file: +```bash +vim siva-webapp.service +``` + +Inside it we need to paste below text. You need to change few things in service setup file. + +* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` +* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. +* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file + +```ini +[Unit] +Description=siva-webapp +After=syslog.target + +[Service] +User=root +ExecStart=/var/apps/siva-webapp.jar +Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 +SuccessExitStatus=143 + +[Install] +WantedBy=multi-user.target +``` + +Save and close the `siva-webapp.service` file. +Next we need to move `siva-webapp-3.1.0.jar` into newly created `/var/apps` directory and rename to +JAR file to `siva-webapp.jar`. match + +!!! note + The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file + +```bash +sudo mkdir /var/apps +sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.1.0.jar /var/apps/siva-webapp.jar +``` + +Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. +Then we are ready to start the `siva-webapp` service. + +```bash +sudo cp siva-webapp.service /lib/systemd/system +sudo systemctl start siva-webapp +``` + +Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below +command. + +```bash +systemctl status siva-webapp +``` + +It should print out similar to below picture: + +``` +● siva-webapp.service - siva-webapp + Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) + Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago + Main PID: 15965 (siva-webapp.jar) + Tasks: 34 + Memory: 429.6M + CPU: 2min 5.721s + CGroup: /system.slice/siva-webapp.service + ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar + └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar + +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +``` + +### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) + +> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet +> containers also possible container application libraries conflicts + +> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version +> conflicts. + +> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - +the http connector parameter `maxPostSize` should be configured with the desired limit. + +> **NOTE 4**: The war file must be deployed to Tomcat ROOT. + +First we need to download Tomcat web servlet container as of the writing latest version available in version 7 branch is 7.0.77. We will download it with `wget` + +```bash +wget http://www-eu.apache.org/dist/tomcat/tomcat-7/v7.0.70/bin/apache-tomcat-7.0.70.tar.gz +``` + +Unpack it somewhere: + +```bash +tar xf apache-tomcat-7.0.70.tar.gz +``` + +Now we should build the WAR file. We have created helper script with all the correct Maven parameters. + +```bash +./war-build.sh +``` + +> **NOTE** The script will skip running the integration tests when building WAR files + +Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. + +```bash +cp siva-parent/siva-webapp/target/siva-webapp-3.1.0.war apache-tomcat-7.0.70/webapps +./apache-tomcat-7.0.77/bin/catalina.sh run +``` + +> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates +> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change +> this default behavior you should set environment variable `DSS_DATA_FOLDER` + +### How-to set WAR deployed SiVa `application.properties` + +SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. +To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. + +Contents of the `setenv.sh` file should look like: + +```bash +export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" +``` + + +### Smoke testing your deployed system + +**Step 1**. Install HTTPIE +`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed +and started correctly on our server. + +If you have Python and its package manager `pip` installed. Then You can issue below command: + +```bash +pip install httpie +``` + +**Step 2**. Download a sample JSON request file. + +```bash +http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdoc_pass.json +``` + +**Step 3**. After successful download issue below command in same directory where you downloaded the file using +the command below. + +```bash +http POST http://10.211.55.9:8080/validate < bdoc_pass.json +``` +**Step 4**. Verify the output. The output of previous command should look like below screenshot. Look for `signatureCount` and +`validSignatureCount` they **must** be equal. + + +![HTTPIE output validation](../../img/siva/siva-output.png) + + +## Logging + +By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. + +For example, adding application.properties to classpath with the **logging.config** property +```bash +logging.config=/path/to/logback.xml +``` + +## Statistics + +For every report validated, a statistical report is composed that collects the following data: + +| Data | Description | +| ----- | ----- | +| Validation duration | The time it takes to process an incoming request - measured in milliseconds | +| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, PAdES or ASiC-E (BatchSignature) ) | +| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | +| Total signatures count | The value of the `signaturesCount` element in the validation report +| Valid signatures count | The value of the `validSignaturesCount` element in the validation report +| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | +| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | +| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | + +There are two channels where this information is sent: + +1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. + +2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. + +The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) + +## Monitoring + +SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. + +!!! note + Note that this endpoint is disabled by default. + + +The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. + +* **Enabling and disabling the monitoring endpoint** + +To enable the endpoint, use the following configuration parameter: +```bash +endpoints.health.enabled=true +``` + +* **Customizing external service health indicators** + +The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. + +Demo webapp and Siva webapp also include additional information about the health of their dependent services. +These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. + +However, using the following parameters, these links can be overridden: + +| Property | Description | +| -------- | ----------- | +|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| +|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| +|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| + +For example: +```bash +endpoints.health.links[0].name=linkToXroad +endpoints.health.links[0].url=http://localhost:7777/monitoring/health +endpoints.health.links[0].timeout=1000 +``` + +!!! note + The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . + + +-------------------------------------------------------------------------------------- +## Configuration parameters + +All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. +However, all the properties can be overridden on the service or embedded web server level, if necessary. + +By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. +Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. + +For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: +```bash +server.port=8080 +``` + +Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: +```bash +server.max-http-post-size: 13981016 +``` + +See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot + +### Siva webapp parameters + +* Updating TSL + +| Property | Description | +| -------- | ----------- | +| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| +| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| +| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| +| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 * * ?**
| +| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| +| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| +| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| + +!!! note + Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). + +!!! note + TSL is currently used only by PDF and BDOC validators + + +* Forward to custom X-road webapp instance + +| Property | Description | +| ------ | ----------- | +| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| + +* Collecting statistics with Google Analytics + +| Property | Description | +| -------- | ----------- | +| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| +| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| +| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| +| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| + +* BDOC validation parameters + +| Property | Description | +| -------- | ----------- | +| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| + +Customizing BDOC validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.bdoc.signaturePolicy.policies[0].name=POLv1 +siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml + +siva.bdoc.signaturePolicy.policies[1].name=POLv2 +siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml + +siva.bdoc.signaturePolicy.defaultPolicy=POLv1 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* PadES validation - customize validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.pdf.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.pdf.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.pdf.signaturePolicy.policies[0].name=POLv1 +siva.pdf.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.pdf.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.pdf.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml + +siva.pdf.signaturePolicy.policies[1].name=POLv2 +siva.pdf.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.pdf.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +siva.pdf.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml + +siva.pdf.signaturePolicy.defaultPolicy=POLv1 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* DDOC validation + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| + +Customizing DDOC validation policies: + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.ddoc.signaturePolicy.policies[0].name=POLv1 +siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml + +siva.ddoc.signaturePolicy.policies[1].name=POLv2 +siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2 +siva.ddoc.signaturePolicy.policies[1].constraintPath=pdf_constraint_qes.xml + +siva.ddoc.signaturePolicy.defaultPolicy=POLv1 +``` +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +### X-road validation webapp parameters + +* X-road validation + +| Property | Description | +| -------- | ----------- | +|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| + + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.ddoc.signaturePolicy.policies[0].name=POLv1 +siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1 +siva.ddoc.signaturePolicy.policies[0].constraintPath=pdf_constraint_no_type.xml + +siva.ddoc.signaturePolicy.defaultPolicy= POLv1 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) +!!! note + By default, X-road validation currently supports only POLv1 + + +### Demo webapp parameters + +* Linking to SiVa webapp + +| Property | Description | +| -------- | ----------- | +|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| +|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| +|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| + + +## FAQ + +--------------------------------------------------- +Q: SiVa webapp API-s require that you specify the document type? Is it possible to detect the container/file type automatically based on the provided file. + +A: There is a demo webapp that provides a reference solution. See `ee.openeid.siva.sample.siva.ValidationRequestUtils` for reference. + +--------------------------------------------------- diff --git a/docs/siva2/appendix/validation_policy.md b/docs/siva2/appendix/validation_policy.md index 437e0de94..8a7a73da5 100644 --- a/docs/siva2/appendix/validation_policy.md +++ b/docs/siva2/appendix/validation_policy.md @@ -1,211 +1,211 @@ -# SiVa Signature Validation Policy - -## Introduction -This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). - -### Versioning - -Different policy versions may be used by the service in the following conditions: - -* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; -* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); -* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. -* for later reference, previous versions of validation policy documents should remain available for the Service's users. - -The following validation policy versions are supported in SiVa 2.0 service: - -1. [**SiVA Signature Validation Policy - Version 3 (POLv3)**](validation_policy/#POLv3) -2. [**SiVA Signature Validation Policy - Version 4 (POLv4)**](validation_policy/#POLv4) - -The following validation policy versions are marked as obsolete in SiVa 2.0 service: - -1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1) -2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2) - -### General principles of SiVa validation policies - -1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. -* All rules described for electronic signatures also apply for electronic seals and digital stamps if not explicitly stated otherwise. -* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: - * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). - * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). - -!!! note - When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. - - -## SiVA Signature Validation Policy - Version 3 (POLv3) - - -### Description -Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv3 -``` - -### POLv3 validation constraints -1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: - * Qualified Certificate (QC) requirement - * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * Signer certificate may or may not comply with SSCD/QSCD criteria. - * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. -* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section - - -## SiVA Signature Validation Policy - Version 4 (POLv4) - - -### Description -Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - -### URL - -``` -http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 -``` - -### POLv4 validation constraints - -1. The requirements for the signature level depend on signature type. - * Qualified Certificate (QC) requirement - * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. - * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. - * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement - * In case of Signatures, signer certificate should comply with SSCD/QSCD criteria, otherwise warning is returned. - * In case of Seals, there is no requirement for SSCD/QSCD criteria. - * If it is not possible to determine the signature type, it must comply with SSCD/QSCD criteria. - * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. - * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: - * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). -* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section - - -## Common validation constraints (POLv3, POLv4) - - -### General constraints - -1. The validation result returned by SiVa determines whether a signature is technically valid and depending of a container type also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** -2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. - -### Signature format constraints - - -1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: - - * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures - * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures - * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures - * [XAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf) signatures - * [CAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.01.01_60/en_31912201v010101p.pdf) signatures - * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures - * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) - -### Base libraries' constraints - - -1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: - - * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. - * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate signatures in BDOC 2.1 format - * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - is used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. - * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate all other signature formats than mentioned above - -### Baseline Profile constraints -1. The signature must comply with Baseline Profile of the respective signature format: - * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) - * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) - * [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) -2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. -3. The following table describes supported Baseline Profile levels, according to signature formats: - -| Signature format | BASELINE_B | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | -|--|--|--|--|--|--| -|**BDOC** | NOK | NOK| **OK** | **OK** | **OK** | -|**X-Road signature (simple form)** | NOK | NOK | **OK** | NOK | NOK | -|**X-Road signature (batch signature)** | **OK** | NOK | NOK | NOK | NOK | -|**PAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**XAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**CAdES** | NOK | NOK | **OK** | NOK | **OK** | -|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | **OK** | NOK | -|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | **OK** | NOK | - -Legend: - -* OK - the respective Baseline Profile level is supported and acceptable. -* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. - - -### X.509 validation constraints - -1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). - - -### Cryptographic algorithm constraints -1. Hash algorithm constraints: - * In case of BDOC format: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. -2. Asymmetric cryptographic algorithm contraints: - * RSA and ECC cryptographic algorithms are supported - * In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. - -### Trust anchor constraints -1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. -2. Trust Anchors are: - * In case of XAdES/CAdES/PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). - * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. - * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. - - -### Revocation data constraints -1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. -2. The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960) or as a Certificate Revocation List. -3. No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. -4. Checking revocation of certificates regarded as Trust Anchors: - * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. - * In case of XAdES/CAdES/PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. - - -### Signer certificate's revocation freshness constraints -1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. -2. In case of XAdES/CAdES/PAdES BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: - * In case of OCSP responce if difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. If the difference is more than 15 minutes and less then 24h then a validation warning is returned. - * In case of Certificate Revocation List the signature time-stamp's production time (genTime field) must be within validity range of the CRL (between thisUpdate and nextUpdate) - - -### Trusted signing time constraints -1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: - * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. - * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. - * In case of basic signature (BASELINE_B) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. - - -### BDOC container spceific requirements -The BDOC container must conform with [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) standard. -1. File extension - * ".bdoc" file extension is supported during signature validation. -2. Only one signature shall be stored in one signatures.xml file. -3. All signatures in the container must sign all of the data files. -4. All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. -5. Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. -6. Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". -7. "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). - -### ASICE container spceific requirements -The ASICE container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) standard. -1. Warning is returned when signatures in the container do not sign all of the data files. -2. Manifest file must be present. - -### ASICS container spceific requirements -The service supports both signature and Time Stamp Token (TST) based ASIC-S containers. Evidence record based containers are not supported. The ASIC-S container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) and [ETSI EN 319 162-2](http://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf) standards. - -1. Manifest file can not be present in case of signature based ASIC-S containers. -2. Only one TimeStampToken per container is supported. No AsicArchiveManifest.xml support. -3. No TSL based verification of certificates is done in case of TimeStampToken based containers. - - - +# SiVa Signature Validation Policy + +## Introduction +This signature validation policy document specifies signature validation rules used for validating signatures in **SiVa digital signature validation service** (hereinafter: Service). + +### Versioning + +Different policy versions may be used by the service in the following conditions: + +* different validation policies may be in use simultaneously, enabling the Service's user to choose the most suitable policy for a specific business context; +* validation policies are subject to change, i.e. there may be an update to a policy which causes the previous version to become no longer used (obsolete); +* for later reference, the validation report returned by the Service must indicate the specific version of validation policy that was used during validation process. +* for later reference, previous versions of validation policy documents should remain available for the Service's users. + +The following validation policy versions are supported in SiVa 2.0 service: + +1. [**SiVA Signature Validation Policy - Version 3 (POLv3)**](validation_policy/#POLv3) +2. [**SiVA Signature Validation Policy - Version 4 (POLv4)**](validation_policy/#POLv4) + +The following validation policy versions are marked as obsolete in SiVa 2.0 service: + +1. [**SiVA Signature Validation Policy - Version 1 (POLv1)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv1) +2. [**SiVA Signature Validation Policy - Version 2 (POLv2)**](http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv2) + +### General principles of SiVa validation policies + +1. The validation policy documents describe validation rules for all digital signature formats that are supported in SiVa. +* All rules described for electronic signatures also apply for electronic seals and digital stamps if not explicitly stated otherwise. +* The set of signature validation constraints that are used by the Service are a combination of constraints defined in the Service itself and constraints that are implicitly defined in base components of the service, including: + * Validation rules defined by the standard or specification documents of the digital signature formats supported in SiVa (described in [Signature format constraints](validation_policy/#common_format) section). + * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](validation_policy/#common_libraries) section). + +!!! note + When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources. + + +## SiVA Signature Validation Policy - Version 3 (POLv3) + + +### Description +Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv3 +``` + +### POLv3 validation constraints +1. The signature may be a Qualified Electronic Signature (QES), Advanced electronic Signature (AdES) or AdES supported by a Qualified Certificate (AdES/QC) taking account of the following requirements: + * Qualified Certificate (QC) requirement + * The signer’s certificate may be a qualified or non-qualified certificate, as meant by the eIDAS regulation. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's QC compliance. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * Signer certificate may or may not comply with SSCD/QSCD criteria. + * The signer's certificate is considered acceptable by the validation process even if it is not possible to determine the certificate's SSCD/QSCD compliance. +* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section + + +## SiVA Signature Validation Policy - Version 4 (POLv4) + + +### Description +Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + +### URL + +``` +http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 +``` + +### POLv4 validation constraints + +1. The requirements for the signature level depend on signature type. + * Qualified Certificate (QC) requirement + * The signer’s certificate must be a qualified certificate, as meant by the eIDAS regulation. + * If Trusted Lists are used during signature validation then also the signer certificate’s qualification information in the Trusted List is taken into account. + * SSCD/QSCD (Secure/Qualified Signature Creation Device) requirement + * In case of Signatures, signer certificate should comply with SSCD/QSCD criteria, otherwise warning is returned. + * In case of Seals, there is no requirement for SSCD/QSCD criteria. + * If it is not possible to determine the signature type, it must comply with SSCD/QSCD criteria. + * If Trusted Lists are used during signature validation then the also signer certificate’s SSCD/QSCD qualification information in the Trusted List is taken into account. + * The signer's certificate is not considered acceptable by the validation process if it is not possible to determine the certificate's QC and SSCD/QSCD compliance, with the following exception: + * In case of DIGIDOC-XML 1.0...1.3 and the respective hashcode formats, it is assumed that the signer's certificate complies with QC and SSCD/QSCD requirements, if the certificate is issued by [SK](https://sk.ee/en/repository/certs/) and if the nonRepudiation bit has been set in the certificate's Key Usage field. See also [Certificate Profile](https://sk.ee/en/repository/profiles/) documents of certificates issued by SK, [ETSI EN 319 412-2](http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.01.01_60/en_31941202v020101p.pdf) and [ETSI EN 319 412-3](http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf). +* Constraints defined in the [Common validation constraints (POLv3, POLv4)](validation_policy/#common_POLv3_POLv4) section + + +## Common validation constraints (POLv3, POLv4) + + +### General constraints + +1. The validation result returned by SiVa determines whether a signature is technically valid and depending of a container type also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.** +2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined. + +### Signature format constraints + + +1. SiVa implicitly implements constraints that are specified in the specification documents of the signature formats supported by the Service: + + * [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) ASiC-E/XAdES signatures + * [X-Road](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) ASiC-E/XAdES signatures + * [PAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf) signatures + * [XAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31913201/01.01.01_60/en_31913201v010101p.pdf) signatures + * [CAdES](http://www.etsi.org/deliver/etsi_en/319100_319199/31912201/01.01.01_60/en_31912201v010101p.pdf) signatures + * [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) 1.0, 1.1, 1.2, 1.3 signatures + * DIGIDOC-XML 1.0, 1.1, 1.2 and 1.3 signatures in [hashcode format](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode) + +### Base libraries' constraints + + +1. SiVa implicitly implements constraints that are imposed by the base software libraries that are used by the service. For more information, see the documentation and source code of the base libraries: + + * [JDigiDoc](https://github.com/open-eid/jdigidoc) - is used to validate signatures in DIGIDOC-XML 1.0...1.3 format, including documents in hashcode form. + * [DigiDoc4J](https://github.com/open-eid/digidoc4j) - is used to validate signatures in BDOC 2.1 format + * [asicverifier](https://github.com/vrk-kpa/xroad-public/tree/master/src/asicverifier) - is used for validating ASiC-E/XAdES signatures created in [X-Road](https://www.ria.ee/en/x-road.html) system. + * [Open-eID DSS fork](https://github.com/open-eid/sd-dss) - is used to validate all other signature formats than mentioned above + +### Baseline Profile constraints +1. The signature must comply with Baseline Profile of the respective signature format: + * [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf) + * [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) + * [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) +2. In case of Baseline LT-level signature with time-mark, the notation BASELINE_LT_TM is used. +3. The following table describes supported Baseline Profile levels, according to signature formats: + +| Signature format | BASELINE_B | BASELINE_T | BASELINE_LT | BASELINE_LT_TM | BASELINE_LTA | +|--|--|--|--|--|--| +|**BDOC** | NOK | NOK| **OK** | **OK** | **OK** | +|**X-Road signature (simple form)** | NOK | NOK | **OK** | NOK | NOK | +|**X-Road signature (batch signature)** | **OK** | NOK | NOK | NOK | NOK | +|**PAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**XAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**CAdES** | NOK | NOK | **OK** | NOK | **OK** | +|**DIGIDOC-XML 1.0...1.3 **| NOK | NOK | NOK | **OK** | NOK | +|**DIGIDOC-XML 1.0...1.3 hashcode **| NOK | NOK | NOK | **OK** | NOK | + +Legend: + +* OK - the respective Baseline Profile level is supported and acceptable. +* NOK - the respective Baseline Profile level is not supported or is considered insufficient for the signature format. + + +### X.509 validation constraints + +1. The signer certificate’s Key Usage field must have nonRepudiation bit set (also referred to as contentCommitment). + + +### Cryptographic algorithm constraints +1. Hash algorithm constraints: + * In case of BDOC format: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned. +2. Asymmetric cryptographic algorithm contraints: + * RSA and ECC cryptographic algorithms are supported + * In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits. + +### Trust anchor constraints +1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature. +2. Trust Anchors are: + * In case of XAdES/CAdES/PAdES formats: [EU Member State Trusted Lists](https://ec.europa.eu/tools/lotl/eu-lotl.xml). + * In case of DIGIDOC-XML 1.0...1.3 and respective hashcode formats: Estonian CA certificates issued by [SK](https://sk.ee/en/repository/certs/), defined in local configuration file. + * In case of X-Road ASiC-E signatures, SK issued KLASS3-SK 2010, and KLASS3-SK 2010 OCSP RESPONDER and SK TIMESTAMPING AUTHORITY certificates, defined in local configuration file. + + +### Revocation data constraints +1. The signature must contain evidence record to confirm that certificate was valid at the time of signing. +2. The evidence record of signer certificate must be in the form of an [OCSP confirmation](https://tools.ietf.org/html/rfc6960) or as a Certificate Revocation List. +3. No additional revocation data other than the data that was originally incorporated in the signature shall be requested during validation time. +4. Checking revocation of certificates regarded as Trust Anchors: + * In case of DIGIDOC-XML 1.0...1.3 and X-Road formats: revocation of Trust Anchor certificates is not checked. + * In case of XAdES/CAdES/PAdES formats: revocation of Trust Anchor certificates is checked on the basis of the data in Trusted Lists. + + +### Signer certificate's revocation freshness constraints +1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time. +2. In case of XAdES/CAdES/PAdES BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules: + * In case of OCSP responce if difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. If the difference is more than 15 minutes and less then 24h then a validation warning is returned. + * In case of Certificate Revocation List the signature time-stamp's production time (genTime field) must be within validity range of the CRL (between thisUpdate and nextUpdate) + + +### Trusted signing time constraints +1. Trusted signing time, denoting the earliest time when it can be trusted (because proven by some Proof-of-Existence present in the signature) that a signature has existed, is determined as follows: + * In case of signature with time-mark (BASELINE_LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature. + * In case of signature with time-stamp (BASELINE_T, BASELINE_LT or BASELINE_LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature. + * In case of basic signature (BASELINE_B) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature. + + +### BDOC container spceific requirements +The BDOC container must conform with [BDOC 2.1](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) standard. +1. File extension + * ".bdoc" file extension is supported during signature validation. +2. Only one signature shall be stored in one signatures.xml file. +3. All signatures in the container must sign all of the data files. +4. All data files in the container must be signed, i.e. all files in the container, except of "mimetype" file and the files in META-INF/ folder, must be signed. +5. Two data files with the same name and same path shall not be allowed in the container as the signed data file must be uniquely identifiable in the container. To avoid conflicts in some operating system environments, file names shall be case insensitive. +6. Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt". +7. "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf). + +### ASICE container spceific requirements +The ASICE container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) standard. +1. Warning is returned when signatures in the container do not sign all of the data files. +2. Manifest file must be present. + +### ASICS container spceific requirements +The service supports both signature and Time Stamp Token (TST) based ASIC-S containers. Evidence record based containers are not supported. The ASIC-S container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) and [ETSI EN 319 162-2](http://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf) standards. + +1. Manifest file can not be present in case of signature based ASIC-S containers. +2. Only one TimeStampToken per container is supported. No AsicArchiveManifest.xml support. +3. No TSL based verification of certificates is done in case of TimeStampToken based containers. + + + diff --git a/docs/siva2/component_diagram.md b/docs/siva2/component_diagram.md index 468234c96..1cf4ead19 100644 --- a/docs/siva2/component_diagram.md +++ b/docs/siva2/component_diagram.md @@ -1,94 +1,94 @@ - - -![SiVa component diagram](../img/siva/siva_module_diagram.png) - -## Web API - -Web API is standard Spring Boot Web application module inside SiVa webapp it will take in JSON or SOAP requests sent by -systems that are integrated with SiVa web service API. The incoming requests will be converted to **SiVa Proxy Module** -Java request objects. Web API module also does basic validation of incoming requests. Checking that all the required -fields are present and document type is correct. - -When validation has been completed by proxy selected validation service the returned qualified validation report Java object -will be marshalled based on incoming request to JSON or SOAP and returned to client that requested the validation. - -### External configuration resources - -* Optionally SiVa webapp can load in configuration file (i.e application.yml) at application startup time. - Configuration file can control Spring Boot configuration options in addition to SiVa application - specific options. -* Optionally SiVa webapp can also load in logging configuration options - -## Validation proxy service - -**Validation proxy service** or validation service selector is Spring Boot module that will take the Web API sent -request object and try to find matching validation service based on the `documentType`inside the request object. -When matching validation service have been found the proxy request is converted to validation request and sent to matched -validation service. - -When no matching validation service has not been found exception is raised and error object is -returned to Web API module. On successful validation the qualified validation report Java object sent from validation -service is returned to Web API module. - -!!! note - Validation services can be added dynamically to SiVa by conforming to pattern `documentType + "ValidationService"` and new - validation service module must be Maven dependency of `siva-validation-proxy`. Example - would be `BDOCValidationService`. - -## Validation reporting service - -**Validation reporting service** is optional module that can be turned on or off using configuration file. It's Spring Boot module and -main purpose is to collect data about: incoming request, validation reports and errors that have been reported during validation process. - -When HTTP authentication header have been set the reporting service will also collect its and adds to required statistics reports. - -After the report object have been created the data will be sent to configured reporting service. SiVa is preconfigured to work with -Google Analytics. - -## TSL Loader - -TSL loader loads in contents of TSL file from given URL in online mode or from directory when -using offline mode in predefined interval. - -## Validation services - -All validation services use different Java library to validate given document in request. The used validation -library is described in each of the validation service section. - -Common process that all validation services do with proxy forwarded validation process is: - -* Convert the Base64 encoded document into `InputStream` byte array -* Check that given document is correct format (i.e valid BDOC). If not then error is thrown and - validation process is terminated. -* After validation of signatures has been completed the validation service starts to build - qualified validation report -* Validation report is created even validation `FAILED` or ended with `INDETERMINATE` result - -### PDF Validation service - -PDF or PaDES as known in DSS validation service uses [Digidoc4J DSS fork Java library](https://github.com/open-eid/sd-dss) PaDES validation -functionality using the validation policy that complies with Estonian laws and regulations. - -Configurable functionality: - -* Possibility to add additional validation policies using SiVa `application.yml` configuration section. - -### BDOC validation service - -BDOC for ASiC compliant containers both TM and TS will latest Maven released **DigiDoc4J** library - -### DDOC Validation service - -DDOC for previous generation digitally signed files will use latest Maven release of **JDigiDoc** - -### X-Road validation service - -X-Road containers are similar to ASiCE containers but are **not** valid ASiCE containers. There we could not use DSS nor DigiDoc4J provided -ASiCE validation functionality but need to X-Road developed `asicverifier` Java command line utility to validate these containers. - -Source code for `asicverifier` can be found in [GitHub xroad-public repository](https://github.com/ria-ee/X-Road/tree/master/src/asicverifier)*[]: -`Asicverfier` has been integrated into SiVa as Java library. Making possible to use all the Java libraries packaged into `asicverifier` fat JAR. - -Configurable functionality: - -* In SiVa configuration `application.yml` file You can define alternative location for `globalconf` directory to be loaded in using input stream + + +![SiVa component diagram](../img/siva/siva_module_diagram.png) + +## Web API + +Web API is standard Spring Boot Web application module inside SiVa webapp it will take in JSON or SOAP requests sent by +systems that are integrated with SiVa web service API. The incoming requests will be converted to **SiVa Proxy Module** +Java request objects. Web API module also does basic validation of incoming requests. Checking that all the required +fields are present and document type is correct. + +When validation has been completed by proxy selected validation service the returned qualified validation report Java object +will be marshalled based on incoming request to JSON or SOAP and returned to client that requested the validation. + +### External configuration resources + +* Optionally SiVa webapp can load in configuration file (i.e application.yml) at application startup time. + Configuration file can control Spring Boot configuration options in addition to SiVa application + specific options. +* Optionally SiVa webapp can also load in logging configuration options + +## Validation proxy service + +**Validation proxy service** or validation service selector is Spring Boot module that will take the Web API sent +request object and try to find matching validation service based on the `documentType`inside the request object. +When matching validation service have been found the proxy request is converted to validation request and sent to matched +validation service. + +When no matching validation service has not been found exception is raised and error object is +returned to Web API module. On successful validation the qualified validation report Java object sent from validation +service is returned to Web API module. + +!!! note + Validation services can be added dynamically to SiVa by conforming to pattern `documentType + "ValidationService"` and new + validation service module must be Maven dependency of `siva-validation-proxy`. Example + would be `BDOCValidationService`. + +## Validation reporting service + +**Validation reporting service** is optional module that can be turned on or off using configuration file. It's Spring Boot module and +main purpose is to collect data about: incoming request, validation reports and errors that have been reported during validation process. + +When HTTP authentication header have been set the reporting service will also collect its and adds to required statistics reports. + +After the report object have been created the data will be sent to configured reporting service. SiVa is preconfigured to work with +Google Analytics. + +## TSL Loader + +TSL loader loads in contents of TSL file from given URL in online mode or from directory when +using offline mode in predefined interval. + +## Validation services + +All validation services use different Java library to validate given document in request. The used validation +library is described in each of the validation service section. + +Common process that all validation services do with proxy forwarded validation process is: + +* Convert the Base64 encoded document into `InputStream` byte array +* Check that given document is correct format (i.e valid BDOC). If not then error is thrown and + validation process is terminated. +* After validation of signatures has been completed the validation service starts to build + qualified validation report +* Validation report is created even validation `FAILED` or ended with `INDETERMINATE` result + +### PDF Validation service + +PDF or PaDES as known in DSS validation service uses [Digidoc4J DSS fork Java library](https://github.com/open-eid/sd-dss) PaDES validation +functionality using the validation policy that complies with Estonian laws and regulations. + +Configurable functionality: + +* Possibility to add additional validation policies using SiVa `application.yml` configuration section. + +### BDOC validation service + +BDOC for ASiC compliant containers both TM and TS will latest Maven released **DigiDoc4J** library + +### DDOC Validation service + +DDOC for previous generation digitally signed files will use latest Maven release of **JDigiDoc** + +### X-Road validation service + +X-Road containers are similar to ASiCE containers but are **not** valid ASiCE containers. There we could not use DSS nor DigiDoc4J provided +ASiCE validation functionality but need to X-Road developed `asicverifier` Java command line utility to validate these containers. + +Source code for `asicverifier` can be found in [GitHub xroad-public repository](https://github.com/ria-ee/X-Road/tree/master/src/asicverifier)*[]: +`Asicverfier` has been integrated into SiVa as Java library. Making possible to use all the Java libraries packaged into `asicverifier` fat JAR. + +Configurable functionality: + +* In SiVa configuration `application.yml` file You can define alternative location for `globalconf` directory to be loaded in using input stream diff --git a/docs/siva2/definitions.md b/docs/siva2/definitions.md index b609712b2..bbac7bcac 100644 --- a/docs/siva2/definitions.md +++ b/docs/siva2/definitions.md @@ -1,43 +1,43 @@ - - -BDOC -: A digital signature format that was created in order to replace the DDOC (DigiDoc) digital signature format that is specific to Estonia. - -DDOC -: A format of digitally signed files based on the ETSI TS 101 903 Standard that is called ‘XML Advanced Electronic Signatures (XAdES)’. The standard describes the structure of digitally signed documents on various levels of incorporation of additional validity verification information. DigiDoc corresponds to the XAdES profile ‘XAdES-X-L’. - -DSS -: Digital Signature Services is Java library to sign and validate European digital signature formats - -Fat JAR -: The fat JAR is the JAR, which contains classes from all the libraries, on which your project depends and, - the classes of built project. - -JAR -: Java Archive is a package file format typically used to aggregate many Java class files and associated metadata - and resources (text, images, etc.) into one file to distribute application software or libraries on the Java platform. - -JVM -: The Java Virtual Machine is the runtime engine of the Java Platform, which - allows any program written in Java or other language compiled into Java bytecode to run on any - computer that has a native JVM. - -Linux -: an operating system, based on UNIX, that runs on many different hardware platforms and whose source - code is available to the public. - -PDF -: Portable document format is a file format that provides an electronic image of text or text and graphics that - looks like a printed document and can be viewed, printed, and electronically transmitted. - -SiVa -: is RESTful web service providing digital signature validation services for BDOC, DDOC, PDF and X-Road - files - -Spring Boot -: is a framework from the team at Pivotal, designed to simplify the bootstrapping and development of a new - Spring application. The framework takes an opinionated approach to configuration, freeing developers from the - need to define boilerplate configuration - -X-Road + + +BDOC +: A digital signature format that was created in order to replace the DDOC (DigiDoc) digital signature format that is specific to Estonia. + +DDOC +: A format of digitally signed files based on the ETSI TS 101 903 Standard that is called ‘XML Advanced Electronic Signatures (XAdES)’. The standard describes the structure of digitally signed documents on various levels of incorporation of additional validity verification information. DigiDoc corresponds to the XAdES profile ‘XAdES-X-L’. + +DSS +: Digital Signature Services is Java library to sign and validate European digital signature formats + +Fat JAR +: The fat JAR is the JAR, which contains classes from all the libraries, on which your project depends and, + the classes of built project. + +JAR +: Java Archive is a package file format typically used to aggregate many Java class files and associated metadata + and resources (text, images, etc.) into one file to distribute application software or libraries on the Java platform. + +JVM +: The Java Virtual Machine is the runtime engine of the Java Platform, which + allows any program written in Java or other language compiled into Java bytecode to run on any + computer that has a native JVM. + +Linux +: an operating system, based on UNIX, that runs on many different hardware platforms and whose source + code is available to the public. + +PDF +: Portable document format is a file format that provides an electronic image of text or text and graphics that + looks like a printed document and can be viewed, printed, and electronically transmitted. + +SiVa +: is RESTful web service providing digital signature validation services for BDOC, DDOC, PDF and X-Road + files + +Spring Boot +: is a framework from the team at Pivotal, designed to simplify the bootstrapping and development of a new + Spring application. The framework takes an opinionated approach to configuration, freeing developers from the + need to define boilerplate configuration + +X-Road : X-Road, the data exchange layer for information systems, is a technological and organizational environment enabling a secure Internet-based data exchange between information systems. \ No newline at end of file diff --git a/docs/siva2/deployment.md b/docs/siva2/deployment.md index d830e7bcc..cb7616169 100644 --- a/docs/siva2/deployment.md +++ b/docs/siva2/deployment.md @@ -1,20 +1,20 @@ -The deployment view of the architecture describes the various physical nodes in the most typical configuration for SiVa service provider. - -![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) - -### Nodes - -In the following section, a description of each network node element is described in detail. - -| Node | Setup description | -| ------ | ----------- | -| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used.| -| **Siva server** | Two separate services are set up to run on SiVa server: the **SiVa webapp** itself and the **X-road validation webapp**, to provide X-road support
  • SiVa webapp

SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.

There also should be separate user created to run executalbe JAR as Linux service.

Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service)
  • X-road validation webapp

SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081

Note that X-Road separate installation is required to avoid BouncyCastle library version conflicts and class loader issues.| -| **X-road security server** | A standard X-road security server setup. The SiVa validation service wsdl has to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaton (see the [official installation instructions](https://www.ria.ee/en/x-road-instructions.html#v6)).| -| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation.
  • Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service.
| - -### Horizontal scaling - -Neither the **Siva webapp**, **X-road validation webapp**, nor **Demo wbapp** persist their state in sessions between requests. Therefore it is possible to install multiple instances of these services behind respective load balancers. - - +The deployment view of the architecture describes the various physical nodes in the most typical configuration for SiVa service provider. + +![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) + +### Nodes + +In the following section, a description of each network node element is described in detail. + +| Node | Setup description | +| ------ | ----------- | +| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used.| +| **Siva server** | Two separate services are set up to run on SiVa server: the **SiVa webapp** itself and the **X-road validation webapp**, to provide X-road support
  • SiVa webapp

SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.

There also should be separate user created to run executalbe JAR as Linux service.

Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service)
  • X-road validation webapp

SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081

Note that X-Road separate installation is required to avoid BouncyCastle library version conflicts and class loader issues.| +| **X-road security server** | A standard X-road security server setup. The SiVa validation service wsdl has to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaton (see the [official installation instructions](https://www.ria.ee/en/x-road-instructions.html#v6)).| +| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation.
  • Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service.
| + +### Horizontal scaling + +Neither the **Siva webapp**, **X-road validation webapp**, nor **Demo wbapp** persist their state in sessions between requests. Therefore it is possible to install multiple instances of these services behind respective load balancers. + + diff --git a/docs/siva2/deployment_view.md b/docs/siva2/deployment_view.md index a27566681..ba021290d 100644 --- a/docs/siva2/deployment_view.md +++ b/docs/siva2/deployment_view.md @@ -1,34 +1,34 @@ - - -![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) - -## Load balancer - -Load balancer can distribute traffic between SiVa nodes when there is more then one instance running. -SiVa do not set any specific requirements for load balancer but in diagram the Nginx reverse proxy option is used. - -## SiVa web application - -SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are -packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable -if its not already. - -There also should be separate user created to run executalbe JAR as Linux service. - -Read more about running -[Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service) - -## SiVa X-Road validation service - -SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux -service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081 - -X-Road separate installation is required to avoid BouncyCastle libraries version conflicts and class loader -issues. - -## Security server - -Into XRoad v6 security server the SiVa validation service will be registered to provide service to other organisations -using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaiton. - - + + +![SiVa Deployment view](../img/siva/uml_siva_deployment_diagram.png) + +## Load balancer + +Load balancer can distribute traffic between SiVa nodes when there is more then one instance running. +SiVa do not set any specific requirements for load balancer but in diagram the Nginx reverse proxy option is used. + +## SiVa web application + +SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are +packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable +if its not already. + +There also should be separate user created to run executalbe JAR as Linux service. + +Read more about running +[Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service) + +## SiVa X-Road validation service + +SiVa X-Road validation service is also Spring Boot executable JAR application and also should be installed as Linux +service. X-Road validation service communicates with SiVa web application over HTTP and default port is 8081 + +X-Road separate installation is required to avoid BouncyCastle libraries version conflicts and class loader +issues. + +## Security server + +Into XRoad v6 security server the SiVa validation service will be registered to provide service to other organisations +using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaiton. + + diff --git a/docs/siva2/interfaces.md b/docs/siva2/interfaces.md index 23f90fa19..989cb0482 100644 --- a/docs/siva2/interfaces.md +++ b/docs/siva2/interfaces.md @@ -1,829 +1,829 @@ - - -In this section the SiVa external interfaces are described. For information of internal components and their interfaces, please refer to [**Structure and activities**](structure_and_activities). - -SiVa service provides **REST JSON** and **SOAP** interfaces that enable the service users to: - -* Request validation of signatures in a digitally signed document (i.e. signature container like BDOC,ASiC-E/PDF/...); -* Request validation of signature with providing data file hashes. -* Receive a response with the validation result of all the signatures in the document. -* Request datafiles inside of DDOC container -* Receive datafiles from DDOC container - -SiVa service SOAP interface supports X-Road v6. However, it is optional whether to integrate SiVa service using X-Road or using "plain" SOAP interface. This document only describes the SiVa service part of the interface, for the X-Road specifics visit Riigi Infosüsteemi Amet [webpage](https://www.ria.ee/ee/x-tee.html). - -In the following subsections, the SiVa validation request and response interfaces are described in detail. - -## Validation request interface - - -** REST JSON Endpoint ** - -``` -POST https:///validate -``` - -** SOAP Endpoint ** -``` -POST https:///soap/validationWebService/validateDocument -``` - -** SOAP WSDL ** -``` -POST https:///soap/validationWebService/validateDocument?wsdl -``` - -### Validation request parameters - -Validation request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-------------|----------------| -| document | Document | + | String | Base64 encoded string of digitally signed document to be validated | -| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.bdoc), max length 255 characters. | -| documentType | DocumentType | - | String | If not present document type is determined automatically based on the file extension used in the filename. This parameter is necessary to differentiate XROAD ASIC-E containers from standard ASIC-E containers.
**Possible values:**
XROAD - for documents created in the [X-Road](https://www.ria.ee/en/x-road.html) information system, see also [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) of the signature format. | -| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | -| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | - -### Sample JSON request with mandatory parameters - -```json -{ - "filename":"sample.bdoc", - "document":"PD94bWwgdmVyc2lvbj0iMS4...." -} -``` -### Sample JSON request with all parameters - -```json -{ - "filename":"sample.asice", - "document":"PD94bWwgdmVyc2lvbj0iMS4....", - "documentType":"XROAD", - "signaturePolicy":"POLv3", - "reportType":"Detailed" -} -``` - -### Sample SOAP request - -```xml - - - - - - PD94bWwgdmVyc2lvbj0iMS4.... - sample.asice - XROAD - POLv3 - Detailed - - - - -``` - -## Validation request interface for hashcode - -Hashcode XAdES validation is supported for **REST JSON** and **SOAP** interfaces. - -** REST JSON Endpoint ** - -``` -POST https:///validateHashcode -``` - -** SOAP Endpoint ** -``` -POST https:///soap/hashcodeValidationWebService -``` - -** SOAP WSDL ** -``` -POST https:///soap/hashcodeValidationWebService?wsdl -``` - -### Validation request parameters - -Validation request parameters for JSON interface are described in the table below. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|----------------|-------------| -| signatureFile | SignatureFile | + | String | Base64 encoded string of XAdES document to be validated | -| filename | Filename | + | String | File name of the XAdES document (i.e. signature0.xml). Only XML files supported. | -| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | -| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | -| datafiles | DataFiles | + | Array | Array containing the information for datafiles that signature is covering | -| datafiles[0] | DataFile | + | Object | Object containing data file information | -| datafiles.filename | Filename | + | String | File name of the hashed data file, max length 255 characters. | -| datafiles.hashAlgo | HashAlgo | + | String | Hash algorithm used for hashing the data file (must match with algorithm in signature file). Accepted values are dependant of validation policy | -| datafiles.hash | Hash | + | String | Data file hash in Base64 encoded format. | - -### Sample JSON request with mandatory parameters - -```json -{ - "signatureFile": "PD94bWwgdmVyc2lvbj0iMS4...." - "filename": "signature0.xml", - "datafiles": [{ - "filename": "test.pdf", - "hashAlgo": "SHA256", - "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" - }] -} -``` -### Sample JSON request with all parameters and multiple datafiles - -```json -{ - "signatureFile":"sample.asice", - "filename":"PD94bWwgdmVyc2lvbj0iMS4....", - "signaturePolicy":"POLv3", - "reportType":"Detailed", - "datafiles": [{ - "filename": "test.pdf", - "hashAlgo": "SHA256", - "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" - }, - { - "filename": "test2.pdf", - "hashAlgo": "SHA256", - "hash": "IucjUcbRo9Rke0bZLiHc23SSasw9pSrSPr7LKln1EiI=" - }] -} -``` - -### Sample SOAP request with mandatory parameters - -```xml - - - - - PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... - signature.xml - - - test.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - - - - -``` -### Sample SOAP request with all parameters and multiple datafiles - -```xml - - - - - PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... - signature.xml - Simple - POLv4 - - - test.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - test2.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - test3.pdf - SHA256 - IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= - - - - - - -``` - -## Validation response interface -The signature validation report (i.e. the validation response) for JSON and SOAP interfaces depends on what type of validation report was requested. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva2/appendix/wsdl). - -### Validation response parameters Simple Report (successful scenario) - -General structure of validation response. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-----------------|-------------| -| validationReport | ValidationReport | + | Object | Object containing SIVA validation report | -| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion | - -Structure of validationConclusion block - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-----------------|-------------| -| policy | Policy | + | Object | Object containing information of the SiVa signature validation policy that was used for validation. | -| policy.policyName | Policy.PolicyName | + | String | Name of the validation policy | -| policy. policyDescription | Policy. PolicyDescription | + | String | Short description of the validation policy. | -| policy.policyUrl | Policy.PolicyUrl | + | String | URL where the signature validation policy document can be downloaded. The validation policy document shall include information about validation of all the document formats, including the different validation policies that are used in case of different file formats and base libraries. | -| signaturesCount | SignaturesCount | + | Number | Number of signatures found inside digitally signed file. | -| validSignaturesCount | ValidSignaturesCount | + | Number | Signatures count that have validated to `TOTAL-PASSED`. See also `Signature.Indication` field. | -| validationLevel | ValidationLevel | - | Date | Validation process against what the document is validated, only applicable on DSS based validations.
**Possible values:**
ARCHIVAL_DATA| -| validationTime | ValidationTime | + | Date | Time of validating the signature by the service. | -| validationWarnings | ValidationWarnings | - | Array | Array of SiVa validation warnings that do not affect the overall validation result. See also `signatures.warnings` parameter. | -| validationWarnings[0] | ValidationWarning | + | Object | Object containing the warning. | -| validationWarnings[0]. content | ValidationWarning. Content| + | String | Description of the warning. | -| validatedDocument | ValidatedDocument | + | Object | Object containing information about validated document. | -| validatedDocument. filename | ValidatedDocument. Filename | + | String | Digitally signed document's file name. | -| validatedDocument. fileHashInHex | ValidatedDocument. FileHashInHex | - | String | Calculated hash in hex of validated document. | -| validatedDocument. hashAlgo | ValidatedDocument. HashAlgo | - | String | Hash algorithm used. | -| signatureForm | SignatureForm | - | String | Format (and optionally version) of the digitally signed document container.
In case of documents in [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) format, the "hashcode" suffix is used to denote that the container was validated in [hashcode mode](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode), i.e. without original data files.
**Possible values:**
DIGIDOC_XML_1.0
DIGIDOC_XML_1.0_hashcode
DIGIDOC_XML_1.1
DIGIDOC_XML_1.1_hashcode
DIGIDOC_XML_1.2
DIGIDOC_XML_1.2_hashcode
DIGIDOC_XML_1.3
DIGIDOC_XML_1.3_hashcode
ASiC_E - used in case of all ASIC-E ([BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf)) documents and X-Road simple containers that don't use batch time-stamping (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_E_batchsignature - used in case of X-Road containers with batch signature (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_S - used in case of all ASIC-S documents | -| signatures | Signatures | - | Array | Collection of signatures found in digitally signed document | -| signatures[0] | Signature | + | Object | Signature information object | -| signatures[0]. claimedSigningTime | Signature. ClaimedSigningTime | + | Date | Claimed signing time, i.e. signer's computer time during signature creation | -| signatures[0].id | Signature.Id | + | String | Signature ID attribute | -| signatures[0].indication | Signature.Indication | + | String | Overall result of the signature's validation process, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 5: Status indications of the signature validation process".
Note that the validation results of different signatures in one signed document (signature container) may vary.
See also `validSignaturesCount` and `SignaturesCount` fields.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED
INDETERMINATE | -| signatures[0]. subIndication | Signature. SubIndication | - | String | Additional subindication in case of failed or indeterminate validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics" | -| signatures[0].errors | Signature.Errors | - | Array | Information about validation error(s), array of error messages. | -| signatures[0].errors[0] | Signature.Errors. Error | + | Object | Object containing the error | -| signatures[0].errors[0]. content | Signature.Errors. Error.Content | + | String | Error message, as returned by the base library that was used for signature validation. | -| signatures[0].info | Signature.Info | - | Object | Object containing trusted signing time information. | -| signatures[0].info. bestSignatureTime | Signature.Info. BestSignatureTime | + | Date | Time value that is regarded as trusted signing time, denoting the earliest time when it can be trusted by the validation application (because proven by some Proof-of-Existence present in the signature) that a signature has existed.
The source of the value depends on the signature profile (see also `SignatureFormat` parameter):
- Signature with time-mark (LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature.
- Signature with time-stamp (LT or LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature.
- Signature with BES or EPES level - the value is empty, i.e. there is no trusted signing time value available. | -| signatures[0]. signatureFormat | Signature. SignatureFormat | + | String | Format and profile (according to Baseline Profile) of the signature. See [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf), [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) and [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) for detailed description of the Baseline Profile levels. Levels that are accepted in SiVa validation policy are described in [SiVa signature validation policy](/siva/appendix/validation_policy)
**Possible values:**
XAdES_BASELINE_B
XAdES_BASELINE_B_BES
XAdES_BASELINE_B_EPES
XAdES_BASELINE_T
XAdES_BASELINE_LT - long-term level XAdES signature where time-stamp is used as a assertion of trusted signing time
XAdES_BASELINE_LT_TM - long-term level XAdES signature where time-mark is used as a assertion of trusted signing time. Used in case of [BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) signatures with time-mark profile and [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) signatures.
XAdES_BASELINE_LTA
CAdES_BASELINE_B
CAdES_BASELINE_T
CAdES_BASELINE_LT
CAdES_BASELINE_LTA
PAdES_BASELINE_B
PAdES_BASELINE_T
PAdES_BASELINE_LT
PAdES_BASELINE_LTA | -| signatures[0]. signatureLevel | Signature. SignatureLevel | - |String | Legal level of the signature, according to Regulation (EU) No 910/2014.
- **Possible values on positive validation result:**
QESIG
QESEAL
QES
ADESIG_QC
ADESEAL_QC
ADES_QC
ADESIG
ADESEAL
ADES
- **Possible values on indeterminate validation result:**
prefix INDETERMINATE is added to the level described in positive result. For example INDETERMINATE_QESIG
- **Possible values on negative validation result:**
In addition to abovementioned
NOT_ADES_QC_QSCD
NOT_ADES_QC
NOT_ADES
NA
- In case of DIGIDOC-XML 1.0..1.3 formats, value is missing as the signature level is not checked by the JDigiDoc base library that is used for validation. However, the signatures can be indirectly regarded as QES level signatures, see also [SiVa Validation Policy](/siva2/appendix/validation_policy)
- In case of XROAD ASICE containers the value is missing as the asicverifier base library do not check the signature level.| -| signatures[0].signedBy | Signature.SignedBy | + | String | Signers name and identification number, i.e. value of the CN field of the signer's certificate | -| signatures[0]. signatureScopes | Signature. SignatureScopes | - | Array | Contains information of the original data that is covered by the signature. | -| signatures[0]. signatureScopes[0]. name | Signature. SignatureScopes. SignatureScope.Name | + | String | Name of the signature scope. | -| signatures[0]. signatureScopes[0]. scope | Signature. SignatureScopes. SignatureScope. Scope | + | String | Type of the signature scope. | -| signatures[0]. signatureScopes[0]. content | Signature. SignatureScopes. SignatureScope. Content | + | String | Description of the scope. | -| signatures[0]. warnings | Signature.Warnings | - | Array | Block of validation warnings that do not affect the overall validation result. | -| signatures[0]. warnings[0] | Signature.Warnings. Warning | + | Object | Object containing the warning | -| signatures[0]. warnings[0]. content | Signature.Warnings. Warning.Description | + | String | Warning description, as retuned by the base library that was used for validation. | -| timeStampTokens | TimeStampTokens | - | Array | Array containing the time stamp tokens | -| timeStampTokens[0]. | TimeStampToken | + | Object | Object containing the time stamp token (TST) | -| timeStampTokens[0]. indication | TimeStampToken. Indication | + | String | Result of the time stamp token validation.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED | -| timeStampTokens[0]. signedBy | TimeStampToken. SignedBy | + | String | Signer of the time stamp token. | -| timeStampTokens[0]. signedTime | TimeStampToken. SignedTime | + | String | Time when the time stamp token was given. | -| timeStampTokens[0]. error | TimeStampToken. Errors| - | Array | Errors returned in time stamp token validation. | -| timeStampTokens[0]. error[0] | Errors. Error | + | Object | Object containing the error. | -| timeStampTokens[0]. error[0]. content | Error. Content | + | String | Error description. | - -#### Sample JSON response Simple Report (successful scenario) - -```json -{"validationReport": -{"validationConclusion": { - "validationTime": "2017-11-07T08:14:07Z", - "signaturesCount": 1, - "validationLevel": "ARCHIVAL_DATA", - "validatedDocument": { - "filename": "ValidLiveSignature.asice", - "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", - "hashAlgo": "SHA-256" - }, - "validSignaturesCount": 1, - "signatures": [{ - "signatureFormat": "XAdES_BASELINE_LT", - "signedBy": "NURM,AARE,38211015222", - "claimedSigningTime": "2016-10-11T09:35:48Z", - "signatureLevel": "QESIG", - "warnings": [{"content": "The trusted list is not fresh!"}], - "signatureScopes": [{ - "scope": "FullSignatureScope", - "name": "Tresting.txt", - "content": "Full document" - }], - "id": "S0", - "indication": "TOTAL-PASSED", - "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} - }], - "policy": { - "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", - "policyUrl": "http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4", - "policyName": "POLv4" - }, - "signatureForm": "ASiC_E" -}}} -``` - -#### Sample SOAP response Simple Report (successful scenario) - -```xml - - - - - - - - Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - POLv4 - http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 - - 2017-11-07T08:14:07Z - - ValidLiveSignature.asice - 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 - SHA-256 - - ARCHIVAL_DATA - - ASiC_E - - - S0 - XAdES_BASELINE_LT - QESIG - NURM,AARE,38211015222 - TOTAL-PASSED - - - - - Tresting.txt - FullSignatureScope - Full document - - - 2016-10-11T09:35:48Z - - - The trusted list is not fresh! - - - - 2016-10-11T09:36:10Z - - - - 1 - 1 - - - - - -``` - -### Validation response parameters Detailed Report (successful scenario) - -General structure of validation response. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|-----------------|-------------| -| validationReport | ValidationReport | + | Object | Object containing SIVA validation report. | -| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report. | -| validationReport. validationProcess | ValidationReport. ValidationProcess | - | Object | Object containing information of the validation process. This block is present only on DSS library based validations and is built on DSS detailed report. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/dss-documentation.adoc#validation-process). | -| validationReportSignature | ValidationReportSignature | - | String | Base64 string of ASIC-E container that includes the detailed report and is signed by the validation service provider | - -#### Sample JSON response Detailed Report (successful scenario). The report is shortened but gives general overview of structure. - -```json -{ - "validationReport": { - "validationProcess": { - "qmatrixBlock": { - "tlanalysis": [{ - "conclusion": {"indication": "PASSED"}, - "countryCode": "EU", - "constraint": [ - { - "name": { - "nameId": "QUAL_TL_FRESH", - "value": "Is the trusted list fresh ?" - }, - "status": "OK" - }, - ... - ] - }, - { - "conclusion": {"indication": "PASSED"}, - "countryCode": "EE", - "constraint": [{ - "name": { - "nameId": "QUAL_TL_FRESH", - "value": "Is the trusted list fresh ?" - }, - "status": "OK" - }, - ... - ] - } - ], - "signatureAnalysis": [{ - "conclusion": {"indication": "PASSED"}, - "signatureQualification": "QESIG", - "constraint": [{ - "name": { - "nameId": "QUAL_IS_ADES", - "value": "Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ?" - }, - "status": "OK" - }, - ... - ], - "id": "S0" - }] - }, - "basicBuildingBlocks": [{ - "conclusion": {"indication": "PASSED"}, - "cv": { - "conclusion": {"indication": "PASSED"}, - "constraint": [{ - "name": { - "nameId": "BBB_CV_IRDOF", - "value": "Is the reference data object(s) found?" - }, - "status": "OK" - }, - ... - ]}, - ... - "id": "1561CD6BEA97B0A72664067021330509894BE1EBA586D3057D77787E5F4180A4", - "type": "TIMESTAMP" - }, - ... - "signatures": [{ - "validationProcessArchivalData": { - "conclusion": {"indication": "PASSED"}, - "constraint": [{ - "name": { - "nameId": "ARCH_LTVV", - "value": "Is the result of the LTV validation process acceptable?" - }, - "status": "OK" - }]}, - ... - }, - "id": "S0", - "validationProcessLongTermData": { - "conclusion": {"indication": "PASSED"}, - "constraint": [{ - "name": { - "nameId": "LTV_ABSV", - "value": "Is the result of the Basic Validation Process acceptable?"}, - "status": "OK" - }, - ... - }]}}] - }, - "validationConclusion": { - "validationTime": "2017-11-07T09:20:18Z", - "signaturesCount": 1, - "validationLevel": "ARCHIVAL_DATA", - "validatedDocument": { - "filename": "ValidLiveSignature.asice", - "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", - "hashAlgo": "SHA-256" - }, - "validSignaturesCount": 1, - "signatures": [{ - "signatureFormat": "XAdES_BASELINE_LT", - "signedBy": "NURM,AARE,38211015222", - "claimedSigningTime": "2016-10-11T09:35:48Z", - "signatureLevel": "QESIG", - "signatureScopes": [{ - "scope": "FullSignatureScope", - "name": "Tresting.txt", - "content": "Full document" - }], - "id": "S0", - "indication": "TOTAL-PASSED", - "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} - }], - "policy": { - "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", - "policyUrl": "http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4", - "policyName": "POLv4" - }, - "signatureForm": "ASiC_E" - } - }, - "validationReportSignature": "UEsDBBQACAgIAIlaZ0sAA..." -} - -``` - -#### Sample SOAP response Simple Report (successful scenario) - -```xml - - - - - - - - Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. - POLv4 - http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 - - 2017-11-07T09:20:18Z - - ValidLiveSignature.asice - 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 - SHA-256 - - ARCHIVAL_DATA - - ASiC-E - - - S0 - XAdES_BASELINE_LT - QESIG - NURM,AARE,38211015222 - TOTAL-PASSED - - - - - Tresting.txt - FullSignatureScope - Full document - - - 2016-10-11T09:35:48Z - - - 2016-10-11T09:36:10Z - - - - 1 - 1 - - - - - - Is the result of the Basic Validation Process conclusive? - OK - - - PASSED - - - ... - - - Is the result of the LTV validation process acceptable? - OK - - - PASSED - - - - ... - - - - Is the expected format found? - OK - - ... - - - Can the certificate chain be built till the trust anchor? - OK - - - - - ... - - Is the trusted list well signed ? - OK - - - PASSED - - - ... - - - Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ? - OK - - ... - - PASSED - - - - - - UEsDBBQACAgIAIlaZ0s... - - - - -``` - -### Sample JSON response (error situation) -In case of error (when validation report is not returned) status code 400 is returned together with following message body: - -```json -{"requestErrors": [{ - "message": "Document malformed or not matching documentType", - "key": "document" -}]} -``` - -### Sample SOAP response (error situation) - -```xml - - - - - soap:Server - Document malformed or not matching documentType - - - -``` - -## Data files request interface - - -** REST JSON Endpoint ** - -``` -POST https:///getDataFiles -``` - -** SOAP Endpoint ** -``` -POST https:///soap/dataFilesWebService/getDocumentDataFiles -``` - -** SOAP WSDL ** -``` -POST https:///soap/dataFilesWebService/getDocumentDataFiles?wsdl -``` - -### Data files request parameters - -Data files request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|----------------|-------------| -| document | Document | + | String | Base64 encoded string of digitally signed DDOC document | -| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.ddoc), max length 255 characters. Currently only DDOC file format is supported for this operation| - -### Sample JSON request - -```json -{ - "filename":"sample.ddoc", - "document":"PD94bWwgdmVyc2lvbj0iMS4...." -} -``` - - -### Sample SOAP request - -```xml - - - - - - PD94bWwgdmVyc2lvbj0iMS4wI... - sample.ddoc - - - - -``` - - -## Data files response interface - -### Data files response parameters (successful scenario) - -The data file extraction report (i.e. the data files response) for JSON and SOAP interfaces is described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). -SiVa returns all data files as they are extracted by JDigiDoc library in an as is form. No extra operations or validations are done. - -| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | -|----------------|----------------|-----------|----------------|-------------| -| dataFiles | DataFiles | - | Array | Collection of data files found in digitally signed document | -| dataFiles[0] | DataFile | + | Object | Extracted data file object | -| dataFiles[0].fileName | DataFile.FileName | - | String | File name of the extracted data file | -| dataFiles[0].size | DataFile.Size | - | Long | Extracted data file size in bytes | -| dataFiles[0].base64 | DataFile.Base64 | - |String | Base64 encoded string of extracted data file | -| dataFiles[0].mimeType | DataFile.MimeType | - | String | MIME type of the extracted data file | - -### Sample JSON response (successful scenario) - -```json -{ -"dataFiles": [{ - "fileName": "Glitter-rock-4_gallery.jpg", - "size": 41114, - "base64": "/9j/4AAQSkZJ...", - "mimeType": "application/octet-stream" }] -} -``` - -### Sample SOAP response (successful scenario) - -```xml - - - - - - - - UCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUH... - Glitter-rock-4_gallery.jpg - application/octet-stream - 41114 - - - - - - -``` - -### Sample JSON response (error situation) -In case of error (when datafiles are not returned) status code 400 is returned together with following message body: - -```json -{"requestErrors": [{ - "message": "Invalid document type. Can only return data files for DDOC type containers.", - "key": "documentType" -}]} -``` - -### Sample SOAP response (error situation) - -```xml - - - - - soap:Client - Invalid document type. Can only return data files for DDOC type containers. - - - -``` - - - -## Service health monitoring - -SiVa webapps provide an interface for external monitoring tools (to periodically check the generic service health status). - -### The request -The monitoring endpoint is accessible via HTTP GET at **/monitoring/health** or **/monitoring/health.json** url. - -Sample request: -``` -GET https:///monitoring/health -``` - -### The response - -As a response, a JSON object is returned with the following information: - -| Field | Description | -| ---------| --------------- | -| status | General status of the webapp.
Possible values:
  • **DOWN** - when some of the dependent indicators status are down (ie when `link{number}.status` is DOWN, the overall service status is DOWN)
  • **UP** - the default value.
| -| health.status | Status of current webapp - constant value **UP** | -| health.webappName | The artifact name of the webapp. Taken from the MANIFEST.MF file (inside the jar/war file). | -| health.version | The release version fo the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | -| health.buildTime | Build date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') of the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | -| health.startTime | Webapp startup date and time (format yyyy-MM-dd'T'HH:mm:ss'Z')| -| health.currentTime | Current server date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') | -| link{number}.status | (OPTIONAL) Represents the status of a link to the external system that the webapp depends on.
  • **DOWN** when the webapp does not respond (within a specified timeout limit - default 10 seconds) or the response is in invalid format (default Spring boot actuator /health endpoint format is expected).
  • **UP** if the service responds with HTTP status code 200 and returns a valid JSON object with status "UP"
|) | -| link{number}.name | (OPTIONAL) Descriptive name for the link to the external system | - -Sample response: - -```json -{ - "status":"UP", - "health":{ - "status":"UP", - "webappName":"siva-demo-application", - "version":"3.1.0", - "buildTime":"2016-10-21T15:56:21Z", - "startTime":"2016-10-21T15:57:48Z", - "currentTime":"2016-10-21T15:58:39Z" - }, - "link1":{ - "status":"UP", - "name":"sivaService" - } -} -``` + + +In this section the SiVa external interfaces are described. For information of internal components and their interfaces, please refer to [**Structure and activities**](structure_and_activities). + +SiVa service provides **REST JSON** and **SOAP** interfaces that enable the service users to: + +* Request validation of signatures in a digitally signed document (i.e. signature container like BDOC,ASiC-E/PDF/...); +* Request validation of signature with providing data file hashes. +* Receive a response with the validation result of all the signatures in the document. +* Request datafiles inside of DDOC container +* Receive datafiles from DDOC container + +SiVa service SOAP interface supports X-Road v6. However, it is optional whether to integrate SiVa service using X-Road or using "plain" SOAP interface. This document only describes the SiVa service part of the interface, for the X-Road specifics visit Riigi Infosüsteemi Amet [webpage](https://www.ria.ee/ee/x-tee.html). + +In the following subsections, the SiVa validation request and response interfaces are described in detail. + +## Validation request interface + + +** REST JSON Endpoint ** + +``` +POST https:///validate +``` + +** SOAP Endpoint ** +``` +POST https:///soap/validationWebService/validateDocument +``` + +** SOAP WSDL ** +``` +POST https:///soap/validationWebService/validateDocument?wsdl +``` + +### Validation request parameters + +Validation request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-------------|----------------| +| document | Document | + | String | Base64 encoded string of digitally signed document to be validated | +| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.bdoc), max length 255 characters. | +| documentType | DocumentType | - | String | If not present document type is determined automatically based on the file extension used in the filename. This parameter is necessary to differentiate XROAD ASIC-E containers from standard ASIC-E containers.
**Possible values:**
XROAD - for documents created in the [X-Road](https://www.ria.ee/en/x-road.html) information system, see also [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf) of the signature format. | +| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | +| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | + +### Sample JSON request with mandatory parameters + +```json +{ + "filename":"sample.bdoc", + "document":"PD94bWwgdmVyc2lvbj0iMS4...." +} +``` +### Sample JSON request with all parameters + +```json +{ + "filename":"sample.asice", + "document":"PD94bWwgdmVyc2lvbj0iMS4....", + "documentType":"XROAD", + "signaturePolicy":"POLv3", + "reportType":"Detailed" +} +``` + +### Sample SOAP request + +```xml + + + + + + PD94bWwgdmVyc2lvbj0iMS4.... + sample.asice + XROAD + POLv3 + Detailed + + + + +``` + +## Validation request interface for hashcode + +Hashcode XAdES validation is supported for **REST JSON** and **SOAP** interfaces. + +** REST JSON Endpoint ** + +``` +POST https:///validateHashcode +``` + +** SOAP Endpoint ** +``` +POST https:///soap/hashcodeValidationWebService +``` + +** SOAP WSDL ** +``` +POST https:///soap/hashcodeValidationWebService?wsdl +``` + +### Validation request parameters + +Validation request parameters for JSON interface are described in the table below. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|----------------|-------------| +| signatureFile | SignatureFile | + | String | Base64 encoded string of XAdES document to be validated | +| filename | Filename | + | String | File name of the XAdES document (i.e. signature0.xml). Only XML files supported. | +| signaturePolicy | SignaturePolicy | - | String | Can be used to change the default signature validation policy that is used by the service.
See also [SiVa Validation Policy](/siva2/appendix/validation_policy) for more detailed information on given policy constraints.
**Possible values:**
POLv3 - signatures with all legal levels are accepted (i.e. QES, AdESqc and AdES, according to Regulation (EU) No 910/2014.)
POLv4 - the default policy. Accepted signatures depend on their type (i.e. signature, seal or unknown) and legal level (i.e. QES, AdESqc and Ades) | +| reportType | ReportType | - | String | Can be used to change the default returned report type.
**Possible values:**
Simple - default report type. Returns overall validation result (validationConclusion block)
Detailed - returns detailed information about the signatures and their validation results (validationConclusion, validationProcess and validationReportSignature. Two later ones are optionally present). | +| datafiles | DataFiles | + | Array | Array containing the information for datafiles that signature is covering | +| datafiles[0] | DataFile | + | Object | Object containing data file information | +| datafiles.filename | Filename | + | String | File name of the hashed data file, max length 255 characters. | +| datafiles.hashAlgo | HashAlgo | + | String | Hash algorithm used for hashing the data file (must match with algorithm in signature file). Accepted values are dependant of validation policy | +| datafiles.hash | Hash | + | String | Data file hash in Base64 encoded format. | + +### Sample JSON request with mandatory parameters + +```json +{ + "signatureFile": "PD94bWwgdmVyc2lvbj0iMS4...." + "filename": "signature0.xml", + "datafiles": [{ + "filename": "test.pdf", + "hashAlgo": "SHA256", + "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" + }] +} +``` +### Sample JSON request with all parameters and multiple datafiles + +```json +{ + "signatureFile":"sample.asice", + "filename":"PD94bWwgdmVyc2lvbj0iMS4....", + "signaturePolicy":"POLv3", + "reportType":"Detailed", + "datafiles": [{ + "filename": "test.pdf", + "hashAlgo": "SHA256", + "hash": "IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI=" + }, + { + "filename": "test2.pdf", + "hashAlgo": "SHA256", + "hash": "IucjUcbRo9Rke0bZLiHc23SSasw9pSrSPr7LKln1EiI=" + }] +} +``` + +### Sample SOAP request with mandatory parameters + +```xml + + + + + PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... + signature.xml + + + test.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + + + + +``` +### Sample SOAP request with all parameters and multiple datafiles + +```xml + + + + + PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu... + signature.xml + Simple + POLv4 + + + test.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + test2.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + test3.pdf + SHA256 + IucjUcbRo9Rke0bZLiHcwiIiplP9pSrSPr7LKln1EiI= + + + + + + +``` + +## Validation response interface +The signature validation report (i.e. the validation response) for JSON and SOAP interfaces depends on what type of validation report was requested. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva2/appendix/wsdl). + +### Validation response parameters Simple Report (successful scenario) + +General structure of validation response. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-----------------|-------------| +| validationReport | ValidationReport | + | Object | Object containing SIVA validation report | +| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion | + +Structure of validationConclusion block + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-----------------|-------------| +| policy | Policy | + | Object | Object containing information of the SiVa signature validation policy that was used for validation. | +| policy.policyName | Policy.PolicyName | + | String | Name of the validation policy | +| policy. policyDescription | Policy. PolicyDescription | + | String | Short description of the validation policy. | +| policy.policyUrl | Policy.PolicyUrl | + | String | URL where the signature validation policy document can be downloaded. The validation policy document shall include information about validation of all the document formats, including the different validation policies that are used in case of different file formats and base libraries. | +| signaturesCount | SignaturesCount | + | Number | Number of signatures found inside digitally signed file. | +| validSignaturesCount | ValidSignaturesCount | + | Number | Signatures count that have validated to `TOTAL-PASSED`. See also `Signature.Indication` field. | +| validationLevel | ValidationLevel | - | Date | Validation process against what the document is validated, only applicable on DSS based validations.
**Possible values:**
ARCHIVAL_DATA| +| validationTime | ValidationTime | + | Date | Time of validating the signature by the service. | +| validationWarnings | ValidationWarnings | - | Array | Array of SiVa validation warnings that do not affect the overall validation result. See also `signatures.warnings` parameter. | +| validationWarnings[0] | ValidationWarning | + | Object | Object containing the warning. | +| validationWarnings[0]. content | ValidationWarning. Content| + | String | Description of the warning. | +| validatedDocument | ValidatedDocument | + | Object | Object containing information about validated document. | +| validatedDocument. filename | ValidatedDocument. Filename | + | String | Digitally signed document's file name. | +| validatedDocument. fileHashInHex | ValidatedDocument. FileHashInHex | - | String | Calculated hash in hex of validated document. | +| validatedDocument. hashAlgo | ValidatedDocument. HashAlgo | - | String | Hash algorithm used. | +| signatureForm | SignatureForm | - | String | Format (and optionally version) of the digitally signed document container.
In case of documents in [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) format, the "hashcode" suffix is used to denote that the container was validated in [hashcode mode](http://sertkeskus.github.io/dds-documentation/api/api_docs/#ddoc-format-and-hashcode), i.e. without original data files.
**Possible values:**
DIGIDOC_XML_1.0
DIGIDOC_XML_1.0_hashcode
DIGIDOC_XML_1.1
DIGIDOC_XML_1.1_hashcode
DIGIDOC_XML_1.2
DIGIDOC_XML_1.2_hashcode
DIGIDOC_XML_1.3
DIGIDOC_XML_1.3_hashcode
ASiC_E - used in case of all ASIC-E ([BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf)) documents and X-Road simple containers that don't use batch time-stamping (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_E_batchsignature - used in case of X-Road containers with batch signature (see [specification document](https://cyber.ee/research/reports/T-4-23-Profile-for-High-Performance-Digital-Signatures.pdf))
ASiC_S - used in case of all ASIC-S documents | +| signatures | Signatures | - | Array | Collection of signatures found in digitally signed document | +| signatures[0] | Signature | + | Object | Signature information object | +| signatures[0]. claimedSigningTime | Signature. ClaimedSigningTime | + | Date | Claimed signing time, i.e. signer's computer time during signature creation | +| signatures[0].id | Signature.Id | + | String | Signature ID attribute | +| signatures[0].indication | Signature.Indication | + | String | Overall result of the signature's validation process, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 5: Status indications of the signature validation process".
Note that the validation results of different signatures in one signed document (signature container) may vary.
See also `validSignaturesCount` and `SignaturesCount` fields.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED
INDETERMINATE | +| signatures[0]. subIndication | Signature. SubIndication | - | String | Additional subindication in case of failed or indeterminate validation result, according to [ETSI EN 319 102-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31910201/01.01.01_60/en_31910201v010101p.pdf) "Table 6: Validation Report Structure and Semantics" | +| signatures[0].errors | Signature.Errors | - | Array | Information about validation error(s), array of error messages. | +| signatures[0].errors[0] | Signature.Errors. Error | + | Object | Object containing the error | +| signatures[0].errors[0]. content | Signature.Errors. Error.Content | + | String | Error message, as returned by the base library that was used for signature validation. | +| signatures[0].info | Signature.Info | - | Object | Object containing trusted signing time information. | +| signatures[0].info. bestSignatureTime | Signature.Info. BestSignatureTime | + | Date | Time value that is regarded as trusted signing time, denoting the earliest time when it can be trusted by the validation application (because proven by some Proof-of-Existence present in the signature) that a signature has existed.
The source of the value depends on the signature profile (see also `SignatureFormat` parameter):
- Signature with time-mark (LT_TM level) - the producedAt value of the earliest valid time-mark (OCSP confirmation of the signer's certificate) in the signature.
- Signature with time-stamp (LT or LTA level) - the genTime value of the earliest valid signature time-stamp token in the signature.
- Signature with BES or EPES level - the value is empty, i.e. there is no trusted signing time value available. | +| signatures[0]. signatureFormat | Signature. SignatureFormat | + | String | Format and profile (according to Baseline Profile) of the signature. See [XAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf), [CAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf) and [PAdES Baseline Profile](http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.02.02_60/ts_103172v020202p.pdf) for detailed description of the Baseline Profile levels. Levels that are accepted in SiVa validation policy are described in [SiVa signature validation policy](/siva/appendix/validation_policy)
**Possible values:**
XAdES_BASELINE_B
XAdES_BASELINE_B_BES
XAdES_BASELINE_B_EPES
XAdES_BASELINE_T
XAdES_BASELINE_LT - long-term level XAdES signature where time-stamp is used as a assertion of trusted signing time
XAdES_BASELINE_LT_TM - long-term level XAdES signature where time-mark is used as a assertion of trusted signing time. Used in case of [BDOC](http://id.ee/wp-content/uploads/2020/06/bdoc-spec212-eng.pdf) signatures with time-mark profile and [DIGIDOC-XML](https://www.id.ee/wp-content/uploads/2020/08/digidoc_format_1.3.pdf) (DDOC) signatures.
XAdES_BASELINE_LTA
CAdES_BASELINE_B
CAdES_BASELINE_T
CAdES_BASELINE_LT
CAdES_BASELINE_LTA
PAdES_BASELINE_B
PAdES_BASELINE_T
PAdES_BASELINE_LT
PAdES_BASELINE_LTA | +| signatures[0]. signatureLevel | Signature. SignatureLevel | - |String | Legal level of the signature, according to Regulation (EU) No 910/2014.
- **Possible values on positive validation result:**
QESIG
QESEAL
QES
ADESIG_QC
ADESEAL_QC
ADES_QC
ADESIG
ADESEAL
ADES
- **Possible values on indeterminate validation result:**
prefix INDETERMINATE is added to the level described in positive result. For example INDETERMINATE_QESIG
- **Possible values on negative validation result:**
In addition to abovementioned
NOT_ADES_QC_QSCD
NOT_ADES_QC
NOT_ADES
NA
- In case of DIGIDOC-XML 1.0..1.3 formats, value is missing as the signature level is not checked by the JDigiDoc base library that is used for validation. However, the signatures can be indirectly regarded as QES level signatures, see also [SiVa Validation Policy](/siva2/appendix/validation_policy)
- In case of XROAD ASICE containers the value is missing as the asicverifier base library do not check the signature level.| +| signatures[0].signedBy | Signature.SignedBy | + | String | Signers name and identification number, i.e. value of the CN field of the signer's certificate | +| signatures[0]. signatureScopes | Signature. SignatureScopes | - | Array | Contains information of the original data that is covered by the signature. | +| signatures[0]. signatureScopes[0]. name | Signature. SignatureScopes. SignatureScope.Name | + | String | Name of the signature scope. | +| signatures[0]. signatureScopes[0]. scope | Signature. SignatureScopes. SignatureScope. Scope | + | String | Type of the signature scope. | +| signatures[0]. signatureScopes[0]. content | Signature. SignatureScopes. SignatureScope. Content | + | String | Description of the scope. | +| signatures[0]. warnings | Signature.Warnings | - | Array | Block of validation warnings that do not affect the overall validation result. | +| signatures[0]. warnings[0] | Signature.Warnings. Warning | + | Object | Object containing the warning | +| signatures[0]. warnings[0]. content | Signature.Warnings. Warning.Description | + | String | Warning description, as retuned by the base library that was used for validation. | +| timeStampTokens | TimeStampTokens | - | Array | Array containing the time stamp tokens | +| timeStampTokens[0]. | TimeStampToken | + | Object | Object containing the time stamp token (TST) | +| timeStampTokens[0]. indication | TimeStampToken. Indication | + | String | Result of the time stamp token validation.
**Possible values:**
TOTAL-PASSED
TOTAL-FAILED | +| timeStampTokens[0]. signedBy | TimeStampToken. SignedBy | + | String | Signer of the time stamp token. | +| timeStampTokens[0]. signedTime | TimeStampToken. SignedTime | + | String | Time when the time stamp token was given. | +| timeStampTokens[0]. error | TimeStampToken. Errors| - | Array | Errors returned in time stamp token validation. | +| timeStampTokens[0]. error[0] | Errors. Error | + | Object | Object containing the error. | +| timeStampTokens[0]. error[0]. content | Error. Content | + | String | Error description. | + +#### Sample JSON response Simple Report (successful scenario) + +```json +{"validationReport": +{"validationConclusion": { + "validationTime": "2017-11-07T08:14:07Z", + "signaturesCount": 1, + "validationLevel": "ARCHIVAL_DATA", + "validatedDocument": { + "filename": "ValidLiveSignature.asice", + "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", + "hashAlgo": "SHA-256" + }, + "validSignaturesCount": 1, + "signatures": [{ + "signatureFormat": "XAdES_BASELINE_LT", + "signedBy": "NURM,AARE,38211015222", + "claimedSigningTime": "2016-10-11T09:35:48Z", + "signatureLevel": "QESIG", + "warnings": [{"content": "The trusted list is not fresh!"}], + "signatureScopes": [{ + "scope": "FullSignatureScope", + "name": "Tresting.txt", + "content": "Full document" + }], + "id": "S0", + "indication": "TOTAL-PASSED", + "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} + }], + "policy": { + "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", + "policyUrl": "http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4", + "policyName": "POLv4" + }, + "signatureForm": "ASiC_E" +}}} +``` + +#### Sample SOAP response Simple Report (successful scenario) + +```xml + + + + + + + + Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + POLv4 + http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 + + 2017-11-07T08:14:07Z + + ValidLiveSignature.asice + 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 + SHA-256 + + ARCHIVAL_DATA + + ASiC_E + + + S0 + XAdES_BASELINE_LT + QESIG + NURM,AARE,38211015222 + TOTAL-PASSED + + + + + Tresting.txt + FullSignatureScope + Full document + + + 2016-10-11T09:35:48Z + + + The trusted list is not fresh! + + + + 2016-10-11T09:36:10Z + + + + 1 + 1 + + + + + +``` + +### Validation response parameters Detailed Report (successful scenario) + +General structure of validation response. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|-----------------|-------------| +| validationReport | ValidationReport | + | Object | Object containing SIVA validation report. | +| validationReport. validationConclusion | ValidationReport. ValidationConclusion | + | Object | Object containing information of the validation conclusion. The same object that is present in Simple Report. | +| validationReport. validationProcess | ValidationReport. ValidationProcess | - | Object | Object containing information of the validation process. This block is present only on DSS library based validations and is built on DSS detailed report. For more information visit [DSS documentation](https://github.com/esig/dss/blob/develop/dss-cookbook/src/main/asciidoc/dss-documentation.adoc#validation-process). | +| validationReportSignature | ValidationReportSignature | - | String | Base64 string of ASIC-E container that includes the detailed report and is signed by the validation service provider | + +#### Sample JSON response Detailed Report (successful scenario). The report is shortened but gives general overview of structure. + +```json +{ + "validationReport": { + "validationProcess": { + "qmatrixBlock": { + "tlanalysis": [{ + "conclusion": {"indication": "PASSED"}, + "countryCode": "EU", + "constraint": [ + { + "name": { + "nameId": "QUAL_TL_FRESH", + "value": "Is the trusted list fresh ?" + }, + "status": "OK" + }, + ... + ] + }, + { + "conclusion": {"indication": "PASSED"}, + "countryCode": "EE", + "constraint": [{ + "name": { + "nameId": "QUAL_TL_FRESH", + "value": "Is the trusted list fresh ?" + }, + "status": "OK" + }, + ... + ] + } + ], + "signatureAnalysis": [{ + "conclusion": {"indication": "PASSED"}, + "signatureQualification": "QESIG", + "constraint": [{ + "name": { + "nameId": "QUAL_IS_ADES", + "value": "Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ?" + }, + "status": "OK" + }, + ... + ], + "id": "S0" + }] + }, + "basicBuildingBlocks": [{ + "conclusion": {"indication": "PASSED"}, + "cv": { + "conclusion": {"indication": "PASSED"}, + "constraint": [{ + "name": { + "nameId": "BBB_CV_IRDOF", + "value": "Is the reference data object(s) found?" + }, + "status": "OK" + }, + ... + ]}, + ... + "id": "1561CD6BEA97B0A72664067021330509894BE1EBA586D3057D77787E5F4180A4", + "type": "TIMESTAMP" + }, + ... + "signatures": [{ + "validationProcessArchivalData": { + "conclusion": {"indication": "PASSED"}, + "constraint": [{ + "name": { + "nameId": "ARCH_LTVV", + "value": "Is the result of the LTV validation process acceptable?" + }, + "status": "OK" + }]}, + ... + }, + "id": "S0", + "validationProcessLongTermData": { + "conclusion": {"indication": "PASSED"}, + "constraint": [{ + "name": { + "nameId": "LTV_ABSV", + "value": "Is the result of the Basic Validation Process acceptable?"}, + "status": "OK" + }, + ... + }]}}] + }, + "validationConclusion": { + "validationTime": "2017-11-07T09:20:18Z", + "signaturesCount": 1, + "validationLevel": "ARCHIVAL_DATA", + "validatedDocument": { + "filename": "ValidLiveSignature.asice", + "fileHashInHex": "0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501", + "hashAlgo": "SHA-256" + }, + "validSignaturesCount": 1, + "signatures": [{ + "signatureFormat": "XAdES_BASELINE_LT", + "signedBy": "NURM,AARE,38211015222", + "claimedSigningTime": "2016-10-11T09:35:48Z", + "signatureLevel": "QESIG", + "signatureScopes": [{ + "scope": "FullSignatureScope", + "name": "Tresting.txt", + "content": "Full document" + }], + "id": "S0", + "indication": "TOTAL-PASSED", + "info": {"bestSignatureTime": "2016-10-11T09:36:10Z"} + }], + "policy": { + "policyDescription": "Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result.", + "policyUrl": "http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4", + "policyName": "POLv4" + }, + "signatureForm": "ASiC_E" + } + }, + "validationReportSignature": "UEsDBBQACAgIAIlaZ0sAA..." +} + +``` + +#### Sample SOAP response Simple Report (successful scenario) + +```xml + + + + + + + + Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. + POLv4 + http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#POLv4 + + 2017-11-07T09:20:18Z + + ValidLiveSignature.asice + 0A805C920603750E0B427C3F25D7B22DCEC183DEF3CA14BE9A2D4488887DD501 + SHA-256 + + ARCHIVAL_DATA + + ASiC-E + + + S0 + XAdES_BASELINE_LT + QESIG + NURM,AARE,38211015222 + TOTAL-PASSED + + + + + Tresting.txt + FullSignatureScope + Full document + + + 2016-10-11T09:35:48Z + + + 2016-10-11T09:36:10Z + + + + 1 + 1 + + + + + + Is the result of the Basic Validation Process conclusive? + OK + + + PASSED + + + ... + + + Is the result of the LTV validation process acceptable? + OK + + + PASSED + + + + ... + + + + Is the expected format found? + OK + + ... + + + Can the certificate chain be built till the trust anchor? + OK + + + + + ... + + Is the trusted list well signed ? + OK + + + PASSED + + + ... + + + Is the signature/seal an acceptable AdES (ETSI EN 319 102-1) ? + OK + + ... + + PASSED + + + + + + UEsDBBQACAgIAIlaZ0s... + + + + +``` + +### Sample JSON response (error situation) +In case of error (when validation report is not returned) status code 400 is returned together with following message body: + +```json +{"requestErrors": [{ + "message": "Document malformed or not matching documentType", + "key": "document" +}]} +``` + +### Sample SOAP response (error situation) + +```xml + + + + + soap:Server + Document malformed or not matching documentType + + + +``` + +## Data files request interface + + +** REST JSON Endpoint ** + +``` +POST https:///getDataFiles +``` + +** SOAP Endpoint ** +``` +POST https:///soap/dataFilesWebService/getDocumentDataFiles +``` + +** SOAP WSDL ** +``` +POST https:///soap/dataFilesWebService/getDocumentDataFiles?wsdl +``` + +### Data files request parameters + +Data files request parameters for JSON and SOAP interfaces are described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|----------------|-------------| +| document | Document | + | String | Base64 encoded string of digitally signed DDOC document | +| filename | Filename | + | String | File name of the digitally signed document (i.e. sample.ddoc), max length 255 characters. Currently only DDOC file format is supported for this operation| + +### Sample JSON request + +```json +{ + "filename":"sample.ddoc", + "document":"PD94bWwgdmVyc2lvbj0iMS4...." +} +``` + + +### Sample SOAP request + +```xml + + + + + + PD94bWwgdmVyc2lvbj0iMS4wI... + sample.ddoc + + + + +``` + + +## Data files response interface + +### Data files response parameters (successful scenario) + +The data file extraction report (i.e. the data files response) for JSON and SOAP interfaces is described in the table below. Data types of SOAP parameters are defined in the [SiVa WSDL document](/siva/appendix/wsdl). +SiVa returns all data files as they are extracted by JDigiDoc library in an as is form. No extra operations or validations are done. + +| JSON parameter | SOAP parameter | Mandatory | JSON data type | Description | +|----------------|----------------|-----------|----------------|-------------| +| dataFiles | DataFiles | - | Array | Collection of data files found in digitally signed document | +| dataFiles[0] | DataFile | + | Object | Extracted data file object | +| dataFiles[0].fileName | DataFile.FileName | - | String | File name of the extracted data file | +| dataFiles[0].size | DataFile.Size | - | Long | Extracted data file size in bytes | +| dataFiles[0].base64 | DataFile.Base64 | - |String | Base64 encoded string of extracted data file | +| dataFiles[0].mimeType | DataFile.MimeType | - | String | MIME type of the extracted data file | + +### Sample JSON response (successful scenario) + +```json +{ +"dataFiles": [{ + "fileName": "Glitter-rock-4_gallery.jpg", + "size": 41114, + "base64": "/9j/4AAQSkZJ...", + "mimeType": "application/octet-stream" }] +} +``` + +### Sample SOAP response (successful scenario) + +```xml + + + + + + + + UCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUCgUH... + Glitter-rock-4_gallery.jpg + application/octet-stream + 41114 + + + + + + +``` + +### Sample JSON response (error situation) +In case of error (when datafiles are not returned) status code 400 is returned together with following message body: + +```json +{"requestErrors": [{ + "message": "Invalid document type. Can only return data files for DDOC type containers.", + "key": "documentType" +}]} +``` + +### Sample SOAP response (error situation) + +```xml + + + + + soap:Client + Invalid document type. Can only return data files for DDOC type containers. + + + +``` + + + +## Service health monitoring + +SiVa webapps provide an interface for external monitoring tools (to periodically check the generic service health status). + +### The request +The monitoring endpoint is accessible via HTTP GET at **/monitoring/health** or **/monitoring/health.json** url. + +Sample request: +``` +GET https:///monitoring/health +``` + +### The response + +As a response, a JSON object is returned with the following information: + +| Field | Description | +| ---------| --------------- | +| status | General status of the webapp.
Possible values:
  • **DOWN** - when some of the dependent indicators status are down (ie when `link{number}.status` is DOWN, the overall service status is DOWN)
  • **UP** - the default value.
| +| health.status | Status of current webapp - constant value **UP** | +| health.webappName | The artifact name of the webapp. Taken from the MANIFEST.MF file (inside the jar/war file). | +| health.version | The release version fo the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | +| health.buildTime | Build date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') of the webapp. Taken from the MANIFEST.MF (inside the jar/war file). | +| health.startTime | Webapp startup date and time (format yyyy-MM-dd'T'HH:mm:ss'Z')| +| health.currentTime | Current server date and time (format yyyy-MM-dd'T'HH:mm:ss'Z') | +| link{number}.status | (OPTIONAL) Represents the status of a link to the external system that the webapp depends on.
  • **DOWN** when the webapp does not respond (within a specified timeout limit - default 10 seconds) or the response is in invalid format (default Spring boot actuator /health endpoint format is expected).
  • **UP** if the service responds with HTTP status code 200 and returns a valid JSON object with status "UP"
|) | +| link{number}.name | (OPTIONAL) Descriptive name for the link to the external system | + +Sample response: + +```json +{ + "status":"UP", + "health":{ + "status":"UP", + "webappName":"siva-demo-application", + "version":"3.1.0", + "buildTime":"2016-10-21T15:56:21Z", + "startTime":"2016-10-21T15:57:48Z", + "currentTime":"2016-10-21T15:58:39Z" + }, + "link1":{ + "status":"UP", + "name":"sivaService" + } +} +``` diff --git a/docs/siva2/logging.md b/docs/siva2/logging.md index 39c30472d..15e2b75b5 100644 --- a/docs/siva2/logging.md +++ b/docs/siva2/logging.md @@ -1,93 +1,93 @@ - - -Logging functionality is handled by the **SLF4J** logging facade and on top -of it the **Logback** framework is used. As a result, logging can be -configured via the standard Logback configuration file. By default, -logging works on the `INFO` level and logs are directed to the system -console as well as a log file. - -The logback xml configuration file can be found at: -``` -pdfValidator/pdf-validator-webapp/src/main/resources/logback.xml -``` - -and when compiled the file will reside at  -``` -WEB-INF/classes/logback.xml -``` - -within the packaged war. There is also a possibility to set the location -of the default configuration file with a system -property `logback.configurationFile` as a JVM argument. The value of -this property can be a URL, a resource on the class path or a path to a -file external to the application. - -```bash -java -Dlogback.configurationFile=/path/to/config.xml -``` - -In this configuration file there are three appenders: `STDOUT` (logs to -standard output), `FILE` (logs to a file) and `SYSLOG` (logs to syslog -server over the network). To disable certain appender from logging, -commenting out its `appender-ref` is sufficient, but it is *recommended* -that the appender itself should also be commented out. For example to -disable `SYSLOG` appender (which is the default configuration), then one -can use following configuration: - -```xml - - - - - - - - -``` - -Logback configuration manual:  - -STDOUT appender ----------------- - -- Default the log level is set to DEBUG -- Appender output pattern is: `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L [%thread] - %msg%n` - -FILE appender -------------- - -- Default log level is set to `INFO` -- uses RollingFileAppender configured with `TimeBasedRollingPolicy`. - Current configuration makes a seperate logfile for each day and each - file is kept for *30 days*. - - *PS!* keep in mind when using relative - destination file path, then the path is added at the end of the - currently working directory, i.e. where the application was started. - (Current day's logfile path: `logs/pdf-validator-webapp.log`, - prievious days pattern:  - - logs/pdf-validator-webapp.%d{yyyy-MM-dd}.log) - -- Appender output pattern is:  `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L \[%thread\] - %msg%n` - - -Dlogback.configurationFile=config.xml - -SYSLOG appender ---------------- - -- Default log level is set to `INFO` -- Target's ip/hostname and port are configurable -- Syslog messsages' severity is configurable -- Syslog messages' payload's timestamp and hostname part are created - implicitly and the suffixpattern is:  `%-5level %logger{0}:%L \[%thread\] - %msg` + + +Logging functionality is handled by the **SLF4J** logging facade and on top +of it the **Logback** framework is used. As a result, logging can be +configured via the standard Logback configuration file. By default, +logging works on the `INFO` level and logs are directed to the system +console as well as a log file. + +The logback xml configuration file can be found at: +``` +pdfValidator/pdf-validator-webapp/src/main/resources/logback.xml +``` + +and when compiled the file will reside at  +``` +WEB-INF/classes/logback.xml +``` + +within the packaged war. There is also a possibility to set the location +of the default configuration file with a system +property `logback.configurationFile` as a JVM argument. The value of +this property can be a URL, a resource on the class path or a path to a +file external to the application. + +```bash +java -Dlogback.configurationFile=/path/to/config.xml +``` + +In this configuration file there are three appenders: `STDOUT` (logs to +standard output), `FILE` (logs to a file) and `SYSLOG` (logs to syslog +server over the network). To disable certain appender from logging, +commenting out its `appender-ref` is sufficient, but it is *recommended* +that the appender itself should also be commented out. For example to +disable `SYSLOG` appender (which is the default configuration), then one +can use following configuration: + +```xml + + + + + + + + +``` + +Logback configuration manual:  + +STDOUT appender +---------------- + +- Default the log level is set to DEBUG +- Appender output pattern is: `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L [%thread] - %msg%n` + +FILE appender +------------- + +- Default log level is set to `INFO` +- uses RollingFileAppender configured with `TimeBasedRollingPolicy`. + Current configuration makes a seperate logfile for each day and each + file is kept for *30 days*. + + *PS!* keep in mind when using relative + destination file path, then the path is added at the end of the + currently working directory, i.e. where the application was started. + (Current day's logfile path: `logs/pdf-validator-webapp.log`, + prievious days pattern:  + + logs/pdf-validator-webapp.%d{yyyy-MM-dd}.log) + +- Appender output pattern is:  `%d{HH:mm:ss.SSS} %-5level %logger{0}:%L \[%thread\] - %msg%n` + + -Dlogback.configurationFile=config.xml + +SYSLOG appender +--------------- + +- Default log level is set to `INFO` +- Target's ip/hostname and port are configurable +- Syslog messsages' severity is configurable +- Syslog messages' payload's timestamp and hostname part are created + implicitly and the suffixpattern is:  `%-5level %logger{0}:%L \[%thread\] - %msg` diff --git a/docs/siva2/overview.md b/docs/siva2/overview.md index 9d7352e49..0ed43ff08 100644 --- a/docs/siva2/overview.md +++ b/docs/siva2/overview.md @@ -1,55 +1,55 @@ - - -## What is SiVa? - -SiVa (Signature Validation) web service provides JSON and SOAP based API web interface to validate digital signatures. -Please take a look in [Validation Policy](appendix/validation_policy) section for supported formats and applied constraints. - -SiVa uses following Java libraries and command line utilities: - -* DigiDoc4J Java library to validate BDOC containers. Supported signature - types are `TimeStamp` and `TimeMark` -* JDigiDoc Java library is used to validate DDOC containers. -* X-Road ASiCE containers are validated using X-Road security server project - provided command line utility -* EU DSS (Digital Signature Service) library is used to validate all other types of digital signatures that are not covered above. - -## Validation libraries - -### DigiDoc4j EU DSS fork - -[DigiDoc4J EU DSS fork](https://github.com/open-eid/sd-dss) is used as the main validation library. The fork includes [Estonian specific changes](https://github.com/open-eid/sd-dss/wiki/BDoc-specific-modifications) and may not be suitable for all signatures. - -**SiVa will use the following functionality of EU DSS library:** - -* XAdES/CAdES/PAdES Validation Functionality -* ASIC-E and ASIC-S container validation -* TSL loading functionality - -### DigiDoc4J - -DigiDoc4J is used to validate both `TimeMark` and `TimeStamp` based BDOC containers. For more information on DigiDoc4J visit [Github](https://github.com/open-eid/digidoc4j) - -SiVa will use the following functionality of DigiDoc4J: - -* BDOC validation functionality - -### JDigiDoc - -JDigiDoc is used to validate DDOC containers. For more information on JDigiDoc visit [GitHub](https://github.com/open-eid/jdigidoc) - -SiVa will use the following functionality of JDigiDoc: - -* DDOC validation functionality - -### X-Road signature validation utility - -X-Road signature validation utility is command line tool to validate X-Road Security server -generated ASiCe files. For more information on this utility visit [GitHub](https://github.com/ria-ee/X-Road) - -## Main features of SiVa validation service: - -- SOAP and REST/JSON API to validate signatures. -- SOAP and REST/JSON API to retrieve data files from DDOC containers. -- SOAP API is compadible with X-Road v6. + + +## What is SiVa? + +SiVa (Signature Validation) web service provides JSON and SOAP based API web interface to validate digital signatures. +Please take a look in [Validation Policy](appendix/validation_policy) section for supported formats and applied constraints. + +SiVa uses following Java libraries and command line utilities: + +* DigiDoc4J Java library to validate BDOC containers. Supported signature + types are `TimeStamp` and `TimeMark` +* JDigiDoc Java library is used to validate DDOC containers. +* X-Road ASiCE containers are validated using X-Road security server project + provided command line utility +* EU DSS (Digital Signature Service) library is used to validate all other types of digital signatures that are not covered above. + +## Validation libraries + +### DigiDoc4j EU DSS fork + +[DigiDoc4J EU DSS fork](https://github.com/open-eid/sd-dss) is used as the main validation library. The fork includes [Estonian specific changes](https://github.com/open-eid/sd-dss/wiki/BDoc-specific-modifications) and may not be suitable for all signatures. + +**SiVa will use the following functionality of EU DSS library:** + +* XAdES/CAdES/PAdES Validation Functionality +* ASIC-E and ASIC-S container validation +* TSL loading functionality + +### DigiDoc4J + +DigiDoc4J is used to validate both `TimeMark` and `TimeStamp` based BDOC containers. For more information on DigiDoc4J visit [Github](https://github.com/open-eid/digidoc4j) + +SiVa will use the following functionality of DigiDoc4J: + +* BDOC validation functionality + +### JDigiDoc + +JDigiDoc is used to validate DDOC containers. For more information on JDigiDoc visit [GitHub](https://github.com/open-eid/jdigidoc) + +SiVa will use the following functionality of JDigiDoc: + +* DDOC validation functionality + +### X-Road signature validation utility + +X-Road signature validation utility is command line tool to validate X-Road Security server +generated ASiCe files. For more information on this utility visit [GitHub](https://github.com/ria-ee/X-Road) + +## Main features of SiVa validation service: + +- SOAP and REST/JSON API to validate signatures. +- SOAP and REST/JSON API to retrieve data files from DDOC containers. +- SOAP API is compadible with X-Road v6. - Signing of validation report. \ No newline at end of file diff --git a/docs/siva2/qa_strategy.md b/docs/siva2/qa_strategy.md index 853d8a322..2262abaf9 100644 --- a/docs/siva2/qa_strategy.md +++ b/docs/siva2/qa_strategy.md @@ -1,156 +1,156 @@ - -## Introduction -The goal of this document is to give general overview of the used infrastructure, processes, schedule and actions to ensure good quality delivery. The document describes activities in the whole software development process. Analysis, development and testing are separated for the sake of structure and transparency although they are integral parts of the development cycle. -This is living document and will be constantly updated as the project evolves. -## Environments and infrastructure -![Enviroment](../img/siva/qa_strategy/siva2/Env.png) - -There are different test environments for quality assurance, depending on the nature and aim. - -1. TravisCI environment for public CI - Platform: Linux -2. Test environment for local test and load test - Platform: Linux - -Instructions how to set up test enviroment and run tests together with more info can be found in [SiVa GitHub page](https://github.com/open-eid/SiVa) - -System requirements: - -* At least 2GB of RAM on machine where the build is executed -* Minimum required Java version is Java 8 -* SiVa project provided Maven Wrapper (./mvnw) - -Tools used: - -* TravisCI – is a continuous integration service used to build and test software projects hosted at GitHub -* Jenkins – is an open source continuous integration tool written in Java. -* JMeter – tool for creating and running load tests. -* IntelliJ IDEA – is a Java integrated development environment(IDE) for developing and executing automated tests locally -* Apache Tomcat - is an open source servlet container developed by the Apache Software Foundation. -* Docker – is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux. -* Rest-Assured - is a Java DSL(Domain-specific language) for simplifying testing of REST based Services built on top of HTTP Builder. - -## Analysis -Analysis will be tagged with identificators to enable cross-reference between requirements and corresponding tests. This includes both functional and non-functional requirements. -See documents[(2) and (3) in References](/siva/references/) - -## Development -### Development process -Customized process based on Kanban is used in the development. The process consists of following elements: - -* Product backlog is maintained JIRA -* Tasks are maintained through JIRA Kanban board -* Daily team stand-ups are held -* Tasks marked done are developed, tested and ready to be shipped -* Bi-weekly meetings are held to give status on progress and discuss open questions -![Development process](../img/siva/qa_strategy/siva2/developmentProcess.png) - -### Issue lifecycle -Each ticket in JIRA Kanban board goes through the following states that correspond the development procedure described in previous chapter. -![Issue lifecycle](../img/siva/qa_strategy/siva2/taskWorkFlow.png) - -Description of states: - -* Awaiting analysis - ticket to be dealt with, product backlog. -* Awaiting implementation - ticket analysed and ready to be implemented. -* In progress - ticket is being handled (feature coding, document writing, ...). -* In Review - ticket is ready for review -* Resolved - ticket is ready for test -* Closed - ticket has been tested and found ready for release - -### QA activities and quality criterias in the development -**Process improvement** - -The development process is constantly monitored and adjusted to the changing situations. Retrospective meetings for process feedback are held. - -**Unit tests** - -It is responsibility of developer to write, maintain and execute the unit tests on developed features. The code must compile and pass unit tests before it is allowed to be submitted to the code repository. The code of the unit tests is integral part of the source code and is maintained on the same principles. -Unit tests are also automatically executed on each build, if the unit tests do not pass further test execution is stopped. - -**Static testing/code reviews** - -All changes (including changes in unit test code) are reviewed by another development team member using GitHub. The code must pass review before it is submitted to testing. -SonarLint is used to validate code automatically. It integrates both suggested tools mentioned in reference document [(3) References](/siva/references/) - -## Testing -### Approach -Testing follows the principles described in reference document [(1) in References](/siva/references/) -The goal is to automate as much of the testing process as possible, however some aspects of the testing will be carried out manually. -As the development is carried out by the backlog priority the testing follows the same principle. After each feature release test cases, test automation code and test results will be available through GitHub. -![Testing schedule](../img/siva/qa_strategy/siva2/testingFlow.png) -### Testing process - -All automatic tests, except load tests will follow the same execution process. The tests are ran automatically during the project build process by Travis CI after each push in GitHub. -![Testing process](../img/siva/qa_strategy/siva2/TestProcess.png) - -### Test case management -Test cases are handled as integral part of test automation code. The same applies on manual tests, in manual test cases some portion of automation may be used to execute the tests but the results are verified manually. All the test cases and test code will be maintained in the GitHub. -Test cases are developed and maintained together with test automation code by the QA specialist for Integration and System Testing. -Following elements will be present in test cases: - -* TestCaseID: unique ID that makes possible to identify specific test case -* TestType: Automated, Automated SoapUI or Manual -* Requirement: Reference to the requirement that is tested -* Title: Description of the test -* Expected Result: expected outcome of the test (pass criteria for the test) -* File: input test file that is used - - -**Test case sample** - -Automatic and manual test cases will have the same description principles (shown below). - -```bash -/** -* TestCaseID: Bdoc-ValidationFail-27 -* -* TestType: Automated -* -* Requirement: http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#common-validation-constraints-polv1-polv2 -* -* Title: Bdoc OCSP response doesn't correspond to the signers certificate -* -* Expected Result: The document should fail the validation -* -* File: NS28_WrongSignerCertInOCSPResp.bdoc -*/ -@Test -public void bdocWrongSignersCertInOcspResponse() { -setTestFilesDirectory("bdoc/live/timemark/"); -post(validationRequestFor("NS28_WrongSignerCertInOCSPResp.bdoc")) -.then() -.body("signatures[0].indication", Matchers.is("TOTAL-FAILED")) -.body("signatures[0].subIndication", Matchers.is("TRY_LATER")) -.body("signatures[0].errors.content", Matchers.hasItem("No revocation data for the certificate")) -.body("validSignaturesCount", Matchers.is(0)); -} -``` -### Defect management -All found defects will be reported and handled in Jira. The defect report will follow similar lifecycle in JIRA Kanban board as tasks. -The report will have at least the following elements: - -* Title: Short, precise description of the problem -* Details: Type, Priority, Epic Link -* Description: - * **Steps to reproduce bug** - sequence for reproduction, link to test case if applicable. - * **Expected behavior** - expected outcome of the test sequence. - * **Actual behavior** - actual result of the test sequence. The description should be thorough enough to enable the debugging of the problem and to give objective base for severity assessment. - * **File attachments** - Test files, logs, images, ... -### Test levels - -**Integration testing** - -The scope of the tests is illustrated on the image below. The goal is to test the SiVA application API (both X-Road and REST/JSON) and to test the independent module capability for validation of specific type of file. Both valid and invalid inputs are tested. More info about testing specifics can be found in Test Plan [Integration testing](/siva/test_plan/#integration-test-introduction) section. -![Integration testing](../img/siva/qa_strategy/IntegrationTest.png) - -**System testing** - -The scope of the tests is illustrated on the image below. The goal of the test is to test the entire length of signature validation process and to test supportive functions. In addition Demo application is tested. More info about testing specifics can be found in Test Plan [System testing](/siva/test_plan/#system-test-introduction) section. -![System testing](../img/siva/qa_strategy/SystemTest.png) - - -**Regression testing** - -Regression testing will consist of two parts: -Running all automated tests (unit, integration and system tests) -Manual testing of the areas that are not covered by automatic tests based on the regression test checklist + +## Introduction +The goal of this document is to give general overview of the used infrastructure, processes, schedule and actions to ensure good quality delivery. The document describes activities in the whole software development process. Analysis, development and testing are separated for the sake of structure and transparency although they are integral parts of the development cycle. +This is living document and will be constantly updated as the project evolves. +## Environments and infrastructure +![Enviroment](../img/siva/qa_strategy/siva2/Env.png) + +There are different test environments for quality assurance, depending on the nature and aim. + +1. TravisCI environment for public CI - Platform: Linux +2. Test environment for local test and load test - Platform: Linux + +Instructions how to set up test enviroment and run tests together with more info can be found in [SiVa GitHub page](https://github.com/open-eid/SiVa) + +System requirements: + +* At least 2GB of RAM on machine where the build is executed +* Minimum required Java version is Java 8 +* SiVa project provided Maven Wrapper (./mvnw) + +Tools used: + +* TravisCI – is a continuous integration service used to build and test software projects hosted at GitHub +* Jenkins – is an open source continuous integration tool written in Java. +* JMeter – tool for creating and running load tests. +* IntelliJ IDEA – is a Java integrated development environment(IDE) for developing and executing automated tests locally +* Apache Tomcat - is an open source servlet container developed by the Apache Software Foundation. +* Docker – is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux. +* Rest-Assured - is a Java DSL(Domain-specific language) for simplifying testing of REST based Services built on top of HTTP Builder. + +## Analysis +Analysis will be tagged with identificators to enable cross-reference between requirements and corresponding tests. This includes both functional and non-functional requirements. +See documents[(2) and (3) in References](/siva/references/) + +## Development +### Development process +Customized process based on Kanban is used in the development. The process consists of following elements: + +* Product backlog is maintained JIRA +* Tasks are maintained through JIRA Kanban board +* Daily team stand-ups are held +* Tasks marked done are developed, tested and ready to be shipped +* Bi-weekly meetings are held to give status on progress and discuss open questions +![Development process](../img/siva/qa_strategy/siva2/developmentProcess.png) + +### Issue lifecycle +Each ticket in JIRA Kanban board goes through the following states that correspond the development procedure described in previous chapter. +![Issue lifecycle](../img/siva/qa_strategy/siva2/taskWorkFlow.png) + +Description of states: + +* Awaiting analysis - ticket to be dealt with, product backlog. +* Awaiting implementation - ticket analysed and ready to be implemented. +* In progress - ticket is being handled (feature coding, document writing, ...). +* In Review - ticket is ready for review +* Resolved - ticket is ready for test +* Closed - ticket has been tested and found ready for release + +### QA activities and quality criterias in the development +**Process improvement** + +The development process is constantly monitored and adjusted to the changing situations. Retrospective meetings for process feedback are held. + +**Unit tests** + +It is responsibility of developer to write, maintain and execute the unit tests on developed features. The code must compile and pass unit tests before it is allowed to be submitted to the code repository. The code of the unit tests is integral part of the source code and is maintained on the same principles. +Unit tests are also automatically executed on each build, if the unit tests do not pass further test execution is stopped. + +**Static testing/code reviews** + +All changes (including changes in unit test code) are reviewed by another development team member using GitHub. The code must pass review before it is submitted to testing. +SonarLint is used to validate code automatically. It integrates both suggested tools mentioned in reference document [(3) References](/siva/references/) + +## Testing +### Approach +Testing follows the principles described in reference document [(1) in References](/siva/references/) +The goal is to automate as much of the testing process as possible, however some aspects of the testing will be carried out manually. +As the development is carried out by the backlog priority the testing follows the same principle. After each feature release test cases, test automation code and test results will be available through GitHub. +![Testing schedule](../img/siva/qa_strategy/siva2/testingFlow.png) +### Testing process + +All automatic tests, except load tests will follow the same execution process. The tests are ran automatically during the project build process by Travis CI after each push in GitHub. +![Testing process](../img/siva/qa_strategy/siva2/TestProcess.png) + +### Test case management +Test cases are handled as integral part of test automation code. The same applies on manual tests, in manual test cases some portion of automation may be used to execute the tests but the results are verified manually. All the test cases and test code will be maintained in the GitHub. +Test cases are developed and maintained together with test automation code by the QA specialist for Integration and System Testing. +Following elements will be present in test cases: + +* TestCaseID: unique ID that makes possible to identify specific test case +* TestType: Automated, Automated SoapUI or Manual +* Requirement: Reference to the requirement that is tested +* Title: Description of the test +* Expected Result: expected outcome of the test (pass criteria for the test) +* File: input test file that is used + + +**Test case sample** + +Automatic and manual test cases will have the same description principles (shown below). + +```bash +/** +* TestCaseID: Bdoc-ValidationFail-27 +* +* TestType: Automated +* +* Requirement: http://open-eid.github.io/SiVa/siva/appendix/validation_policy/#common-validation-constraints-polv1-polv2 +* +* Title: Bdoc OCSP response doesn't correspond to the signers certificate +* +* Expected Result: The document should fail the validation +* +* File: NS28_WrongSignerCertInOCSPResp.bdoc +*/ +@Test +public void bdocWrongSignersCertInOcspResponse() { +setTestFilesDirectory("bdoc/live/timemark/"); +post(validationRequestFor("NS28_WrongSignerCertInOCSPResp.bdoc")) +.then() +.body("signatures[0].indication", Matchers.is("TOTAL-FAILED")) +.body("signatures[0].subIndication", Matchers.is("TRY_LATER")) +.body("signatures[0].errors.content", Matchers.hasItem("No revocation data for the certificate")) +.body("validSignaturesCount", Matchers.is(0)); +} +``` +### Defect management +All found defects will be reported and handled in Jira. The defect report will follow similar lifecycle in JIRA Kanban board as tasks. +The report will have at least the following elements: + +* Title: Short, precise description of the problem +* Details: Type, Priority, Epic Link +* Description: + * **Steps to reproduce bug** - sequence for reproduction, link to test case if applicable. + * **Expected behavior** - expected outcome of the test sequence. + * **Actual behavior** - actual result of the test sequence. The description should be thorough enough to enable the debugging of the problem and to give objective base for severity assessment. + * **File attachments** - Test files, logs, images, ... +### Test levels + +**Integration testing** + +The scope of the tests is illustrated on the image below. The goal is to test the SiVA application API (both X-Road and REST/JSON) and to test the independent module capability for validation of specific type of file. Both valid and invalid inputs are tested. More info about testing specifics can be found in Test Plan [Integration testing](/siva/test_plan/#integration-test-introduction) section. +![Integration testing](../img/siva/qa_strategy/IntegrationTest.png) + +**System testing** + +The scope of the tests is illustrated on the image below. The goal of the test is to test the entire length of signature validation process and to test supportive functions. In addition Demo application is tested. More info about testing specifics can be found in Test Plan [System testing](/siva/test_plan/#system-test-introduction) section. +![System testing](../img/siva/qa_strategy/SystemTest.png) + + +**Regression testing** + +Regression testing will consist of two parts: +Running all automated tests (unit, integration and system tests) +Manual testing of the areas that are not covered by automatic tests based on the regression test checklist \ No newline at end of file diff --git a/docs/siva2/references.md b/docs/siva2/references.md index 4d57fad84..938b6d453 100644 --- a/docs/siva2/references.md +++ b/docs/siva2/references.md @@ -1,8 +1,8 @@ -# References - - * (1) Lisa_6_Osa_I_SiVa_Testimise_korraldus.pdf - * (2) Lisa_4_Osa_I_SiVa_Valideerimisteenuse_analuus MUUDETUD.pdf - * (3) Lisa_3_RIA_Mittefunktsionaalsed_nouded.pdf - - - +# References + + * (1) Lisa_6_Osa_I_SiVa_Testimise_korraldus.pdf + * (2) Lisa_4_Osa_I_SiVa_Valideerimisteenuse_analuus MUUDETUD.pdf + * (3) Lisa_3_RIA_Mittefunktsionaalsed_nouded.pdf + + + diff --git a/docs/siva2/systemintegrators_guide.md b/docs/siva2/systemintegrators_guide.md index fc706f33a..afd5f09be 100644 --- a/docs/siva2/systemintegrators_guide.md +++ b/docs/siva2/systemintegrators_guide.md @@ -1,587 +1,587 @@ -This guide describes how to integrate SiVa service with other applications. -The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. - -### System requirements - -Following are the minimum requirements to build and deploy SiVa webapps as a service: - -* Java 8 or above Oracle JVM is supported -* Git version control system version 1.8 or above is recommended -* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM -* Minimum 1 processor core -* Open internet connection -* 2GB of free disk space -* Supported operating system is Ubuntu 16.04 LTS - -## Building - -### Building SiVa webapps on Ubuntu 16.04 - -First we need to install Git and Java SDK 8 by issuing below commands: - -```bash -sudo apt-get update -sudo apt-get install git -y -sudo apt-get install default-jdk -y -``` - -Next we need to clone the SiVa Github repository: - -```bash -git clone https://github.com/open-eid/SiVa.git --branch master -``` - -Final step is building the SiVa project using Maven Wrapper - -```bash -cd SiVa -./mvnw clean install -``` - -!!! note - The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the - required dependencies - -To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. -The last lines of build output should look very similar to below image: - -```text -[INFO] Reactor Summary: -[INFO] -[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 1.632 s] -[INFO] validation-services-parent ......................... SUCCESS [ 0.897 s] -[INFO] validation-commons ................................. SUCCESS [ 12.321 s] -[INFO] tsl-loader ......................................... SUCCESS [ 6.917 s] -[INFO] Generic Validation Service ......................... SUCCESS [ 27.919 s] -[INFO] TimeStampToken Validation Service .................. SUCCESS [ 7.046 s] -[INFO] BDOC Validation Service ............................ SUCCESS [ 50.087 s] -[INFO] DDOC Validation Service ............................ SUCCESS [ 16.712 s] -[INFO] SiVa webapp and other core modules ................. SUCCESS [ 0.653 s] -[INFO] siva-monitoring .................................... SUCCESS [ 9.736 s] -[INFO] xroad-validation-service ........................... SUCCESS [ 19.761 s] -[INFO] siva-statistics .................................... SUCCESS [ 13.734 s] -[INFO] SiVa validation service proxy ...................... SUCCESS [ 11.509 s] -[INFO] SiVa signature service ............................. SUCCESS [ 6.869 s] -[INFO] siva-webapp ........................................ SUCCESS [ 27.608 s] -[INFO] SiVa Web Service integration tests ................. SUCCESS [03:53 min] -[INFO] siva-distribution .................................. SUCCESS [ 10.818 s] -[INFO] ------------------------------------------------------------------------ -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 08:18 min -[INFO] Finished at: 2017-12-04T13:49:48+02:00 -[INFO] Final Memory: 113M/903M -[INFO] ------------------------------------------------------------------------ -``` - - -## Deploying - -### OPTION 1 - starting webapps from command line -SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the -project by issuing below commands: - -**First start the Siva webapp** - -```bash -./siva-parent/siva-webapp/target/siva-webapp-3.0.0.jar -``` - -**Second we need to start X-road validation webapp** - -```bash -./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.0.0.jar -``` - -The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. -Easiest way to test out validation is run [SiVa demo application](https://github.com/open-eid/SiVa-demo-application). - -### OPTION 2 - running webapps as systemd services - -Maven build generates executable JAR files. This means web container and all its dependencies are package inside -single JAR file. It makes a lot easier to deploy it into servers. - -Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. - -For that we first need to create service file: -```bash -vim siva-webapp.service -``` - -Inside it we need to paste below text. You need to change few things in service setup file. - -* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` -* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. -* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file - -```ini -[Unit] -Description=siva-webapp -After=syslog.target - -[Service] -User=root -ExecStart=/var/apps/siva-webapp.jar -Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 -SuccessExitStatus=143 - -[Install] -WantedBy=multi-user.target -``` - -Save and close the `siva-webapp.service` file. -Next we need to move `siva-webapp-3.0.0.jar` into newly created `/var/apps` directory and rename to -JAR file to `siva-webapp.jar`. match - -!!! note - The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file - -```bash -sudo mkdir /var/apps -sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.0.0.jar /var/apps/siva-webapp.jar -``` - -Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. -Then we are ready to start the `siva-webapp` service. - -```bash -sudo cp siva-webapp.service /lib/systemd/system -sudo systemctl start siva-webapp -``` - -Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below -command. - -```bash -systemctl status siva-webapp -``` - -It should print out similar to below picture: - -``` -● siva-webapp.service - siva-webapp - Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) - Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago - Main PID: 15965 (siva-webapp.jar) - Tasks: 34 - Memory: 429.6M - CPU: 2min 5.721s - CGroup: /system.slice/siva-webapp.service - ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar - └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar - -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) -Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync -``` - -### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) - -> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet -> containers also possible container application libraries conflicts - -> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version -> conflicts. - -> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - -the http connector parameter `maxPostSize` should be configured with the desired limit. - -> **NOTE 4**: The war file must be deployed to Tomcat ROOT. - -First we need to download Tomcat web servlet container as of the writing latest version available in version 8 branch is 8.5.24. We will download it with `wget` - -```bash -wget http://www-eu.apache.org/dist/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gz -``` - -Unpack it somewhere: - -```bash -tar xf apache-tomcat-8.5.24.tar.gz -``` - -Now we should build the WAR file. We have created helper script with all the correct Maven parameters. - -```bash -./war-build.sh -``` - -> **NOTE** The script will skip running the integration tests when building WAR files - -Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. - -```bash -cp siva-parent/siva-webapp/target/siva-webapp-3.0.0.war apache-tomcat-8.5.24/webapps -./apache-tomcat-7.0.77/bin/catalina.sh run -``` - -> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates -> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change -> this default behavior you should set environment variable `DSS_DATA_FOLDER` - -### How-to set WAR deployed SiVa `application.properties` - -SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. -To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. - -Contents of the `setenv.sh` file should look like: - -```bash -export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" -``` - - -### Smoke testing your deployed system - -**Step 1**. Install HTTPIE -`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed -and started correctly on our server. - -If you have Python and its package manager `pip` installed. Then You can issue below command: - -```bash -pip install httpie -``` - -**Step 2**. Download a sample JSON request file. - -```bash -http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdocPass.json -``` - -**Step 3**. After successful download issue below command in same directory where you downloaded the file using -the command below. - -```bash -http POST http://localhost:8080/validate < bdocPass.json -``` -**Step 4**. Verify the output. The output of previous command should have similar data as below screenshot. Look for `signatureCount` and -`validSignatureCount`, they **must** be equal. - - -![HTTPIE output validation](../img/siva/siva2-output.png) - - -## Logging - -By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. - -For example, adding application.properties to classpath with the **logging.config** property -```bash -logging.config=/path/to/logback.xml -``` - -## Statistics - -For every report validated, a statistical report is composed that collects the following data: - -| Data | Description | -| ----- | ----- | -| Validation duration | The time it takes to process an incoming request - measured in milliseconds | -| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, ASiC-S or ASiC-E (BatchSignature) ) | -| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | -| Total signatures count | The value of the `signaturesCount` element in the validation report -| Valid signatures count | The value of the `validSignaturesCount` element in the validation report -| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | -| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | -| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | - -There are two channels where this information is sent: - -1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. - -2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. - -The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) - -## Monitoring - -SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. - -!!! note - Note that this endpoint is disabled by default. - - -The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. - -* **Enabling and disabling the monitoring endpoint** - -To enable the endpoint, use the following configuration parameter: -```bash -endpoints.health.enabled=true -``` - -* **Customizing external service health indicators** - -The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. - -Demo webapp and Siva webapp also include additional information about the health of their dependent services. -These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. - -However, using the following parameters, these links can be overridden: - -| Property | Description | -| -------- | ----------- | -|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| -|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| -|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| - -For example: -```bash -endpoints.health.links[0].name=linkToXroad -endpoints.health.links[0].url=http://localhost:7777/monitoring/health -endpoints.health.links[0].timeout=1000 -``` - -!!! note - The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . - - -## Validation Report Signature - -SiVa provides the ability to sign the validation report. The idea of supplementing the validation report with a validation report signature is to prove the authority's authenticity and integrity over the validation. - -!!! note - Signing of validation report is disabled by default - -To enable it, use the following configuration parameter: -```bash -siva.report.reportSignatureEnabled=true -``` - -When validation report signature is enabled, only detailed validation reports will be signed, simple reports will not be signed. -The validation report's digital signature is composed out of response's `validationReport` object. The target format of the signature is ASiC-E (signature level is configurable). The ASiC-E container contents are encoded into Base64 and put on the same level int the response as the validation report itself. - -!!! note - Enabling the validation report signing will affect the performance of the service. - -Example structure of the response containing report signature: - -```json -{ - "validationReport": { - ... - }, - "validationReportSignature": "ZHNmYmhkZmdoZGcgZmRmMTM0NTM..." -} -``` - -Supported interfaces for signature creation: - -* **PKCS#11** - a platform-independent API for cryptographic tokens, such as hardware security modules (HSM) and smart cards -* **PKCS#12** - for files bundled with private key and certificate - -Report signature configuration parameters: - -Property | Description | -| -------- | ----------- | -|**siva.report.reportSignatureEnabled**| Enables signing of the validation report. Validation report will only be signed when requesting detailed report.
  • Default: **false**
| -|**siva.signatureService.signatureLevel**| The level of the validation report signature.
**Example values:**
* XAdES_BASELINE_B
* XAdES_BASELINE_T
* XAdES_BASELINE_LT
* XAdES_BASELINE_LTA | -|**siva.signatureService.tspUrl**| URL of the timestamp provider.
Only needed when the configured signature level is at least XAdES_BASELINE_T | -|**siva.signatureService.ocspUrl**| URL of the OCSP provider.
Only needed when the configured signature level is at least XAdES_BASELINE_LT | -|**siva.signatureService.pkcs11.path**| path to PKCS#11 module (depends on your installed smart card or hardware token library, for example: /usr/local/lib/opensc-pkcs11.so) | -|**siva.signatureService.pkcs11.password**| pin/password of the smart card or hardware token | -|**siva.signatureService.pkcs11.slotIndex**| depends on the hardware token. E.g. Estonian Smart Card uses 2, USB eToken uses 0.
  • Default: **0**
| -|**siva.signatureService.pkcs12.path**| path to keystore file containing certificate and private key | -|**siva.signatureService.pkcs12.password**| password of the keystore file containing certificate and private key | - -!!! note - When configuring report signature, either PKCS#11 or PKCS#12 should be configured, no need to configure both. - --------------------------------------------------------------------------------------- -## Configuration parameters - -All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. -However, all the properties can be overridden on the service or embedded web server level, if necessary. - -By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. -Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. - -For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: -```bash -server.port=8080 -``` - -Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: -```bash -server.max-http-post-size: 13981016 -``` - -See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot - -### Siva webapp parameters - -* Updating TSL - -| Property | Description | -| -------- | ----------- | -| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| -| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| -| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| -| **siva.tsl.loader.trustedTerritories** | Sets the trusted territories by countries
  • Default: **"AT", "BE", "BG", "CY", "CZ", "DE", "DK", "EE", "ES", "FI", "FR", "GR", "HU", "HR", "IE", "IS", "IT", "LT", "LU", "LV", "LI", "MT", "NO", "NL", "PL", "PT", "RO", "SE", "SI", "SK", "UK"**
| -| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 \* * ?**
| -| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| -| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| -| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| - -!!! note - Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). - -!!! note - TSL is currently used only by Generic and BDOC validators - - -* Forward to custom X-road webapp instance - -| Property | Description | -| ------ | ----------- | -| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| - -* Collecting statistics with Google Analytics - -| Property | Description | -| -------- | ----------- | -| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| -| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| -| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| -| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| - -* BDOC validation parameters - -| Property | Description | -| -------- | ----------- | -| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| - -Customizing BDOC validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.bdoc.signaturePolicy.policies[0].name=POLv3 -siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml - -siva.bdoc.signaturePolicy.policies[1].name=POLv4 -siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 -siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml - -siva.bdoc.signaturePolicy.defaultPolicy=POLv4 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* Generic validation - customize validation policies - -| Property | Description | -| -------- | ----------- | -|**siva.europe.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.europe.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.europe.signaturePolicy.policies[0].name=POLv3 -siva.europe.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.europe.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.europe.signaturePolicy.policies[0].constraintPath=generic_constraint_ades.xml - -siva.europe.signaturePolicy.policies[1].name=POLv4 -siva.europe.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.europe.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 -siva.europe.signaturePolicy.policies[1].constraintPath=generic_constraint_qes.xml - -siva.europe.signaturePolicy.defaultPolicy=POLv4 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* DDOC validation - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| - -Customizing DDOC validation policies: - -| Property | Description | -| -------- | ----------- | -|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.ddoc.signaturePolicy.policies[0].name=POLv3 -siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.ddoc.signaturePolicy.policies[0].constraintPath=ddoc_constraint_no_type.xml - -siva.ddoc.signaturePolicy.policies[1].name=POLv4 -siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. -siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 -siva.ddoc.signaturePolicy.policies[1].constraintPath=ddoc_constraint_qes.xml - -siva.ddoc.signaturePolicy.defaultPolicy=POLv4 -``` -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) - -* X-road validation - -| Property | Description | -| -------- | ----------- | -|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| - - -| Property | Description | -| -------- | ----------- | -|**siva.xroad.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| -|**siva.xroad.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| - -By default, the following configuration is used -```text -siva.xroad.signaturePolicy.policies[0].name=POLv3 -siva.xroad.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. -siva.xroad.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 -siva.xroad.signaturePolicy.policies[0].constraintPath=xroad_constraint_no_type.xml - -siva.xroad.signaturePolicy.defaultPolicy= POLv3 -``` - -!!! note - Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) -!!! note - By default, X-road validation currently supports only POLv3 - -### Demo webapp parameters - -* Linking to SiVa webapp - -| Property | Description | -| -------- | ----------- | -|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| -|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| -|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| -|**siva.service.jsonDataFilesServicePath**| Data file service path in Siva webapp to access the REST/JSON API
  • Default: **/getDataFiles**
| -|**siva.service.soapDataFilesServicePath**| Data file service path in Siva webapp to access the SOAP API
  • Default: **/soap/dataFilesWebService/getDocumentDataFiles**
| - +This guide describes how to integrate SiVa service with other applications. +The following is for system integrators who need to set-up, configure, manage, and troubleshoot SiVa system. + +### System requirements + +Following are the minimum requirements to build and deploy SiVa webapps as a service: + +* Java 8 or above Oracle JVM is supported +* Git version control system version 1.8 or above is recommended +* Minimum 2 GB of RAM. Recommended at least 4 GB of RAM +* Minimum 1 processor core +* Open internet connection +* 2GB of free disk space +* Supported operating system is Ubuntu 16.04 LTS + +## Building + +### Building SiVa webapps on Ubuntu 16.04 + +First we need to install Git and Java SDK 8 by issuing below commands: + +```bash +sudo apt-get update +sudo apt-get install git -y +sudo apt-get install default-jdk -y +``` + +Next we need to clone the SiVa Github repository: + +```bash +git clone https://github.com/open-eid/SiVa.git --branch master +``` + +Final step is building the SiVa project using Maven Wrapper + +```bash +cd SiVa +./mvnw clean install +``` + +!!! note + The build can take up to **30 minutes** because there are lot of tests that will be run through and downloading of the + required dependencies + +To verify that SiVa project built successfully look for `BUILD SUCCESS` in build compilation output last lines. +The last lines of build output should look very similar to below image: + +```text +[INFO] Reactor Summary: +[INFO] +[INFO] SiVa Digitally signed documents validation service . SUCCESS [ 1.632 s] +[INFO] validation-services-parent ......................... SUCCESS [ 0.897 s] +[INFO] validation-commons ................................. SUCCESS [ 12.321 s] +[INFO] tsl-loader ......................................... SUCCESS [ 6.917 s] +[INFO] Generic Validation Service ......................... SUCCESS [ 27.919 s] +[INFO] TimeStampToken Validation Service .................. SUCCESS [ 7.046 s] +[INFO] BDOC Validation Service ............................ SUCCESS [ 50.087 s] +[INFO] DDOC Validation Service ............................ SUCCESS [ 16.712 s] +[INFO] SiVa webapp and other core modules ................. SUCCESS [ 0.653 s] +[INFO] siva-monitoring .................................... SUCCESS [ 9.736 s] +[INFO] xroad-validation-service ........................... SUCCESS [ 19.761 s] +[INFO] siva-statistics .................................... SUCCESS [ 13.734 s] +[INFO] SiVa validation service proxy ...................... SUCCESS [ 11.509 s] +[INFO] SiVa signature service ............................. SUCCESS [ 6.869 s] +[INFO] siva-webapp ........................................ SUCCESS [ 27.608 s] +[INFO] SiVa Web Service integration tests ................. SUCCESS [03:53 min] +[INFO] siva-distribution .................................. SUCCESS [ 10.818 s] +[INFO] ------------------------------------------------------------------------ +[INFO] BUILD SUCCESS +[INFO] ------------------------------------------------------------------------ +[INFO] Total time: 08:18 min +[INFO] Finished at: 2017-12-04T13:49:48+02:00 +[INFO] Final Memory: 113M/903M +[INFO] ------------------------------------------------------------------------ +``` + + +## Deploying + +### OPTION 1 - starting webapps from command line +SiVa project compiles **2 fat executable JAR** files that you can run after successfully building the +project by issuing below commands: + +**First start the Siva webapp** + +```bash +./siva-parent/siva-webapp/target/siva-webapp-3.0.0.jar +``` + +**Second we need to start X-road validation webapp** + +```bash +./validation-services-parent/xroad-validation-service/target/xroad-validation-service-3.0.0.jar +``` + +The SiVa webapp by default runs on port **8080** and XRoad validation service starts up on port **8081**. +Easiest way to test out validation is run [SiVa demo application](https://github.com/open-eid/SiVa-demo-application). + +### OPTION 2 - running webapps as systemd services + +Maven build generates executable JAR files. This means web container and all its dependencies are package inside +single JAR file. It makes a lot easier to deploy it into servers. + +Easiest option to setup SiVa is as `systemd` service in Ubuntu servers. + +For that we first need to create service file: +```bash +vim siva-webapp.service +``` + +Inside it we need to paste below text. You need to change few things in service setup file. + +* First you **must not** run service as `root`. So it's strongly recommended to change line `User=root` +* Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file. +* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file + +```ini +[Unit] +Description=siva-webapp +After=syslog.target + +[Service] +User=root +ExecStart=/var/apps/siva-webapp.jar +Environment=JAVA_OPTS=-Xmx320m RUN_ARGS=--server.port=80 +SuccessExitStatus=143 + +[Install] +WantedBy=multi-user.target +``` + +Save and close the `siva-webapp.service` file. +Next we need to move `siva-webapp-3.0.0.jar` into newly created `/var/apps` directory and rename to +JAR file to `siva-webapp.jar`. match + +!!! note + The copied JAR filename must match option `ExecStart` in `siva-webapp.service` file + +```bash +sudo mkdir /var/apps +sudo cp siva-parent/siva-webapp/target/executable/siva-webapp-3.0.0.jar /var/apps/siva-webapp.jar +``` + +Next we need to copy the `siva-webapp.service` file into `/lib/systemd/system` directory. +Then we are ready to start the `siva-webapp` service. + +```bash +sudo cp siva-webapp.service /lib/systemd/system +sudo systemctl start siva-webapp +``` + +Final step of setting up the `siva-webapp` service is to verify that service started correctly by issuing below +command. + +```bash +systemctl status siva-webapp +``` + +It should print out similar to below picture: + +``` +● siva-webapp.service - siva-webapp + Loaded: loaded (/lib/systemd/system/siva-webapp.service; disabled; vendor preset: enabled) + Active: active (running) since Thu 2016-07-21 08:48:14 EDT; 1 day 2h ago + Main PID: 15965 (siva-webapp.jar) + Tasks: 34 + Memory: 429.6M + CPU: 2min 5.721s + CGroup: /system.slice/siva-webapp.service + ├─15965 /bin/bash /var/apps/stage/siva-webapp.jar + └─15982 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -Xmx320m -jar /var/apps/stage/siva-webapp.jar + +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.getTslModel(TSLParser.java:143) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: at eu.europa.esig.dss.tsl.service.TSLParser.call(TSLParser.java:129) +Jul 20 03:00:01 siva siva-webapp.jar[15965]: ... 5 common frames omitted +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +Jul 20 03:00:01 siva siva-webapp.jar[15965]: 20.07.2016 03:00:01.450 INFO [pool-3-thread-1] [e.e.e.dss.tsl.service.TSLRepository.sync +``` + +### OPTION 3 - deploy webapps as war files (Tomcat setup for legacy systems) + +> **NOTE 1**: We do not recommend using WAR deployment option because lack of testing done on different servlet +> containers also possible container application libraries conflicts + +> **NOTE 2**: Each SiVa service **must** be deployed to separate instance of Tomcat to avoid Java JAR library version +> conflicts. + +> **NOTE 3**: To limit your webapp request size (this is set automatically when deploying service as jar) one needs to configure the container manually. For example, when using [Tomcat 7](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) or [Tomcat 8](http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) - +the http connector parameter `maxPostSize` should be configured with the desired limit. + +> **NOTE 4**: The war file must be deployed to Tomcat ROOT. + +First we need to download Tomcat web servlet container as of the writing latest version available in version 8 branch is 8.5.24. We will download it with `wget` + +```bash +wget http://www-eu.apache.org/dist/tomcat/tomcat-8/v8.5.24/bin/apache-tomcat-8.5.24.tar.gz +``` + +Unpack it somewhere: + +```bash +tar xf apache-tomcat-8.5.24.tar.gz +``` + +Now we should build the WAR file. We have created helper script with all the correct Maven parameters. + +```bash +./war-build.sh +``` + +> **NOTE** The script will skip running the integration tests when building WAR files + +Final steps would be copying built WAR file into Tomcat `webapps` directory and starting the servlet container. + +```bash +cp siva-parent/siva-webapp/target/siva-webapp-3.0.0.war apache-tomcat-8.5.24/webapps +./apache-tomcat-7.0.77/bin/catalina.sh run +``` + +> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates +> `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change +> this default behavior you should set environment variable `DSS_DATA_FOLDER` + +### How-to set WAR deployed SiVa `application.properties` + +SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system. +To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory. + +Contents of the `setenv.sh` file should look like: + +```bash +export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.properties" +``` + + +### Smoke testing your deployed system + +**Step 1**. Install HTTPIE +`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed +and started correctly on our server. + +If you have Python and its package manager `pip` installed. Then You can issue below command: + +```bash +pip install httpie +``` + +**Step 2**. Download a sample JSON request file. + +```bash +http --download https://raw.githubusercontent.com/open-eid/SiVa/develop/build-helpers/sample-requests/bdocPass.json +``` + +**Step 3**. After successful download issue below command in same directory where you downloaded the file using +the command below. + +```bash +http POST http://localhost:8080/validate < bdocPass.json +``` +**Step 4**. Verify the output. The output of previous command should have similar data as below screenshot. Look for `signatureCount` and +`validSignatureCount`, they **must** be equal. + + +![HTTPIE output validation](../img/siva/siva2-output.png) + + +## Logging + +By default, logging works on the INFO level and logs are directed to the system console only. Logging functionality is handled by the SLF4J logging facade and on top of the Logback framework. As a result, logging can be configured via the standard Logback configuration file through Spring boot. Additional logging appenders can be added. Consult [logback documentation](http://logback.qos.ch/documentation.html) for more details on log file structure. + +For example, adding application.properties to classpath with the **logging.config** property +```bash +logging.config=/path/to/logback.xml +``` + +## Statistics + +For every report validated, a statistical report is composed that collects the following data: + +| Data | Description | +| ----- | ----- | +| Validation duration | The time it takes to process an incoming request - measured in milliseconds | +| Container type | Container type ( text value that identifies the signature type of the incoming document: ASiC-E, XAdES, ASiC-S or ASiC-E (BatchSignature) ) | +| Siva User ID | String (Text data that contains the SiVa user identifier for reports (from the HTTP x-authenticated-user header) or `N/A`) | +| Total signatures count | The value of the `signaturesCount` element in the validation report +| Valid signatures count | The value of the `validSignaturesCount` element in the validation report +| Signature validation indication(s) | Values of elements signatures/indication and signatures/subindication from the validation report. `indication[/subindication]` | +| Signature country/countries | Country code extracted from the signer certs. The ISO-3166-1 alpha-2 country code that is associated with signature (the signing certificate). Or constant string "XX" if the country cannot be determined. | +| Signature format(s) | Values of element signatures/signatureFormat from the validation report. | + +There are two channels where this information is sent: + +1. Log feeds (at INFO level) which can be redirected to files or to a syslog feed. + +2. **Google Analytics service** (as GA events). Turned off by default. See [Configuration parameters](/siva/v2/systemintegrators_guide/#configuration-parameters) for further details. + +The format and events are described in more detail in [SiVa_statistics.pdf](/pdf-files/SiVa_statistics.pdf) + +## Monitoring + +SiVa webapps provide an endpoint for external monitoring tools to periodically check the generic service health status. + +!!! note + Note that this endpoint is disabled by default. + + +The url for accessing JSON formatted health information with HTTP GET is `/monitoring/health` or `/monitoring/health.json`. See the [Interfaces section](/siva/v2/interfaces.md#service-health-monitoring) for response structure and details. + +* **Enabling and disabling the monitoring endpoint** + +To enable the endpoint, use the following configuration parameter: +```bash +endpoints.health.enabled=true +``` + +* **Customizing external service health indicators** + +The endpoint is implemented as a customized Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health), which allows to add custom health indicators. + +Demo webapp and Siva webapp also include additional information about the health of their dependent services. +These links to dependent web services have been preconfigured. For example, the Demo webapp is preset to check whether the Siva webapp is accessible from the following url (parameter `siva.service.serviceHost` value)/monitoring/health and the Siva webapp verifies that the X-road validation service webapp is accessible by checking the default url (configured by parameter `siva.proxy.xroadUrl` value)/monitoring/health url. + +However, using the following parameters, these links can be overridden: + +| Property | Description | +| -------- | ----------- | +|**endpoints.health.links[index].name**| A short link name
  • Default: **N/A**
| +|**endpoints.health.links[index].url**| URL to another monitoring endpoint that produces Spring boot [health endpoint](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html#production-ready-health) compatible JSON object as a response to HTTP GET.
  • Default: **N/A**
| +|**endpoints.health.links[index].timeout**| Connection timeout (in milliseconds)
  • Default: **N/A**
| + +For example: +```bash +endpoints.health.links[0].name=linkToXroad +endpoints.health.links[0].url=http://localhost:7777/monitoring/health +endpoints.health.links[0].timeout=1000 +``` + +!!! note + The external link configuration must be explicitly set when the monitoring service on the target machine is configured to run on a different port as the target service itself(ie using the `management.port` option in configuration) . + + +## Validation Report Signature + +SiVa provides the ability to sign the validation report. The idea of supplementing the validation report with a validation report signature is to prove the authority's authenticity and integrity over the validation. + +!!! note + Signing of validation report is disabled by default + +To enable it, use the following configuration parameter: +```bash +siva.report.reportSignatureEnabled=true +``` + +When validation report signature is enabled, only detailed validation reports will be signed, simple reports will not be signed. +The validation report's digital signature is composed out of response's `validationReport` object. The target format of the signature is ASiC-E (signature level is configurable). The ASiC-E container contents are encoded into Base64 and put on the same level int the response as the validation report itself. + +!!! note + Enabling the validation report signing will affect the performance of the service. + +Example structure of the response containing report signature: + +```json +{ + "validationReport": { + ... + }, + "validationReportSignature": "ZHNmYmhkZmdoZGcgZmRmMTM0NTM..." +} +``` + +Supported interfaces for signature creation: + +* **PKCS#11** - a platform-independent API for cryptographic tokens, such as hardware security modules (HSM) and smart cards +* **PKCS#12** - for files bundled with private key and certificate + +Report signature configuration parameters: + +Property | Description | +| -------- | ----------- | +|**siva.report.reportSignatureEnabled**| Enables signing of the validation report. Validation report will only be signed when requesting detailed report.
  • Default: **false**
| +|**siva.signatureService.signatureLevel**| The level of the validation report signature.
**Example values:**
* XAdES_BASELINE_B
* XAdES_BASELINE_T
* XAdES_BASELINE_LT
* XAdES_BASELINE_LTA | +|**siva.signatureService.tspUrl**| URL of the timestamp provider.
Only needed when the configured signature level is at least XAdES_BASELINE_T | +|**siva.signatureService.ocspUrl**| URL of the OCSP provider.
Only needed when the configured signature level is at least XAdES_BASELINE_LT | +|**siva.signatureService.pkcs11.path**| path to PKCS#11 module (depends on your installed smart card or hardware token library, for example: /usr/local/lib/opensc-pkcs11.so) | +|**siva.signatureService.pkcs11.password**| pin/password of the smart card or hardware token | +|**siva.signatureService.pkcs11.slotIndex**| depends on the hardware token. E.g. Estonian Smart Card uses 2, USB eToken uses 0.
  • Default: **0**
| +|**siva.signatureService.pkcs12.path**| path to keystore file containing certificate and private key | +|**siva.signatureService.pkcs12.password**| password of the keystore file containing certificate and private key | + +!!! note + When configuring report signature, either PKCS#11 or PKCS#12 should be configured, no need to configure both. + +-------------------------------------------------------------------------------------- +## Configuration parameters + +All SiVa webapps have been designed to run with predetermined defaults after building and without additional configuration. +However, all the properties can be overridden on the service or embedded web server level, if necessary. + +By default, the service loads it's global configuration from the application.yml file that is packaged inside the jar file. +Default configuration parameters can be overridden by providing custom application.yml in the [following locations](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files), or using command line parameters or by using other [externalized configuration methods](http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html) methods. + +For example, to configure the embedded Tomcat web server inside a fat jar to run on different port (default is 8080), change the **server.port** following property: +```bash +server.port=8080 +``` + +Or to increase or modify the default http request limit, override the **server.max-http-post-size** property: +```bash +server.max-http-post-size: 13981016 +``` + +See the reference list of all common [application properties](http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html) provided by Spring boot + +### Siva webapp parameters + +* Updating TSL + +| Property | Description | +| -------- | ----------- | +| **siva.tsl.loader.loadFromCache** | A boolean value that determines, whether the TSL disk cache is updated by downloading a new TSL in a predetermined interval

Note that the cache is by default stored in a system temporary folder (can be set with system property `java.io.tmpdir`) in a subdirectory named `dss_cache_tsl`
  • When set to **false** the cache is refreshed periodically by SiVa in a predetermined interval specified by `siva.tsl.loader.schedulerCron` using `siva.tsl.loader.url`
  • When set to **true** the siva uses existing cache as it's TSL. No direct polling for updates are performed.
  • Default: **false**
| +| **siva.tsl.loader.url** | A url value that points to the external TSL
  • Default: **https://ec.europa.eu/tools/lotl/eu-lotl.xml**
| +| **siva.tsl.loader.code** | Sets the LOTL code in DSS
  • Default: **EU**
| +| **siva.tsl.loader.trustedTerritories** | Sets the trusted territories by countries
  • Default: **"AT", "BE", "BG", "CY", "CZ", "DE", "DK", "EE", "ES", "FI", "FR", "GR", "HU", "HR", "IE", "IS", "IT", "LT", "LU", "LV", "LI", "MT", "NO", "NL", "PL", "PT", "RO", "SE", "SI", "SK", "UK"**
| +| **siva.tsl.loader.schedulerCron** | A string in a [Crontab expression format](http://www.manpagez.com/man/5/crontab/) that defines the interval at which the TSL renewal process is started. The default is 03:00 every day (local time)
  • Default: **0 0 3 \* * ?**
| +| **siva.keystore.type** | Keystore type. Keystore that contains public keys to verify the signed TSL
  • Default: **JKS**
| +| **siva.keystore.filename** | Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore.jks**
| +| **siva.keystore.password** | Keystore password. Keystore that contains public keys to verify the signed TSL
  • Default: **siva-keystore-password**
| + +!!! note + Note that the keystore file location can be overriden using environment variable `DSS_DATA_FOLDER`. By default the keystore file location, is expected to be on local filesystem in `etc` directory which is at the same level with the fat jar file (one is created, if no such directory exists). + +!!! note + TSL is currently used only by Generic and BDOC validators + + +* Forward to custom X-road webapp instance + +| Property | Description | +| ------ | ----------- | +| **siva.proxy.xroadUrl** | A URL where the X-Road validation requests are forwarded
  • Default: **http://localhost:8081**
| + +* Collecting statistics with Google Analytics + +| Property | Description | +| -------- | ----------- | +| **siva.statistics.google-analytics.enabled** | Enables/disables the service
  • Default: **false**
| +| **siva.statistics.google-analytics.url** | Statistics endpoint URL
  • Default: **http://www.google-analytics.com/batch**
| +| **siva.statistics.google-analytics.trackingId** | The Google Analytics tracking ID
  • Default: **UA-83206619-1**
| +| **siva.statistics.google-analytics.dataSourceName** | Descriptive text of the system
  • Default: **SiVa**
| + +* BDOC validation parameters + +| Property | Description | +| -------- | ----------- | +| **siva.bdoc.digidoc4JConfigurationFile** | Path to Digidoc4j configuration override
  • Default: **N/A**
| + +Customizing BDOC validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.bdoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.bdoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.bdoc.signaturePolicy.policies[0].name=POLv3 +siva.bdoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.bdoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.bdoc.signaturePolicy.policies[0].constraintPath=bdoc_constraint_no_type.xml + +siva.bdoc.signaturePolicy.policies[1].name=POLv4 +siva.bdoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.bdoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 +siva.bdoc.signaturePolicy.policies[1].constraintPath=bdoc_constraint_qes.xml + +siva.bdoc.signaturePolicy.defaultPolicy=POLv4 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* Generic validation - customize validation policies + +| Property | Description | +| -------- | ----------- | +|**siva.europe.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.europe.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.europe.signaturePolicy.policies[0].name=POLv3 +siva.europe.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.europe.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.europe.signaturePolicy.policies[0].constraintPath=generic_constraint_ades.xml + +siva.europe.signaturePolicy.policies[1].name=POLv4 +siva.europe.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.europe.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 +siva.europe.signaturePolicy.policies[1].constraintPath=generic_constraint_qes.xml + +siva.europe.signaturePolicy.defaultPolicy=POLv4 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* DDOC validation + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.jdigidocConfigurationFile**| Path to JDigidoc configuration file. Determines the Jdigidoc configuration parameters (see [JDigidoc manual](https://github.com/open-eid/jdigidoc/blob/master/doc/SK-JDD-PRG-GUIDE.pdf) for details.
  • Default: **/siva-jdigidoc.cfg**
| + +Customizing DDOC validation policies: + +| Property | Description | +| -------- | ----------- | +|**siva.ddoc.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.ddoc.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.ddoc.signaturePolicy.policies[0].name=POLv3 +siva.ddoc.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.ddoc.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.ddoc.signaturePolicy.policies[0].constraintPath=ddoc_constraint_no_type.xml + +siva.ddoc.signaturePolicy.policies[1].name=POLv4 +siva.ddoc.signaturePolicy.policies[1].description=Policy for validating Qualified Electronic Signatures and Qualified Electronic Seals (according to Regulation (EU) No 910/2014). I.e. signatures that have been recognized as Advanced electronic Signatures (AdES) and AdES supported by a Qualified Certificate (AdES/QC) do not produce a positive validation result. +siva.ddoc.signaturePolicy.policies[1].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv4 +siva.ddoc.signaturePolicy.policies[1].constraintPath=ddoc_constraint_qes.xml + +siva.ddoc.signaturePolicy.defaultPolicy=POLv4 +``` +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) + +* X-road validation + +| Property | Description | +| -------- | ----------- | +|**siva.xroad.validation.service.configurationDirectoryPath**| Directory that contains the certs of approved CA's, TSA's and list of members
  • Default: **/verificationconf**
| + + +| Property | Description | +| -------- | ----------- | +|**siva.xroad.signaturePolicy.defaultPolicy**| Selected default policy name
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].name**| Policy name
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].description**| Policy description
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].constraintPath**| Constraint XML file path for the policy. An absolute path or a reference to a resource on the classpath
  • Default: **N/A**
| +|**siva.xroad.signaturePolicy.policies[index].url**| Policy URL
  • Default: **N/A**
| + +By default, the following configuration is used +```text +siva.xroad.signaturePolicy.policies[0].name=POLv3 +siva.xroad.signaturePolicy.policies[0].description=Policy for validating Electronic Signatures and Electronic Seals regardless of the legal type of the signature or seal (according to Regulation (EU) No 910/2014), i.e. the fact that the electronic signature or electronic seal is either Advanced electronic Signature (AdES), AdES supported by a Qualified Certificate (AdES/QC) or a Qualified electronic Signature (QES) does not change the total validation result of the signature. +siva.xroad.signaturePolicy.policies[0].url=http://open-eid.github.io/SiVa/siva2/appendix/validation_policy/#POLv3 +siva.xroad.signaturePolicy.policies[0].constraintPath=xroad_constraint_no_type.xml + +siva.xroad.signaturePolicy.defaultPolicy= POLv3 +``` + +!!! note + Default policy configuration is lost when policy detail properties (name, description, url or constraintPath) are overridden or new custom policies added in custom configuration files (in this case, the existing default policies must be redefined in configuration files explicitly) +!!! note + By default, X-road validation currently supports only POLv3 + +### Demo webapp parameters + +* Linking to SiVa webapp + +| Property | Description | +| -------- | ----------- | +|**siva.service.serviceHost**| An HTTP URL link to the Siva webapp
  • Default: **http://localhost:8080**
| +|**siva.service.jsonServicePath**| Service path in Siva webapp to access the REST/JSON API
  • Default: **/validate**
| +|**siva.service.soapServicePath**| Service path in Siva webapp to access the SOAP API
  • Default: **/soap/validationWebService/validateDocument**
| +|**siva.service.jsonDataFilesServicePath**| Data file service path in Siva webapp to access the REST/JSON API
  • Default: **/getDataFiles**
| +|**siva.service.soapDataFilesServicePath**| Data file service path in Siva webapp to access the SOAP API
  • Default: **/soap/dataFilesWebService/getDocumentDataFiles**
| + From 9220bd60c4eca8d8b1055edac8a8dc804d3daa3e Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 10:50:26 +0300 Subject: [PATCH 07/11] Restore accidentaly removed .gitattributes file by merge conflict fixes --- .gitattributes | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 .gitattributes diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 000000000..2eb7c2878 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,6 @@ +# Set the default behavior, in case people don't have core.autocrlf set. +* text=auto + +# Declare files that will always have LF line endings on checkout. +mvnw text eol=lf +*.sh text eol=lf From 13d0656bc3c2d9a78fe9ebecd1a93ef9cb0410c8 Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 11:16:11 +0300 Subject: [PATCH 08/11] Fix other issues from merge conflicts --- .../DDOCContainerValidationReportBuilder.java | 17 ++++------------- ...TimemarkHashcodeValidationReportBuilder.java | 4 ++-- .../timemark/util/SignatureScopeParser.java | 8 ++++---- 3 files changed, 10 insertions(+), 19 deletions(-) diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java index cd7bf4cf7..92cd46510 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/DDOCContainerValidationReportBuilder.java @@ -23,6 +23,7 @@ import ee.openeid.siva.validation.document.report.ValidationConclusion; import ee.openeid.siva.validation.document.report.ValidationWarning; import ee.openeid.siva.validation.service.signature.policy.properties.ValidationPolicy; +import ee.openeid.validation.service.timemark.util.SignatureScopeParser; import org.apache.commons.lang3.StringUtils; import org.digidoc4j.Container; import org.digidoc4j.ContainerValidationResult; @@ -35,7 +36,6 @@ import java.util.ArrayList; import java.util.List; -import java.util.stream.Collectors; public class DDOCContainerValidationReportBuilder extends TimemarkContainerValidationReportBuilder { @@ -85,10 +85,9 @@ List getExtraValidationWarnings() { @Override List getSignatureScopes(Signature signature, List dataFilenames) { - return dataFilenames - .stream() - .map(this::mapDataFile) - .collect(Collectors.toList()); + return dataFilenames.stream() + .map(SignatureScopeParser::createFullSignatureScopeForDataFile) + .toList(); } @Override @@ -107,14 +106,6 @@ List getArchiveTimestamps(Signature signature) { return null; } - private Scope mapDataFile(String filename) { - Scope signatureScope = new Scope(); - signatureScope.setName(filename); - signatureScope.setContent(FULL_DOCUMENT); - signatureScope.setScope(FULL_SIGNATURE_SCOPE); - return signatureScope; - } - private String getDigidocXmlSignatureForm() { return DDOC_SIGNATURE_FORM_PREFIX + ((DDocContainer) container).getDDoc4JFacade().getVersion() + getSignatureFormSuffix(); } diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java index 05a4a1063..06d5e1754 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkHashcodeValidationReportBuilder.java @@ -3,7 +3,7 @@ import ee.openeid.siva.validation.document.Datafile; import ee.openeid.siva.validation.document.ValidationDocument; import ee.openeid.siva.validation.document.report.Reports; -import ee.openeid.siva.validation.document.report.SignatureScope; +import ee.openeid.siva.validation.document.report.Scope; import ee.openeid.siva.validation.document.report.SignatureValidationData; import ee.openeid.siva.validation.document.report.SimpleReport; import ee.openeid.siva.validation.document.report.ValidationConclusion; @@ -122,7 +122,7 @@ private Optional getAsicSignatureS : Optional.empty(); } - private List getSignatureScopes() { + private List getSignatureScopes() { return signature instanceof AsicSignature ? getAsicSignatureScopes((AsicSignature) signature, getDataFileNames()) : emptyList(); diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java index 26f40c0b8..92cbd7c2a 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/util/SignatureScopeParser.java @@ -1,6 +1,6 @@ package ee.openeid.validation.service.timemark.util; -import ee.openeid.siva.validation.document.report.SignatureScope; +import ee.openeid.siva.validation.document.report.Scope; import lombok.experimental.UtilityClass; import org.digidoc4j.impl.asic.AsicSignature; import org.slf4j.LoggerFactory; @@ -16,7 +16,7 @@ public class SignatureScopeParser { private static final String FULL_SIGNATURE_SCOPE = "FullSignatureScope"; private static final String FULL_DOCUMENT = "Digest of the document content"; - public static List getAsicSignatureScopes(AsicSignature signature, List dataFilenames) { + public static List getAsicSignatureScopes(AsicSignature signature, List dataFilenames) { return signature.getOrigin().getReferences() .stream() .map(r -> decodeUriIfPossible(r.getURI())) @@ -34,8 +34,8 @@ private static String decodeUriIfPossible(String uri) { } } - public static SignatureScope createFullSignatureScopeForDataFile(String filename) { - SignatureScope signatureScope = new SignatureScope(); + public static Scope createFullSignatureScopeForDataFile(String filename) { + Scope signatureScope = new Scope(); signatureScope.setName(filename); signatureScope.setScope(FULL_SIGNATURE_SCOPE); signatureScope.setContent(FULL_DOCUMENT); From a780d1720b4abcf09f74d43d589e17744f6955ea Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 11:23:37 +0300 Subject: [PATCH 09/11] Fix other issues from merge conflicts --- .../HashcodeGenericValidationServiceTest.java | 61 ++++++------------- 1 file changed, 17 insertions(+), 44 deletions(-) diff --git a/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java b/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java index dfc551e22..d506845bb 100644 --- a/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java +++ b/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java @@ -1,5 +1,5 @@ /* - * Copyright 2019 - 2025 Riigi Infosüsteemi Amet + * Copyright 2019 - 2024 Riigi Infosüsteemi Amet * * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by * the European Commission - subsequent versions of the EUPL (the "Licence"); @@ -22,7 +22,7 @@ import ee.openeid.siva.validation.document.report.CertificateType; import ee.openeid.siva.validation.document.report.Reports; import ee.openeid.siva.validation.document.report.SignatureProductionPlace; -import ee.openeid.siva.validation.document.report.Scope; +import ee.openeid.siva.validation.document.report.SignatureScope; import ee.openeid.siva.validation.document.report.SignatureValidationData; import ee.openeid.siva.validation.document.report.SignerRole; import ee.openeid.siva.validation.service.signature.policy.ConstraintLoadingSignaturePolicyService; @@ -49,7 +49,6 @@ import java.security.cert.Certificate; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; -import java.util.ArrayList; import java.util.Collections; import java.util.List; @@ -60,8 +59,6 @@ @SpringBootTest(classes = {PDFValidationServiceTest.TestConfiguration.class}) @ExtendWith(SpringExtension.class) class HashcodeGenericValidationServiceTest { - - private HashcodeGenericValidationService validationService; private ConstraintLoadingSignaturePolicyService signaturePolicyService; @Autowired @@ -77,13 +74,12 @@ class HashcodeGenericValidationServiceTest { @BeforeEach public void setUp() { + signaturePolicyService = new ConstraintLoadingSignaturePolicyService(policySettings); + validationService = new HashcodeGenericValidationService(); validationService.setTrustedListsCertificateSource(trustedListsCertificateSource); - - signaturePolicyService = new ConstraintLoadingSignaturePolicyService(policySettings); validationService.setSignaturePolicyService(signaturePolicyService); validationService.setReportConfigurationProperties(new ReportConfigurationProperties(true)); - validationService.setContainerValidatorFactory(containerValidatorFactory); validationService.setRevocationFreshnessValidatorFactory(revocationFreshnessValidatorFactory); validationService.setOcspSourceFactory(ocspSourceFactory); @@ -91,8 +87,8 @@ public void setUp() { @Test void validHashcodeRequest() throws Exception { - Reports response = validationService.validate(getValidationDocumentSingletonList()); - Scope signatureScope = response.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureScopes().get(0); + Reports response = validationService.validateDocument(getValidationDocument()); + SignatureScope signatureScope = response.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureScopes().get(0); assertEquals("LvhnsrgBZBK9kTQ8asbPtcsjuEhBo9s3QDdCcIxlMmo=", signatureScope.getHash()); assertEquals("SHA256", signatureScope.getHashAlgo()); assertEquals("test.pdf", signatureScope.getName()); @@ -100,30 +96,9 @@ void validHashcodeRequest() throws Exception { assertEquals(1L, response.getSimpleReport().getValidationConclusion().getSignatures().size()); } - @Test - void validMultipleSignatures() throws Exception { - List validationDocuments = getValidationDocumentSingletonList(); - validationDocuments.addAll(getValidationDocumentSingletonList()); - Reports response = validationService.validate(validationDocuments); - assertEquals((Integer) 2, response.getSimpleReport().getValidationConclusion().getValidSignaturesCount()); - assertEquals((Integer) 2, response.getSimpleReport().getValidationConclusion().getSignaturesCount()); - assertEquals(2L, response.getSimpleReport().getValidationConclusion().getSignatures().size()); - } - - @Test - void validDataFromSignatureFile() throws Exception { - List validationDocuments = getValidationDocumentSingletonList(); - validationDocuments.get(0).setDatafiles(null); - Reports response = validationService.validate(validationDocuments); - Scope signatureScope = response.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureScopes().get(0); - assertEquals("LvhnsrgBZBK9kTQ8asbPtcsjuEhBo9s3QDdCcIxlMmo=", signatureScope.getHash()); - assertEquals("SHA256", signatureScope.getHashAlgo()); - assertEquals("test.pdf", signatureScope.getName()); - } - @Test void hashcodeValidationCertificateCorrectlyPresent() throws Exception { - Reports response = validationService.validate(getValidationDocumentSingletonList()); + Reports response = validationService.validateDocument(getValidationDocument()); SignatureValidationData signatureValidationData = response.getSimpleReport().getValidationConclusion().getSignatures().get(0); CertificateFactory cf = CertificateFactory.getInstance("X.509"); @@ -149,7 +124,7 @@ void hashcodeValidationCertificateCorrectlyPresent() throws Exception { @Test void hashcodeValidationSubjectDNCorrectlyPresent() throws Exception { - Reports reports = validationService.validate(getValidationDocumentSingletonList()); + Reports reports = validationService.validateDocument(getValidationDocument()); assertSame(1, reports.getSimpleReport().getValidationConclusion().getSignatures().size()); SignatureValidationData signature = reports.getSimpleReport().getValidationConclusion().getSignatures().get(0); @@ -160,7 +135,7 @@ void hashcodeValidationSubjectDNCorrectlyPresent() throws Exception { @Test void populatesSignerRole() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList()); + Reports reports = validationService.validateDocument(getValidationDocument()); List signerRole = reports.getSimpleReport().getValidationConclusion().getSignatures().get(0).getInfo().getSignerRole(); assertEquals(1, signerRole.size()); assertEquals("Direktorius", signerRole.get(0).getClaimedRole()); @@ -168,7 +143,7 @@ void populatesSignerRole() throws IOException, URISyntaxException { @Test void populatesSignatureProductionPlace() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList("test-files/signatures_with_sig_production_place.xml")); + Reports reports = validationService.validateDocument(getValidationDocument("test-files/signatures_with_sig_production_place.xml")); SignatureProductionPlace signatureProductionPlace = reports.getSimpleReport().getValidationConclusion() .getSignatures().get(0).getInfo().getSignatureProductionPlace(); @@ -180,31 +155,29 @@ void populatesSignatureProductionPlace() throws IOException, URISyntaxException @Test void populatesSignatureMethod() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList("test-files/signatures_with_sig_production_place.xml")); + Reports reports = validationService.validateDocument(getValidationDocument("test-files/signatures_with_sig_production_place.xml")); assertEquals("http://www.w3.org/2001/04/xmldsig-more#rsa-sha256", reports.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureMethod()); } @Test void populatesTimeAssertionMessageImprint() throws IOException, URISyntaxException { - Reports reports = validationService.validate(getValidationDocumentSingletonList()); + Reports reports = validationService.validateDocument(getValidationDocument()); assertEquals("MDEwDQYJYIZIAWUDBAIBBQAEIBf8So+lfR/lrfzu5i+SZwguJGakhr/W+eHwrAQJ0acJ", reports.getSimpleReport().getValidationConclusion().getSignatures().get(0).getInfo().getTimeAssertionMessageImprint()); } - private List getValidationDocumentSingletonList() throws URISyntaxException, IOException { - return getValidationDocumentSingletonList("test-files/signatures.xml"); + private ValidationDocument getValidationDocument() throws URISyntaxException, IOException { + return getValidationDocument("test-files/signatures.xml"); } - private List getValidationDocumentSingletonList(String signatureTestFile) throws URISyntaxException, IOException { - List validationDocuments = new ArrayList<>(); + private ValidationDocument getValidationDocument(String signatureTestFile) throws URISyntaxException, IOException { ValidationDocument validationDocument = new ValidationDocument(); validationDocument.setDatafiles(Collections.singletonList(getDataFile())); Path documentPath = Paths.get(getClass().getClassLoader().getResource(signatureTestFile).toURI()); validationDocument.setBytes(Files.readAllBytes(documentPath)); validationDocument.setSignaturePolicy("POLv3"); - validationDocuments.add(validationDocument); - return validationDocuments; + return validationDocument; } private Datafile getDataFile() { @@ -214,4 +187,4 @@ private Datafile getDataFile() { datafile.setHashAlgo("SHA256"); return datafile; } -} +} \ No newline at end of file From 8c7b0ba68ad0fd21e816ff83add4c3af00f2f275 Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 11:31:18 +0300 Subject: [PATCH 10/11] Fix other issues from merge conflicts --- .../generic/HashcodeGenericValidationServiceTest.java | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java b/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java index d506845bb..bd9e224b6 100644 --- a/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java +++ b/validation-services-parent/generic-validation-service/src/test/java/ee/openeid/validation/service/generic/HashcodeGenericValidationServiceTest.java @@ -1,5 +1,5 @@ /* - * Copyright 2019 - 2024 Riigi Infosüsteemi Amet + * Copyright 2019 - 2025 Riigi Infosüsteemi Amet * * Licensed under the EUPL, Version 1.1 or – as soon they will be approved by * the European Commission - subsequent versions of the EUPL (the "Licence"); @@ -22,7 +22,7 @@ import ee.openeid.siva.validation.document.report.CertificateType; import ee.openeid.siva.validation.document.report.Reports; import ee.openeid.siva.validation.document.report.SignatureProductionPlace; -import ee.openeid.siva.validation.document.report.SignatureScope; +import ee.openeid.siva.validation.document.report.Scope; import ee.openeid.siva.validation.document.report.SignatureValidationData; import ee.openeid.siva.validation.document.report.SignerRole; import ee.openeid.siva.validation.service.signature.policy.ConstraintLoadingSignaturePolicyService; @@ -88,7 +88,7 @@ public void setUp() { @Test void validHashcodeRequest() throws Exception { Reports response = validationService.validateDocument(getValidationDocument()); - SignatureScope signatureScope = response.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureScopes().get(0); + Scope signatureScope = response.getSimpleReport().getValidationConclusion().getSignatures().get(0).getSignatureScopes().get(0); assertEquals("LvhnsrgBZBK9kTQ8asbPtcsjuEhBo9s3QDdCcIxlMmo=", signatureScope.getHash()); assertEquals("SHA256", signatureScope.getHashAlgo()); assertEquals("test.pdf", signatureScope.getName()); @@ -187,4 +187,4 @@ private Datafile getDataFile() { datafile.setHashAlgo("SHA256"); return datafile; } -} \ No newline at end of file +} From f115a251751d1fb6d008d7ad813bbb3d44ce4b6c Mon Sep 17 00:00:00 2001 From: "Sander.Kondratjev" Date: Tue, 3 Jun 2025 13:13:48 +0300 Subject: [PATCH 11/11] Fix other issues from merge conflicts --- .../AsicContainerValidationReportBuilder.java | 29 ++----------------- ...emarkContainerValidationReportBuilder.java | 2 -- 2 files changed, 2 insertions(+), 29 deletions(-) diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java index 3739ca506..0ed523b91 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/AsicContainerValidationReportBuilder.java @@ -41,16 +41,14 @@ import org.digidoc4j.impl.asic.AsicSignature; import org.digidoc4j.impl.asic.asice.AsicESignature; -import java.io.UnsupportedEncodingException; -import java.net.URLDecoder; import java.security.cert.X509Certificate; import java.util.ArrayList; import java.util.List; import java.util.Optional; -import java.util.stream.Collectors; import static ee.openeid.siva.validation.document.report.builder.ReportBuilderUtils.getDateFormatterWithGMTZone; import static ee.openeid.validation.service.timemark.util.SignatureCertificateParser.getCertificate; +import static ee.openeid.validation.service.timemark.util.SignatureScopeParser.getAsicSignatureScopes; public class AsicContainerValidationReportBuilder extends TimemarkContainerValidationReportBuilder { @@ -117,13 +115,7 @@ List getExtraValidationWarnings() { @Override List getSignatureScopes(Signature signature, List dataFilenames) { - AsicESignature bDocSignature = (AsicESignature) signature; - return bDocSignature.getOrigin().getReferences() - .stream() - .map(r -> decodeUriIfPossible(r.getURI())) - .filter(dataFilenames::contains) //filters out Signed Properties - .map(AsicContainerValidationReportBuilder::createFullSignatureScopeForDataFile) - .collect(Collectors.toList()); + return getAsicSignatureScopes((AsicSignature) signature, dataFilenames); } @Override @@ -148,23 +140,6 @@ List getArchiveTimestamps(Signature signature) { .orElse(null); } - private static Scope createFullSignatureScopeForDataFile(String filename) { - Scope signatureScope = new Scope(); - signatureScope.setName(filename); - signatureScope.setScope(FULL_SIGNATURE_SCOPE); - signatureScope.setContent(FULL_DOCUMENT); - return signatureScope; - } - - private String decodeUriIfPossible(String uri) { - try { - return URLDecoder.decode(uri, "UTF-8"); - } catch (UnsupportedEncodingException e) { - LOGGER.warn("datafile " + uri + " has unsupported encoding", e); - return uri; - } - } - private List generateArchiveTimestamps(List timestamps, Signature signature) { List archiveTimestamps = new ArrayList<>(); diff --git a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java index e6da81089..1fcbb4972 100644 --- a/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java +++ b/validation-services-parent/timemark-container-validation-service/src/main/java/ee/openeid/validation/service/timemark/report/TimemarkContainerValidationReportBuilder.java @@ -76,8 +76,6 @@ public abstract class TimemarkContainerValidationReportBuilder { protected static final org.slf4j.Logger LOGGER = LoggerFactory.getLogger(TimemarkContainerValidationReportBuilder.class); - protected static final String FULL_SIGNATURE_SCOPE = "FullSignatureScope"; - protected static final String FULL_DOCUMENT = "Digest of the document content"; protected static final String XADES_FORMAT_PREFIX = "XAdES_BASELINE_"; protected static final String REPORT_INDICATION_INDETERMINATE = "INDETERMINATE"; protected static final String BDOC_SIGNATURE_FORM = "ASiC-E";