Overview of all update notes

4.21

Breaking change for queries used in definition query obligations (since 4.21.1)

Policies allow to define definition query obligations to limit access to features of a layer. Definition query obligations require you to define a query that may contain references to attributes of the requesting user like this:

Referencing the user attribute 'customattribute0' in a query
LEVEL <= ${user.customattribute0}

security.manager now checks that user attributes only resolve to SQL literal values when they are replaced in query expressions. By default, non-literal values are rejected and will cause a request failure.

If you have to accept user attribute values resolving to anything else than SQL literals, you must now explicitly mark them as insecure inside the query. Otherwise user requests will fail with errors. The following example demonstrates how to flag a user attribute that should be replaced with the provided value without any checks.

Accepting any kind of user attribute value
LEVEL <= ${user.customattribute0;insecure}

4.20

Unresolved include directive in modules/ROOT/pages/releasenotes/update-overview_en.adoc - include::4.21/_update-notes_en.adoc[]

4.19

Remove the Access Logging configuration

Access logging was an optional feature and is not part of the product anymore. If you know that access logging is not activated you can skip the following note.

Check if the feature is active by opening the module files in the [INSTALL_FOLDER]/webapp/wss/WEB-INF/classes/enforcementpoint-modules. If the following entry is not present, nothing has to be done.

  • <Interceptor class="de.conterra.suite.security.interceptor.logging.LoggingInterceptor">…​</Interceptor>

In case you found this entry please remove the element from all module files. Delete the file [INSTALL_FOLDER]/webapp/wss/WEB-INF/classes/log4j.xml if present.

Changed Rollout Folder Structure

Please note that the folder structure of the product delivery has changed.

4.18

Configuration Changes

The properties security.responseHeaders.common and security.responseHeaders.html were added to allow the use of additional HTTP headers.

The property security.allowed.ipranges was added to define IP address ranges that are allowed to access secured endpoints.

Please refer to the section Security Settings for further details.

Other Changes

Tomcat 8.5 and Java 8 are no longer supported.

4.17

Configuration Changes

  • The configuration properties db.driver.class and db.hibernate.dialect are not supported any more. Remove these properties from [INSTALL_FOLDER]/data/application.properties. Instead you have to add the new configuration property db.type and set its value to sqlserver, postgresql, or oracle, according to the database system you use. More information can be found at Database Connection.

  • The configuration property policymgr.default.wfs.geometryclasses was removed. This means that you cannot configure, which geometry types are available for spatial obligations, anymore. Instead you can only choose features having polygon geometries when defining spatial obligations. If you are using policymgr.default.wfs.geometryclasses in [INSTALL_FOLDER]/data/application.properties, you can safely delete that entry.

Other Changes

  • The database table WPOS_MAILS is not used any more and can be deleted.

  • Please note that the upcoming minor version of security.manager Enterprise Edition (4.18) will not support Tomcat 8.5 and Java 8 anymore.

4.16

Configuration Changes

The set of allowed values for the already existing property policymgr.default.wfs.geometryclasses changed due to the update of 3rd party libraries. It controls which feature types are available when selecting the geometries used for spatial obligations. If you added this property to your application.properties file, you need to replace its values' prefix to org.locationtech.jts.geom. A valid value is org.locationtech.jts.geom.MultiPolygon, org.locationtech.jts.geom.Polygon, for example.

Other Changes

  • WFS 1.0.0 is not supported as data source for spatial obligation geometries any more. WFS 1.1.0 is now the required.

  • Some misspelled message keys have been changed in the internationalization files of the security.manager language files. If you added languages files to the existing "en" (default) or "_de" files, you might need to update the message keys accordingly. The following keys were changed in the respecting file:

    • [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

Configuration Changes

wss.arcgistoken.support.enabled

This property has been removed. ArcGIS Token Authentication support is always enabled as of now.

security.ssl.trustAny

New property to toggle certificate validation.

security.sso.cookie.secure

New property to toggle secure flag on SSO cookie issued by security.manager

security.sso.cookie.samesite

New property to toggle sameSite flag on SSO cookie issued by security.manager

cors.allowed.origins

New property to define, from which origins security.manager can be used via CORS

cors.any.origins

New property to define that security.manager can be used via CORS from any origin Do not use it in production environments.

4.14

To update from 4.13 to 4.14, you do not need to follow any update notes.

4.13

Database Changes

With this version of security.manager support for the following versions of database systems has been marked as deprecated:

  • PostgreSQL 8.4

  • Microsoft SQL Server 2008 and 2014

  • Oracle 10g

Support for those versions is dropped in the next version of security.manager.

4.12

Updating Prerequisites

  • A database user with according grants to create tables and indexes

  • A database client to run an SQL script

  • Access to the SQL migration script available in [UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.11-4.12

Update Database Schema

An update from a version prior to 4.12.0 requires the creation of a new table.

  1. Stop Tomcat running security.manager

  2. As a database user with according grants, run the script [UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.11-4.12/[DBMS]-schema-changes.sql as appropriate to your actual DBMS type.

  3. Check if the table was created in the schema that contains the other security.manager tables.

  4. Start Tomcat

4.11

Configuration Changes

security.user.username.regexpr

The default value of the configuration property security.user.username.regexpr was changed (see System hardening). Before this change, usernames were allowed to contain spaces, which is prohibited now. If you override this property in your application.properties file, adopt this behavior.

Database Changes

This section describes the required update of an existing security.manager database to version 4.11. These instructions apply if you are updating from any security.manager version starting from 4.4.0 up to 4.11.1.

The existing database schema used by this product as well as its tables and data can still be used. The schema, however, needs to be updated as described in the following.

Updating Prerequisites

  • A database user with grants to create tables and indexes

  • A database client to run an SQL script

  • Access to the SQL migration script available in [UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.4-4.11

Update Database Schema

An update from a version prior to 4.11.0 requires the creation of a new table and an index for that table.

  1. Stop Tomcat running security.manager

  2. As a database user with according grants, run the script [UNPACK_FOLDER]/security.manager/software/sql/upgrade/4.4-4.11/[DBMS]-schema-changes.sql as appropriate to your actual DBMS type.

  3. Check if the table and index was created in the schema that contains the other security.manager tables.

  4. Start Tomcat

4.10

To update from 4.9 to 4.10, you do not need to follow any update notes.