Globale Konfiguration

Im folgenden Abschnitt wird die Konfiguration speziell für smart.finder SDI erläutert. Weitere Informationen zur Konfiguration finden Sie in der smart.finder Dokumentation.

Konfigurationsdateien

Folgende Konfigurationsdateien werden von smart.finder SDI verarbeitet:

  • WEB-INF/classes/default-application.properties (NICHT EDITIEREN)

    In dieser Datei befinden sich alle Konfigurationsoptionen von smart.finder SDI mit ihren Standardwerten.

  • WEB-INF/classes/custom-application.properties

    Wenn eine Änderung des Arbeitsverzeichnisses data.directory.location nötig ist, muss die Änderung in dieser Datei erfolgen. Alle weiteren Anpassungen erfolgen in der nachfolgenden Datei.

  • [data.directory.location]/application.properties
    Das Bearbeiten dieser Datei ist der empfohlene Weg Konfigurationsänderungen vorzunehmen.
    Das Arbeitsverzeichnis data.directory.location von smart.finder SDI ist in der Standardinstallation das Verzeichnis ${user.home}/.smartfinder. Die Datei wird nicht automatisch erstellt, daher kann als Vorlage die Datei WEB-INF/classes/application.properties dienen. Es wird empfohlen nur die Einstellungen in der Datei zu belassen, die geändert wurden.

Das Format der Konfigurationsdateien muss dem Java Properties-Dateiformat entsprechen.

Beispiel .properties
# Die Dateien müssen UTF-8 kodiert sein, sonst können Umlaute zu Fehlern führen!
# Am sichersten ist die Kodierung von Umlauten in Unicode-Syntax z.B: ä = \u00E4 (vgl. http://0xcc.net/jsescape/)

# Kommentare erfolgen mit vorangestellter Raute

# Allgemeine Syntax:
key = value

# Ein Value kann einen anderen Key referenzieren
key1 = http://${key.with.server}/test
Nach der Änderung einer der Konfigurationsdateien ist ein Neustart der Web-Applikation erforderlich. Sie können auch den kompletten Tomcat Server neu starten.

Konfigurationsparameter

Bitte beachten Sie zusätzlich auch Anpassung von Properties für smart.finder und map.apps in den dazugehörigen application.properties.

Es gibt weitere smart.finder SDI spezifische Properties, die im folgenden, unabhängig von der jeweiligen Komponente, erläutert werden:

finder.service.url

URL zum Suchdienst

Die Angabe muss immer absolut erfolgen.

Beispiel: http(s)://<yourserver>/smartfinder-search

finder.capabilities.default.language

Standardsprache der CSW Capabilities

Standardwert: GER

preview.dir

Verzeichnis, in dem hochgeladene Thumbnails abgelegt werden

Standardwert: ${data.directory.location}/preview

Datenbank-Anbindung

Die benötigten JDBC-Datenbanktreiber werden nicht mit ausgeliefert. Kopieren Sie daher die zu Ihrem Datenbanksystem passenden Treiber entweder nach [TOMCAT_HOME]/lib oder [TOMCAT_HOME]/webapps/smartfinder-editor/WEB-INF/lib.

smart.finder SDI verwendet standardmäßig eine HSQL-Datenbank, die in der Auslieferung enthalten ist. Sie wird zu Testzwecken automatisch im Dateisystem erstellt und erfordert keine weitere Konfiguration. Lediglich der Datenbanktreiber muss auch hier ergänzt werden.

Verwenden Sie die HSQL-Datenbank nicht in produktiven Umgebungen.

Vorbereitung der Datenbankumgebung

Die folgenden Angaben sind in erster Linie Hilfestellungen, an denen Sie sich orientieren können. Einige Einstellungen müssen Sie entsprechend den Richtlinien ihrer Datenbankumgebung erstellen, beispielsweise ein explizites Schema im Falle von PostgreSQL oder die genaue Größe und Struktur des Tablespaces in Oracle.

