Archiv der Kategorie: Tipps & Tricks

Transportverschlüsselung für novaFACTORY und WEGA

Hinweis: Dieser Artikel stellt ein Update des Textes aus dem Jahr 2021 dar.

Transportverschlüsselung

Transportverschlüsselung stellt in der IT-Sicherheit die Verschlüsselung der Daten während des Transports der Daten zwischen zwei Servern oder einem Server und dem Client dar. Dabei handelt es sich um eine Punkt-zu-Punkt-Verschlüsselung. Bekanntestes Beispiel für eine Transportverschlüsselung ist HTTPS, bei dem das eigentlich unverschlüsselte HTTP durch einen TLS-Tunnel verschlüsselt übertragen wird.

Im Folgenden wird die Einrichtung von HTTPS für novaFACTORY und WEGA unter dem Betriebssystem Windows beschrieben.

Voraussetzungen

Die Verwendung von HTTPS setzt die Benutzung eines X.509-Zertifikats für den Server voraus. Mit diesem Zertifikat weist sich der Server gegenüber dem Client aus. Auf Basis des Zertifikats kann der Client beim Aufbau der Verbindung beurteilen, dass die Kommunikation mit dem richtigen Server aufgebaut wird. Dazu muss das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) explizit für den abzusichernden Server ausgestellt worden sein. Zum Zertifikat gehört grundsätzlich ein serverspezifischer, privater Schlüssel, auf dessen Basis die Anfrage bei der CA zur Ausstellung des Zertifikats gestellt wurde.

Bei der Zertifizierungsstelle kann es sich sowohl um eine öffentliche oder eine interne Stelle handeln. Eine öffentliche CA stellt Zertifikate aus, die von jedem Browser als vertrauenswürdig eingestuft werden. Diese Zertifikate kommen in der Regel bei Servern zum Einsatz, die aus dem Internet erreichbar sein sollen. Eine interne CA stellt in der Regel Zertifikate aus, die nur im Behörden- oder Firmenintranet akzeptiert werden. Eine CA besitzt ebenfalls ein Zertifikat, dem explizit das Vertrauen ausgesprochen werden muss. Bei öffentlichen Stellen sind diese in der Regel bereits im Browser bzw. im System hinterlegt. Bei internen CAs muss dies durch die Systemadministration z.B. durch das Active Directory erledigt werden.

Für Zertifikate gibt es verschiedene Dateiformate, in denen das Zertifikat und der dazugehörige Schlüssel vorliegen können. Unter Windows hat sich das Format „PKCS 12“ als Standard etabliert. Dieses ist an der Dateiendung „.p12“ oder „.pfx“ erkennbar. Dieses Format enthält das Zertifikat und den dazugehörigen Schlüssel in einer einzelnen Datei, womit die Einrichtung stark vereinfacht wird.

Zertifikatsspeicher in Windows

Unter Windows gibt es zwei Zertifikatsspeicher: Einen Speicher für den Benutzer und einen Speicher für den Computer. Im Computerspeicher sind normalerweise die beglaubigten Zertifikate der CAs hinterlegt. Im persönlichen Speicher des Benutzers hingegen werden die Zertifikate hinterlegt, für die der Anwender einen privaten Schlüssel besitzt. Aus Sicht von novaFACTORY und WEGA handelt es sich bei „dem Benutzer“ um die Betriebssystembenutzer, unter dem die Windowsdienste – speziell der Apache Tomcat – laufen.

Für die Einrichtung von HTTPS für novaFACTORY und WEGA muss daher zuerst das Zertifikat mit dem dazugehörigen Schlüssel in den persönlichen Zertifikatsspeicher des Dienstebenutzers importiert werden. Bei Vorliegen einer pfx-Datei passiert dies am einfachsten durch Doppelklick auf die Datei. Alternativ kann die Konfigurationskonsole „certmgr.msc“ als Dienstebenutzer gestartet und der Import manuell durchgeführt werden. Es ist wichtig, dass das Zertifikat in den persönlichen Speicher des Benutzers importiert wird.

Zertifikat in den persönlichen Zertifikatsspeicher importieren
Zertifikat in den persönlichen Zertifikatsspeicher importieren

Nach dem Import wird das Zertifikat in der Zertifikatskonsole von Windows angezeigt. Dabei wird der Servername angezeigt, für den das Zertifikat ausgestellt wurde. Dabei handelt es sich um den sogenannten Common Name (CN). Dieser wird später noch benötigt.

