Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • fit-connect/docs
1 result
Show changes
Commits on Source (28)
Showing
with 266 additions and 50 deletions
......@@ -24,3 +24,6 @@ build/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
scripts/faq.md
scripts/faq.json
......@@ -25,7 +25,7 @@ build:
- apk add git
- yarn
script:
- export DOCUSAURUS_BASE_URL="/fit-connect/" && [[ "$CI_COMMIT_REF_NAME" != "main" ]] && export DOCUSAURUS_BASE_URL="/preview/fit-connect/$CI_COMMIT_REF_SLUG/"
- export DOCUSAURUS_BASE_URL="/fit-connect/" && [[ "$CI_COMMIT_REF_NAME" != "main" ]] && export DOCUSAURUS_BASE_URL="/fit-connect/$CI_COMMIT_REF_SLUG/"
- yarn build
artifacts:
expose_as: 'Built Documentation'
......@@ -35,14 +35,14 @@ build:
rules:
- when: always
upload:review:
upload:preview:
stage: upload
image: alpine:latest
environment:
name: review/$CI_COMMIT_REF_NAME
on_stop: stop:review
name: preview/$CI_COMMIT_REF_NAME
on_stop: stop:preview
auto_stop_in: 2 week
url: https://docs.fitko.de/preview/fit-connect/$CI_COMMIT_REF_SLUG/
url: https://preview.docs.fitko.dev/fit-connect/$CI_COMMIT_REF_SLUG/
needs:
- build
rules:
......@@ -50,7 +50,8 @@ upload:review:
before_script:
- *pre-deploy-uber-space-setup
script:
- rsync -rLvz --delete --checksum -e "ssh -o CheckHostIP=no" --ipv4 --progress ./build/. fitko@dorado.uberspace.de:html/preview/fit-connect/$CI_COMMIT_REF_SLUG
- ssh -o CheckHostIP=no fitko@dorado.uberspace.de mkdir -p preview.docs.fitko.dev/fit-connect
- rsync -rLvz --delete --checksum -e "ssh -o CheckHostIP=no" --ipv4 --progress ./build/. fitko@dorado.uberspace.de:preview.docs.fitko.dev/fit-connect/$CI_COMMIT_REF_SLUG
upload:production:
stage: upload
......@@ -65,20 +66,21 @@ upload:production:
before_script:
- *pre-deploy-uber-space-setup
script:
- rsync -rLvz --delete --checksum -e "ssh -o CheckHostIP=no" --ipv4 --progress ./build/. fitko@dorado.uberspace.de:html/fit-connect
- ssh -o CheckHostIP=no fitko@dorado.uberspace.de mkdir -p projects/fit-connect
- rsync -rLvz --delete --checksum -e "ssh -o CheckHostIP=no" --ipv4 --progress ./build/. fitko@dorado.uberspace.de:projects/fit-connect
stop:review:
stop:preview:
stage: .post
image: alpine:latest
environment:
name: review/$CI_COMMIT_REF_NAME
name: preview/$CI_COMMIT_REF_NAME
action: stop
needs:
- upload:review
- upload:preview
rules:
- if: $CI_MERGE_REQUEST_ID
when: manual
before_script:
- *pre-deploy-uber-space-setup
script:
- ssh fitko@dorado.uberspace.de "rm -rf html/preview/fit-connect/$CI_COMMIT_REF_SLUG"
- ssh fitko@dorado.uberspace.de "rm -rf preview.docs.fitko.dev/fit-connect/$CI_COMMIT_REF_SLUG"
......@@ -4,11 +4,17 @@ Die Dokumentation ist hier zu finden: https://docs.fitko.de/fit-connect/
## Lokale Entwicklung
### Serves the last build statically made
```shell
$ yarn
$ yarn start
```
### Serves the current active dev environment
```shell
$ yarn
$ yarn serve
```
## Bauen für Produktion
```shell
......
......@@ -2,7 +2,27 @@
Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.com/de).
Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Connect](https://docs.fitko.de/fit-connect/docs/getting-started/first-steps#test-infrastruktur).
Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Connect](https://docs.fitko.de/fit-connect/docs/getting-started/first-steps#testing).
## 2022-04-27
### Dokumentation
- [Beschreibung der Betriebsumgebungen](getting-started/first-steps.mdx#environments) ergänzt
## 2022-05-03
### Dokumentation
- Dokumentation zu [Benachrichtigungen und Löschfristen](getting-started/notifications-and-deletion-deadlines.mdx) ergänzt.
### Zustelldienst 1.5.12
- Automatisches Abweisen von Einreichungen, wenn diese mehr als 14 Tage im Status 'submitted' bleiben.
([Story](https://git.fitko.de/fit-connect/planning/-/issues/283))
- Automatisches Löschen von Einreichungen im Zustand 'incomplete' (nach 1 Tag), 'accepted' und 'rejected' (nach 7 Tagen).
Gelöscht werden dabei Metainformationen und Anhänge der Einreichungen; ein entsprechender Eintrag wird im Ereignisprotokoll erzeugt.
([Story](https://git.fitko.de/fit-connect/planning/-/issues/91))
## 2022-04-21
### Zustelldienst 1.5.11
- Löschen der Zustellpunkte im DVDV wenn diese im Zustelldienst gelöscht werden.
([Story](https://git.fitko.de/fit-connect/planning/-/issues/369))
## 2022-04-14
### Zustelldienst 1.5.10
......@@ -25,6 +45,10 @@ Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Co
([Bug](https://git.fitko.de/fit-connect/planning/-/issues/306))
- Fix: An den DVDV wurden falsch formatierte Werte für `alg` und `keyOp` übergeben ([Commit](https://git.fitko.de/fit-connect/zustelldienst/-/commit/ad3621d5addfddb3b11a2c100cb27fec279ee1fd), [Commit](https://git.fitko.de/fit-connect/zustelldienst/-/commit/b3d5df127a8f08ef8ebdf9cf5688c3d1b75a736b))
## 2022-04-01
### Dokumentation
- Dokumentation zur Sicherstellung der Integrität des Gesamtantrags für [sendende](sending/metadata.mdx#integrity) und [empfangende Systeme](receiving/verification.mdx#integrity).
## 2022-03-28
### Zustelldienst 1.5.6
- Signed Event Tokens werden jetzt auch korrekt angenommen, wenn der "issued at" (iat) Claim 5 Minuten in der Zukunft
......
This diff is collapsed.
......@@ -12,7 +12,7 @@ Als Voraussetzungen hierfür ist es notwendig, Accounts für [API-Clients im Sel
## Abruf von Access Tokens beim OAuth-Dienst
:::note Hinweis
Die URL der Submission API und die OAuth-Token-URL finden sich im Artikel [Erste Schritte](first-steps.mdx#test-infrastruktur).
Die URL der Submission API und die OAuth-Token-URL finden sich im Artikel [Erste Schritte](first-steps.mdx#testing).
:::
Fast alle Anfragen an die FIT-Connect Submission API müssen authentifiziert werden.
......@@ -121,5 +121,5 @@ Authorization: Bearer ey...
```
:::note Hinweis
Die URL der Submission API findet sich im Artikel [Erste Schritte](first-steps.mdx#test-infrastruktur).
Die URL der Submission API findet sich im Artikel [Erste Schritte](first-steps.mdx#testing).
:::
......@@ -13,15 +13,15 @@ Das Akzeptieren oder Zurückweisen von Einreichungen auf einer rein technischen
Gründe für technische Rückweisungen wären beispielsweise Probleme bei der Entschlüsselung oder Validierungsfehler der Datenstrukturen.
In der folgenden Tabelle sind die möglichen Ereignisse, ihre Beschreibungen und die Autoren aufgeführt und beschrieben.
| Event | Autor | Bedeutung |
|------------------------------------------------------------------------------------------|---------------------|-------------------------------|
| `https://schema.fitko.de/fit-connect/events/create-submission` [↓](#create-submission) | Zustelldienst | Die Einreichung wurde durch den Sender angelegt. |
| `https://schema.fitko.de/fit-connect/events/submit-submission` [↓](#submit-submission) | Zustelldienst | Die Einreichung wurde durch den Sender abgesendet. |
| `https://schema.fitko.de/fit-connect/events/notify-submission` [↓](#notify-submission) | Zustelldienst | Der Empfänger wurde per Webhook über die Einreichung informiert. |
| `https://schema.fitko.de/fit-connect/events/forward-submission` [↓](#forward-submission) | Empfangendes System | Ein nachgelagertes System hat die Einreichung zur Weiterleitung übernommen. |
| `https://schema.fitko.de/fit-connect/events/reject-submission` [↓](#reject-submission) | Empfangendes System | Die Einreichung wurde durch den Empfänger zurückgewiesen. |
| `https://schema.fitko.de/fit-connect/events/accept-submission` [↓](#accept-submission) | Empfangendes System | Die Einreichung wurde durch den Empfänger akzeptiert. |
| `https://schema.fitko.de/fit-connect/events/delete-submission` [↓](#delete-submission) | Zustelldienst | Die Einreichung wurde durch den Zustelldienst gelöscht. |
| Event | Autor | Bedeutung |
|------------------------------------------------------------------------------------------|-----------------------------------|-------------------------------|
| `https://schema.fitko.de/fit-connect/events/create-submission` [↓](#create-submission) | Zustelldienst | Die Einreichung wurde durch den Sender angelegt. |
| `https://schema.fitko.de/fit-connect/events/submit-submission` [↓](#submit-submission) | Zustelldienst | Die Einreichung wurde durch den Sender abgesendet. |
| `https://schema.fitko.de/fit-connect/events/notify-submission` [↓](#notify-submission) | Zustelldienst | Der Empfänger wurde per Webhook über die Einreichung informiert. |
| `https://schema.fitko.de/fit-connect/events/forward-submission` [↓](#forward-submission) | Empfangendes System | Ein nachgelagertes System hat die Einreichung zur Weiterleitung übernommen. |
| `https://schema.fitko.de/fit-connect/events/reject-submission` [↓](#reject-submission) | Empfangendes System/Zustelldienst | Die Einreichung wurde durch den Empfänger zurückgewiesen *oder* die Einreichung war mehr als 14 Tage im Status `submitted` und wurde deshalb vom Zustelldienst zurückgewiesen. |
| `https://schema.fitko.de/fit-connect/events/accept-submission` [↓](#accept-submission) | Empfangendes System | Die Einreichung wurde durch den Empfänger akzeptiert. |
| `https://schema.fitko.de/fit-connect/events/delete-submission` [↓](#delete-submission) | Zustelldienst | Die Einreichung wurde [durch den Zustelldienst gelöscht](../notifications-and-deletion-deadlines.mdx). |
## create-submission {#create-submission}
......@@ -144,6 +144,9 @@ dass es die Einreichung zur Weiterleitung übernommen hat.
Mit dem Event `https://schema.fitko.de/fit-connect/events/reject-submission` dokumentiert das empfangende System,
dass die Einreichung zurückgewiesen wird.
Alternativ kann auch der Zustelldienst Einreichungen als `reject` markieren, wenn diese mehr als 14 Tage im Status `submitted` verbleiben.
Unter [Benachrichtigungen und Löschfristen](../notifications-and-deletion-deadlines.mdx) finden sich hierzu genaue Angaben.
Das Event enthält ein Array `problems`, dass die Fehler der Einreichung dokumentiert.
Der Aufbau ist an [RFC 7807](https://datatracker.ietf.org/doc/html/rfc7807) angelehnt,
lässt jedoch den Status aus, weil hier kein passender HTTP Status Code angegeben werden kann.
......@@ -177,6 +180,7 @@ lässt jedoch den Status aus, weil hier kein passender HTTP Status Code angegebe
}
```
## accept-submission {#accept-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/accept-submission` dokumentiert das empfangende System,
......@@ -247,8 +251,8 @@ werden diese analog zu der `problems` Liste in [`reject-submission`](#reject-sub
## delete-submission {#delete-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/delete-submission` dokumentiert der Zustelldienst,
dass die Einreichung gelöscht wurde.
Mit dem Event `https://schema.fitko.de/fit-connect/events/delete-submission` dokumentiert der Zustelldienst, dass die Einreichung gelöscht wurde.
Die Fristen, wann eine Einreichungen mit welchem Status gelöscht wird, finden sich unter [Benachrichtigungen und Löschfristen](../notifications-and-deletion-deadlines.mdx).
```json
{
......
......@@ -13,15 +13,28 @@ Kern von FIT-Connect ist der Zustelldienst, der sendende und empfangende Systeme
Jedes empfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Zustellpunkte (Destinations), an die Einreichungen (Anträge oder Berichte) gesendet werden.
Zustellpunkte können von empfangenden Systemen [über das Self-Service-Portal](./account.mdx) konfiguriert und von sendenden Systemen adressiert werden.
## Test-Infrastruktur
:::tip Hinweis
Auf den folgenden Seiten stellen wir Code-Beispiele für die Anbindung von IT-Systemen an FIT-Connect zur Verfügung. Die Code-Beispiele veranschaulichen und vereinfachen die konkrete Implementierung der Nutzung der Programmierschnittstellen (APIs) von FIT-Connect. Diese Schnittstellen basieren auf gängigen offenen Standards und ermöglichen auch über die bereitgestellten Code-Beispiel hinaus eine Anbindung an FIT-Connect mit allen gängigen Programmiersprachen.
:::
## Betriebsumgebungen der FIT-Connect-Infrastruktur {#environments}
### Übersicht
Für FIT-Connect stehen derzeit mehrere Betriebsumgebungen bereit, die jeweils einen etwas anderen Zweck erfüllen.
Umgebungen, die von der FITKO zu Test- und Entwicklungszwecken bereitgestellt werden, stehen unter einer Subdomain unterhalb von `fitko.dev` zur Verfügung.
Produktive und produktivnahe Umgebungen stehen unter einer Subdomain unterhalb von `fitko.net` (bzw. unterhalb von `niedersachsen.de` für die bei IT.Niedersachsen betriebenen Infrastrukturen) zur Verfügung.
| Umgebung | Zweck und Zielgruppe |
| ---------------------------------- | -------------------- |
| Testumgebung (`testing`) | **Zweck**: Die Testumgebung dient vorrangig Anbindungstests und der Erprobung neuer Features.<br/>**Zielgruppe**: Die Testumgebung steht allen Interessierten zur freien Nutzung zur Verfügung, darf nicht für produktive Zwecke genutzt werden und unterliegt keinerlei Verfügbarkeitsgarantien.<br/>**Besonderheiten**: In der Testumgebung können selbst-generierte Test-Zertifikate anstelle von Zertifikaten aus einer PKI-Infrastruktur genutzt werden. |
| Staging-/Referenzumgebung (`refz`) | **Zweck**: Die Stagingumgebung, auch Referenzumgebung genannt, ist identisch zur Produktivumgebung konfiguriert und dient dem Test von Updates der an FIT-Connect angebundenen Systeme, bevor diese an die Produktivumgebung angebunden werden. Zudem dient die Stagingumgebung der Gewährleistung einer reibungslosen Funktionalität von Updates der FIT-Connect-Infrastruktur selbst, bevor diese auf der Produktivumgebung ausgerollt werden.<br/>**Zielgruppe**: Die Stagingumgebung steht ausschließlich Systemen zur Verfügung, die ebenfalls zum Zugriff auf die Produktivumgebung berechtigt sind.<br/>**Besonderheiten**: Die Nutzung der Stagingumgebung setzt den Einsatz von Zertifikaten aus der Verwaltungs-PKI voraus. |
| Produktivumgebung (`prod`) | **Zweck**: Die Produktivumgebung dient der produktiven Nutzung der FIT-Connect-Infrastruktur.<br/>**Zielgruppe**: Die Nutzung der Produktivumgebung ist Betreiber:innen vorbehalten, die entsprechende Nutzungsbedingungen unterzeichnet und einen Auftragsdatenverarbeitungsvertrag mit der FITKO abgeschlossen haben.<br/>**Besonderheiten**: Die Nutzung der Produktivumgebung setzt den Einsatz von Zertifikaten aus der Verwaltungs-PKI voraus. |
Für Anbindungstests in der Testumgebung können Sie die folgenden Links & Infos verwenden:
### Testumgebung {#testing}
Für Anbindungstests in der Testumgebung können Sie die folgenden Endpunkte & Infos verwenden:
- Self-Service-Portal der Testumgebung: siehe [Accountregistrierung und Client-Verwaltung](./account.mdx)
- [OAuth Token URL](./authentication.mdx): `https://auth-testing.fit-connect.fitko.dev/token`
- [Submission API](../apis/submission-api.mdx): `https://submission-api-testing.fit-connect.fitko.dev`
- [Routing API](../apis/routing-api.mdx): `https://routing-api-testing.fit-connect.fitko.dev`
:::tip Hinweis
Auf den folgenden Seiten stellen wir Code-Beispiele für die Anbindung von IT-Systemen an FIT-Connect zur Verfügung. Die Code-Beispiele veranschaulichen und vereinfachen die konkrete Implementierung der Nutzung der Programmierschnittstellen (APIs) von FIT-Connect. Diese Schnittstellen basieren auf gängigen offenen Standards und ermöglichen auch über die bereitgestellten Code-Beispiel hinaus eine Anbindung an FIT-Connect mit allen gängigen Programmiersprachen.
:::
# Benachrichtigungen und Löschfristen
### Löschung nach erfolgreicher Abholung
Bei erfolgreicher Abholung einer Einreichung durch ein empfangendes System (Fachverfahren) wird dieser zustelldienstseitig nach 7 Tage gelöscht.
### Löschung unvollständiger Einreichungen
Unvollständige Einreichungen, die durch das sendende System (Onlinedienst) nicht abgeschlosen wurden und dem empfangenden System noch nicht bekannt sind, werden nach 1 Tag gelöscht.
### Löschung bei nicht erfolgter Abholung
Bei nicht erfolgter Abholung einer Einreichung durch ein empfangendes System (Fachverfahren) erfolgt eine Benachrichtigung des technischen Kontakts auf Empfängerseite 3 Tage nach Eingang der Einreichung.
14 Tage nach Eingang einer neuen Einreichung in der FIT-Connect-Infrastruktur erfolgt eine Markierung der Einreichung als nicht-zustellbar ("reject"-Event). Ab diesem Zeitpunkt können Einreichungen nicht mehr abgerufen werden. Nach weiteren 7 Tagen, die zu Debugging-Zwecken benötigt werden, erfolgt anschließend eine Löschung der übermittelten Einreichung.
| Zeitpunkt | Aktion |
| --------- | ------ |
| Tag 3 nach Eingang | Mail an Betreiber des empfangenden Systems |
| Tag 14 nach Eingang | Reject-Event |
| Tag 21 nach Eingang | Löschung der Einreichung |
......@@ -20,7 +20,7 @@ Wird eine Anfrage-Begrenzung überschritten, wird diese mit dem HTTP-Status-Code
## Beispiel
Beispiel für die in der HTTP-Response enthaltenen HTTP-Header:
```yaml
```yml
RateLimit-Limit: 20 # Begrenzung auf 20 Anfragen im aktuellen Zeitfenster
RateLimit-Remaining: 3 # Es sind noch 3 Anfragen im aktuellen Zeitfenster möglich
RateLimit-Reset: 14 # In 14 Sekunden wird das aktuelle Zeitfenster ablaufen und ein neues beginnen.
......
......@@ -8,7 +8,7 @@ import ApiLink from '@site/src/components/ApiLink'
Der Abruf einer Einreichung ist über den Endpunkt <ApiLink api="submission-api" to="/v1/submissions/{submissionId}" /> möglich. Liegen zur Einreichung neben den verschlüsselten Metadaten (`encryptedMetadata`) und Fachdaten (`encryptedData`) zusätzlich weitere Anlagen vor, so sind die IDs der Anlagen im Feld `attachments` zu finden. Anlagen müssen separat heruntergeladen werden (siehe nächster Abschnitt). Einreichungen und deren Anlagen können dabei nur im Status Submitted oder Forwarded abgerufen werden.
:::note Hinweis
Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-started/first-steps.mdx#test-infrastruktur).
Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-started/first-steps.mdx#testing).
:::
```bash title="Abfrage der Einreichung inkl. Fachdaten und Metadaten"
......
......@@ -66,3 +66,6 @@ $ curl \
]
}
```
## E-Mail
Bei nicht erfolgter Abholung einer Einreichung durch ein empfangendes System (Fachverfahren) erfolgt eine Benachrichtigung des technischen Kontakts [auf Empfängerseite 3 Tage nach Eingang der Einreichung](../getting-started/notifications-and-deletion-deadlines.mdx).
......@@ -7,6 +7,9 @@ import Mermaid from '@site/src/components/Mermaid'
Für den Empfang von Einreichungen und die Verarbeitung dieser werden in diesem und den folgenden Abschnitten alle notwendigen Aktionen beschrieben, um schnell die ersten Schritte machen zu können.
Als Leitlinie dafür ist der unten dargestellte Prozessablauf heranzuziehen, dessen Schritte im Folgenden beschrieben werden.
Bei nicht erfolgter Abholung einer Einreichung durch ein empfangendes System (Fachverfahren) erfolgt eine Benachrichtigung des technischen Kontakts auf Empfängerseite 3 Tage nach Eingang der Einreichung.
Sollte sich eine Einreichung mehr als 14 Tage im Status `submitted` befinden, wird [diese automatisch vom Server abgewiesen](../getting-started/notifications-and-deletion-deadlines.mdx) und in den Status `rejected` überführt.
<Mermaid>
sequenceDiagram
participant C as Client;
......
......@@ -57,7 +57,7 @@ Sofern Sie den Fehler "'iat' must not be after ..." (`https://schema.fitko.de/fi
Die Payload- und Header-Attribute des SET müssen wie oben beschrieben definiert werden (siehe markierte Zeilen). Mehr Informationen zu dem SET Aufbau finden Sie unter [SET Erzeugen](../getting-started/event-log/set-creation.mdx)
Im dritten markierten Block wird das SET mit dem Schlüssel signiert. Anschließend kann der serialisierte Wert an den Endpunkt <ApiLink api="submission-api" to="/v1/cases/{caseId}/events" withMethod="post" /> gesendet werden.
```java {3-10,12-16,22-24}
```java
try {
JWSSigner signer = new RSASSASigner(signaturePrivateKey.toRSAKey());
JWTClaimsSet claimsSet = new JWTClaimsSet.Builder()
......
......@@ -15,7 +15,7 @@ Die über das Self-Service-Portal erstellten Zustellpunkte sind in der Testumgeb
Dieses Feature ist als zukünftige Erweiterung geplant.
Sofern eine Destination-ID bereits bekannt ist, können die in einem Zustellpunkt hinterlegten technischen Parameter übergangsweise auch über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}" /> der Submission API des zuständigen Zustelldienstes [abgerufen werden (siehe unten)](#submissionapi).
Die [Konfiguration des Antragsroutings](routing.mdx) in der produktiven Umgebung ist bereits jetzt möglich. Entsprechend konfigurierte Zustellpunkte sind in der Produktivumgebung bereits über Routing API abrufbar.
Die [Konfiguration des Antragsroutings](routing.mdx) in der produktiven Umgebung ist bereits jetzt möglich. Entsprechend konfigurierte Zustellpunkte sind in der Produktivumgebung bereits über Routing API abrufbar.
:::
Die Ermittlung der `destinationId` und die Ermittlung der technischen Parameter über die Routing-API erfolgt über einen GET-Request auf den Endpunkt <ApiLink api="routing-api" to="/routes" /> des FIT-Connect Routingdienstes.
......@@ -370,7 +370,7 @@ Dabei ist für das JSON des Payload zu beachten, dass
#### Prüfung der vollständigen Signatur
Um die Signatur zu überprüfen, ist es notwendig auf die verwendeten Schlüssel (im Format JSON Web Key, kurz JWK) zugreifen zu können.
Um die Signatur zu überprüfen, ist es notwendig auf die verwendeten Schlüssel (im Format JSON Web Key, kurz JWK) zugreifen zu können.
Der Zustelldienst stellt ein JSON Web Key Set (JWKS) öffentlich zugänglich über den Endpunkt <ApiLink api="submission-api" to="/.well-known/jwks.json" /> bereit.
Da der Zustelldienst mit mehreren Instanzen betrieben werden kann, kann es auch mehrere Endpunkte zum JWKS geben.
Diese Endpunkte können dynamisch aus dem Payload (`Zustellpunkt`) erzeugt werden.
......@@ -399,7 +399,7 @@ private final static String DVDV_SUBMISSIONURL_KEY = "submissionUrl";
private final static String KEYSTORE_URL_ENDING = ".well-known/jwks.json";
private final static String[] VALID_KEYSTORE_URLS = new String[]{ "https://submission-api-testing.fit-connect.fitko.dev/v1/.well-known/jwks.json"};
protected void validateBySignedJWT(SignedJWT signedJWT) throws BadJOSEException, JOSEException, IOException, ParseException
protected void validateBySignedJWT(SignedJWT signedJWT) throws BadJOSEException, JOSEException, IOException, ParseException
{
//1. Prüfung auf erlaubten Algorithmus PS512
if ( !JWSAlgorithm.PS512.equals(signedJWT.getHeader().getAlgorithm()) )
......@@ -414,7 +414,7 @@ protected void validateBySignedJWT(SignedJWT signedJWT) throws BadJOSEException,
Optional<URL> keyStoreUrl = getKeyStoreUrl(getBaseKeyStoreUrl(signedJWT));
if ( keyStoreUrl.isEmpty() )
throw new RuntimeException("No JWKSetUrl found in Payload!");
validateKeyStoreUrl(keyStoreUrl.get());
//KeyStore laden
......@@ -440,14 +440,14 @@ protected void validateBySignedJWT(SignedJWT signedJWT) throws BadJOSEException,
}
```
```java
protected String getBaseKeyStoreUrl(SignedJWT signedJWT)
protected String getBaseKeyStoreUrl(SignedJWT signedJWT)
{
Map<String, Object> payload = signedJWT.getPayload().toJSONObject();
return String.valueOf(payload.get(DVDV_SUBMISSIONURL_KEY));
}
```
```java
protected Optional<URL> getKeyStoreUrl(String baseKeyStoreUrl)
protected Optional<URL> getKeyStoreUrl(String baseKeyStoreUrl)
{
if (baseKeyStoreUrl==null)
throw new RuntimeException("KeyStoreUrl not set!");
......@@ -455,18 +455,18 @@ protected void validateBySignedJWT(SignedJWT signedJWT) throws BadJOSEException,
baseKeyStoreUrl+="/";
baseKeyStoreUrl+= KEYSTORE_URL_ENDING;
try
try
{
return Optional.of(new URL(baseKeyStoreUrl));
}
catch (MalformedURLException e)
}
catch (MalformedURLException e)
{
throw new RuntimeException("KeyStoreUrl not valid! MalformedURLException for url " + baseKeyStoreUrl);
throw new RuntimeException("KeyStoreUrl not valid! MalformedURLException for url " + baseKeyStoreUrl);
}
}
```
```java
public void validateKeyStoreUrl(URL url)
public void validateKeyStoreUrl(URL url)
{
if ( !VALID_KEYSTORE_URLS.contains(String.valueOf(url)) )
throw new RuntimeException("KeyStoreUrl not valid!");
......@@ -561,7 +561,7 @@ Beispiel für die Response
Zum Abruf der Zustellpunkt-Informationen stellt die Submission API einen Endpunkt bereit, der über Angabe des Parameters `destinationId` die technischen Parameter der Einreichung für den jeweiligen Zustellpunkt ausgibt. Diese kann genutzt werden, wenn die `destinationId` bereits bekannt ist. Die angebotenen Informationen über eine Destination unterscheiden sich fachlich nicht von den Information aus der Routing API. Bei der Submission API muss lediglich der Verschlüsselungsschlüssel über einen zusätzlichen Endpunkt abgerufen werden, anstatt diesen zusammen mit den anderen Informationen in einer Response zu erhalten (siehe Artikel [Verschlüsseln](../sending/encrypt.mdx)).
:::note Hinweis
Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-started/first-steps.mdx#test-infrastruktur).
Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-started/first-steps.mdx#testing).
:::
<Tabs
......
......@@ -13,6 +13,8 @@ Vor dem Hochladen von Anlagen müssen diese durch den Sender [verschlüsselt wer
Eine bereits verschlüsselte Datei kann über den Endpunkt <ApiLink api="submission-api" to="/v1/submissions/{submissionId}/attachments/{attachmentId}" withMethod="put" /> hochgeladen werden:
Unvollständige Einreichungen, die durch das sendende System (Onlinedienst) nicht abgeschlosen wurden und dem empfangenden System noch nicht bekannt sind, [werden nach 1 Tag gelöscht](../getting-started/notifications-and-deletion-deadlines.mdx).
<Tabs
defaultValue="curl"
values={[
......
......@@ -95,7 +95,7 @@ Mit dem zuvor eingelesenen Schlüssel können nun Zeichenketten und Binärdaten
Für die verschlüsselung von Zeichenketten (z.B. serialisierte JSON- oder XML-Objekte) kann die in Browser verfügbare [TextEncoder-API](https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder) verwendet werden, die den String UTF8-kodiert in ein `Uint8Array` umwandelt.
```javascript
```js
const data = {
config: 'option1',
age: 42
......@@ -110,7 +110,7 @@ const encryptedText = await new CompactEncrypt(encodedText)
Anhänge wie PDF-Dateien, Bilder o. ä. liegen meist in einem `Uint8Array` vor bzw. können einfach darin umgewandelt werden.
Im Folgenden Beispiel wird eine Datei aus einem HTML-File-Input direkt heraus verschlüsselt.
```javascript
```js
// .arrayBuffer() => https://developer.mozilla.org/en-US/docs/Web/API/Blob/arrayBuffer
// Verschlüsselung der ersten Datei aus einem Datei-Input: <input type="file" id="my-file-input" />
const buffer = await document.getElementById("my-file-input").files[0].arrayBuffer()
......
......@@ -16,6 +16,8 @@ Das dafür benötigte Schlüsselmaterial wird als Teil der technischen Informati
Während der Einreichung erhält man von der API eine `caseId`, mithilfe welcher man nach der Abgabe den Event Log der Einreichung abrufen kann.
Dieser Event Log enthält eine Liste von Ereignissen, ähnlich wie im Interface einer Paketverfolgung, mit denen der aktuelle Zustellungsstatus der Einreichung sowie aller zukünftig zu diesem Case hinzugehörigen Einreichungen transparent wird.
Einreichungen unterliegen diversen automatischen Löschfristen, nach welchen diese vom Server bereinigt werden. Genaue Fristen und Bedingungen finden sich in [Benachrichtigungen und Löschfristen](../getting-started/notifications-and-deletion-deadlines.mdx).
## Prozessablauf
<Mermaid>
......
......@@ -17,7 +17,7 @@ Die für das Anlegen von Einreichungen notwendige Struktur von Einreichungen und
:::
:::note Hinweis
Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-started/first-steps.mdx#test-infrastruktur).
Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-started/first-steps.mdx#testing).
:::
......@@ -91,7 +91,7 @@ axios.post(
</TabItem>
<TabItem value="csharp">
```chsarp
```csharp
TBD
```
......
......@@ -14,6 +14,9 @@ Diese PUT Methode kann nur folgreich durchgeführt werden, wenn folgende Bedingu
- Sowohl der Metadatensatz als auch der Fachdatensatz müssen verschlüsselt im JWE-Format vorliegen.
Wenn die Nutzung dieses Endpunkts erfolgreich war, wechselt die Einreichung in den Status `submitted` und die vollständige Einreichung (Anlagen, Metadatensatz und Fachdatz) liegt nun für das empfangende System zum Abruf bereit.
Bei nicht erfolgter Abholung einer Einreichung durch ein empfangendes System (Fachverfahren) erfolgt eine Benachrichtigung des technischen Kontakts auf Empfängerseite 3 Tage nach Eingang der Einreichung.
Sollte sich eine Einreichung mehr als 14 Tage im Status `submitted` befinden, wird [diese automatisch vom Server abgewiesen](../getting-started/notifications-and-deletion-deadlines.mdx) und in den Status `rejected` überführt.
Ein Beispiel für die Nutzung des Endpunkt ist im Folgenden Ausschnitt dargestellt:
......