Oracle

  1. Erzeugen Sie einen Nutzer und weisen Sie ihm einen Tablespace zu:

    CREATE USER <USERNAME> IDENTIFIED BY <PASSWORD> QUOTA UNLIMITED ON <TABLESPACE> TEMPORARY TABLESPACE TEMP;

  2. Weisen Sie folgende Rechte zu:

    GRANT CREATE SESSION TO <USERNAME>;
GRANT CREATE TABLE TO <USERNAME>;
GRANT CREATE SEQUENCE TO <USERNAME>;
MS SQL Server

  1. Erzeugen Sie eine Datenbank:

    CREATE DATABASE <DATABASE>;

  2. Erzeugen Sie Login Master Database und einen assoziierten Nutzer in <DATABASE>:

    CREATE LOGIN <LOGIN> WITH password='<PASSWORD>';
USE <DATABASE>;
CREATE USER <USERNAME> FROM LOGIN <LOGIN>;

  3. Weisen Sie folgende Rollen zu:

    ALTER ROLE db_datareader ADD MEMBER [<USERNAME>];
ALTER ROLE db_datawriter ADD MEMBER [<USERNAME>];
ALTER ROLE db_ddladmin ADD MEMBER [<USERNAME>];
PostgreSQL

  1. Erzeugen Sie eine Datenbank:

    CREATE DATABASE <DATABASE>;

  2. Erzeugen Sie einen Benutzer:

    CREATE USER <USERNAME> WITH ENCRYPTED PASSWORD '<PASSWORD>';

  3. Weisen Sie diesem Benutzer folgende Rechte/Privileges zu:

    GRANT ALL PRIVILEGES ON DATABASE <DATABASE> TO <USERNAME>;

Properties

db.use

Legt den Modus der Datenbankanbindung fest

  • jdbc - Direkte Datenbankverbindung: Jede Web-App baut eine eigene Datenbankverbindung auf.

  • jndi - container-managed (empfohlen): Die Web-Apps verwenden vom Container (Tomcat) per JNDI bereitgestellte Datenbankverbindungen.

Verwenden Sie JNDI, wenn mehrere Webanwendungen im Container (z.B. Apache Tomcat) vorhanden sind, die auf dieselbe Datenbank zugreifen (siehe Apache Tomcat JNDI-Dokumentation ). Bei JDBC ist keine Container-Konfiguration notwendig.

Erlaubte Werte: jndi, jdbc
Standardwert: jdbc

db.hibernate.dialect

Technischer Dialekt Ihrer Datenbank

Dieser wird intern verwendet, um korrekte und optimierte Datenbankanfragen zu erzeugen.

Datenbank Dialekt

PostgreSQL

de.conterra.sdi.common.db.dialect.PostgreSQL9MapDialect

Oracle

org.hibernate.dialect.OracleDialect

Microsoft SQL Server

org.hibernate.dialect.SQLServerDialect

HSQLDB

org.hibernate.dialect.HSQLDialect
db.type

Herstellerspezifischer Typ des verwendeten Datenbanksystems.

Dieser wird intern verwendet, um korrekte und optimierte Datenbankanfragen zu erzeugen.

Erlaubte Werte:

Datenbank Typ

PostgreSQL

postgresql

Oracle Database

oracle

Microsoft SQL Server

sqlserver

HSQLDB

hsqldb

Standardwert: hsqldb

db.jdbc.driver

JDBC Treibername

Der Wert ist vom verwendeten Datenbanksystem abhängig, vgl. Tabelle.

Datenbank JDBC Treiber JDBC Verbindungs-URL (Beispiele)

Postgres

org.postgresql.Driver

jdbc:postgresql://localhost:5432/sfsdi

MS SQL Server

com.microsoft.sqlserver.jdbc.SQLServerDriver

jdbc:sqlserver://localhost:1433;DATABASENAME=sfsdi

Oracle

oracle.jdbc.driver.OracleDriver

jdbc:oracle:thin:@localhost:1521/sfsdi

HSQLDB

org.hsqldb.jdbc.JDBCDriver

jdbc:hsqldb:file:$\{data.directory.location\}/storage/db;shutdown=true
Container-managed Datenbankverbindung (JNDI)
db.jndi.name

