Skip to content
Snippets Groups Projects
Commit 7e7c5c6f authored by David Schwarzmann's avatar David Schwarzmann
Browse files

Adjust wording for Fachanwendung

parent f3b41543
No related branches found
No related tags found
1 merge request!43Introduce docusaurus
Hide whitespace changes
Inline Side-by-side
docs/details/authentication/applications.md
+ 10
− 10
View file @ 7e7c5c6f
# Authentifizierung von antragsempfangenden Systemen # Authentifizierung von empfangenden Systemen
Die Authentifizierung von antragsempfangenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Zum Abruf von Anträgen müssen sich antragsempfangende Systeme mit Hilfe von OAuth 2.0 Client-Credentials beim Authorisierungsdienst authentifizieren. Die hierfür nötigen Client erhalten Behörden und andere Abrufberechtigte, nach einer Anmeldung im Self-Service-Portal der FITKO. (TODO: link) Die Authentifizierung von empfangenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Zum Abruf von Anträgen müssen sich empfangende Systeme mit Hilfe von OAuth 2.0 Client-Credentials beim Authorisierungsdienst authentifizieren. Die hierfür nötigen Client erhalten Behörden und andere Abrufberechtigte, nach einer Anmeldung im Self-Service-Portal der FITKO. (TODO: link)
Zum Abruf von Anträgen müssen sich antragsempfangende Systeme zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server ein Berechtigungstoken (im Folgenden "Subscriber-Token") nach dem Standard JSON Web Token gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519) abrufen. Dieser vom OAuth-Server signierte Subscriber-Token kann anschließend genutzt werden, um sich gegenüber der Antrags-API eines Zustelldienstes zu authentifizieren. Zum Abruf von Anträgen müssen sich empfangende Systeme zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server ein Berechtigungstoken (im Folgenden "Subscriber-Token") nach dem Standard JSON Web Token gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519) abrufen. Dieser vom OAuth-Server signierte Subscriber-Token kann anschließend genutzt werden, um sich gegenüber der Antrags-API eines Zustelldienstes zu authentifizieren.
Für jede Destination müssen folgende Informationen im Self-Service-Portal bereitgestellt werden Für jede Destination müssen folgende Informationen im Self-Service-Portal bereitgestellt werden
...@@ -17,17 +17,17 @@ Oder: ...@@ -17,17 +17,17 @@ Oder:
Außerdem Außerdem
- Der Public Key zur Verschlüsselung der Antragsdaten - Der Public Key zur Verschlüsselung der Antragsdaten
- Der Public Key des antragsempfangenden Systems zur Signaturprüfung - Der Public Key des empfangenden Systems zur Signaturprüfung
- Callback-Endpunkte des antragsempfangenden Systems - Callback-Endpunkte des empfangenden Systems
- Referenzen zu allen von diesem Endpunkt unterstützen Schemas - Referenzen zu allen von diesem Endpunkt unterstützen Schemas
Bei erfolgreicher Registrierung erhält die für den Zustellpunkt verantwortliche Behörde OAuth2-Zugangsdaten für den Authentifizierungstyp "Client-Credentials" (`client_id` und `client_secret`). Mit diesen kann sich das antragsempfangende System beim Authentifizuerungsdienst authentifizieren und erhält einen Access Token im JSON Web Token-Format (JWT). Mit diesem Access Token ist anschließend ein Abruf der im Zustelldienst hinterlegten Anträge möglich. Bei erfolgreicher Registrierung erhält die für den Zustellpunkt verantwortliche Behörde OAuth2-Zugangsdaten für den Authentifizierungstyp "Client-Credentials" (`client_id` und `client_secret`). Mit diesen kann sich das empfangende System beim Authentifizuerungsdienst authentifizieren und erhält einen Access Token im JSON Web Token-Format (JWT). Mit diesem Access Token ist anschließend ein Abruf der im Zustelldienst hinterlegten Anträge möglich.
<img src="/images/oauth/JWT-Konzept-Fachanwendung.png" alt="JWT Konzept" width="400"/> <img src="/images/oauth/JWT-Konzept-Fachanwendung.png" alt="JWT Konzept" width="400"/>
## Zugriff auf die Antrags-API mittels Access Token ## Zugriff auf die Antrags-API mittels Access Token
Der Access Token für antragsempfangende Systeme muss beim Zugriff auf die Antrags-API via HTTP-Header an den Zustelldienst übermittelt werden. Der Access Token für empfangende Systeme muss beim Zugriff auf die Antrags-API via HTTP-Header an den Zustelldienst übermittelt werden.
**Beispiel** **Beispiel**
...@@ -37,7 +37,7 @@ Host: api.zustelldienst-01.example.com ...@@ -37,7 +37,7 @@ Host: api.zustelldienst-01.example.com
Token: XXX Token: XXX
``` ```
### Payload des Access Tokens für antragsempfangende Systeme ### Payload des Access Tokens für empfangende Systeme
Im Payload des signierten Access Token MÜSSEN mindestens die folgenden [standartisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein: Im Payload des signierten Access Token MÜSSEN mindestens die folgenden [standartisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein:
...@@ -46,11 +46,11 @@ Im Payload des signierten Access Token MÜSSEN mindestens die folgenden [standar ...@@ -46,11 +46,11 @@ Im Payload des signierten Access Token MÜSSEN mindestens die folgenden [standar
| `iat` | Unix Timestamp | Zeitpunkt, wann der Token vom Autorisierungsdienst ausgestellt wurde, als Unix Timestamp | | `iat` | Unix Timestamp | Zeitpunkt, wann der Token vom Autorisierungsdienst ausgestellt wurde, als Unix Timestamp |
| `exp` | Unix Timestamp | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 2 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) | | `exp` | Unix Timestamp | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 2 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
| `iss` (Issuer) | *URL des Authentifizierungsservers* | Die URL des Authentifizierungsservers, der das Token ausgestellt hat. | | `iss` (Issuer) | *URL des Authentifizierungsservers* | Die URL des Authentifizierungsservers, der das Token ausgestellt hat. |
| `sub` (Subject) | ID des antragsempfangenden Systems | Wird bei der Anmeldung des antragsempfangenden Systems durch den Authorisierungsdienst festgelegt und dient zur Identifizierung des antragsempfangenden Systems. | | `sub` (Subject) | ID des empfangenden Systems | Wird bei der Anmeldung des empfangenden Systems durch den Authorisierungsdienst festgelegt und dient zur Identifizierung des empfangenden Systems. |
| `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. | | `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. |
| `aud` (Audience) | *URL der Zustelldienst-API* | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). | | `aud` (Audience) | *URL der Zustelldienst-API* | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
| `scope` | *Liste von Zustellberechtigungs-Scopes* | Eine Liste der Zustellberechtigungs-Scopes, für die der Token einen Abruf von Anträgen erlaubt (Präfix `destination:subscribe`), separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) | | `scope` | *Liste von Zustellberechtigungs-Scopes* | Eine Liste der Zustellberechtigungs-Scopes, für die der Token einen Abruf von Anträgen erlaubt (Präfix `destination:subscribe`), separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) |
| `token_type` | `subscriber` | Gibt an, das es sich um einen Token für ein antragsempfangendes System handelt | | `token_type` | `subscriber` | Gibt an, das es sich um einen Token für ein empfangendes System handelt |
**Beispiel-Payload eines Access Tokens mit Token-Typ `subscriber`** **Beispiel-Payload eines Access Tokens mit Token-Typ `subscriber`**
......
docs/details/authentication/cli.md
+ 8
− 8
View file @ 7e7c5c6f
# Developer-CLI # Developer-CLI
Im Folgenden wird beschrieben, wie die OAuth-basierte Authentifizierung mithilfe des FIT-Connect Commandline-Tools funktioniert. Im Folgenden wird beschrieben, wie die OAuth-basierte Authentifizierung mithilfe des FIT-Connect Commandline-Tools funktioniert.
Dafür werden entweder OAuth-Credentials (Client-ID, Client-Secret) sowie die Adresse des OAuth-Token-Endpunktes oder ein Zugang zum FIT-Connect Developer Portal benötigt. Dafür werden entweder OAuth-Credentials (Client-ID, Client-Secret) sowie die Adresse des OAuth-Token-Endpunktes oder ein Zugang zum FIT-Connect Developer Portal benötigt.
Weitere Informationen dazu wie die OAuth-Authentifizierung selbst implementiert werden kann befinden sich in [Authentifizierung von Fachanwendungen](applications) und [Authentifizierung von Usern an Zustelldiensten](users) - außerdem ist hier das Konzept zu [Zustellberechtiungs-Scopes](scopes) zu beachten. Weitere Informationen dazu wie die OAuth-Authentifizierung selbst implementiert werden kann befinden sich in [Authentifizierung von Fachanwendungen](applications) und [Authentifizierung von Usern an Zustelldiensten](users) - außerdem ist hier das Konzept zu [Zustellberechtiungs-Scopes](scopes) zu beachten.
## Installation CLI-Tool ## Installation CLI-Tool
...@@ -15,13 +15,13 @@ pip install fitconnect-cli ...@@ -15,13 +15,13 @@ pip install fitconnect-cli
Nach der Installation von fitconnect-cli kann mithilfe des folgenden Kommandos eine neue FIT-Connect API-Konfiguration angelegt werden. Nach der Installation von fitconnect-cli kann mithilfe des folgenden Kommandos eine neue FIT-Connect API-Konfiguration angelegt werden.
```bash ```bash
fitconnect create_config --config=test_sender.json fitconnect create_config --config=test_sender.json
``` ```
Hierbei muss ausgewählt werden, ob ein Sende- oder Empfangsdienst betrieben werden und ob automatisch RSA-Keys für die Generierung von JWTs angelegt werden sollen. Hierbei muss ausgewählt werden, ob ein Sende- oder Empfangsdienst betrieben werden und ob automatisch RSA-Keys für die Generierung von JWTs angelegt werden sollen.
```bash ```bash
fitconnect create_config --config=test_sender.json fitconnect create_config --config=test_sender.json
? Do you want to setup a config for a sender (e.g. onlineservice) or receiver? sender ? Do you want to setup a config for a sender (e.g. onlineservice) or receiver? sender
? Oauth Token URL: https://fit-connect.de/oauth/token ? Oauth Token URL: https://fit-connect.de/oauth/token
? Client id: nnXVC6DSPG9BkoMw5NXOur4RPOkEpLMMwYFbycIo ? Client id: nnXVC6DSPG9BkoMw5NXOur4RPOkEpLMMwYFbycIo
...@@ -51,13 +51,13 @@ Mithilfe der fitconnect-cli können JWTs zum Abrufen von bzw. Versenden von Antr ...@@ -51,13 +51,13 @@ Mithilfe der fitconnect-cli können JWTs zum Abrufen von bzw. Versenden von Antr
### Abrufen von JWTs für antragssendene Systeme (Onlineservices) ### Abrufen von JWTs für antragssendene Systeme (Onlineservices)
Für die Generierung von JWTs zum Versenden von Anträgen muss neben der Konfiguration außerdem über den Parameter *destination* angegeben werden, an welche Destination-IDs Anträge gesendet werden sollen. Für die Generierung von JWTs zum Versenden von Anträgen muss neben der Konfiguration außerdem über den Parameter *destination* angegeben werden, an welche Destination-IDs Anträge gesendet werden sollen.
```bash ```bash
fitconnect get_jwt --config=test_sender.json --destination "d771f1d8-6967-4740-9668-82c5a910a29b" fitconnect get_jwt --config=test_sender.json --destination "d771f1d8-6967-4740-9668-82c5a910a29b"
``` ```
Bei erfolgreicher Generierung erhält man ein JSON-Objekt mit einem User-Token und einen Online-Service-Token zurück. Diese können dann dazu verwendet werden um mithilfe eines FIT-Connect-API-Client oder CURL einen Einreichung versenden. Bei erfolgreicher Generierung erhält man ein JSON-Objekt mit einem User-Token und einen Online-Service-Token zurück. Diese können dann dazu verwendet werden um mithilfe eines FIT-Connect-API-Client oder CURL einen Einreichung versenden.
```json ```json
{ {
...@@ -109,12 +109,12 @@ Ein CURL-Request um dann mit diesen Tokens auf die API zuzugreifen, könnte z.B. ...@@ -109,12 +109,12 @@ Ein CURL-Request um dann mit diesen Tokens auf die API zuzugreifen, könnte z.B.
curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "token: ...token..." -H "online-service-token: ...online-service-token..." https://fit-connect-url.einfügen curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "token: ...token..." -H "online-service-token: ...online-service-token..." https://fit-connect-url.einfügen
``` ```
### Abrufen von JWTs für antragsempfangende Systeme (Fachverfahren / virtuelle Poststellen) ### Abrufen von JWTs für empfangende Systeme (Fachverfahren / virtuelle Poststellen)
Wenn ein JWT zum Abrufen von Anträgen generiert werden soll, kann auf den Parameter destination verzichtet werden. Wenn ein JWT zum Abrufen von Anträgen generiert werden soll, kann auf den Parameter destination verzichtet werden.
```bash ```bash
fitconnect get_jwt --config=test_receiver.json fitconnect get_jwt --config=test_receiver.json
``` ```
Als Antwort erhält man einen (vom Authentifizierungsserver via OAuth Client Credentials abgerufenen) JWT, welchen man zur Authentifizierung beim Abrufen von Anträgen verwenden kann. Als Antwort erhält man einen (vom Authentifizierungsserver via OAuth Client Credentials abgerufenen) JWT, welchen man zur Authentifizierung beim Abrufen von Anträgen verwenden kann.
......
docs/details/encryption.mdx
+ 1
− 1
View file @ 7e7c5c6f
...@@ -44,7 +44,7 @@ Nicht vertrauenswürdige Schlüssel dürfen nicht für die Verschlüsselung von ...@@ -44,7 +44,7 @@ Nicht vertrauenswürdige Schlüssel dürfen nicht für die Verschlüsselung von
Kern von FIT-Connect ist der Zustelldienst, der über die beiden APIs "Application Sender API" und "Application Subscriber API" den Absender (Sender) und Empfänger (Subscriber) einer Einreichung verbindet. Kern von FIT-Connect ist der Zustelldienst, der über die beiden APIs "Application Sender API" und "Application Subscriber API" den Absender (Sender) und Empfänger (Subscriber) einer Einreichung verbindet.
Jedes antragsempfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Endpunkt, an den Anträge gesendet werden (Zustellpunkt) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …). Jedes empfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Endpunkt, an den Anträge gesendet werden (Zustellpunkt) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
Ein Einreichung wird an einen Zustellpunkt (Zielort) geschickt. Diesen Zustellpunkt legt der Empfänger über die "Application Subscriber API" an. Der Absender muss die Destination-ID des Zustellpunktes kennen und kann dann Anträge über die "Application Sender API" an diese Destination-ID senden. Ein Einreichung wird an einen Zustellpunkt (Zielort) geschickt. Diesen Zustellpunkt legt der Empfänger über die "Application Subscriber API" an. Der Absender muss die Destination-ID des Zustellpunktes kennen und kann dann Anträge über die "Application Sender API" an diese Destination-ID senden.
......
docs/getting-started/receiving/destination.mdx
+ 1
− 1
View file @ 7e7c5c6f
...@@ -12,7 +12,7 @@ welche eine eindeutige Zustelladresse in der Zustelldienstinstanz für diese Lei ...@@ -12,7 +12,7 @@ welche eine eindeutige Zustelladresse in der Zustelldienstinstanz für diese Lei
zusammen mit der LeiKa-ID und den Gemeindekennungen gelistet und wird somit für Antragsversender auffindbar. zusammen mit der LeiKa-ID und den Gemeindekennungen gelistet und wird somit für Antragsversender auffindbar.
Nachdem ein Zustellpunkt angelegt wurde, können über diesen Anträge empfangen werden. Wenn eine Einreichung für diesen eingegangen ist, Nachdem ein Zustellpunkt angelegt wurde, können über diesen Anträge empfangen werden. Wenn eine Einreichung für diesen eingegangen ist,
wird die Fachanwendung darüber über einen Callback benachrichtigt. Um die Einreichung abzurufen, muss die Fachanwendung sich zuerst via OAuth2 authentifizieren wird das empfangende System darüber über einen Callback benachrichtigt. Um die Einreichung abzurufen, muss das empfangende System sich zuerst via OAuth2 authentifizieren
und kann sich dann mithilfe des JWT gegenüber der FIT-Connect API autorisieren und die Einreichung abrufen. und kann sich dann mithilfe des JWT gegenüber der FIT-Connect API autorisieren und die Einreichung abrufen.
## Zustellpunkt anlegen ## Zustellpunkt anlegen
......
docs/more/glossary.mdx
+ 3
− 3
View file @ 7e7c5c6f
...@@ -5,8 +5,8 @@ hide_table_of_contents: true ...@@ -5,8 +5,8 @@ hide_table_of_contents: true
| Begriff | Beschreibung | | Begriff | Beschreibung |
|---------|--------------| |---------|--------------|
| Antragsempfangendes System (subscriber) | Das technische System, das Einreichungen auf Verwaltungsseite entgegennimmt. (z.B. Fachanwendung / virtuelle Poststelle) | | empfangendes System (subscriber) | Das technische System, das Einreichungen auf Verwaltungsseite entgegennimmt. (z.B. Fachanwendung / virtuelle Poststelle) |
| Antragssendendes System (sender) | Das technische System, das eine Einreichung über die Zustelldienst-API vornimmt. (z.B. Online-Antragsservice oder Unternehmenssystem). Dies ist in der Regel ein Online-Antragsservice (spezialisiertes Webportal für eine bestimmte Fachlichkeit), das Endgerät der Antragsteller:in oder auch ein Verwaltungsportal, das typischerweise mehrere Fachlichkeiten / Antragstypen unterstützt. Perspektivisch wären hier auch andere API-Clients denkbar, z.B. spezialisierte Anwendungen zur Antragseinreichung ohne Webinterface oder Fachverfahren der Verwaltung, über die beim Behördengang durch eine Sachbearbeiter:in stellvertretend für die Antragsteller:in ein Einreichung eingereicht wird. | | sendendes System (sender) | Das technische System, das eine Einreichung über die Zustelldienst-API vornimmt. (z.B. Online-Antragsservice oder Unternehmenssystem). Dies ist in der Regel ein Online-Antragsservice (spezialisiertes Webportal für eine bestimmte Fachlichkeit), das Endgerät der Antragsteller:in oder auch ein Verwaltungsportal, das typischerweise mehrere Fachlichkeiten / Antragstypen unterstützt. Perspektivisch wären hier auch andere API-Clients denkbar, z.B. spezialisierte Anwendungen zur Antragseinreichung ohne Webinterface oder Fachverfahren der Verwaltung, über die beim Behördengang durch eine Sachbearbeiter:in stellvertretend für die Antragsteller:in ein Einreichung eingereicht wird. |
| API-Client | Ein technisches System, dass auf die APIs (des Zustelldienstes) zugreift. Dieser Begriff kann verwendet werden, wenn eine Unterscheidung zwischen Fachverfahren, virtueller Poststelle, Onlineservice oder Endgerät der antragstellenden Person nicht nötig ist. | | API-Client | Ein technisches System, dass auf die APIs (des Zustelldienstes) zugreift. Dieser Begriff kann verwendet werden, wenn eine Unterscheidung zwischen Fachverfahren, virtueller Poststelle, Onlineservice oder Endgerät der antragstellenden Person nicht nötig ist. |
| API-Gateway | Das API-Gateway ist eine technische Komponente, die die Prüfung von OAuth-Tokens prüft und nicht oder falsch authentifizierte Anfragen blockiert. Ein Zugriff auf die Schnittstellen des Zustelldienstes ist ausschließlich über das API-Gateway möglich. | | API-Gateway | Das API-Gateway ist eine technische Komponente, die die Prüfung von OAuth-Tokens prüft und nicht oder falsch authentifizierte Anfragen blockiert. Ein Zugriff auf die Schnittstellen des Zustelldienstes ist ausschließlich über das API-Gateway möglich. |
| Antragsteller:in (applicant) | Bezeichnung der Person, die den Onlinedienst benutzt. Z.B. eine Verwaltungskund:in, die einen Einreichung absendet. | | Antragsteller:in (applicant) | Bezeichnung der Person, die den Onlinedienst benutzt. Z.B. eine Verwaltungskund:in, die einen Einreichung absendet. |
...@@ -23,4 +23,4 @@ hide_table_of_contents: true ...@@ -23,4 +23,4 @@ hide_table_of_contents: true
| Self-Service-Portal | Das Self-Service-Portal ist Teil des Authorisierungsdienst und ermöglicht es, Accounts/Berechtigungen für die Anbindung von Onlinediensten und Fachverfahren/virtuellen Poststellen anzulegen. | | Self-Service-Portal | Das Self-Service-Portal ist Teil des Authorisierungsdienst und ermöglicht es, Accounts/Berechtigungen für die Anbindung von Onlinediensten und Fachverfahren/virtuellen Poststellen anzulegen. |
| Vorgangsreferenz (caseID) | Systemübergreifend eindeutige ID für einen langlaufenden Kommunikationsvorgang zwischen dem einreichenden System und der Empfangsseite, wenn über die FIT-Connect kommuniziert werden sollen. Innerhalb einem Kommunikationsvorgang können weitere Fachdatensätze und Anlagen zwischen beiden Parteien ausgetauscht werden. | | Vorgangsreferenz (caseID) | Systemübergreifend eindeutige ID für einen langlaufenden Kommunikationsvorgang zwischen dem einreichenden System und der Empfangsseite, wenn über die FIT-Connect kommuniziert werden sollen. Innerhalb einem Kommunikationsvorgang können weitere Fachdatensätze und Anlagen zwischen beiden Parteien ausgetauscht werden. |
| Zustellberechtigungs-Scope | Beschreibt die Scopes aus den OAuth-Tokens (JWT), die im Zustelldienst dazu dienen, um zu überprüfen, ob ein Onlinedienst Einreichungen bei einer Destination vornehmen darf. | | Zustellberechtigungs-Scope | Beschreibt die Scopes aus den OAuth-Tokens (JWT), die im Zustelldienst dazu dienen, um zu überprüfen, ob ein Onlinedienst Einreichungen bei einer Destination vornehmen darf. |
| Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur digitalen Einreichung von Anträgen oder Berichten an die Verwaltung über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt repräsentiert typischerweise ein konkretes antragsempfangendes System (Fachverfahren oder virtuelle Poststelle). Für ein antragsempfangendes System können jedoch multiple Zustellpunkte angelegt werden. In der Konfiguration eines Zustellpunkts sind interne und öffentliche Teile hinterlegt. Interne Angaben sind solche, die zu Administrationszwecken dienen. Öffentliche Angaben legen z. B. fest, in welcher Form der Empfänger Einreichungen akzeptiert. Die öffentlichen Angaben sind:<br/>- Zulässige Schemata für einen Fachdatensatz (und die Pflicht, einen Fachdatensatz mit dem definierten Fachdatensatz in einer Einreichung zu nutzen)<br />- Öffentlicher Schlüssel zur Verschlüsselung von Fachdatensatz, Anlage und Metadatensatz | | Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur digitalen Einreichung von Anträgen oder Berichten an die Verwaltung über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt repräsentiert typischerweise ein konkretes empfangendes System (Fachverfahren oder virtuelle Poststelle). Für ein empfangendes System können jedoch multiple Zustellpunkte angelegt werden. In der Konfiguration eines Zustellpunkts sind interne und öffentliche Teile hinterlegt. Interne Angaben sind solche, die zu Administrationszwecken dienen. Öffentliche Angaben legen z. B. fest, in welcher Form der Empfänger Einreichungen akzeptiert. Die öffentlichen Angaben sind:<br/>- Zulässige Schemata für einen Fachdatensatz (und die Pflicht, einen Fachdatensatz mit dem definierten Fachdatensatz in einer Einreichung zu nutzen)<br />- Öffentlicher Schlüssel zur Verschlüsselung von Fachdatensatz, Anlage und Metadatensatz |
docs/overview.mdx
+ 5
− 5
View file @ 7e7c5c6f
...@@ -3,7 +3,7 @@ title: Überblick ...@@ -3,7 +3,7 @@ title: Überblick
slug: / slug: /
--- ---
Willkommen auf der Dokumentation für die FIT-Connect API von FITKO. Die FIT-Connect API baut auf dem bestehenden IT-Planungsrat Standard FIT-Connect auf und bietet Lösungsverantwortlichen von antragssendenden und antragsempfangenden Systemen eine einfache Möglichkeit, ihre Software schnell und wirtschaftlich in länder- und ebenenübergreifende Antragsprozesse zu integrieren. Willkommen auf der Dokumentation für die FIT-Connect API von FITKO. Die FIT-Connect API baut auf dem bestehenden IT-Planungsrat Standard FIT-Connect auf und bietet Lösungsverantwortlichen von sendenden und empfangenden Systemen eine einfache Möglichkeit, ihre Software schnell und wirtschaftlich in länder- und ebenenübergreifende Antragsprozesse zu integrieren.
## Was ist die FIT-Connect API und was unterscheidet diese API vom bisherigen XFall Standard? ## Was ist die FIT-Connect API und was unterscheidet diese API vom bisherigen XFall Standard?
...@@ -17,8 +17,8 @@ Bei der Entwicklung der FIT-Connect API wurden viele Konzepte mit Hinblick auf d ...@@ -17,8 +17,8 @@ Bei der Entwicklung der FIT-Connect API wurden viele Konzepte mit Hinblick auf d
Die FIT-Connect API besteht aus zwei getrennt nutzbaren APIs: Die FIT-Connect API besteht aus zwei getrennt nutzbaren APIs:
- Für antragsempfangende Systeme wird eine `Application Subscriber API` für den Empfang von Anträgen sowie eine `Callback` / Webhook Funktion für die technische Benachrichtigung über vorliegende Anträge angeboten. - Für empfangende Systeme wird eine `Application Subscriber API` für den Empfang von Anträgen sowie eine `Callback` / Webhook Funktion für die technische Benachrichtigung über vorliegende Anträge angeboten.
- Für antragssendende Systeme wird eine `Application Sender API` angeboten, um an beliebige antragsempfangende Systeme Anträge zu senden, die sich mit einem Zustellpunkt registriert haben. - Für sendende Systeme wird eine `Application Sender API` angeboten, um an beliebige empfangende Systeme Anträge zu senden, die sich mit einem Zustellpunkt registriert haben.
Diese beiden APIs werden durch einen zentralen Intermediär (`FIT-Connect Zustelldienst`) bereitgestellt. Um auf diese APIs zuzugreifen, müssen interessierte Entwickler ihre Anwendungen beim FIT-Connect Autorisierungsdienst vorab registrieren. Diese beiden APIs werden durch einen zentralen Intermediär (`FIT-Connect Zustelldienst`) bereitgestellt. Um auf diese APIs zuzugreifen, müssen interessierte Entwickler ihre Anwendungen beim FIT-Connect Autorisierungsdienst vorab registrieren.
...@@ -26,7 +26,7 @@ Diese beiden APIs werden durch einen zentralen Intermediär (`FIT-Connect Zustel ...@@ -26,7 +26,7 @@ Diese beiden APIs werden durch einen zentralen Intermediär (`FIT-Connect Zustel
![Applicationtransfer_Architecture](/images/api_overview/XFall_Integration_Architecture.png "Antragsübertragungsarchitektur FIT-Connect") ![Applicationtransfer_Architecture](/images/api_overview/XFall_Integration_Architecture.png "Antragsübertragungsarchitektur FIT-Connect")
Über die `Application Subscriber API` können die zuständigen Stellen für ihre Systeme einen Zustellpunkt eröffnen, der über eine `destination-Id` eindeutig adressierbar ist. Für diese Zustellpunkte legen die zuständigen Stellen alle fachlichen Vorgaben (Zulässige Fachstandards, Verschlüsselung, Datenformate etc.) fest, damit eine medienbruchfreie Weiterverarbeitung in ihren Systemen gewährleistet ist. Über die Angabe der `destination-Id` in der `Application Sender API` können beliebige antragssendende Systemen Anträge an die zuständige Stelle senden. Über die `Application Subscriber API` können die zuständigen Stellen für ihre Systeme einen Zustellpunkt eröffnen, der über eine `destination-Id` eindeutig adressierbar ist. Für diese Zustellpunkte legen die zuständigen Stellen alle fachlichen Vorgaben (Zulässige Fachstandards, Verschlüsselung, Datenformate etc.) fest, damit eine medienbruchfreie Weiterverarbeitung in ihren Systemen gewährleistet ist. Über die Angabe der `destination-Id` in der `Application Sender API` können beliebige sendende Systemen Anträge an die zuständige Stelle senden.
Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jeweiligen örtlichen Antragskontext (bspw. Ort der Antragsstellung) korrekt zu ermitteln. Damit die Ermittlung des korrekten Zustellpunkts skalierbar für das ganze Bundesgebiet funktioniert, ist langfristig vorgesehen, die `destination-Id` in den Leistungs- und Zuständigkeitsinformationen des jeweils bekannten Zuständigkeitsfinders zu hinterlegen. Diese dezentral gepflegten Informationen sollen durch das Online-Gateway (<https://www.onlinezugangsgesetz.de/Webs/OZG/DE/umsetzung/portalverbund/online-gateway/online-gateway-node.html>) gebündelt und über eine offene API im XZuFi Format (<https://www.xrepository.de/details/urn:xoev-de:fim:standard:xzufi>) nutzbar gemacht werden. Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jeweiligen örtlichen Antragskontext (bspw. Ort der Antragsstellung) korrekt zu ermitteln. Damit die Ermittlung des korrekten Zustellpunkts skalierbar für das ganze Bundesgebiet funktioniert, ist langfristig vorgesehen, die `destination-Id` in den Leistungs- und Zuständigkeitsinformationen des jeweils bekannten Zuständigkeitsfinders zu hinterlegen. Diese dezentral gepflegten Informationen sollen durch das Online-Gateway (<https://www.onlinezugangsgesetz.de/Webs/OZG/DE/umsetzung/portalverbund/online-gateway/online-gateway-node.html>) gebündelt und über eine offene API im XZuFi Format (<https://www.xrepository.de/details/urn:xoev-de:fim:standard:xzufi>) nutzbar gemacht werden.
...@@ -34,7 +34,7 @@ Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jewei ...@@ -34,7 +34,7 @@ Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jewei
## Für wen ist die FIT-Connect API gedacht und warum sollte ich sie nutzen? ## Für wen ist die FIT-Connect API gedacht und warum sollte ich sie nutzen?
Die FIT-Connect API ist für alle Hersteller, Entwickler und Verfahrensverantwortliche von antragssendenden und antragsempfangenden Systemen gedacht. Insbesondere folgende Systeme mit bundesweiten Nutzungsszenarien sollen mit der FIT-Connect API unterstützt werden: Die FIT-Connect API ist für alle Hersteller, Entwickler und Verfahrensverantwortliche von sendenden und empfangenden Systemen gedacht. Insbesondere folgende Systeme mit bundesweiten Nutzungsszenarien sollen mit der FIT-Connect API unterstützt werden:
- **Einer für alle (EfA) Verfahren**: Länderübergreifend entwickelte Antragsverfahren für eine bestimmte Verwaltungsleistung oder ein Leistungsbündel, die entweder in verschiedenen Ländern nachnutzbar betrieben werden oder länderübergreifend als gemeinsamer Antragsdienst für alle zuständigen Stellen betrieben werden. - **Einer für alle (EfA) Verfahren**: Länderübergreifend entwickelte Antragsverfahren für eine bestimmte Verwaltungsleistung oder ein Leistungsbündel, die entweder in verschiedenen Ländern nachnutzbar betrieben werden oder länderübergreifend als gemeinsamer Antragsdienst für alle zuständigen Stellen betrieben werden.
- **Antragsgeneratoren / Antragsmanagementsysteme**: Standardsoftware zur Erstellung und dem Betrieb von direkt nutzbaren Onlineantragsdiensten, die im ganzen Bundesgebiet bei einzelnen Stellen oder Gebietskörperschaften (bspw. als Basiskomponente) im Einsatz sind. - **Antragsgeneratoren / Antragsmanagementsysteme**: Standardsoftware zur Erstellung und dem Betrieb von direkt nutzbaren Onlineantragsdiensten, die im ganzen Bundesgebiet bei einzelnen Stellen oder Gebietskörperschaften (bspw. als Basiskomponente) im Einsatz sind.
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment