Sicherheitseinstellungen

security.keystore.location

Pfad zur Keystore-Datei, der das Schlüsselpaar zur Validierung und Erzeugung von digitalen Signaturen enthält.

security.keystore.passwd

Passwort für den Zugriff auf den Keystore.

security.keystore.key.alias

Alias des Zertifikates oder privaten Schlüssels.

security.keystore.key.passwd

Passwort für den Zugriff auf den privaten Schlüssel.

security.pdp.service.url

URL zum Rechtedienst (Policy Decision Point), dies ist normalerweise die URL auf die Administrator-Webanwendung mit nachgestelltem PDP.

Beispiel: http://localhost:8080/administration/PDP

security.was.service.url

URL zum Authentifizierungsdienst (WAS), dies ist normalerweise die URL auf die Administrator-Webanwendung mit nachgestelltem WAS

Beispiel: http://localhost:8080/administration/WAS

security.login.service.url

URL zum Single Sign-On Dienst, dies ist normalerweise die URL auf die Administrator-Webanwendung mit nachgestelltem start.do

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

security.allowed.hostnames

Kommaseparierte Liste von Hostnamen, von denen aus der Zugriff auf abgesicherte Endpunkte erlaubt ist (localhost muss nicht konfiguriert werden)

security.allowed.ipranges

Kommaseparierte Liste von IP-Bereichen, von den aus der Zugriff auf abgesicherte Endpunkte erlaubt ist. Unterstützt werden einzelne Adressen (172.12.25.84) oder Subnetzmasken (172.12.25.0/24) oder Intervalle (172.12.25.10-172.12.25.20). Es werden nur IPv4 Adressen unterstützt.

Beispiel: 172.12.25.84,172.12.25.0/24,172.12.25.10-172.12.25.20

security.password.history.capacity

Anzahl der Passwörter, die in der Nutzerhistorie gespeichert werden sollen.

security.password.history.check.count

Anzahl der letzten Passwörter aus der Nutzerhistorie, die nicht erlaubt sind, wenn der Nutzer versucht, sein Passwort zu ändern. Ein Wert 3 bedeutet z.B., dass ein neues Passwort sich immer von den letzten drei Passwörtern unterscheiden muss.

security.password.changePause

Die Mindestzeit, die zwischen 2 Passwortwechseln eines Nutzers liegen muss. Mögliche Einheiten sind Sekunden (s), Minuten (m), Stunden (h) und Tage (d), z.B. 3h oder 10s.

security.user.login.lock.username

Aktiviert oder deaktiviert die Funktion zum Sperren von Logins zum Schutz vor Brute-Force Attacken auf Passwörter. Wenn die Eigenschaft auf true gesetzt ist, werden Login-Versuche nach mehr als drei aufeinanderfolgenden Login-Fehlversuchen für einen Nutzernamen oder nach zehn Fehlversuchen von derselben IP-Adresse blockiert. Der Zugang wird dann standardmäßig für 30 Minuten gesperrt. Die Zahl maximal aufeinanderfolgender Fehlversuche pro Nutzername oder IP-Adresse sowie der Sperr-Zeitraum können in der Datei spring-security-config.xml in der Webapplikation geändert werden.

security.user.login.log

Aktiviert das Protokollieren von Login-Versuchen in einer separaten Log-Datei. Die Einträge werden standardmäßig in [TOMCAT_HOME]/logs/ct-security-administration-webapp-login_audit.log geschrieben

security.user.usermail.regexpr

Der reguläre Ausdruck zum Validieren einer E-Mail-Adresse während der Selbstregistrierung, beim Ändern des Profils oder beim Anlegen eines Nutzers durch den Administrator

security.user.username.regexpr

Der reguläre Ausdruck zum Validieren eines Nutzernamens während der Selbstregistrierung

Beispiel: [a-zA-Z0-9\00f6\00e4\00fc\00c4\00d6\00dc_]* (erlaubt alle Buchstaben, Zahlen und deutsche Umlaute)

security.user.userpwd.validate

Definiert, ob das eingegebene Passwort gegen einen regulären Ausdruck validiert werden soll.

security.user.userpwd.regexpr

Der reguläre Ausdruck zum Validieren eines Nutzerpasswortes während der Selbstregistrierung, bei der Funktion Passwort ändern und beim Setzen des Passwortes durch einen Administrator.

Wenn Sie einen regulären Ausdruck in die application.properties eintragen, müssen Sie im Audruck vorkommende Backslashes (\) escapen. Dazu stellen Sie einem Backslash einen weiteren Backslash voran. Den regulären Ausdruck \w{8,} tragen Sie also folgendermaßen ein: \\w{8,}.

Beispiele für reguläre Ausdrücke
Regulärer Ausdruck
(\ bereits escaped)		 Bedeutung

\\w{8,}

Mindestens 8 alphanumerische Zeichen (inkl. _)

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

Mindestens 8 Zeichen Länge, beginnend und endend mit einem Buchstaben

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

Länge des Passwortes egal, aber mindestens einen Klein- und einen Großbuchstaben

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

Mindestens 10 Zeichen Länge, mindestens einen Klein- und einen Großbuchstaben, sowie eine Zahl und ein Sonderzeichen. Erlaubte Sonderzeichen sind: @, #, $, %, &, =.
security.user.userpwd.validationkey.#

Erlaubt die Definition von Erklärungen, um auf Basis von vordefinierten Fehlernachrichten die aktuelle Validierungsregel zu erläutern. Es können bis zu 5 Fehlernachrichten hinzugefügt werden. Dazu muss das Zeichen # mit einer Zahl zwischen 0 und 4 ersetzt werden. Der Wert dieser Eigenschaft kann der folgenden Tabelle entnommen werden:

Wert Entsprechende Fehlernachricht

errors.user.passwordformat.minimalLength, <minimalLength>

Das Passwort muss aus mindestens <minimalLength> Zeichen bestehen.

errors.user.passwordformat.uppercaseCharReq

Großbuchstabe erforderlich.

errors.user.passwordformat.uppercaseCharNotReq

Großbuchstabe nicht erforderlich.

errors.user.passwordformat.lowercaseCharReq

Kleinbuchstabe erforderlich.

errors.user.passwordformat.lowercaseCharNotReq

Kleinbuchstabe nicht erforderlich.

errors.user.passwordformat.specialCharReq

Sonderzeichen erforderlich.

errors.user.passwordformat.specialCharNotReq

Sonderzeichen nicht erforderlich.

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

Erlaubte Sonderzeichen: <List of special characters>

Die minimalLength und permittedSpecialChars Schlüssel erfordern ein zusätzliches Argument. Dieses wird, durch ein Komma getrennt, an den Wert der Eigenschaft angehängt. Beispiel:
security.user.userpwd.validationkey.0=errors.user.passwordformat.minimalLength,8 (Hier wird eine Fehlernachricht definiert, die besagt, dass das Passwort aus mindestens 8 Zeichen bestehen muss.)

security.sso.cookie.name

Name des Cookies, das für das domänenweite Single Sign-on verwendet wird.

security.sso.cookie.domain

Name der Domäne, in der das Single Sign-on Cookie gültig ist. Es muss mit einem Punkt beginnen und den Regeln in RFC 2109 entsprechend.

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

Entweder true oder false. Wenn dieses Flag aktiviert ist (true), fügt der security.manager dem SSO-Cookie das Flag Secure hinzu. Der Browser transportiert das Cookie dann nur, wenn eine HTTPS-Verbindung genutzt wird. Wird der security.manager über HTTP benutzt, während dieses Flag aktiv ist, kann sich ein Nutzer nicht mehr einloggen. Setzen Sie den Wert auf true, wenn der security.manager per HTTPS betrieben wird, um das Risiko eines Cookie-Diebstahls zu minimieren.

Standard: false

Seit Version 4.15

security.sso.cookie.samesite

