Überblick aller Update-Hinweise

4.21

Grundlegende Änderungen für Abfragen in Definition-Query Obligationen (ab 4.21.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:

Abfrage mit Verweis auf das Attribut 'customattribute0'
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:

Ungeprüfte Übernahme des Wertes von 'customattribute0'
LEVEL <= ${user.customattribute0;insecure}

4.20

Für das Update von 4.19 auf 4.20 müssen Sie keine Update-Hinweise beachten.

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.

Veränderte Rollout-Ordner-Struktur

Bitte beachten Sie, dass sich die Ordner-Struktur der Produktauslieferung geändert hat.

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.

Andere Änderungen

Tomcat 8.5 und Java 8 werden nicht mehr unterstützt.

4.17

Konfigurationsänderungen

  • Die Konfigurationseigenschaften db.driver.class und db.hibernate.dialect werden nicht mehr unterstützt. Entfernen Sie diese Eigenschaften aus [INSTALL_FOLDER]/data/application.properties. Stattdessen müssen Sie die neue Konfigurationseigenschaft db.type hinzufügen und deren Wert entsprechend dem von Ihnen verwendeten Datenbanksystem auf sqlserver, postgresql oder oracle 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 Eigenschaft policymgr.default.wfs.geometryclasses in der Datei [INSTALL_FOLDER]/data/application.properties verwenden, können Sie den Eintrag löschen.

Andere Änderungen

  • Die Datenbanktabelle WPOS_MAILS wird nicht mehr verwendet und kann gelöscht werden.

  • Beachten Sie, dass security.manager Enterprise Edition mit der nächsten Minor Version Tomcat 8.5 sowie Java 8 voraussichtlich nicht mehr unterstützen wird.

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 Ihre application.properties eingetragen haben, müssen Sie die Präfixe der Werte anpassen. Der neue Präfix lautet org.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.14

Für das Update von 4.13 auf 4.14 müssen Sie keine Update-Hinweise beachten.

4.13

Datenbankänderungen

Diese Version des security.manager ist die letzte, mit der folgende Versionen von Datenbank-Management-Systemen unterstützt werden:

  • PostgreSQL 8.4

  • Microsoft SQL Server 2008 and 2014

  • Oracle 10g

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.

  1. Stoppen Sie den Tomcat, in dem der security.manager betrieben wird.

  2. 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)

  3. Prüfen Sie, ob die Tabelle in dem Schema angelegt wurde, in dem sich die übrigen security.manager Tabellen befinden.

  4. 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.

  1. Stoppen Sie den Tomcat, in dem der security.manager betrieben wird.

  2. 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)

  3. Prüfen Sie, ob die Tabelle und der Index in dem Schema angelegt wurden, in dem sich die übrigen security.manager Tabellen befinden.

  4. Starten Sie den Tomcat.

4.10

Für das Update von 4.9 auf 4.10 müssen Sie keine Update-Hinweise beachten.