Konfiguration in Apache Tomcat

Da sowohl novaFACTORY als auch WEGA die Servlet Engine Apache Tomcat für die Auslieferung der Weboberfläche benutzen, erfolgt die eigentliche Einrichtung von HTTPS in dieser Software. Dazu ist in der Konfigurationsdatei conf\server.xml in der Installation des Apache Tomcat folgender „Connector“ zu konfigurieren:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
    sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
    maxThreads="150"
    SSLEnabled="true"
    scheme="https"
    secure="true"
    keyAlias="<CN_des_Zertifikats>"
    keystoreFile=""
    keystorePass=""
    keystoreType="Windows-My"
    clientAuth="false"
    sslProtocol="TLS"
    sslEnabledProtocols="TLSv1.2"
    keepAliveTimeout="200000" />

Beim Parameter keyAlias ist der Common Name des Zertifikats einzutragen. Der keystoreType „Windows-My“ stellt den persönlichen Zertifikatsspeicher des Dienstebenutzers dar, in den das Zertifikat vorher importiert wurde. Die leeren Parameter zum Zertifikatsspeicher sind aufgrund eines Bugs notwendig. Die aktivierten Protokolle („sslEnabledProtocol“) sind mit der IT-Administration abzustimmen. Beim Einsatz moderner Browser kann die oben beschriebene Konfiguration verwendet werden.

Zusätzlich muss die Java-Ausführungsumgebung für den Apache Tomcat so angepasst werden, dass die Windows-Zertifikatsspeicher verwendet werden können. Die Konfiguration erfolgt im Tomcat-Monitor im Reiter „Java“. Dort müssen folgende Parameter unter „Java Options“ ergänzt werden.

-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.keyStoreProvider=SunMSCAPI
-Djavax.net.ssl.keyStoreType=Windows-MY
-Dcom.sun.security.enableAIAcaIssuers=true

Hier wird festgelegt, dass für die beglaubigten CA-Zertifikate der Zertifikatsspeicher des Benutzers verwendet wird („Windows-ROOT“). Zusätzlich wird nochmals der Zertifikatsspeicher des Dienstebenutzers für die Zertifikate mit privatem Schlüssel angegeben („Windows-My“). Der letzte Parameter ermöglicht eine zusätzliche Suchmöglichkeit nach CA-Zertifikaten, die die AIA-Erweiterung der Zertifikate nutzt. Diese Erweiterung ist z.B. für den OSM-WMS von Terrestris notwendig.

Alternativ ist es ab Java 11.0.18  auch möglich, auf Zertifikate im Computer anstatt des Benutzers zurückzugreifen. In den obigen Parametern ist dazu der Parameter trustStoreType auf „Windows-ROOT-LOCALMACHINE“ und der Parameter keyStoreType auf „Windows-MY-LOCALMACHINE“ zu ändern. Dann ist es nicht mehr notwendig, das Zertifikat mit dem privaten Schlüssel in den Benutzer des Apache Tomcat zu importieren, sondern das Zertifikat kann mit Mitteln des Active Directory dem Computer selbst zugewiesen werden. Die angesprochene Java-Version steht ab dem Frühjahrsrelease 2023 mit novaFACTORY und WEGA bereit.

Mit diesen Konfigurationsoptionen wird der integrierte Zertifikatsspeicher der Java JRE deaktiviert und nur noch auf die in Windows eingebauten Speicher zugegriffen. Wenn Sie Zertifikate in Java importiert haben, müssen diese damit in Windows importiert werden. Vorteil ist, dass die Zertifikate und Schlüssel auch ein Update der JRE überstehen, das den dortigen Zertifikatsspeicher überschreibt.

Nach einem Neustart des Apache Tomcat stehen die Weboberflächen von novaFACTORY und / oder WEGA damit unter HTTPS zur Verfügung.

Konfiguration in novaFACTORY

Wenn ein selbstsigniertes Zertifikat oder ein Zertifikat von einer nicht öffentlich beglaubigten CA verwendet werden soll, so sind in novaFACTORY noch verschiedene Konfigurationen anzupassen, damit dieses im Betrieb eingesetzt werden kann. Dies hängt damit zusammen, dass im Standardauslieferungszustand novaFACTORY auf die öffentlichen Beglaubigungsketten gesetzt wird, die solche Zertifikate nicht umfassen.

Zuerst sind in der Konfigurationsdatei rds.ini für die beiden Parameter „javaOpts“, „java64Opts“ und „pcmCmdOpts“ die Windows-CA-Speicher zu aktivieren. Dazu sind wieder die gleichen Parameter wie beim Apache Tomcat zuständig, die entsprechend ergänzt werden müssen.

-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Dcom.sun.security.enableAIAcaIssuers=true

Da hier kein Zertifikat eingesetzt, sondern nur gelesen werden soll, können die beiden Parameter für den Zertifikatsspeicher weggelassen werden. Es gilt auch das oben gesagte, das statt „Windows-ROOT“ auch „Windows-ROOT-LOCALMACHINE“ verwendet werden kann, wenn der CA-Speicher des Rechners anstatt des Benutzers verwendet werden soll.

Zusätzlich sind in der Konfigurationsdatei rosy.ini folgende Umgebungsparameter zu ergänzen.

CURL_CA_BUNDLE=<Pfad zum Stammzertifikatsbundle>
REQUESTS_CA_BUNDLE=<Pfad zum Stammzertifikatsbundle>

Diese beiden Variablen dienen dazu, der Programmiersprache Python beziehungsweise deren Modul Requests aktualisiertes CA-Bundle zur Verfügung zu stellen. Dieses CA-Bundle dient Python als CA-Speicher analog dem in Windows integrierten Speicher, der weiter oben für Java verwendet wird.

Das entsprechende CA-Bundle muss manuell erzeugt werden. Dazu ist zuerst ein aktuelles Bundle in Form der Datei „cacert.pem“ unter https://curl.se/docs/caextract.html herunterzuladen. Dabei handelt es sich um den aktuellen CA-Speicher des Mozilla Firefox, das im Rahmen des Curl-Projekts in einer standardisierten Form zur Verfügung gestellt wird. Bei der heruntergeladenen Datei handelt es sich um eine Textdatei, die die CA-Zertifikate im Format PEM bzw. RFC 1422 enthält.

Um die Datei für novaFACTORY zu erweitern, benötigen Sie Ihr selbstsigniertes Zertifikat oder das Root-Zertifikat ihre eignen CA in ebendiesem Format. Kopieren Sie den Inhalt dieser PEM-Datei an das Ende der zuvor heruntergeladenen „cacert.pem“ und speichern Sie die Datei auf dem novaFACTORY-Server. Der Pfad der so veränderten „cacert.pem“ muss abschließend in die beiden o.g. Parameter in der rosy.ini eingetragen werden.

Konfiguration in WEGA-AuthService

Wenn Sie den WEGA-AuthService mit einem Active Directory verbunden haben, dann kann auch dort die Transportverschlüsselung für die Kommunikation mit den Domänen Controllern konfiguriert werden. Dabei kommt im Gegensatz zur Kommunikation im Browser das Protokoll LDAPS zum Einsatz.

Ausgehend von obiger Konfiguration im Apache Tomcat ist nur eine Zeile in der Konfigurationsdatei shiro.ini des WEGA-AuthService zu ändern und eine Zeile hinzuzufügen.

ldapContextFactory.environment[java.naming.security.protocol] = ssl
ldapContextFactory.url = ldaps://<DC-Servername>:636

Die erste Zeile aktiviert dabei die Transportverschlüsselung für die Kommunikation mit dem Active Directory. Der Wert „ssl“ ist hier historisch zu sehen. Auf modernen Systemen wird tatsächlich ein Tunnel mittels TLS aufgebaut. In der zweiten Zeile ist die Adresse des Domain Controllers eingetragen. Wichtig sind hier der Protokollname „ldaps“ und der Port 636 über den anschließend die verschlüsselte Verbindung läuft.

Nach der Änderung der Konfiguration ist ein Neustart des Apache Tomcat notwendig. Da die Clients nicht direkt mit dem Active Directory kommunizieren, sind dort keine Änderungen notwendig.

Tipps & Tricks: HxMap 3D Editor

Der HxMap 3D-Editor bietet vielfältige Möglichkeiten der Erfassung und Überarbeitung von Dächern und diese sind auch entsprechend im Handbuch von Leica dokumentiert. Einige Einstellung sind aber etwas versteckt oder nicht auf den ersten Blick erkennbar und hier sollen Ihnen die folgenden Tipps helfen, typischen Stolperfallen beim Editieren mit dem 3D-Editor aus dem Weg zu gehen.