Entweder true oder false. Ist diese Eigenschaft auf true gesetzt, wird dem SSO-Cookie das Flag SameSite=Strict oder SameSite=Lax hinzu gefügt, um zu verhindern, dass das Cookie bei Cross-Site-Anfragen mitgeschickt wird. Dadurch werden Cross-Site-Request-Forgery-Angriffe (CSRF) verhindert. Der Wert SameSite=Lax wird nur verwendet, wenn das Cookie aufgrund eines Logins durch einen SAML Identity Provider aus einer anderen Domain erstellt wird. Das gesetzte Flag kann jedoch einige Workflows stören, bei denen Clients nicht in derselben Domain wie der security.manager sind. Dies ist beispielsweise der Fall, wenn geschützte Dienste über den /sso Endpunkt in ArcGIS Online eingeladen werden. Die Nutzung geschützter Dienste über den ArcGIS Server Token Endpunkt /agstoken ist nicht von dieser Einschränkung betroffen.

Standard: false

Seit Version 4.15

security.sso.service.url

URL des Webdienstes von dem die Single Sign-on Sessioninformationen abgerufen werden können.

security.forwardmapping.extrapathpatterns

In einigen Fällen kann es notwendig sein, den Zugriff auf geblockte Ressourcen explizit freizugeben. Bei den Ressourcen handelt es sich üblicherweise um Dateien wie XML-Schemadateien oder Bilddateien, die in Antworten eines geschützten Dienstes referenziert werden. Geblockte Ressourcen können mithilfe der Log-Datei der WSS Web-Application identifiziert werden. Dieses wird standardmäßig unter [TOMCAT_INSTALL]/logs/ct-security-wss-webapp.log gespeichert.

Einträge in der Log-Datei der 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.

markieren den Zugriff auf eine geblockte Ressource, in diesem Fall wfs-schema/featureType1.xsd und wfs-schema/featureType2.xsd.

Ressourcen, die von außen zugreifbar sein sollen, können mithilfe dieser Einstellung freigegeben werden:

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

