Bedre dokumentasjon kreves ved direkt bruk av HTTP (verken Java eller C#)

[boguszjelinski]

Jeg refererer til https://signering-docs.readthedocs.io/en/latest/client-integration/direct-flow.html og "/direct/signature-jobs" på den sida. jeg har mistet en uke med ping-pong med brannmur gutter og masse tid med tester og feil for å oppdage at det er egentlig api//direct/signature-jobs (stemmer?) kanskje der er dokumentert en annet sted, men vær så snill korriger den beskrivelsen. Bra at det blir et CURL eksempel der, takk! Meget bra ville det være å gi et eksempel hvordan å generere dokumentpakka med ekstern signering - digidoc4j ? Årsaken jeg ikke bruker API er signering med HSM - og det blir flere og flere firmaer hvor applikasjoner ikke får virksomhetssertifikater utlevert av sine sikkerhets avdelinger ;) På forkant takk!

[boguszjelinski]

tag er blitt skjult - jeg mente api/orgnr/direct/signature-jobs

[boguszjelinski]

et eksempel med et bibliotek og ekstern signering er viktig fordi ZIPen jeg fikk fra digidoc4j (ETSI TS 102 918 "compliant") hadde manifest i META-INF, noe som Difi klager på - "ASICE_VALIDATION_FAILED: Error when valicating ASiCE: manifest.xml was not found"

[asjafjell]

Heisann!

Det er en glipp at vi ikke har skrevet hele URL i eksemplet der. Det er nå fikset.

Grunnen til at vi har klientbiblioteker er at kryptering og signering er vanskelig. Hvis man ønsker å gjøre noe annerledes enn det de aller fleste gjør, så må man bare prøve og feile litt på egenhånd. Vi kan dessverre ikke bruke tid på å lage eksempler som gjør omtrent det samme som klientbiblioteket i et annet rammeverk. Det dere prøver å gjøre er det sikkert noen andre som gjør, men ikke så mange at det er noe vi støtter ut av boksen.

Koden vår åpen kildekode, så det er ikke noe i veien for at du graver litt der for å se hvordan vi gjør det og gjør det samme. Hvis det viser seg at du kan gjenbruke det meste, så kan det hende vi kan eksponere ut funksjonaliteten som lager ASiCE og muliggjøre at vi tar inn ferdig kryptert pakke og sende den direkte.

Vi hadde litt kluss med generering av ASiCE med .NET Core og her var løsningen å bruke BouncyCastle og ikke innebygd .NET-funksjonalitet. Kanskje det samme er en løsning for deg?

[boguszjelinski]

Det skjønner jeg, takk for svaret. Jeg skal se på CreateSignature.createXmlSignature og om jeg klarer å endre på det med tjenester som min HSM leverer (nå har jeg stoppet med "ASICE_VALIDATION_FAILED: Error when valicating ASiCE: Parse error: Failed to parse XMLDirectSignatureJobManifest"). Kanskje noe som skal sjekkes likevel - om ETSI TS 102 918 krever å strukturere pakka med META-INF. Det har jeg sett i flere dokumenter.

[boguszjelinski]

status for i dag (etter feilanalyse) - manifest.xml skal ligge i root og signatures.xml i META-INF, ser så ut ...

[asjafjell]

Det stemmer. En liten glipp her fra vår side også. Dokumentasjonen er nå oppdatert til å reflektere dette. Takk!

[boguszjelinski]

De endringene i dokumentasjonen er den eneste suksessen min til i dag, det gleder meg veldig mye, takk :) BTW - når jeg sender manifest.xml funnet på Difi sider får jeg "ASICE_VALIDATION_FAILED: Error when valicating ASiCE: Parse error: Failed to parse XMLDirectSignatureJobManifest". når jeg sender manifest.xml hentet fra DifiAPI får jeg ikke den feilen: <?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns4:direct-signature-job-manifest xmlns="http://uri.etsi.org/01903/v1.3.2#" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://uri.etsi.org/2918/v1.2.1#" xmlns:ns4="http://signering.posten.no/schema/v1"><ns4:signer><ns4:personal-identification-number>1234...</ns4:personal-identification-number></ns4:signer><ns4:sender><ns4:organization-number>974761076</ns4:organization-number></ns4:sender><ns4:document href="minimal.pdf" mime="application/pdf"><ns4:title>Subject</ns4:title></ns4:document></ns4:direct-signature-job-manifest>

[boguszjelinski]

i dag lyktes jeg å gå gjennom hele flyten med HTML og curl (signatures.xml levert av HSM). Den saken kan lukkes. Når jeg ser på tegningen (char of flow) og det som tjenesten returner da tenker jeg at den tegningen kan forvirre noen som prøver å fordele signerings jobben mellom frontend og backend (React og Boot i mitt tilfelle). Takk for hjelpen :)

[asjafjell]

Supert å høre at du fikk fikset det! 🚀Hvis du kunne forklart hva som er forvirrende med den tegningen, så kan vi se om vi kan få justert litt. Vi har fått fikset noen småting i dokumentasjonen som du har kommentert underveis, og hvis du har andre tanker rundt dokumentasjonen som kunne vært bedre, så vil vi gjerne høre fra deg.

[boguszjelinski]

Beklager, jeg har ikke hatt tid til å svare tidligere. så til den tegningen på direct-flow.html. Det jeg mente er at det ikke er klar hvilken del av en hipotetisk app gjør hva, fokusert på arkitektur, hvilke data vi trenger når ("jobId/status url må persisteres for å fullføre signering", "nødvendi å ha en sessionId i exitUrls"), hva anbefales - skal exitUrl pekke på frontend eller backend? Jeg tenker nå på noe liknende, nemlig OpenId Connect, se her: https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660 . F.eks. nå har jeg frontend, backend, bruker/browser og Difis API og en sånn flyt: 1) frontend får redirectUrl fra backend, backend lagrer statusUrl hvor som helst 2) frontend sender brukeren til Difi side 3) Difis side kaller tilbake frontend (Url-er med sessionId i meta.xml) 3) frontend sender token og sessionId/skjemaId til backend (og det kan skje etter en time kanskje, fordi bruker ville kontakte advokaten sin, session i infrastrukturen kan utløpe), 4) backend henter jobId/statusUrl fra en "session" og kaller Difi API, henter pades/xades URL-er, henter dokumenter, lagrer dem, whatever, flyten slutter her. Det er noe som utviklere kan lure på som trenger mer forklaring. f.eks. i Java delen leser jeg "DirectJobStatusResponse [...] As returned when getting job status" men den koden blir kalt i request #2 (fullfør signering), når den objekten ikke lenger eksisterer. En bekymring til - noen arkitekter ville ha exitUrls som pekker på backend (jeg så en sånn løsning hos min arbeidsgiver!) men noen JS biblioteker oppfører seg ikke bra under redirect, jeg vil gjerne teste det og komme med et eksempel. Til å oppsummere - jeg vet ikke om det er mange i Norge som er interessert i den signerings tjenesten, men det ville være bra å gi dem en tekning til, kanskje :) Viktig - et bibliotek som støtter ekstern levering av signatures.xml er nødvending, virksomhets sertifikater skal beskytes bedre i Norge, applikasjoner/server adminstratører skal ikke få virksomhets sertifikater og passord til dem, takk !! :)