Anbindung von Fachverfahren an kommunale Postfächer über XTA
Wir favorisieren den Austausch dieser XBau-Nachrichten über sogenannte XTA2 Webservices und einem dahinter befindlichen Intermediär. Konkret wird dazu die EfA Lösung im DVDV registriert und kann über einen XTA2 Endpunkt im DVZ Schwerin die XBau-Nachrichten versenden und empfangen.
Die Fachverfahren der Kommunen benötigen ebenfalls einen eigenen, durch die UBAB selbst zu organisierenden XTA2-Endpunkt und DVDV Eintrag. In einigen Bundesländern existieren dafür Landeslösungen oder Zweckverbände, die das in der Fläche organisieren. Bitte informieren Sie sich dazu bei den Ansprechpartnern des entsprechenden Bundeslandes. Damit die EfA-Lösung der UBAB (Kommune) XBau-Nachrichten senden kann, werden in der EfA Lösung die DVDV Kennung und der Präfix der UBAB hinterlegt (z.B. Kennung 15088 und Präfix bab).
Wenn man realisitisch die Infrastruktursituation beurteilt, dann ist die Nachrichtenübertragung über XTA2 und Intermediär in einigen Bundesländern und bei einigen Kommunen bereits produktiv umsetzbar und nutzbar. Das sollte dort unbedingt so realisiert werden!
Leider ist das Thema Intermediär und XTA Schnittstelle bei einigen Ländern und deren Kommunen ein echtes Hindernis, welches zur Lösung mindestens mehrere Monate benötigt. Deshalb bieten wir in der Pilotphase den Fachverfahren der UBAB mindestens in der Testumgebung durch die EfA-Lösung einen direkten XTA-Endpunkt an. Die Details dazu werden im Abschnitt Testumgebung näher beschrieben.
Inwiewiet die direkte Bereitstellung von XTA-Endpunkten an der EfA-Lösung auch als Produktivumgebung bei Bedarf angeboten kann, wird derzeit geklärt.
Die Ursprünge von XTA bzw. XTA 2
● XTA (XÖV Transport Adapter) ist vom IT-Planungsrat empfohlener Interoperabilitätsstandard
● XTA definiert zum einen die Anbindung von IT-Fachapplikationen an eine technische Infrastruktur für Nachrichtenübermittlung
● Gründe
-Implementierung von OSCI-Kommunikation in Fachverfahren trotz vorhandenem SDK komplex
-Aufbau von Clearingstellen als zentrale Infrastruktur (z.B. im Einwohnerwesen)
● XTA enthält zudem Definitionen für Struktur und Semantik von "Service Profilen"
● mit "XTA Service Profiles" formuliert eine Fachlichkeit die durch sie geforderten Service-Qualitäten für die Nachrichten- und Datenübermittlung
-ersetzt die Prosa-Dokumente, die im Rahmen der Standardisierung einzelner Fachlichkeiten entstanden sind
-ermöglicht eine maschinelle Auswertung z.B. in Gateways
● Hier wird z.B. festgelegt, ob eine Nachricht transport-signiert oder inhalts-verschlüsselt ist
● Hintergrund: Teile von XTA 2 sind eine Profilierung von OSCI Transport 2.x → wird durch die Namespaces deutlich
Bestandteile des XTA 2-Standards
● Der XTA 2-Standard definiert zwei Aspekte: Service Profile und XTA-WS
● Ein Service Profile dient dazu, Eigenschaften des Datenschutzes, der Datensicherheit und der Transportstruktur bezogen auf eine Fachlichkeit festzulegen.
● Hierzu wird ein Profil erstellt, welches Standard-Bausteine (z.B. im Bereich der Kryptographie) referenziert
● Ziel: Sender und Empfänger verwenden die gleichen Transport-Parameter bei einer OSCI-Kommunikation
● XTA-WS definierten Methoden, mit der eine Gateway-Komponente an ein Fachverfahren angebunden werden kann
● Diese Gateway-Komponente (z.B. eine Clearingstelle) übernimmt dann die OSCI-Kommunikation
● Daher: XTA2 definiert kein Kommunikationsprotokoll!
Profile: Früher und Heute
Profile bezogen auf XBau 2.x
● Leider heute noch kein XTA 2-konformes Profile Bestandteil des XBau-Standards
● Kommunikationsparameter in Prosa im XBau-Standard beschrieben
● Gateways verwenden derzeit XAuslaender-Profil, da dies der gewünschten Struktur nahe kommt (daher nicht wundern!)
● Aufgabe für die Standardisierungs-Agenda von XBau!
Exkurs zum Verständnis: OSCI-Transport
Rollen in OSCI-Transport
● Autor (engl. author)
● Sender (engl. originator)
● Intermediär (engl. intermediary)
● Empfänger (engl. addressee)
● Leser (engl. reader)
Rollen: Autor
● Ursprung der Daten auf Inhaltsebene (Content Container),
die an den Leser gehen
● Ziel der Antworten auf Inhaltsebene (Content Container),
die vom Leser kommen
● Kann einzelne Inhaltsdaten signieren
● Kann Verschlüsselung einzelner Inhaltsdaten für Leser veranlassen
● Mehrfachsignaturen (von verschiedene Autoren) möglich
● Mehrfachverschlüsselung (an verschiedene Leser) möglich
● Qualifizierte Signatur durch einen menschlichen Autor möglich,
aber nicht erforderlich
● Kann mit dem (technischen) Sender gemeinsame Zertifikate/Schlüssel benutzen
Rollen: Leser
● Pendant zum Autor
● Ziel der Daten auf Inhaltsebene, die vom Autor kommen
● Ursprung der Antworten auf Inhaltsebene, die an den Autor gehen
● Entschlüsselt Inhaltsdaten des Autors
● Prüft Signatur der Inhaltsdaten des Autors
● Fungiert im Antwortfall als Autor
-Kann einzelne Inhaltsdatenantworten signieren
-Kann Verschlüsselung einzelner Inhaltsdatenantworten für den ursprünglichen Autor veranlassen
-Ursprünglicher Autor wird zum Leser
● Kann mit dem (technischen) Empfänger gemeinsame Zertifikate/Schlüssel benutzen
Rollen: Sender und Empfänger
● Technische Endpunkte der Kommunikation
● Können Nachricht insgesamt signieren (Transportsignatur)
● Können Nachricht insgesamt für den Intermediär verschlüsseln (Transportverschlüsselung)
● Transportsicherheit endet beim Intermediär und kann von der jeweils anderen Seite der Kommunikation nicht überprüft werden
Rollen: Intermediär
● Zentrale Vermittlungsstelle für OSCI-Nachrichten
● Typischerweise hoch verfügbar
● Notwendige technische Rolle in jeder OSCI-Kommunikation
● Eine direkte OSCI-Kommunikation (bei OSCI-Transport 1.2) zwischen zwei Endpunkten ohne Intermediär (nur über Client-Bibliotheken) ist technisch nicht möglich!
● Zentralisiert kryptografische Mehrwertdienste
● Stellt indirekte Vertrauensbeziehung zwischen sich gegenseitig nicht bekannten Kommunikationspartnern her
● Hat keinen Einblick in die Inhaltsdaten (TDDSG)
● Daher keine Signaturprüfung der Inhaltsdaten
● Kann als Rolle bzw. Modul auch von einem der Kommunikationsendpunkte übernommen werden (separates Serversystem nicht zwingend erforderlich)
Technische Aufgaben des Intermediärs
● Vermittlung der synchronen und asynchronen Kommunikation zwischen den Endpunkten (separate TCP-Verbindungen)
● Sicherheitsmerkmale auf Transportebene (Verschlüsselung und Signatur, Conversation IDs, Challenge/Response-Verfahren etc.)
● Authentisierung und Autorisierung von Kommunikationspartnern
● Validierung der Nachrichtenstruktur, soweit zugänglich
● Führung, Archivierung und Bereitstellung von Laufzetteln
● Zertifikatsprüfungen, auch online
● Integration von Zeitstempeln
● Führung von Postfächern
● Funktionen des Intermediärs in der KoSIT-Bibliothek nicht enthalten
OSCI-Postfächer
● Bedeutung: Definierte Erreichbarmachung von OSCI-Empfängern, die nicht ständig online sind oder nicht direkt (passiv) erreichbar sind
● Vom Intermediär geführte Ablage für asynchrone OSCI-Nachrichten (Zustellungsaufträge)
-Aktive Abholung durch den Empfänger
-Eigener Zeitplan (z.B. nächtlicher Batch-Lauf)
● Eigene TCP-Verbindung (d.h. intern initiiert)
● Postfachidentifikation über Chiffrierzertifikat des Empfängers
-Einreicher (OSCI-Absender) benutzt Chiffrierzertifikat als Postfachangabe
-Abholer (OSCI-Empfänger) weist sich durch Chiffrierzertifikat und Besitznachweis des zugehörigen Chiffrierschlüssels aus
● Vorhaltedauer in Spezifikation nicht geregelt
Laufzettel
● Automatische Aufzeichnung des Intermediärs zu allen vermittelten Nachrichten
● Bedeutung: Sichere Zustellungs- bzw. Eingangsquittung
● Laufzettel umfasst
-Nachrichtenkennung (Message-ID)
-Metadaten und Prüfergebnis zu beteiligten Zertifikaten
-Div. Vermittlungszeitpunkte (Systemzeit oder Zeitstempel)
● Vom Intermediär als Protokollantwort automatisch zurück geliefert
● Mittels definierten Protokolls nachträglich abrufbar
● Zeitraum und Medium der Aufzeichnung in OSCI-Spezifikation nicht festgelegt
● Ggf. zusätzlich erforderlich: Speicherung der eigentlichen Nachricht inkl. Zertifikaten beim Absender und/oder beim Empfänger
Das Kommunikationsmodell aus Sicht XTA 2
Was macht Governikus Com Despina?
● Governikus Com Despina ist ein Produkt der Governikus GmbH & Co. KG, Bremen
● Vorgängerprodukt war das Governikus Communication Gateway (GCG)
● Governikus Com Despina ist Teil der Governikus-Suite → ist bei vielen öffentlichen Einrichtung über entsprechende Vereinbarungen lizenziert
● Despina stellt grundsätzlich folgende Funktionen zur Verfügung
-XTA2-Webservice-Endpunkt
-OSCI-Sender und OSCI-Empfänger-Funktion
-Unterstützung von Profilen
-Abfrage des DVDV zur Adressierung
-Pufferfunktion
-Direkte Adressierung zwischen Usern der gleichen Despina-Instanz möglich
Anatomie einer XTA2-Content-Nachricht
Ab XBau 2.3 erfolgt stets eine getrennte Übertragung von XML-Fachnachricht und binären Anlagen. In XBau ist keine Ende-zu-Ende-Verschlüsselung vorgesehen.
Referenzierung von Attachments
Jede Nachricht muss als Ganzes, einschließlich aller Anhänge, in der Struktur GenericContentContainer/ContentContainer übertragen werden. Jede Datenlieferung muss eine Nachricht (XML) als Inhalt in XTA im Element Message haben. Weitere Primärdokumente und Anhänge zu der Fachnachricht können als weitere Inhalte im Element Attachment in demselben ContentContainer folgen.
In letzterem Fall muss die Referenz aus der XBau-Fachnachricht (enthalten im Element referenzPrimaerdokument) auch im XTA-Attribut id des Elements Attachment enthalten und eindeutig sein.
Wichtige Methoden der XTA2-Webservices
Holen von Nachrichten aus einem Postfach (MsgBox)
| getStatusList() | Mit der Methode getStatusList kann der Leser vom Empfänger Informationen (MessageID und Metadaten des Transportauftrags) über die eingegangenen Nachrichten abrufen bzw. prüfen, ob Nachrichten bereitstehen. |
| getMessage() | Mit der Methode getMessage holt der Leser eine Nachricht vom Empfänger ab. Die Identifikation der Nachricht erfolgt also durch die MessageID des zugehörigen Transportauftrages, die als Ergebnis der Methode getStatusList zurückgegeben wurde. Wenn der Leser gezielt eine MessageID benennt, erhält er die entsprechende Nachricht. Bei dieser gezielten Abholung ist nicht relevant, ob die Nachricht bereits früher abgeholt wurde. Der Empfang abgeholter Nachrichten muss vom Leser gegenüber dem Empfänger (mit der Methode close und mindestens der MessageID aus dem MessageMetaData-Container) quittiert werden. |
| getNextMessage() | Der Leser hat für das Abholen der Nachrichten vom Empfänger eine Ressourcenkennung erhalten. Unter Angabe dieser Kennung kann er die nächste Nachricht abholen. Dabei sollte er die MessageID der zuletzt abgeholten Nachricht mit angeben. Dadurch quittiert er die erfolgreiche Abholung dem Empfänger. Liegt keine weitere Nachricht vor, dann liefert der Empfänger eine entsprechende Meldung zurück. |
| close() | Mithilfe der Methode close soll sichergestellt werden, dass Nachrichten oder Listen nicht mehrfach verarbeitet werden: Der Leser bestätigt dem Empfänger durch eine entsprechende Quittierung, dass Nachrichten und (Teil-)listen erfolgreich abgeholt werden konnten. |
TLS-Client-Authentication
● Die Authentisierung von Leser bzw. Autor (= Fachverfahren) gegenüber den Endpunkten des Webservices erfolgt mittels TLS-Client-Authentication.
● Hierzu wird ein entsprechendes Zertifikat und zugehöriger Schlüssel vom Betreiber des Endpunkts benötigt. Dieses Zertifikat dient als “Login” gegenüber dem Gateway und ist nicht notwendigerweise identisch zum Zertifikat/Schlüssel eines OSCI-Postfaches.
● Zusätzlich gibt es ein TLS-Zertifikats des Endpunkts selbst, mit dem die Clients dessen Identität prüfen müssen.
● Dies bedeutet, dass dem genutzten Framework eine TLS-Authentication konfiguriert werden muss und entsprechende Key- bzw. Truststores auf dem Client hinterlegt werden müssen.
● Irgendjemand dachte bei der Spezifikation der XTA-WS, das wäre einfacher als Webservice-Security.
● Beachte: Firewall- und Webproxy-Configuration müssen TLS-Client-Authentication am Endpunkt (!) erlauben.
Das Deutsche Verwaltungsdiensteverzeichnis DVDV
● Das DVDV ist ein Verzeichnisdienst, der es erlaubt, Kommunikationsparameter einer OSCI-Kommunikation (wie Empfänger-Zertifikat, Intermediärs-URL und -Zertifikate) abzurufen.
● Für jeden verwalteten Fach-Dienst benötigt es ein DVDV-Eintragungskonzept, welches Adressierung und Services festlegt und mit dem Fachstandard gepflegt wird.
● Das DVDV wird über Pflege-Clients dezentral gepflegt, über ein Master/Slave-Konzept erfolgt eine Verteilung des Datenbestands an die DVDV-Landesserver.
● Über XTA2-WS kann mit der Methode lookupService() geprüft werden, ob ein Leser grundsätzlich verzeichnet ist.
● Ein Eintrag wird durch und den referenziert.
● Der DVDV-Präfix macht eine Kennung eindeutig.
Verwaltung von Schlüsseln im DVDV (bezogen auf XBau)
● DVDV-Präfixe im XRepository (https://xrepository.de ) abrufbar: urn:xoev-de:bund:bmi:bit:codeliste:dvdv.praefix
-bab - Bauaufsichtsbehörde
-bap - Bauportal
-gba - Gemeindebauamt
● Die unterstützten Dienste ist in Abschnitt “IV.D DVDV-unterstützte Dienste” der XBau-Spezifikation aufgelistet
● Die Adressierung der Behörden erfolgt über den AGS (Amtlichen Gemeindeschlüssel) oder Kreisschlüssel (siehe z.B. https://www.xrepository.de/details/urn:de:bund:destatis:bevoelkerungsstatistik:schluessel:ags)
● Die Eintragung der konkreten Behörden eines Landes erfolgt durch die DVDV-Pflegende Stelle des jeweiligen Bundeslandes.
Beispiel: Nachrichtenempfang
Checkliste, bevor begonnen wird
| Habe ich die XTA2-Schemata heruntergeladen (bei EfA-Baeuen wird XTA2 Version 3 genutzt - urn:xoev-de:kosit:standard:xta2_3) ? | Wenn nein, unter https://www.xrepository.de/details/urn:xoev-de:kosit:standard:xta2_3#version herunterladen. |
| Kenne ich den richtigen XTA2-Webservice-Endpunkt und kann ich ihn von meinem Entwicklungsrechner erreichen? | Wenn nein, nachsehen unter https://www.digitale-baugenehmigung.de/de/testumgebung.html |
| Habe ich einen Trust-Store passend zum Endpunkt vorliegen? | Wenn nein, herunterladen von https://www.digitale-baugenehmigung.de/de/testumgebung.html |
| Habe ich das zu meinem Postfach passende TLS-Client-Zertifikat inkl. Schlüssel und Passwort vorliegen? | Wenn nein, bitte Kontakt unter https://www.digitale-baugenehmigung.de/de/testumgebung.html suchen. |
| Habe ich ein Webservice-Framework, welches zusammen mit der TLS-Clientauthentication verwendet werden kann? | Wenn nein, ggf. auf eine andere Technologie ausweichen. |
Erzeugung der Quellen aus der XTA2-WSDL (hier in einer Java-Umgebung)
java -Djavax.xml.accessExternalDTD=all -classpath /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/lib/tools.jar com.sun.tools.internal.ws.WsImport -s generated -extension -B-XautoNameResolution -XadditionalHeaders -Xnocompile file:./XTA.wsdl
Kompilieren der erzeugten Quellen
javac -d build $(find ./generated | grep .java)