Gefilterten Dächern eine Ebene zuweisen

Im Normalfall weisen Sie, zum Beispiel nach dem Editieren, die Ebene einem Dach direkt über das Fenster Eigenschaften zu:

Genauso denkbar ist es aber, dass Sie einer gefilterten Objektliste eine bestimmte Ebene zuweisen wollen, z.B. allen Gebäuden mit der Dacherkennungsqualität 0. Gehen Sie dann am besten wie folgt vor:

1. Erstellen Sie eine Objektliste mit den gefilterten Dächern:

Erstellen Sie eine Objektliste mit den gefilterten Dächern

2. Markieren Sie alle Objekte in der Liste und selektieren Sie diese mit dem Button ‚Objekte auswählen‘:

2. Markieren Sie alle Objekte in der Liste und selektieren Sie diese mit dem Button ‚Objekte auswählen‘:

3. Für alle ausgewählten Dächer können Sie jetzt im Fenster Eigenschaften die neue Ebene übernehmen:

3. Für alle ausgewählten Dächern können Sie jetzt im Fenster Eigenschaften die neue Ebene übernehmen:

Ebenendarstellung steuern

Mit novaFACTORY 9.3.1.1 und HxMap 4.3 können Sie ab sofort einzelne Ebenen ein- oder ausblenden. Die Liste der verwendeten Ebenen wird dynamisch erzeugt und im Ebenenfenster innerhalb des geladenen 3D-Models angezeigt, d.h. es werden immer nur die im Modell verwendeten Ebenen dargestellt. Durch Ausblenden einzelner Ebenen können Sie die Darstellung entsprechend steuern, so zum Beispiel nur die oben auf Ebene 2 gelegten Dächer mit Dacherkennungsqualität 0 anzeigen:

Aufnahmefunktionen laden

Wenn Sie ein neues Dach erfassen wollen und die Möglichkeit, Objekte zu erfassen im RMT-Menü nicht auftaucht oder der Menüpunkt unter Bearbeiten ausgegraut ist, liegt das an fehlenden Aufnahmefunktionen.

Um diese zu Laden, müssen Sie im Menü Bearbeiten den Menüpunkt Define Preset… aufrufen:

Damit wird das Fenster mit den Aufnahmefunktionen geladen, welches aber in unserem Fall leer ist.

Um nun die Standard-Aufnahmefunktionen zu laden, müssen Sie auf den Schalter Rückstellen drücken, damit werden die Default-Aufnahmefunktionen geladen:

Nach Bestätigung der Einstellungen mit OK können ab sofort wieder alle in den Aufnahmefunktionen hinterlegten Dachformen erfasst werden.

Zugriff auf das Menü Eigenschaften ermöglichen

Unter Datei > Eigenschaften… können allgemeine Einstellungen des 3D-Editors vorgenommen werden, z.B. die Belegung der Tastenkombinationen angepasst werden. Es kann allerdings vorkommen, dass dieser Aufruf ausgegraut und damit nicht anwählbar ist.

Ursache dafür sind fehlende Schreibrechte im HxMap-Unterverzeichnis etc der HxMap-Installation. Um diesen Fehler zu beheben, sind 2 Schritte notwendig:

1. Kopieren Sie den Ordner <HxMap-Installation>\Workflow Manager\etc in ein Verzeichnis mit Schreibrechten.

2. Tragen Sie den neuen Pfad in der ini ein. Dafür einfach die Variable etc_folder neu setzen:

[General]
(...)
; The location of the etc folder (from the HxMap installation folder). Default is: etc
etc_folder=c:/Users/tak.MCM/HxMap/etc

Nach einem Neustart des 3D-Editors ist der Link zu den Einstellungen erreichbar.

KI-Leuchtturm-Projekt „FutureForest“ zum klimaangepassten Waldumbau wird mit 2.5 Millionen Euro gefördert

Das Projektteam

Unter der Leitung des Darmstädter Start-Ups wetransform GmbH sollen, zusammen mit den Projektpartnern FU Berlin, TU München sowie von ECOSOPH GmbH (München) und M.O.S.S. Computer Grafik Systeme GmbH (Taufkirchen), KI-Verfahren entwickelt werden, um Daten zum Zustand des Waldes zu erfassen und auszuwerten sowie Entscheidungsprozesse beim klimaangepassten Waldumbau zu unterstützen.