Neben der Freigabe einzelner expliziter Dateien können Wildcards verwendet werden:

  • wfs-schema/* – Freigabe aller Dateien im Ordner wfs-schema

  • wfs-schema/*.xsd – Freigabe aller .xsd Dateien im Ordner wfs-schema

  • wfs-schema/** – Freigabe aller Ordner und Dateien unterhalb wfs-schema

    security.manager fügt der Liste bereits folgende Pfade hinzu:

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

Komma-separierte Liste von URLs. Diese Liste definiert, welche Ziele zur Weiterleitung (Redirect) akzeptiert werden, wenn der security.manager am Ende des Login-Prozesses den Browser zur nächsten Seite weiterleitet. Mit dieser Maßnahme ist sichergestellt, dass Angreifer den Nutzer nicht über den security.manager unter Vorlage einer entsprechenden URL auf eine bösartige Seite lenken können.

Fügen Sie hier URLs hinzu, wenn Sie Applikationen im Einsatz haben, die den Nutzer zum Login auf den security.manager umleiten und die Applikation unter einem anderen Hostnamen als der security.manager aufgerufen wird.

URLs, die Sie hier definieren, dürfen die Wildcards * (beliebige Zeichenfolge, aber nur innerhalb desselben Verzeichnisses) und ** (beliebige Zeichenfolge) enthalten.

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

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

Seit Version 4.8

security.login.redirect.trusted.hosts

Analog zu security.login.redirect.trusted.urls können Sie mit diesem Parameter eine Liste von akzeptierten Hostnamen definieren. Sie können Wildcards verwenden, um beispielsweise Redirects auf alle Rechner einer Domäne zu erlauben.

Beispiel: *.gishost.org

Standard: localhost

Seit Version 4.8

security.login.redirect.trusted.sameHost

Entweder true oder false. Definiert ob Redirects zu URLs generell erlaubt werden, die denselben Hostnamen verwenden wie der, der in der Anfrage benutzt wird.

Beachten Sie security.login.redirect.trusted.urls für detaillierte Informationen.

Standard: true

Seit Version 4.8

security.login.redirect.trusted.sameHost.sameContext

Entweder true oder false. Diese Eigenschaft wird nur ausgewertet, wenn security.login.redirect.trusted.sameHost auf true gesetzt ist.

Schränkt die "sameHost"-Direktive ein auf Redirects zum selben Web-Kontext wie der, der in der Anfrage verwendet wird.

Standard: false

Seit Version 4.8

security.ssl.trustAny

Entweder true oder false. Wenn auf true gesetzt, akzeptiert security.manager alle Server-Zertifikate, sobald eine Verbindung zu einem HTTPS-Endpunkt hergestellt wird. Zertifikate werden nicht auf Vertrauenswürdigkeit oder passenden Host-Namen geprüft. Wenn auf false gesetzt, müssen Zertifikate von der JVM als vertrauenswürdig erachtet werden. Andernfalls schlägt die Verbindung fehl.

Weitere Details finden Sie unter Ausgehende HTTPS-Verbindungen.

Standard: true

Seit Version 4.15

security.embedding.allowed.origins

Komma-separierte Liste von Origins, die security.manager in einem iFrame einbetten dürfen. Ist die einbettende Seite nicht erlaubt, wird den Responses der Anfrage der X-Frame-Options: DENY Header hinzugefügt.

Wenn die einbettende Seite die selbe Origin wie der einzubettende security.manager hat, wird dies automatisch erlaubt.

Standard: <leer>

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

Seit Version 4.15

security.responseHeaders.common

Liste von HTTP Headern, welche an jede Antwort der Administration-Website und und des Gateways geschrieben werden. Die Konfiguration sollte nur bei besonderen Sicherheitsanforderungen verändert werden.

Standardmäßig werden folgende Header ergänzt:

  • X-Content-Type-Options:nosniff: Definiert, dass der Browser Serverantworten nur auf Basis des Content-Type Headers interpretieren darf (MDN ).

  • Strict-Transport-Security:max-age=604800: Wirkt nur wenn security.manager via HTTPS verwendet wird. Definiert, dass der Browser sich merken soll, dass der Host für 7 Tage (604800 Sekunden) nicht mehr per HTTP angefragt werden darf (MDN ).

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

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

Seit Version 4.18

security.responseHeaders.html

Liste von HTTP Headern, welche beim Ausliefern der HTML Seiten der Administration-Website und und des Gateways ergänzt werden. Die Konfiguration sollte nur bei besonderen Sicherheitsanforderungen verändert werden.

Standardmäßig werden folgende Header ergänzt:

  • Referrer-Policy:same-origin : Definiert, dass der Browser einen Referrer Header nur zu den Seiten senden soll, die zum gleichen Ursprung wie die Ausgangsseite gehören (MDN ).

  • Content-Security-Policy: Definiert Sicherheitsrestriktionen (MDN ).

Standard: 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'

Beispiel: 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'

Seit Version 4.18

cors.allowed.origins

Definiert die Webseiten, welchen erlaubt ist, Endpunkte des security.manager via CORS zu nutzen.

Wenn z.B. eine map.apps Anwendung unter http://mapapps.example.com:8080 versucht, einen durch security.manager unter http://secman.example.com:8080 abgesicherten Dienst einzubinden, werden Requests von map.apps an security.manager durch den Browser geblockt, sofern http://mapapps.example.com:8080 nicht zu cors.allowed.origins hinzugefügt wurde.

Mit der Konfigurationsoption wird eine Komma-separierte Liste definiert, in der die alle abweichenden Origins angegeben werden, von denen aus Endpunkte des security.manager angefragt werden dürfen.

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

Seit Version 4.15

cors.any.origins

Definiert, dass Endpunkte des security.manager von jeder Domain via CORS genutzt werden dürfen.

Das Setzen dieser Option auf true stellt ein Sicherheitsrisiko dar. Setzen Sie den Wert in Produktivumgebungen auf false und definieren Sie erlaubte Origins über cors.allowed.origins.

Standard: false

Seit Version 4.15