Secure XML processing

This release ensures that XML DOCTYPE declarations are denied when parsing, which is to mitigate the possibility for XML External Entity attacks. This is mainly to secure the Posten signering API, because the signature-api-specification-jaxb is used when parsing (unmarshalling) the requests from clients.

Jakarta compatibility

This release provides compatibility with the new Jakarta namespace for the JAXB-artifact. The JAXB stack is still based on the javax namespace in order to also be compatible with legacy Java EE, but care is taken to use on JAXB dependencies which may exist alongside any libraries from the newer Jakarta namespace. This is achieved using https://github.com/digipost/jaxb-resolver-com.sun.xml.bind

What's Changed

• Remove spring dependency by @simenstoa in #270
• Support marshalling to string and byte array by @runeflobakk in #274
• Use old JAXB artifacts by @runeflobakk in #281
• Finalize v3 by @runeflobakk in #288

Full Changelog: 2.8...3.0.0

3.0.0-RC3

What's Changed

• Removed dependency on Spring (Jaxb2Marshaller).
• Fixed error in SignatureApiSchemas, where PORTAL_ONLY pointed at the wrong schema

Multisignatar for synkrone oppdrag

Funksjonelt

• Multisignatar for synkrone oppdrag. Ved opprettelse av synkrone oppdrag er det nå mulig å spesifisere opp til 10 signatarer (samme grense som for asynkrone oppdrag). Tjenesten vil returnere én redirect-url pr. signatar ved opprettelse som avsender skal videresende brukeren(e) til. Ved henting av status vil responsen fra tjenesten inneholde én aggregert status for hele signeringsoppdraget. I tillegg kommer én status og 0 eller én URL for å hente XAdES for hver signatar (avhengig om signataren har signert eller ikke).

Teknisk

• Bryter bakoverkompabilitet: endret respons ved henting av status for synkrone signeringsoppdrag. status i signature er endret fra en XML-enum til string. status kan i fremtiden få nye verdier som vil være ukjent for eksisterende klienter. Klienter som bruker forrige versjon av APIet vil oppleve feil når de mottar responser med nye enum-typer. Ved ukjent signatarstatus skal klienten forholde seg til overordnet signaturstatus, som beskrevet under. Denne endringen påvirker bare integrasjoner som oppretter redirectoppdrag.

Polling på synkrone oppdrag

Funksjonelt

• Polling på synkrone oppdrag.
  Det synkrone API et mot signeringstjenesten er endret med en alternativ måte å hente ned det signerte dokumentet for avsenderen. Utvidelsen gir mulighet til å gjøre generell polling ved å spørre om status på alle synkrone oppdrag for en gitt avsender. På samme måte som i det asynkrone APIet vil klienten tolke alle statuser som returneres (alle åpne synkrone oppdrag) og markere hvilke statuser som er ferdigprosessert før referansen i statusresponsen brukes til å hente det signerte dokumentet.

Varsling og arkiv

Denne versjonen bryter bakoverkompabilitet ved opprettelse av portaloppdrag via API. Se teknisk for mer informasjon.

Funksjonelt

• Langtidsarkivering av signeringsoppdrag.
  Ved arkivering vil oppdrag oppbevares i virksomhetens akriv i Signeringstjenesten i 50 år. Arkivering skrus på for hver enkelt virksomhet, og vil ikke påvirke eksistserende virksomheter.
• Varsling av signatarer.
  Oppslagstjenesten slår opp kontaktinformasjon for borgere i Difis Kontakt- og reservasjonsregister for oppdrag som skal signeres i portalen. Dette gjøres for alle nyopprettede portaloppdrag, og vil derfor endre oppførselen for eksisterende virksomheter. Se den funksjonelle dokumentasjonen for mer informasjon om varsling. Endringen er ikke relevant for synkrone signeringsoppdrag.
• Ikke-sensitiv tittel for oppdrag.
  Virksomheter kan spesifisere en ikke-sensitiv tittel for signeringsoppdraget. Denne tittelen kan brukes i kontekster der brukeren ikke er sterkt autentisert, som for eksempel i varsler eller kommunikasjon til saksbehandlere hos virksomheten.

Teknisk

• Bryter bakoverkompabilitet: endret respons ved polling av status på signeringsoppdrag.
  status i signature er endret fra en XML-enum til string. status kan i fremtiden få nye verdier som vil være ukjent for eksisterende klienter. Klienter som bruker forrige versjon av APIet vil oppleve feil når de mottar responser med nye enum-typer. Ved ukjent signatarstatus skal klienten forholde seg til overordnet signaturstatus, som beskrevet under. Denne endringen påvirker bare integrasjoner som oppretter portaloppdrag.
• Enklere status på oppdrag: Overordnet status på et signeringsoppdrag kan hentes ut i status-feltet på portal-signature-job-status-change-response. Mulig status er IN_PROGRESS, COMPLETED_SUCCESSFULLY eller FAILED. FAILED er en ny enum-status som ikke eksisterte i forrige versjon av APIet.