Unterstützt werden sie von assoziierten Partnern wie dem Thünen-Institut für Waldökosysteme, der forstlichen Versuchsanstalt Baden-Württemberg und das Julius-Kühn-Institut. Das auf drei Jahre ausgelegte Projekt wird vom Bundesministerium für Umwelt und Verbraucherschutz mit insgesamt 2.5 Millionen Euro gefördert.

Ziele des Forschungsvorhabens

Mit diesem Projekt gehen die Forschenden eine wichtige und dringende Herausforderung an: extreme Hitze, langanhaltende Trockenheit, Starkregen, Schädlingsbefall, aber auch Schadstoffe belasten den deutschen Wald.

Um Ökosystemleistungen wie die Nutz-, Schutz- und Erholungsfunktion unserer Wälder auch zukünftig zu erhalten, müssen Waldbesitzende und Forstfachleute in den nächsten Jahren weitreichende, waldbauliche Entscheidungen treffen:

  • Welche meiner Waldbestände sind besonders gefährdet?
  • Welche Baumarten können an diesem Standort zukünftig noch gedeihen?
  • Wie kann ich auch zukünftig Funktionen wie Artenvielfalt und den Erholungswert des Waldes sicherstellen?

Aufgrund der raschen Veränderung des Klimas können sie sich dabei nicht nur auf ihre Erfahrungen verlassen, sondern müssen alle zur Verfügung stehenden Daten kontinuierlich sammeln und auswerten können.

Ein Wald-Datenraum für ganz Deutschland

Konkret werden Daten zur Baumartenzusammensetzung und Vitalität, sowie Boden- und Klimadaten erfasst, vereinheitlicht und mit Hilfe der KI-Methoden analysiert. In einem weiteren Schritt werden für ganz Deutschland Waldumbaumaßnahmen im Klimawandel simuliert und analysiert.

Somit erhalten Waldbesitzende, Försterinnen und Förster, Consultants und Forschende Handlungsempfehlungen zu Bewirtschaftung und Baumartwahl, die an den jeweiligen Standort und den aktuellen Waldzustand angepasst sind. Da Verfahren der Erklärbaren KI zum Einsatz kommen, werden diese Empfehlungen nachvollziehbar und bewertbar sein. Damit wird ein aktiver Beitrag dazu geleistet, dass unsere Waldökosysteme den Herausforderungen des Klimawandels in Zukunft besser gewachsen sind.

Da KI-Methoden nur so gut wie die zu analysierenden Daten sein können, umfasst das Projekt auch die Errichtung eines Datenraums für Sensordaten, Fernerkundungsdaten, Klimadaten sowie Daten aus der Standortskartierung. Dieser Datenraum ermöglicht es allen Akteuren, ihre Daten miteinander zu teilen, ohne die Kontrolle und Souveränität über diese aufgeben zu müssen.

Allgemeine Informationen zur Förderinitiative

Die BMUV-Förderinitiative ist Teil des Fünf-Punkte-Programms „Künstliche Intelligenz für Umwelt und Klima“ und ein Beitrag zur Umsetzung der KI-Strategie der Bundesregierung mit dem Ziel, Deutschland und Europa zu einem führenden Standort für KI-Technologien zu machen und dabei eine verantwortungsvolle und gemeinwohlorientierte Entwicklung und Nutzung von KI voranzubringen. Das Bundesumweltministerium fördert damit Projekte, die Künstliche Intelligenz nutzen, um ökologische Herausforderungen zu bewältigen und beispielgebend sind für eine umwelt-, klima-, gesundheits- und naturgerechte Digitalisierung ("KI-Leuchttürme"). Weitere Informationen zur Initiative erhalten Sie unter

https://www.bmuv.de/themen/nachhaltigkeit-digitalisierung/digitalisierung/unsere-foerderinitiative-ki-leuchttuerme

Tipps & Tricks WEGA: Inbetriebnahme WEGA 10 Client und Parallelbetrieb mit WEGA 9 Client

Überblick

Der neue WEGA 10 Client kann problemlos parallel zum WEGA 9 Client betrieben werden. Beide Clienten nutzen die serverseitigen Komponenten von WEGA gemeinsam, also WEGA-RBA, -EMS, -PPS.

