Überblick aller Update-Hinweise
4.22
Update Tomcat und Java
Bitte aktualisieren Sie Ihre Tomcat-Instanz auf Version 10. Falls Sie bislang Java 11 benutzt haben, aktualisieren Sie dies bitte auf Version 17 oder 21.
Grundlegende Änderungen für Abfragen in Definition-Query Obligationen (ab 4.22.1)
In Rechten können Sie Definition-Query Obligationen definieren, um den Zugriff auf Objekte eines Layers zu beschränken. Bei Definition-Query Obligationen müssen Sie eine Abfrage definieren, die Verweise auf Attribute der anfragenden Person enthalten kann:
LEVEL <= ${user.customattribute0}
security.manager überprüft nun, dass Attribute nur durch SQL-Literalwerte ersetzt werden, wenn sie in Abfragen eingesetzt werden. Standardmäßig werden nicht-literale Werte zurückgewiesen und führen zu einem Fehler bei der Dienstanfrage.
Wenn Sie Attributwerte akzeptieren müssen, die auch durch etwas anderes als SQL-Literale ersetzt werden, müssen Sie sie jetzt innerhalb der Abfrage ausdrücklich als insecure
kennzeichnen.
Andernfalls werden Anfragen mit einer Fehlermeldung fehlschlagen.
Das folgende Beispiel zeigt, wie Sie ein Attribut kennzeichnen, das ohne jegliche Prüfung durch den angegebenen Wert ersetzt werden soll:
LEVEL <= ${user.customattribute0;insecure}
4.19
Entfernen der Konfiguration zur Zugriffsprotokollierung
Die Zugriffsprotokollierung war ein optionales Feature und ist nicht mehr Bestandteil des Produktes. Falls Sie die Protokollierung nicht aktiviert haben, müssen Sie nichts weiter beachten.
Um festzustellen, ob das Feature aktiv ist, überprüfen Sie die Moduldateien im Verzeichnis [INSTALL_FOLDER]/webapp/wss/WEB-INF/classes/enforcementpoint-modules
.
Falls der folgende Eintrag nicht vorhanden ist, brauchen Sie nichts weiter tun.
-
<Interceptor class="de.conterra.suite.security.interceptor.logging.LoggingInterceptor">…</Interceptor>
Falls dieser vorhanden ist, entfernen Sie den Eintrag bitte vollständig.
Löschen Sie die Datei [INSTALL_FOLDER]/webapp/wss/WEB-INF/classes/log4j.xml
, falls diese vorhanden sein sollte.
4.18
Konfigurationsänderungen
Die Konfigurationseigenschaften security.responseHeaders.common
und security.responseHeaders.html
wurden hinzugefügt, um zusätzliche HTTP-Header setzen zu können.
Die Konfigurationseigenschaft security.allowed.ipranges
wurde eingeführt, um IP-Bereiche zu definieren, denen der Zugriff auf abgesicherte Endpunkte erlaubt ist.
Nähere Informationen finden Sie im Kapitel Sicherheitseinstellungen.
4.17
Konfigurationsänderungen
-
Die Konfigurationseigenschaften
db.driver.class
unddb.hibernate.dialect
werden nicht mehr unterstützt. Entfernen Sie diese Eigenschaften aus[INSTALL_FOLDER]/data/application.properties
. Stattdessen müssen Sie die neue Konfigurationseigenschaftdb.type
hinzufügen und deren Wert entsprechend dem von Ihnen verwendeten Datenbanksystem aufsqlserver
,postgresql
oderoracle
setzen. Mehr Informationen finden Sie unter Datenbankverbindung. -
Die Konfigurationseigenschaft
policymgr.default.wfs.geometryclasses
wurde entfernt. Die Geometrietypen, die für eine räumliche Obligation verwendet werden können, lassen sich nun nicht mehr konfigurieren. Stattdessen lassen sich im Rahmen der Definition von räumlichen Obligationen ausschließlich Features polygonaler Feature-Typen auswählen. Sollten Sie die Eigenschaftpolicymgr.default.wfs.geometryclasses
in der Datei[INSTALL_FOLDER]/data/application.properties
verwenden, können Sie den Eintrag löschen.
4.16
Konfigurationsänderungen
-
Für die bereits seit einigen Versionen unterstützte Konfigurationseigenschaft
policymgr.default.wfs.geometryclasses
ändern sich mit diesem Release die erlaubten Konfigurationswerte. Wenn Sie diese Eigenschaft in Ihreapplication.properties
eingetragen haben, müssen Sie die Präfixe der Werte anpassen. Der neue Präfix lautetorg.locationtech.jts.geom
, so dass ein gültiger Wert zum Beispiel folgendermaßen lauten würde:org.locationtech.jts.geom.MultiPolygon, org.locationtech.jts.geom.Polygon
.
Andere Änderungen
-
WFS 1.0.0 kann nicht mehr als Datenquelle für räumliche Berechtigungsgeometrien verwendet werden. Voraussetzung ist nun die Nutzung eines WFS mit Unterstützung für WFS 1.1.0.
-
Einige falsch geschriebene Schlüssel in den Internationalisierungsdateien wurden korrigiert. Wenn weitere Sprachdateien hinzugefügt wurden, so müssen folgende Schlüssel erneuert werden:
-
[SECMAN_INSTALL]/webapp/administration/WEB-INF/lib/ct-security-administrator-base-4.16.0.jar/securityAdminResources[_de].properties
error.common.exceute.cmd
→error.common.execute.cmd
-
[SECMAN_INSTALL]/webapp/administration/WEB-INF/lib/ct-security-administrator-base-4.16.0.jar/wmtsAdminResources[_de].properties
wmts.error.update.decription
→ This property was removed -
[SECMAN_INSTALL]/webapp/administration/WEB-INF/lib/ct-security-administrator-base-4.16.0.jar/genericLicenseAdminResources[_de].properties
license.generic.error.update.decription
→license.generic.error.update.description
-
4.15
Konfigurationsänderungen
- wss.arcgistoken.support.enabled
-
Diese Konfigurationsoption wurde entfernt. ArcGIS Token Authentication-Unterstützung ist jetzt immer aktiviert.
- security.ssl.trustAny
-
Neue Konfigurationsoption, um die Zertifikatvalidierung zu aktivieren.
- security.sso.cookie.secure
-
Neue Konfigurationsoption, um das Setzen der secure-Eigenschaft für das SSO Cookie, das vom security.manager ausgestellt wird, zu aktivieren.
- security.sso.cookie.samesite
-
Neue Konfigurationsoption, um das Setzen der sameSite-Eigenschaft für das SSO Cookie, das vom security.manager ausgestellt wird, zu aktivieren.
- cors.allowed.origins
-
Neue Konfigurationsoption, welche definiert, welche Origins security.manager über CORS anfragen dürfen
- cors.any.origins
-
Neue Konfigurationsoption, welche definiert, dass CORS-Anfragen an security.manager aus beliebigen Origins erlaubt sind. Verwenden Sie diese Option nicht in Produktionsumgebungen.
4.12
Voraussetzungen für die Aktualisierung
-
Datenbankbenutzer mit Berechtigungen zur Erzeugung von Tabellen und Indizes
-
Datenbank-Werkzeug zur Ausführung eines SQL-Skriptes
-
Zugang zum SQL-Skript in [UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.11-4.12
Datenbankschema aktualisieren
Die Aktualisierung einer Version vor 4.12.0 besteht aus der Erzeugung einer neuen Tabelle.
-
Stoppen Sie den Tomcat, in dem der security.manager betrieben wird.
-
Führen Sie das folgende Skript mit einem berechtigten Datenbanknutzer aus:
[UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.11-4.12/[DBMS]-schema-changes.sql
(Wählen Sie das zum DBMS passende Skript) -
Prüfen Sie, ob die Tabelle in dem Schema angelegt wurde, in dem sich die übrigen security.manager Tabellen befinden.
-
Starten Sie den Tomcat.
4.11
Konfigurationsänderungen
- security.user.username.regexpr
-
Der Standard-Wert der Konfigurationsoption
security.user.username.regexpr
wurde geändert (siehe Systemhärtung). Vor diesen Änderungen war es erlaubt, Nutzernamen mit Leerzeichen zu verwenden. Dies ist nun nicht mehr erlaubt. Wenn Sie den Standardwert überschreiben, empfehlen wir, dieses Regel zu übernehmen.
Datenbankänderungen
In diesem Kapitel werden die Schritte für die zwingend erforderliche Aktualisierung einer bestehenden security.manager Datenbank auf Version 4.11 beschrieben.
Das Datenbankschema sowie die dort enthaltenen Tabellen und Daten können weiter verwendet werden, allerdings muss das Datenbankschema wie unten beschrieben aktualisiert werden.
Voraussetzungen für die Aktualisierung
-
Datenbankbenutzer mit Berechtigungen zur Erzeugung von Tabellen und Indizes
-
Datenbank-Werkzeug zur Ausführung eines SQL-Skriptes
-
Zugang zum SQL-Skript in
[UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.4-4.11
Datenbankschema aktualisieren
Die Aktualisierung einer Version vor 4.11.0 besteht aus der Erzeugung einer neuen Tabelle und eines zugehörigen Index.
-
Stoppen Sie den Tomcat, in dem der security.manager betrieben wird.
-
Führen Sie das folgende Skript mit einem berechtigten Datenbanknutzer aus:`[UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.4-4.11/[DBMS]-schema-changes.sql` (Wählen Sie das zum DBMS passende Skript)
-
Prüfen Sie, ob die Tabelle und der Index in dem Schema angelegt wurden, in dem sich die übrigen security.manager Tabellen befinden.
-
Starten Sie den Tomcat.