Die Destination-IDs entscheiden darüber wohin ein Antrag zugestellt wird. Jeder Zustellpunkt eines spezifischen Antrags im FIT-Connect System verfügt über eine Destination ID.
Ein Empfangspunkt kann dabei die Nachrichten für mehrere Destination-IDs empfangen und ein Antrag kann auch an mehrere Destination-IDs versendet werden.
## Zusammensetzung der Destination-IDs
Eine Destination-ID ist immer eine ID in Verbindung mit einem Prefix für die Art der Leistung, die über sie zugestellt wird.
| Type | leika oder custom | Leika steht dafür, das die folgende ID einer Leistung im [Leistungskatalog der öffentlichen Verwaltung](https://leitfaden.ozg-umsetzung.de/display/OZG/2.1+Verwaltungsleistungen+im+Sinne+des+OZG) verzeichnet ist. Custom bedeutet, das es sich um eine Leistung handelt, die nicht Teil des Leistungskatalogs ist und nur in FIT-Connect angelegt wurde |
| ID | eine maximal 9-Stellige Nummer, die die Art des übermittelten Antrags angibt | Wenn der Typ "leika" entspricht, handelt es sich um eine ID, die einer Leistung im Leistungskatalog entspricht. Wenn der Typ "custom" entspricht, dann handelt es sich um eine ID, die einer Custom-Leistung im FIT-Connect Admin-Panel entspricht. |
| Destination-UUID | UUID der Destination | UUID der Destination, an die der Antrag versendet werden soll. |
## Beispiele
LeiKa-Leistung für die [Begutachung von abgeschleppten Fahrzeugen](https://fimportal.de/detail/L/99108008252000):
| iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. |
| exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte max. 24 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)). |
| scope | Liste von Destination-IDs | Eine Liste der Destination-IDs, für die der JWT eine Übermittlung erlaubt. |
| scope | Liste von Destination-IDs | Eine Liste der Destination-IDs oder Präfixes, für die der JWT eine Übermittlung erlaubt. |
| epk | Public Key des Onlinedienstes | Der Public Key, der dem Onlinedienst bei der Anmeldung zugeordnet wurde im JWK Format nach [RFC-7517](https://tools.ietf.org/html/rfc7517) |
| aud | ID des Onlinedienstes | Wird bei der Anmeldung des Onlinedienstes festgelegt und dient zur Identifizierung des Onlineservices |
| domains | Liste von Domains | Eine Liste der Domains, von denen der Onlineservice Anträge übermitteln kann. (Subdomains müssen explizit angegeben werden) |
...
...
@@ -104,7 +104,7 @@ Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose
@@ -131,7 +131,7 @@ Das API-Gateway muss die JWT-Tokens validieren:
2. der Onlinedienst-JWT-Token für max. 24h ausgestellt wurde.
2. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des Onlinedienst-JWT überprüfen.
3. Mithilfe des im JWT-Token des Onlinedienst enthaltenen Public Key die Signatur des User JWT überprüfen
4. Überprüfen, ob die Destination-ID teil der in den Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users)
4. Überprüfen, ob die Destination-ID teil der in den Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users). Bzw. ob der im Präfix des Onlineservice-Tokens dem Präfix der Destination-ID(s) entspricht.
5. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, im domain Feld beider JWKs verzeichnet ist. (Verhindern von gefälschten Onlinediensten, die nicht den FIT-Connect-Standards entsprechen)
Das API-Gateway kann aufgrund der folgenden Parameter Rate-Limiting für API-Calls (angepasst an die jeweiligen Use Cases des Onlineservices) betreiben:
