Security Settings

security.keystore.location

Path to the keystore file that contains the key pair for validating and generating digital signatures.

security.keystore.passwd

Password for accessing the keystore.

security.keystore.key.alias

Alias of certificates or private key.

security.keystore.key.passwdautocompletion.enabled

Password for accessing private key.

security.pdp.service.url

URL to the Policy Decision Point; this is normally the URL to the Administrator web application with PDP appended at the end.

Example: http://localhost:8080/administration/PDP

security.was.service.url

URL to the authentication service (WAS), ; this is normally the URL to the Administrator web application with WAS appended at the end

Example: http://localhost:8080/administration/WAS

security.was.cache.timeout

Defines the cache time in seconds for user information. The configuration option applies to /wss and /gateway application. The default value is 300 seconds = 5 minutes.

Example: 300

security.authn.token.allowedOffset

Defines the maximal time difference a timestamp of a trusted application request for user information may have, at the time it is processed. This allows to cater for clock differences when different hosts are involved, but also for delayed request processing at the target host.

Default: 30000

Since version 4.21

security.login.service.url

URL to the Single Sign-On service; this is normally the URL to the Administrator web application with start.do appended at the end

Example: http://localhost:8080/administration/start.do

security.allowed.hostnames

A comma-separated list of hostnames, which are allowed to access protected endpoints (localhost is automatically allowed)

security.allowed.ipranges

A comma-separated list of IP address ranges, from which access to protected endpoints is allowed. Supported are single addresses (172.12.25.84) or subnet masks (172.12.25.0/24) or intervals (172.12.25.10-172.12.25.20). IPv6 addresses are supported, too.

Example: 172.12.25.84,172.12.25.0/24,172.12.25.10-172.12.25.20

security.password.history.capacity

Sets the number of passwords to be stored in user’s history.

security.password.history.check.count

Sets the number of not allowed passwords in user’s password history, when he tries to change his password. For example a value of 3 means that a new password has to differ from the last 3 passwords in password history.

security.password.changePause

Sets the minimum of time between two password changes of a user. Possible time units are s(econds), m(inutes), h(ours) and d(ays), for example 3h or 10s.

security.user.login.lock.username

Set true or false to enable or disable login locking to protect from brute-force password attacks. If set to true, login attempts for a username or IP address are blocked after more than 3 consecutive login failures (such as wrong password or non-existing username) or more than 10 consecutive login failures from the same IP address. Access is blocked for 30 minutes by default. The maximum number of consecutive failures as well as the blocking period can be changed in the application’s spring-security-config.xml file.

security.user.login.log

Set true or false to enable or disable logging of login attempts into a separate log file. If enabled the log file is written to [TOMCAT_HOME]/logs/ct-security-administration-webapp-login_audit.log by default.

security.user.usermail.regexpr

The regular expression used to validate an email address that is specified when a user registers, changes his profile, or when a new user is created by the administrator.

security.user.username.regexpr

The regular expression used to validate a username when a user registers.

Example: [a-zA-Z0-9\00f6\00e4\00fc\00c4\00d6\00dc_]* (Permits all letters, numbers and German umlauts)

security.user.userpwd.validate

Whether to validate the entered password against a regular expression. Allowed values: true, false

security.user.userpwd.regexpr

The regular expression validating the password that is set or changed by a user or the administrator.

Prepend every backslash (\) in the regular expression with an additional backslash to escape it. For example, the regular expression \w{8,}` has to be specified as \\w{8,}.

Regular expression examples
Regular Expression
(\ already escaped)		 Meaning

\\w{8,}

Any password that has at least 8 alphanumeric characters (including _).

^[A-Za-z]\\w{6,}[A-Za-z]$

Any password that has at least 8 alphanumeric characters and begins and ends with a letter.

^\\w*(?=\\w*\\d)(?=\\w*[a-z])(?=\\w*[A-Z])\\w*$

Any password of arbitrary length and containing at least one lowercase and one uppercase letter.

^.*(?=.{10,})(?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%&=]).*$

Any password having at least 10 characters and containing at least one lowercase and one uppercase letter, as well as a number and a special character. Permitted special characters are @, #, $, %, &, =.
security.user.userpwd.validationkey.#

Used to create an explanation out of predefined text blocks for the currently defined password validation regular expression. You can add up to 5 explanations. Replace the # character with a number between 0 and 4 for each explanation. The value for this property is one of the following:

Error Massage Key Corresponding Explanation Message

errors.user.passwordformat.minimalLength, <minimalLength>

The password must have at least <minimalLength> characters.

errors.user.passwordformat.uppercaseCharReq

An uppercase character is required.

errors.user.passwordformat.uppercaseCharNotReq

An uppercase character is not required.

errors.user.passwordformat.lowercaseCharReq

A lowercase character is required.

errors.user.passwordformat.lowercaseCharNotReq

A lowercase character is not required.

errors.user.passwordformat.specialCharReq

A special character is required.

errors.user.passwordformat.specialCharNotReq

A special character is not required.

errors.user.passwordformat.permittedSpecialChars, <List of special characters>

Permitted special characters are <List of special characters>

Note that the minimalLength and the permittedSpecialChars keys require an additional argument which as appended to the value, separated by a comma. Example: security.user.userpwd.validationkey.0=errors.user.passwordformat.minimalLength,8 (Here, an explanation is defined that says that the minimal length of the password must be 8 characters.)

security.sso.cookie.name

Name used for the domain single sign-on cookie.

security.sso.cookie.domain

Name of the domain at which the domain single sign-on cookie is stored. It must not start with a dot and must comply with the rules in RFC 6265.

Samples
example.org
mysub.domain.com
security.sso.cookie.secure

Either true or false. If set to true, the Secure flag is added to the SSO cookie. With this flag activated, the browser transports the cookie only if an HTTPS connection is used. Therefore, if security.manager is used with HTTP and this flag is set to true, a user is not able to sign in. Activate it, if security.manager is used with HTTPS to minimize the risk of the cookie being stolen.

Default: false

Since version 4.15

security.sso.cookie.samesite

Either true or false. If set to true, the flag SameSite=Strict or SameSite=Lax is added to the SSO cookie preventing the domain cookie to be sent along with cross-site requests to avoid Cross-Site-Request-Forgery attacks (CSRF). The value SameSite=Lax is added if the Cookie is created because of a login from a different domain through a SAML Identity Provider. Be aware that it might break some workflows, where clients are not in the same domain as the security.manager. This might occur, for example if protected services with the /sso auth scheme are consumed by ArcGIS Online. Accessing protected services via ArcGIS token authentication with the /agstoken endpoint is not affected by this setting.

Default: false

Since version 4.15

security.sso.service.url

URL of the web service which provides single sign-on session information.

security.forwardmapping.extrapathpatterns

In some cases, it might be necessary to explicitly release access to blocked resources. These resources are usually files such as XML schema files or image files that are referenced in the responses of a protected service. When accessing protected services, resources that have been blocked can be identified using the WSS Web Application log file stored under [TOMCAT_INSTALL]/logs/ct-security-wss-webapp.log.

Entries in the log file with the form:

[WARN ] 2014-07-01 12:00:01,123 [http-80-4] de.conterra.suite.security.Patch - Access to '/service/ags_local/guest/extref_37791f59-c158-4f8a-be29-3d511b3784b3/wfs-schema/featureType1.xsd' is blocked! To unblock it, add 'wfs-schema/featureType1.xsd' to property 'security.forwardmapping.extrapathpatterns' in the application.properties file.
...
[WARN ] 2014-07-01 12:00:01,223 [http-80-4] de.conterra.suite.security.Patch - Access to '/service/ags_local/guest/extref_37791f59-c158-4f8a-be29-3d511b3784b3/wfs-schema/featureType2.xsd' is blocked! To unblock it, add 'wfs-schema/featureType2.xsd' to property 'security.forwardmapping.extrapathpatterns' in the application.properties file.

highlight blocked access to a resource, in this case, wfs-schema/featureType1.xsd und wfs-schema/featureType2.xsd.

Resources supposed to be accessible from the outside can be unblocked using this property:

Example
security.forwardmapping.extrapathpatterns=wfs-schema/featureType1.xsd,wfs-schema/featureType2.xsd

In addition to unblocking single files explicitly, it is possible to use wildcards:

  • wfs-schema/* – all files in folder wfs-schema

  • wfs-schema/*.xsd – all .xsd files in folder wfs-schema

  • wfs-schema/** – all folders and files under folder wfs-schema

    security.manager already adds a set of well-know patterns automatically. These patterns are:

ags_*
_ags_*
rest/directories/arcgiscache/**
rest/directories/arcgisjobs/**
rest/directories/arcgisoutput/**
rest/directories/arcgissystem/**
rest/directories/arcgisforinspire/**
schemas/**
*/schema/**
security.login.redirect.trusted.urls

Comma-separated list of URLs. This list defines redirection destinations accepted when the security.manager login process is using redirects to forward the client to a specific site after successful login. With this measure you are protected from attackers who intend to redirect users to a malicious site via security.manager.

Adding URLs to this property is only required in special situations, for example if you have applications integrating with security.manager login that are deployed on a different host.

This parameter accepts URLs with wildcards '*' (anything, limited to the same directory) and '**' (anything).

Default: <administration.webapp>/**, <gateway.webapp>/**, <wss.webapp>/**

Example: http://smartfinder.gishost.org/index.*, http://smartfinder.gishost.org/startup/**

Since version 4.8

security.login.redirect.trusted.hosts

Analogous to security.login.redirect.trusted.urls this parameter is a list of accepted hostnames. You can also use wildcards to achieve trust on a domain basis, for example *.gishost.org

Default: localhost

Since version 4.8

security.login.redirect.trusted.sameHost

Either true or false. Defines whether redirects to the same hostname that was used by the requestor are allowed.

For more details, see description for security.login.redirect.trusted.urls.

Default: true

Since version 4.8

security.login.redirect.trusted.sameHost.sameContext

Either true or false. This property is only evaluated if security.login.redirect.trusted.sameHost is set to true. Limits the sameHost direction to redirects pointing to the same web app context path and its sub-paths.

Default: false

Since version 4.8

security.ssl.trustAny

Either true or false. If set to true, security.manager accepts all server certificates when connecting to any HTTPS endpoint. Certificates are not checked for trustworthiness or matching hostname. If set to false, certificates have to be trusted by the JVM. Otherwise connections fail.

For details, see Outgoing HTTPS Connections.

Default: true

Since version 4.15

security.embedding.allowed.origins

Defines a comma-separated list of origins that are allowed to embed security.manager in an iFrame. If the embedding page is not allowed, the X-Frame-Options: DENY header is added to the response.

If the embedding page has the same origin as the embedded security.manager, it is allowed by default.

Default: <empty>

Example: security.embedding.allowed.origins=http://my-example.com:8080,http://demos.de

Since version 4.15

security.responseHeaders.common

List of HTTP headers which are added to responses of the Administration website and the Gateway. Modify this property only if you have special security requirements.

By default the following headers are added:

  • X-Content-Type-Options:nosniff: Defines that the browser should interpret responses based on the Content-Type header only (MDN ).

  • Strict-Transport-Security:max-age=604800: Applies if security.manager is accessed via HTTPS. Defines that the browser should remember that the host is not allowed to be accessed via HTTP for 7 days (604800 seconds) (MDN ).

Default: X-Content-Type-Options:nosniff,Strict-Transport-Security:max-age=604800

Sample: security.responseHeaders.common=X-Content-Type-Options:nosniff,Strict-Transport-Security:max-age=604800

Since version 4.18

security.responseHeaders.html

List of HTTP headers added to responses of HTML pages of the Administration website and the Gateway. Modify the value of this property only if you have special security requirements.

By default the following headers are added:

  • Referrer-Policy:same-origin : Defines that the browser should send a Referrer header only to those pages visited or included that belong to the same origin as the current page (MDN ).

  • Content-Security-Policy: Defines security restrictions to prevent XSS attacks (MDN ).

Default: Referrer-Policy:same-origin, Content-Security-Policy:default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self'; img-src 'self'; worker-src 'self'; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self'

Sample: security.responseHeaders.html=Referrer-Policy:same-origin, Content-Security-Policy:default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self'; img-src 'self'; worker-src 'self'; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self'

Since version 4.18

cors.allowed.origins

Defines the websites that are allowed to use security.manager endpoints via CORS.

If, for example, a map.apps application hosted on http://mapapps.example.com:8080 tries to use a service secured by security.manager hosted on http://secman.example.com:8080, the requests from map.apps is blocked by the browser, unless http://mapapps.example.com:8080 is added to cors.allowed.origins.

The property is a comma separated list specifying the origins, from which security.manager endpoints can be requested, if it is not in the same domain or origin.

Default: http://www.arcgis.com,https://www.arcgis.com

Since version 4.15

cors.any.origins

Defines that any origin is allowed to use security.manager endpoints via CORS.

Setting this option to true introduces a security risk. Set the value to false in production environments and define allowed origins using corses.allowed.origins.

Default: false

Since version 4.15