JNDI Name, über den die Datenbank vom Container erfragt werden kann.

Standardwert: java:comp/env/jdbc/sfsdi.

Direkte Datenbankverbindung (JDBC)
db.jdbc.url

JDBC Datenbankverbindungs-URL

Der Wert ist vom verwendeten Datenbanksystem abhängig, vgl. Tabelle.

db.jdbc.username

Nutzername des Datenbanknutzers

db.jdbc.password

Passwort des Datenbanknutzers

Locking

locking.scheduler.cron

Zeitliche Angabe, wie häufig der Scheduler nach gesperrten Metadatendokumenten suchen soll, die veraltet sind

Die Angabe wird per Cron-String spezifiziert.

Standardwert: 0 0 * * * * (zu jeder vollen Stunde)

locking.scheduler.maturityInMs

Angabe in ms, wann ein gesperrtes Metadatendokument als veraltet gilt

Ist die Sperrung älter als die hier gemachte Angabe bezogen auf die aktuelle Zeit, wird die Sperrung aufgehoben und der Metadatensatz kann erneut editiert werden.

Standardwert: 3600000 (1 Stunde)

Mailing

mailing.host

Hostname des SMTP Servers

mailing.port

Port des SMTP Servers

mailing.username

Nutzername zur Authentifizierung am SMTP Server

mailing.password

Passwort zur Authentifizierung am SMTP Server

mailing.senderaddress

Absenderadresse für den Mailversand

Logging von Fehlern und weiteren Meldungen

Es stehen folgende Konfigurationsparameter zur Anpassung des Loggings zur Verfügung:

logging.logger.level

Dieser Parameter definiert den Detailgrad des Logs.

Erlaubte Werte: TRACE, DEBUG, INFO, WARN, ERROR
Standardwert: INFO

logging.file.location

Ort, an dem die Log-Datei gespeichert wird.

Der Standardwert entspricht dem logs Verzeichnis des Tomcat. Um Log-Dateien im Arbeitsverzeichnis von map.apps zu erstellen, verwenden Sie den Wert ${data.directory.location}/logs.

Standardwert: ${catalina.base}/logs

logging.file.prefix

Namen der Log-Dateien.

Um den Log-Dateien den URL-Kontextpfad der map.apps-Installation voranzustellen (zum Beispiel mapapps), verwenden Sie den Wert ${webcontext.name}.

Standardwert: ct-smartfinder-sdi-webapp

Weitere Logging-Parameter sind in der Datei default-application.properties beschrieben, z.B. zum Aktivieren oder Deaktivieren des Loggings in die Konsole, in Log-Dateien oder mittels GELF.

Sicherheitsaspekte

Web Application Security

smart.finder SDI verwendet security.manager Enterprise Edition zur Authentifizierung der Nutzer. Um die Verbindung zum security.manager Enterprise Edition herzustellen, konfigurieren Sie die folgenden Properties.

Die meisten Werte können direkt aus den Properties der verwendeten Installation des security.manager Enterprise Edition übernommen werden, die mit smart.finder SDI verwendet werden soll. Detailliertere Informationen zu den einzelnen Properties finden Sie in der security.manager EE Dokumentation.
security.administration.url

URL zur /administration Web-Applikation des security.managers

security.administration.base.url

URL zur /administration Web Applikation des security.managers. Wird benötigt, um über die Oberfläche des smart.finder SDI zur Benutzerverwaltung zu gelangen

security.keystore.location

Pfad zur Keystore-Datei, die 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.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 darf nicht mit einem Punkt beginnen und muss den Regeln in RFC 6265 entsprechen.
Beispiele:

 example.com
 subdomain.example.net
secman.db.jdbc.driver

Treiber für den Zugriff auf die security.manager Datenbank

secman.db.jdbc.url

JDBC Verbindungs-URL für den Zugriff auf die security.manager Datenbank

secman.db.jdbc.username

Der JDBC Nutzername

secman.db.jdbc.password

JDBC Passwort

secman.db.hibernate.dialect

Technischer Dialekt Ihrer Datenbank