Der WEGA 10 Client ist der Web-Client der nächsten Generation auf Basis aktueller Web-Technologien:

  • react - JavaScript-Softwarebibliothek (Open Source): Grundgerüst für Ausgabe von User-Interface-Komponenten von Webseiten; Oberflächen auf Basis der react-Komponente "Material-UI"; Ablösung des „Dojo Toolkit“ (seit 2004 im Einsatz)
  • ArcGIS JS API 4 - JavaScript-Softwarebibliothek (Fa. ESRI): Erstellung von WebApps mit ArcGIS Inhalten u. Funktionen; Integration von 2D/ 3D, Abfrage von Layern und räumliche Analysen
  • Cesium: Realisierung der 3D Technologie (Open Source)

Auslieferung / Installation

Der WEGA 10 Client ist ab dem Herbstrelease 2021 Bestandteil des Lieferumfangs von WEGA und kann optional mitinstalliert werden. Dazu muss einfach die Komponente „WEGA-Client“ im WEGA Setup aktiviert werden.

Installation des WEGA 10 Clients im WEGA Setup
Installation des WEGA 10 Clients im WEGA Setup

Im Ergebnis werden zwei parallele Tomcat Servlets sowie zugehörige Verzeichnisse für die Web-Clienten installiert.

Parallel installierte WEGA-Clients
Parallel installierte WEGA-Clients

Konfiguration via WEGA RBA

Es erfolgt zunächst eine Basiskonfiguration mit einer Rolle sowie einer Datenquelle, damit der WEGA 10 Client grundsätzlich startet. Bei zusätzlich installiertem WEGA 10 Client sind insgesamt zwei Projekte vorhanden:

  • "wegabase" (=WEGA 9 Client)
  • "wegaclient" (= WEGA 10 Client)
RBA-Konfiguration der WEGA-Clients
RBA-Konfiguration der WEGA-Clients

Für das Projekt "wegaclient" ist zunächst eine Rolle zu erstellen sowie mindestens eine Datenquelle zu registrieren:

  • Auswahl des Projekts "wegaclient" -> Projekt bearbeiten
  • Karteireiter "Rollen" -> hinzufügen einer neuen Rolle (hier "Erfassung10")
WEGA RBA Rolle erstellen und Datenquelle registrieren
WEGA RBA Rolle erstellen und Datenquelle registrieren

Karteireiter "WMS" -> registrieren einer neuen WMS-Datenquelle

Registrierung der WMS-Datenquelle
Registrierung der WMS-Datenquelle

Nach der auch bei WEGA 9 bekannten Verfahrensweise wird die WMS-Datenquelle zur neuen Rolle als WMS-Datenquellengruppe registriert und anschließend in die Liste der Kartendienste eingetragen.

WMS-Datenquellgruppe registrieren
WMS-Datenquellgruppe registrieren

Nach Abschluss der RBA-Konfiguration sind die Änderungen freizuschalten.

Änderungen freischalten
Änderungen freischalten

Konfiguration Nutzerverwaltung

Der neu erstellten Rolle für den WEGA 10 Client muss ein Nutzer zugeordnet werden. Das Servlet muss danach neu gestartet werden. Beispiel für shiro.ini:

[users]
myUser = myUserPW, Erfassung10, nFUser

Aufruf WEGA Client

WEGA 9: http://localhost:8080/wega-base/
WEGA 10: http://localhost:8080/wega-client/

Fazit

Mit dem WEGA 10 Client ist der Web-Client der nächsten Generation verfügbar. Dies betrifft sowohl die überarbeitete Funktionalität mit fokussierter Nutzerführung, Homogenisierung der GUI bzgl. Diensttypen und Funktionalitäten, einheitlichem Sachdatenhandling und der Ablage/Portierung von Konfigurationen mittels Arbeitsprojekten, als auch die Nachhaltigkeit der verwendeten Frameworks. Der WEGA 10 Client kann parallel zum WEGA 9 Client betrieben werden. Die Administration sowie Konfiguration ist für beide Clienten mit der bereits bekannten GUI von WEGA-RBA möglich.

Tipps & Tricks novaFACTORY & WEGA – Transportverschlüsselung

Transportverschlüsselung?
Transportverschlüsselung stellt in der IT-Sicherheit die Verschlüsselung der Daten während dem Transport der Daten zwischen zwei Servern oder einem Server und dem Client dar. Dabei handelt es sich um eine Punkt-zu-Punkt-Verschlüsselung. Bekanntestes Beispiel für eine Transportverschlüsselung ist HTTPS, bei dem das eigentlich unverschlüsselte HTTP durch einen TLS-Tunnel verschlüsselt übertragen wird.

