Release Notes 4.22

You can now run security.manager on Tomcat 10 and Java 21. Therefore, support for Tomcat 9 and Java 11 is dropped. Please refer to the system requirements for further details.

From this version on, security.manager will no longer require a license file. Already installed license files can be removed.

Please update you Tomcat instance to version 10. In case you have been using Java 11 so far, please update to version 17 or 21.

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:

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.

Google has announced that support for 'Third-Party Cookies' in Google Chrome will be phased out by the end of 2024. This can be read at Update on the plan for phase out of third party cookies on chrome . The security.manager uses 'Third-Party Cookies' for user authentication when integrating protected services into external websites via the /sso endpoint. An example of this is the integration of security.manager protected services into ArcGIS Online via the /sso endpoint. In this case, communication takes place via the browser from an external website (www.arcgis.com) to the security.manager (e.g. security.example.com). We recommend switching to the agstoken authentication method, as it does not rely on Third-Party Cookies.

Additionally, we recommend disabling the use of Third-Party Cookies by setting the option security.sso.cookie.samesite=true.

To visualize changes from other users / systems in the tree displayed on the left side of the Administrator interface, simply select the root node of the tree and the reload tree button.

When two rights are defined that are applicable to a user, it is important to determine the correct sequence in the Security Manager administrator (in the dialog "Policy Set"). For example: It is a legal definition that all users are granted access to a WMS, but with copyright restrictions. A user might be a member of a user group "registered" where another piece of legislation for this WMS defines that the access granted WITHOUT Copyright constraint. Both of these rights are valid if the user group "registered" accesses the WMS. In this case, the first policy in the list is used. To prevent the users of the group "registered" from seeing the same copyright notice as unregistered users, this right must be uppermost in the administration set.

The security.manager does not distinguish feature types which have the same name but different namespaces, for example x:city is recognized as equal to y:city. Therefore It is required that feature types have unique names.

Care must be taken of the accuracy and stability of the displayed feature IDs when using them to create spatial obligations. Feature IDs of the form fid-4d0f905b_126c17decf6_-7d52 indicate internal auto-generated feature-IDs, which change with each new request and thus can not be used for referencing features. If feature IDs change with each request to the WFS, this is due to a lack of feature IDs in the WFS response. The configuration of the WFS service needs to be reviewed so that stable feature identifiers are delivered correctly.

Alternative 1: Create the folder prior to installation.

Alternative 2: During an installation, the context.xml files are stored in the [SECMAN_INSTALL]/postinstall directory. They can be simply copied into the directory [TOMCAT_HOME]/conf/Catalina/localhost. In the installation type container-managed database, the xml files with the suffix -jndi.xml need to be copied.

The following files must be copied:

Depending on their configuration, ArcGIS Server services sometimes use unofficial EPSG codes for Gauß-Krüger reference systems. These are internally mapped to the corresponding official EPSG codes, The following mappings are used:

This mapping is only applied to protected services. For the definition of spatial restrictions via a WFS, only official EPSG codes are supported.

ArcGIS Server WFS do not support multipolygons or more than one polygon within a spatial filter. Thus, spatial restrictions cannot be applied if more than one geometry are selected for this restriction or if the incoming request already contains a spatial filter.

When using a Safari browser, repeated logins might be required. To avoid this, change the security settings to always accept cookies.

Support for spatial obligations with ArcGIS Server cached MapServer instances requires to use the cache storage format "Compact". If any other storage format is used spatial obligations are ignored.

As described in "Filtering features using the layerDefs parameter in WMS requests" , layerDefs has a lower priority when SLD or SLD-BODY parameter is present and is ignored.

URLs of secured MapServer services have to be used with ags-relay URL schema:

The ArcGIS Geocoding Server does not support HTTP chunked transfer encoding. If you want to secure that service, chunked encoding must be manually disabled in the settings file of security.manager. To do that, make sure that the property http.client.chunking in the application.properties file is set to false (SECMAN-658).

ArcGIS for INSPIRE Feature Download Services do not support Polygons in queries with spatial filters. Hence for a spatial restriction is not possible.

ArcGIS for INSPIRE Feature Download Services might create invalid responses if a GetFeature request references multiple stored queries or contains multiple query elements.

Access to protected ArcGIS Server-based WFS might fail when spatial obligations or OGC Filter Expression obligations are in play. Affected are ArcGIS Server versions 10.3 and higher, which don’t properly support the OGC specifications. Depending on the WFS versions requested by the client (1.0.0, 1.1.0, 2.0.0) you might encounter different error messages.

The WFS 1.0.0 and 1.1.0 implementations of UMN MapServer do not support the GML versions as stated in the specifications. Because of this spatial obligations and obligations with OGC Filter Expressions are not supported.

For ArcGIS Server WFS services, DescribeFeatureType requests without listing actual FeatureTypes might lead to exceptions, if this WFS provides many FeatureTypes, or the FeatureTypes have long names.

If a protected service (for example a map service) contains a huge number (> 60) of resources (for example layers) performance of service requests decreases noticeably. Consider splitting up such mapping services into several services.

When trying to load a protected service into ArcMap or ArcGIS Pro via httpauth login fails although correct credentials were specified if username or password contain non-ASCII characters like german umlauts.

When the webadaptor for ArcGIS Server is named "rest" or "services" like http://[HOST]/rest/rest/services or http://[HOST]/services/rest/services, the ArcGIS Server cannot be protected by security.manager. When named "rest", no policies can be created, when named "services" policies cannot be enforced.

In combination with spatial obligations, the MapServer /find operation may not return all expected features. Large result sets of the /find operation will be capped if they exceed the server side limit of features to return. Spatial obligations will only be applied to the capped result set.