secman.db.use

Modus der Datenbankanbindung

Erlaubte Werte: jdbc, jndi

secman.db.jndi.name

JNDI Name, über den die Datenbank vom Container erfragt werden kann

Standardwert: java:comp/env/jdbc/secman

usermgr.type

Art des user-management-adapter

Erlaubte Werte: db, ldap, hybrid

security.responseHeaders.common

Liste von HTTP-Antwortheadern.

Um eine Liste von Antwortheadern zu definieren, verwenden Sie folgende Syntax: <header-name>:<header-value>,<header-name>:<header-value>. Dabei gilt:

  • <header-name> ist der Name eines HTTP-Headers. Dieser muss mit einem Großbuchstaben beginnen

  • <header-value> ist der Wert eines HTTP-Headers

Die Header werden an jede Antwort des smart.finder Backend-Services geschrieben. 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.
Genauere Informationen finden Sie unter X-Content-Type-Options .

Strict-Transport-Security:max-age=604800

Definiert, dass der Browser sich merken soll, dass der Host für 7 Tage (604800 Sekunden) nicht mehr per HTTP angefragt werden darf.
Wird nur angewandt, wenn map.apps via HTTPS aufgerufen wird. Genauere Informationen finden Sie unter Strict-Transport-Security .

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

Caching von Nutzern

Um die Last auf die angebundene Nutzerverwaltung zu reduzieren, werden die Nutzer im smart.finder SDI standardmäßig zwischengespeichert. In einem definierten Intervall werden die Nutzer im Zwischenspeicher aktualisiert. Mit folgenden Properties können Sie das Caching konfigurieren.

usermgr.cache.enabled

Zwischenspeicherung aktivieren bzw. deaktivieren

Erlaubte Werte: true, false

usermgr.cache.intervallInMillis

Intervall, angegeben in Millisekunden, in dem die Nutzer im Zwischenspeicher aktualisiert werden. Standardmäßig werden die Nutzer alle zwei Stunden von der angebundenen Nutzerverwaltung abgerufen.

Standartwert: 7200000

SSL/TLS Server Trust

Beim Aufbau von Verbindungen zu HTTPS-Endpunkten durch serverseitige Java-Komponenten muss sichergestellt werden, dass das SSL/TLS-Server-Zertifikat des angefragten Hosts von der Java Virtual Machine (JVM) akzeptiert und als vertrauenswürdig erachtet wird. Andernfalls wird keine HTTPS-Verbindung zum Server aufgebaut und die Applikation reagiert fehlerhaft.

Die ist relevant, wenn Sie im Manager mittels Job-Konfiguration Quellen indexieren, auf die über einen HTTPS-Endpunkt zugegriffen wird (z.B. OGC CSW-Katalog)

Mit der Konfigurationsoption security.ssl.trustAny wird gesteuert, unter welchen Bedingungen ein TLS-Server-Zertifikat akzeptiert wird:

  • security.ssl.trustAny=true

    Es werden alle Zertifikate akzeptiert, sofern zeitlich gültig. Das Zertifikat muss weder für den angefragten Host noch von einer vertrauenswürdigen Stelle ausgestellt worden sein.

    Aktivieren Sie diese Einstellung nur in Entwicklungsumgebungen.

  • security.ssl.trustAny=false (empfohlen)

    Es werden nur Zertifikate akzeptiert, die von der JVM als vertrauenswürdig erachtet werden. Es wird dringend empfohlen, diese Einstellung beizubehalten. Dies gilt insbesondere für produktive Umgebungen. Sie müssen sicherstellen, dass Server-Zertifikate von HTTPS-Endpunkten, zu denen Verbindungen hergestellt werden, vertrauenswürdig sind. Andernfalls kommt es beim Aufbau einer Verbindung zu einem Fehler.

Server-Zertifikaten vertrauen

Damit ein Server-Zertifikat von der JVM als vertrauenswürdig erachtet wird, muss entweder das konkrete Server-Zertifikat oder dessen Stammzertifikat im Java Runtime Environment (JRE) installiert sein. Vertrauenswürdige Zertifikate bzw. Stammzertifikate werden im JRE standardmäßig in einem Java Keystore unter [JRE_HOME]/lib/security/cacerts gespeichert.