Im Folgenden wird die Einrichtung von HTTPS für novaFACTORY und WEGA unter dem Betriebssystem Windows beschrieben.

Voraussetzungen
Die Verwendung von HTTPS setzt die Benutzung eines X.509-Zertifikats für den Server voraus. Mit diesem Zertifikat weist sich der Server gegenüber dem Client aus. Auf Basis des Zertifikats kann der Client beim Aufbau der Verbindung beurteilen, dass die Kommunikation mit dem richtigen Server aufgebaut wird. Dazu muss das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) explizit für den abzusichernden Server ausgestellt worden sein. Zum Zertifikat gehört grundsätzlich ein serverspezifischer, privater Schlüssel, auf dessen Basis die Anfrage bei der CA zur Ausstellung des Zertifikats gestellt wurde.

Bei der Zertifizierungsstelle kann es sich sowohl um eine öffentliche oder eine interne Stelle handeln. Eine öffentliche CA stellt Zertifikate aus, die von jedem Browser als vertrauenswürdig eingestuft werden. Diese Zertifikate kommen in der Regel bei Servern zum Einsatz, die aus dem Internet erreichbar sein sollen. Eine interne CA stellt in der Regel Zertifikate aus, die nur im Behörden- oder Firmenintranet akzeptiert werden. Eine CA besitzt ebenfalls ein Zertifikat, dem explizit das Vertrauen ausgesprochen werden muss. Bei öffentlichen Stellen, sind diese in der Regel bereits im Browser bzw. im System hinterlegt. Bei internen CAs muss dies durch die Systemadministration z.B. durch das Active Directory erledigt werden.
Für Zertifikate gibt es verschiedene Dateiformate, in denen das Zertifikat und der dazugehörige Schlüssel vorliegen können. Unter Windows hat sich das Format „PKCS 12“ als Standard etabliert. Dieses ist an der Dateiendung „.p12“ oder „.pfx“ erkennbar. Dieses Format enthält das Zertifikat und den dazugehörigen Schlüssel in einer einzelnen Datei, womit die Einrichtung stark vereinfacht wird.

Zertifikatsspeicher in Windows
Unter Windows gibt es zwei Zertifikatsspeicher: Einen Speicher für den Benutzer und einen Speicher für den Computer. Im Computerspeicher sind normalerweise die beglaubigten Zertifikate der CAs hinterlegt. Im persönlichen Speicher des Benutzers hingegen werden die Zertifikate hinterlegt, für die der Anwender einen privaten Schlüssel besitzt. Aus Sicht von novaFACTORY und WEGA handelt es sich bei „dem Benutzer“ um die Betriebssystembenutzer, unter dem die Windowsdienste – speziell der Apache Tomcat – laufen.

Für die Einrichtung von HTTPS für novaFACTORY und WEGA muss daher zuerst das Zertifikat mit dem dazugehörigen Schlüssel in den persönlichen Zertifikatsspeicher des Dienstebenutzers importiert werden. Bei Vorliegen einer pfx-Datei passiert dies am einfachsten durch Doppelklick auf die Datei. Alternativ kann die Konfigurationskonsole „certmgr.msc“ als Dienstebenutzer gestartet und der Import manuell durchgeführt werden. Es ist wichtig, dass das Zertifikat in den persönlichen Speicher des Benutzers importiert wird.

Windows Zertifikat

Nach dem Import wird das Zertifikat in der Zertifikatskonsole von Windows angezeigt. Dabei wird der Servername angezeigt, für den das Zertifikat ausgestellt wurde. Dabei handelt es sich um den sogenannten Common Name (CN). Dieser wird später noch benötigt.

Konfiguration in Apache Tomcat
Da sowohl novaFACTORY als auch WEGA die Servlet Engine Apache Tomcat für die Auslieferung der Weboberfläche benutzen, erfolgt die eigentliche Einrichtung von HTTPS in selbiger Software. Dazu ist in der Konfigurationsdatei conf\server.xml in der Installation des Apache Tomcat folgender „Connector“ zu konfigurieren:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
  sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
  maxThreads="150"
  SSLEnabled="true"
  scheme="https"
  secure="true"
  keyAlias="<CN_des_Zertifikats>"
  keystoreFile=""
  keystorePass=""
  keystoreType="Windows-My"
  clientAuth="false"
  sslProtocol="TLS"
  sslEnabledProtocols="TLSv1.2"
  keepAliveTimeout="200000" />

