Routing-API: Problem bei der Signaturprüfung der Adressierungsinformation

Zusammenfassung

Bei der Signaturprüfung der Adressierungsinformation muss ein anfragender Client wissen, auf welche AGS/ARS der Zustellpunkt registriert worden ist, und zwar auch dann, wenn er mit einer Area-ID oder ARS/AGS angefragt hat.

Schritte zum Reproduzieren

Die Dokumentation in https://docs.fitko.de/fit-connect/docs/sending/get-destination/#checkDestinationSignature fordert, dass die Signatur der Adressierungsinformation geprüft wird. Dazu ist u.a. eine Hypothese über die URN des Gebietes zu formulieren, die dann auf der Basis des Claim-Sets zu prüfen ist.

Ein Zustellpunkt kann auf Basis einer AGS oder ARS registiert werden. Im Beispiel haben wir den Zustellpunkt auf die ARS 066320003003 (Bebra) registriert. Wir können diesen Zustellpunkt auch über die AGS 06632003 und die Area-ID 2227 erreichen.

Folgendes Szenario:

1. Ein Client ohne Kenntnis unserer Registrierungsinformation will unsere Verwaltungsleistung in Bebra in Anspruch nehmen.
2. Der Client fragt über das Routing-API die Area-ID ab und erhält die Id 2227 (bzw. kennt von sich aus die AGS 06632003)
3. Der Client fragt ebenfalls über das Routing-API die Menge der Zustellpunkte für die Area-ID 2227 (oder die AGS 06632003) ab und erhält in der Antwort unseren Zustellpunkt
4. Im Claim-Set der Signatur der Adressierungsinformation steht unter services.gebietIDs der Wert urn:de:bund:destatis:bevoelkerungsstatistik:schluessel:rs:066320003003. Das ist der Wert, mit dem der Zustellpunkt registriert wurde, und nicht der Wert, mit dem der Client angefragt hat

Wie verhält sich der aktuelle Fehler?

Der Client ist nicht in der Lage die Signatur der Adressierungsinformation zu prüfen. Dazu würde er als zusätzliches Wissen benötigen:

1. Wurde der angefragte Zustellpunkt mit einer AGS oder ARS registriert?
2. Welche Länge hatte die zur Registratur verwendete AGS/ARS?
3. Welcher ARS ist die die Area-Id 2227 bzw. die AGS 06632003 zugeordnet?

Was ist das erwartete richtige Verhalten?

Es sind verschiedene Varianten denkbar:

1. Gebiets-IDs sind nicht Teil des zu prüfenden Claim-Sets (sub-optimal)
2. Das Routing-API liefert eine zweite Gebiets-Id zurück, in der die URN des angefragten Gebietes steht. Nur diese URN steht im Claim-Set.
3. Zustellpunkte werden ausschließlich als ARS registriert und ausschließlich über eine ARS im Routing-API abgefragt. Es gibt zusätzliche API-Funktionen, mit deren Hilfe sich ARS ermitteln lassen. Außerdem gilt, dass die angefragte ARS immer eine "Teilmenge" der registrierten ARS ist und somit die ARS im Claim-Set in der durch den Client angefragten ARS enthalten ist ... das lässt sich dann prüfen.

added team::RTD label

Vielen Dank für die sehr ausfühliche und verständliche Beschreibung der Problematik!

Eine Prüung der Gebiets-ID erfolgt bereits im Routingdienst. Auf eine separate Prüfung der Gebiets-ID im anfragenden Client (Sender) kann daher verzichtet werden. Eine zusätzliche Prüfung auf Grundlage der vom Routingdienst bereitgestellten Informationen bietet keinen Sicherheitsmehrwert. Wir werden die Dokumentation hierzu dementsprechend anpassen.

Behandelt in docs!246 (merged)

Anpassung ist live: https://docs.fitko.de/fit-connect/docs/sending/get-destination/#checkservices

closed