Je nach Betriebssystem oder Konfiguration der JVM ist es möglich, dass andere Quellen für vertrauenswürdige Zertifikate genutzt werden.

Im Folgenden wird beschrieben, welche Typen von Server-Zertifikaten von HTTPS-Endpunkten üblicherweise verwendet werden und was bezüglich der Vertrauenswürdigkeit zu beachten ist.

(A) Zertifikate mit Stammzertifikat, das im JRE installiert ist

Produktive Websites, die Dienste per HTTPS zur Verfügung stellen, besitzen üblicherweise Server-Zertifikate, deren Stammzertifikat von einer Vertrauenswürdigen Certificate Authority (CA) ausgestellt wurde. Diese Stammzertifikate sind in der JRE bereits vorinstalliert und werden damit als vertrauenswürdig eingestuft.

Um die Verbindung mit einem Endpunkt zu erlauben, dessen Server-Zertifikat ein bereits in der JRE installiertes Stammzertifikat besitzt, sind keine weiteren Schritte notwendig.

(B) Zertifikate mit Stammzertifikat, das nicht im JRE installiert ist

Gelegentlich werden in Organisationen Server-Zertifikate verwendet, die von einer eigenen, organisationsinternen CA ausgestellt wurden. Das zugehörige Stammzertifikat ist folglich nicht Teil der im JRE vorinstallierten Zertifikate. Verbindungen zu HTTPS-Endpunkten mit solchen Server-Zertifikaten schlagen dann fehl, es sei denn, das Stammzertifikat wird durch unternehmensinterne Prozesse allen JRE-Installationen hinzugefügt.

Um sicherzustellen, dass allen von dieser organisationsinternen CA ausgestellten Server-Zertifikaten vertraut wird, muss das Stammzertifikat der CA dem Keystore [JRE_HOME]/lib/security/cacerts hinzugefügt werden.

(C) Selbst-signierte Zertifikate

Selbst-signierte Server-Zertifikate, also Zertifikate, die sich selbst als Herausgeber referenzieren, werden häufig zu Testzwecken verwendet. Verwenden Sie sie nicht in Produktivsystemen. Da ein selbst-signiertes Server-Zertifikat nicht Teil der mit dem JRE bereits installierten Zertifikate ist, ist es nicht vertrauenswürdig.

Um HTTPS-Verbindungen mit einem Host zu erlauben, der ein selbst-signiertes Server-Zertifikat verwendet, muss dieses Zertifikat dem Keystore [JRE_HOME]/lib/security/cacerts hinzugefügt werden.

Typische Fehlermeldungen

Beim Aufbau serverseitiger HTTPS-Verbindungen kann es zu verschiedenen Fehlersituationen im Zusammenhang mit der Validierung von Server-Zertifikaten kommen. In den folgenden Abschnitten werden typische Fehlermeldungen aufgeführt, die in der Log-Datei der serverseitigen Anwendung oder in den Browser-Oberflächen der Applikationen erscheinen können. Zusätzlich werden ihre möglichen Ursachen beschrieben und Lösungen vorgeschlagen. Abhängig von der konkreten Infrastruktur, in der die betroffene Applikation betrieben wird, sind ggf. andere Ursachen und Lösungen in Betracht zu ziehen.

PKIX path building failed

Vollständige Fehlermeldung:

sun.security.validator.ValidatorException:
 PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Diese Fehlermeldung ist ein Hinweis darauf, dass das vom Server präsentierte Zertifikat für die HTTPS-Verbindung von der JVM nicht als vertrauenswürdig eingestuft wird. Ggf. handelt es sich um ein selbst-signiertes Zertifikat oder das Stammzertifikat ist nicht im JRE installiert.

Mögliche Lösungen:

  • Installieren Sie das Stammzertifikat im JRE

  • Installieren Sie das Server-Zertifikat im JRE

  • Wenn der angefragte Server unter eigener Kontrolle ist: Stellen Sie auf dem angefragten Server ein neues Server-Zertifikat bereit, das von einer vertrauenswürdigen CA ausgestellt wurde.