Beim Parameter keyAlias ist der Common Name des Zertifikats einzutragen. Der keystoreType „Windows-My“ stellt den persönlichen Zertifikatsspeicher des Dienstebenutzers dar, in den das Zertifikat vorher importiert wurde. Die leeren Parameter zum Zertifikatsspeicher sind aufgrund eines Bugs notwendig. Die aktivierten Protokolle („sslEnabledProtocol“) sind mit der IT-Administration abzustimmen. Beim Einsatz moderner Browser kann die o.a. Konfiguration verwendet werden.
Zusätzlich muss die Java-Ausführungsumgebung für den Apache Tomcat so angepasst werden, dass die Windows-Zertifikatsspeicher verwendet werden können. Die Konfiguration erfolgt im Tomcat-Monitor im Reiter „Java“. Dort müssen folgende Parameter unter „Java Options“ ergänzt werden

-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.keyStoreProvider=SunMSCAPI
-Djavax.net.ssl.keyStoreType=Windows-MY
-Dcom.sun.security.enableAIAcaIssuers=true

Hier wird festgelegt, dass für die beglaubigten CA-Zertifikate der Zertifikatsspeicher des Computers verwendet wird („Windows-ROOT“). Zusätzlich wird nochmals der Zertifikatsspeicher des Dienstebenutzers für die Zertifikate mit privatem Schlüssel angegeben („Windows-MY“). Der letzte Parameter ermöglicht eine zusätzliche Suchmöglichkeit nach CA-Zertifikaten, die die AIA-Erweiterung der Zertifikate nutzt. Diese Erweiterung ist z.B. für den OpenStreetmap-WMS von Terrestris notwendig.

Mit diesen Konfigurationsoptionen wird der integrierte Zertifikatsspeicher der Java JRE deaktiviert und nur noch auf die in Windows eingebauten Speicher zugegriffen. Wenn Sie Zertifikate in Java importiert haben, müssen diese damit in Windows importiert werden. Vorteil ist, dass die Zertifikate und Schlüssel auch ein Update der JRE überstehen, das den dortigen Zertifikatsspeicher überschreibt.
Nach einem Neustart des Apache Tomcat stehen die Weboberflächen von novaFACTORY und / oder WEGA damit unter HTTPS zur Verfügung.

WEGA-AuthService
Wenn Sie den WEGA-AuthService mit einem Active Directory verbunden haben, dann kann auch dort die Transportverschlüsselung für die Kommunikation mit den Domänen Controllern konfiguriert werden. Dabei kommt im Gegensatz zur Kommunikation im Browser das Protokoll LDAPS zum Einsatz.

Ausgehend von obiger Konfiguration im Apache Tomcat ist nur eine Zeile in der Konfigurationsdatei shiro.ini des WEGA-AuthService zu ändern und eine Zeile hinzuzufügen.

ldapContextFactory.environment[java.naming.security.protocol] = ssl
ldapContextFactory.url = ldaps://<DC-Servername>:636

Die erste Zeile aktiviert dabei die Transportverschlüsselung für die Kommunikation mit dem Active Directory. Der Wert „ssl“ ist hier historisch zu sehen. Auf modernen Systemen wird tatsächlich ein Tunnel mittels TLS aufgebaut. In der zweiten Zeile ist die Adresse des Domain Controllers eingetragen Wichtig sind hier der Protokollname „ldaps“ und der Port 636 über den anschließend die verschlüsselte Verbindung läuft.

Nach der Änderung der Konfiguration ist ein Neustart des Apache Tomcat notwendig. Da die Clients nicht direkt mit dem Active Directory kommunizieren, sind dort keine Änderungen notwendig. Wenn der WEGA-AuthService per HTTPS erreichbar ist, kann aber dort die URL zum Dienst entsprechend angepasst werden.

Schlusswort
Die Einrichtung einer verschlüsselten Kommunikation ist in modernen Infrastrukturen problemlos möglich. Dabei können sowohl öffentliche Zertifikate für das Internet als auch private Zertifikate im Intranet zum Einsatz kommen.
Wenn Sie Fragen haben, kommen Sie gerne auf uns zu.