No name matching [requested.host.name] found

Vollständige Fehlermeldung:

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No name matching maps.example.com found

Diese Fehlermeldung zeigt an, dass der in der HTTPS-Anfrage genutzte Host-Name nicht zu dem Host-Namen passt, der im Server-Zertifikat angegeben ist. Der Client (Browser, Java-Applikation) vergleicht dabei den in der Anfrage-URL verwendeten Host-Namen mit dem CN Namen des Subject-Feldes im X509-Zertifikat des Servers, z.B.
https://maps.example.com/
mit
CN = www.example.com, O = Example LLC, L = Mountain Dew, ST = California, C = US.

Stimmen beide Namen nicht überein (Groß-/Kleinschreibung ist nicht relevant), wird mit der Verbindungsaufbau mit der o.g. Fehlermeldung abgebrochen. Dabei ist es unerheblich, ob das Zertifikat als vertrauenswürdig eingestuft würde. Die Prüfung der Vertrauenswürdigkeit findet erst statt, wenn das Übereinstimmen der Host-Namen sichergestellt ist.

Häufig kommt es zu diesem Problem, wenn Clients denselben Server mit unterschiedlichen Namen ansprechen können, weil mehrere DNS-Einträge vorhanden sind. Insbesondere wenn der Client sich in derselben Domäne wie der Server befindet, führt die uneinheitliche Nutzung von nicht-qualifizierten und vollqualifizierten Host-Namen in Anfrage-URLs bzw. Server-Zertifikaten häufig zu diesem Problem. Die Verwendung des speziellen Host-Namen localhost oder IP-Adressen in URLs führt zu diesem Problem, wenn das Server-Zertifikat auf den qualifizierten Rechnernamen ausgestellt wurde.

Mögliche Lösungen:

  • Verwenden Sie den Host-Namen in Anfrage-URLs so, wie er im Server-Zertifikat angegeben wird.

  • Erstellen und Hinterlegen Sie ein neues Server-Zertifikat für den vom Client gewünschten Host-Namen, wenn sich herausstellt, dass die Verwendung eines nicht-vollqualifizierten Host-Namens (oder localhost oder IP-Adresse) nicht sinnvoll ist.

  • Erstellen und Hinterlegen Sie ein neues Server-Zertifikat mit alternativen Host-Namen (Subject Alternative DNS Namen), wenn sich herausstellt, dass der Server unausweichlich unter unterschiedlichen Host-Namen erreichbar sein muss.

No subject alternative DNS name [requested.host.name] found

Vollständige Fehlermeldung:

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No subject alternative DNS name matching maps.example.com found

Diese Fehlermeldung ist ein Sonderfall der Fehlermeldung No name matching [requested.host.name] found. Einziger Unterschied ist, dass das Server-Zertifikat ein zusätzliches Feld mit alternativen Host-Namen besitzt, jedoch der vom Client verwendete Host-Name weder dem Subject-CN des Server-Zertifikats entspricht noch in dessen Liste alternativer Host-Namen (Subject Alternative DNS Names) angegeben ist.

Mögliche Lösungen:
Analog zu Lösungsvorschlägen zum Fehler No name matching [requested.host.name] found.

CSW Proxy

Dieses Kapitel enthält die grundlegende Konfigurationseinstellung des CSW Proxy smartfinder-csw. Der CSW Proxy ist unter http(s)://[HOST]:[PORT]/smartfinder-csw/api erreichbar.

Da diese Komponente als Proxy vor dem Backend fungiert, muss die URL zum Backend konfiguriert werden. Dies ist erläutert im Abschnitt Anpassen der URL-Konfiguration.

CSW Capabilities

Um die Capabilities des CSW Proxy zu konfigurieren, müssen folgende Dateien im Order /smartfinder-csw/WEB-INF/classes/capabilities angepasst werden. Hierfür ist ein UTF-8-fähiger Editor notwendig.

Capabilities.xml

Dies ist die Hauptdatei für die Beschreibung der Capabilities gemäß OGC Catalog Service for the Web 2.0.2. Zudem sind sämtliche Anforderungen seitens INSPIRE Discovery Service Spezifikation bereits berücksichtigt.

Sie brauchen nur die Angaben zu ergänzen, die für den Betrieb in einer konkreten Umgebung durch einen konkreten Anbieter erforderlich sind. Dazu zählen:

Service Identifikation
Title

vgl. Title der language.xml

Abstract

vgl. Abstract der language.xml

Keywords

Die Liste der Schlüsselwörter ist bereits mit einigen Begriffen gefüllt. Diese können ergänzt oder gelöscht werden.

ServiceType

Der Wert CSW muss beibehalten werden.

ServiceTypeVersion

Der Wert 2.0.2 muss beibehalten werden.

Fees

Falls Gebühren für die Dienstinstanz anfallen, können diese hier beschrieben werden.

AccessConstraints

Falls Zugriffsrestriktionen auf diese Dienstinstanz existieren, können diese hier beschrieben werden.

ServiceProvider

Sie können bereits vorhandene Werte ersetzen.

ProviderName

Name des Dienstanbieters

ProviderSite

URL zur Web-Seite des Dienstanbieters

ServiceContact

Detaillierter Kontakt zum Anbieter des Dienstes

INSPIRE Metadaten Elemente

Diese Elemente befinden sich im XML Tag inspire_ds:ExtendedCapabilities. Passen Sie zwei Einträge innerhalb von inspire_com:MetadataPointOfContact an. Sie können bereits vorhandene Werte ersetzen.

OrganisationName

Name des Dienstanbieters

EmailAddress

E-Mail-Adresse des Dienstanbieters

languages.xml

In dieser Datei werden alle Inhalte des Capabilities-Dokumentes erfasst, die sprachabhängig sind. Hierzu zählen:

  • Title

  • Abstract

Die Datei ist für die Sprachen Deutsch und Englisch vorkonfiguriert. Falls weitere oder andere Sprachen erforderlich sind, können Sie diese entsprechend mit angegeben und beschreiben. Die Akronyme der verwendeten Sprachen sind determiniert durch ISO 639‑3.

Passen Sie folgende Angaben in dieser Datei an.

defaultLanguageCode

Standardsprache

Falls die Capabilities des Dienstes ohne sprachspezifische Parameter angefragt werden, wird diese Sprache verwendet.
Standardwert: ger

language.code

Sprache des jeweiligen Abschnittes gemäß ISO 639-3

Title

Titel des Katalogdienstes in der Sprache, die dem language.code des Abschnittes entspricht

Dieser Text wird bei der Abfrage der Capabilities automatisch im Abschnitt ServiceIdentification.Title eingefügt.

Abstract

Kurze Zusammenfassung in der Sprache, die dem language.code des Abschnittes entspricht

Dieser Text wird bei der Abfrage der Capabilities automatisch im Abschnitt ServiceIdentification.Abstract eingefügt.

SSL/TLS Unterstützung

Sie können den CSW Proxy für eine gesichter SSL/TLS Verbindung konfigurieren. Hierzu wird ein selbst-signiertes Zertifikat mit ausgeliefert. Passen Sie dieses bitte an. Das ausgelieferte selbst-signierte Zertifikat dient lediglich der Demonstration.

Wenn Sie eine HTTPS-Verbindung einrichten, wird dringend empfohlen, ein signiertes SSL/TLS Zertifikates zu verwenden.

Folgende Properties zeigen die Standardeinstellungen für dieses Zertifikat:

#
# SSL configuration
#
# The format used for the keystore. It could be set to JKS in case it is a JKS file
server.ssl.key-store-type=PKCS12

# The path to the keystore containing the certificate
server.ssl.key-store=classpath:keystore.p12

# The password used to generate the certificate
server.ssl.key-store-password=changeit

# The alias mapped to the certificate
server.ssl.key-alias=ct-security

# enable SSL for this service instance
server.ssl.enabled=false