Version 4.4 security.manager Systemvoraussetzungen
Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung dieser Gegenstände entsprechend den Lizenzbedingungen. Jede nicht vertragsgemäße Vervielfältigung, Veräußerung oder Verwendung der Software oder dieses Dokuments ist nicht gestattet und wird ggf. strafrechtlich verfolgt. Gewährleistung/Haftungsausschluss Obwohl das vorliegende Dokument mit aller Sorgfalt erstellt wurde, können Fehler im Detail nicht ausgeschlossen werden. Die con terra GmbH übernimmt keine Haftung für Schäden, die aus der Anwendung dieses Dokuments oder der Software entstehen. Herausgeber con terra Gesellschaft für Angewandte Informationstechnologie mbh Martin-Luther-King-Weg 24, 48155 Münster Telefon +49 251 74745 2200 info@conterra.de, www.conterra.de 2
Inhalt 1 Laufzeitumgebung 4 1.1 Betriebssystem 4 1.2 Servlet Container 4 1.3 Datenbank Management System 4 1.4 Browser 4 1.5 Optionale Komponenten 5 1.5.1 LDAP oder Active Directory 5 1.5.2 Web Server 5 1.5.3 SMTP Server 5 1.5.4 Web Feature Service für räumliche Berechtigung 5 1.6 Sprachen 6 2 Weitere Voraussetzungen 7 2.1 HTTPS 7 2.2 UTF-8 Unterstützung 7 2.3 Speichereinstellungen 7 2.4 Datenbankberechtigungen 8
1 Laufzeitumgebung Diese Software benötigt einen Servlet-Container als Laufzeitumgebung. Es werden folgende Produkte unterstützt. 1.1 Betriebssystem Da der security.manager aus Java Web Applikationen besteht, werden alle Betriebssysteme unterstützt, auf denen ein Java Runtime Environment zur Verfügung steht. U. a. folgende Betriebssysteme erfüllen diese Bedingung: Windows Server 2012 + 2012 R2 Windows Server 2008R2 Windows Server 2008, 32-bit & 64-bit Windows 7, 32-bit & 64-bit Linux, 32-bit & 64-bit 1.2 Servlet Container Die Applikationen des security.manager sind Java Web Applikationen, die in einem Servlet- Container wie Apache Tomcat laufen. Empfohlene Produkte und Versionen: Tomcat 7.0.23+ mit JRE 1.7.0_13+ Tomcat 8.0.14+ mit JRE 1.8.0_25 + 1.3 Datenbank Management System Der security.manager verwaltet Daten datenbankbasiert. Empfohlene Produkte und Versionen: Oracle 10g, 11g, 12c PostgreSQL 8.4+ PostgreSQL 9+ Microsoft SQL Server 2008+ HSQLDB 2.2.7 1.4 Browser Folgende Browser werden unterstützt: Firefox Version ab Version 8.0 Microsoft Internet Explorer Version 8.0-11.0 Google Chrome ab Version 10 4
Apple Safari ab Version 5.x Aufgrund der Releasezyklen von Chrome und Firefox sind keine über den Verfügbarkeitszeitraum der sdi.suite Produkte gültigen Angaben möglich. 1.5 Optionale Komponenten 1.5.1 LDAP oder Active Directory Alternativ zur datenbankbasierten Verwaltung von Benutzern werden bestehende LDAP/ADS Verzeichnisdienste zur Verwaltung von Benutzern unterstützt. Wird die LDAP/ADS- Unterstützung ausgewählt, erfolgt deren Anbindung rein lesend, d.h. die LDAP/ADS Nutzer können zwar eingesehen, aber nicht modifiziert werden. Für die Authentifizierung werden ebenfalls die Benutzerdaten des angebundenen LDAP/ADS System lesend zugegriffen. Die Administration der Nutzerinformationen muss dann mit einem externen, nicht durch die Software bereitgestellten Werkzeug erfolgen. Weitere Informationen zur Einrichtung und Nutzung von LDAP/ADS sind im Benutzerhandbuch zu finden. Unterstützt werden: LDAP v2 und v3 Microsoft Active Directory Server (ADS) Anmeldung am ADS per simple-bind Anmeldung am ADS per Kerberos Die Authentifizierung erfolgt über das sogenannte simple bind, bei dem der Distinguished Name (DN) des Nutzers und sein Passwort übertragen werden. 1.5.2 Web Server Als Web-Server kann ein beliebiger HTTP-Server (z.b. Apache) verwendet werden. Voraussetzung ist, dass Apache Tomcat als Servlet/JSP-Engine eingebunden ist. Der Apache Tomcat kann auch direkt als Webserver verwendet werden. 1.5.3 SMTP Server Für das Versenden von Selbstregistrierungs-E-Mails wird ein SMTP Server benötigt. Diese Funktion steht bei LDAP basierter Nutzerverwaltung nicht zur Verfügung. 1.5.4 Web Feature Service für räumliche Berechtigung Die räumliche Berechtigung im security.manager erfordert einen installieren WFS-Dienst, der die WFS-Version 1.1.0 unterstützt. Hierzu können z.b. ein ArcGIS Server basierter WFS ab Version 9.3, ein Geoserver WFS ab Version 1.5 oder ein UMN MapServer WFS verwendet werden. Der Dienst muss flächenhafte Geometrie-Daten bereitstellen, die für die räumliche Berechtigung verwendet werden sollen. 5
1.6 Sprachen Alle Komponenten sind mehrsprachig. Deutsche und englische Sprachdateien sind in dieser Distribution enthalten. 6
2 Weitere Voraussetzungen Folgende Voraussetzungen müssen für den Betrieb und die Installation verfügbar sein: 2.1 HTTPS Der verwendete Web-Server muss über HTTPS zugreifbar sein, hierzu ist in der Regel ein SSL-Zertifikat erforderlich. Für Apache Tomcat ist dieser Dokumentation eine kurze Anleitung (siehe Kapitel Einrichten der HTTPS-Verbindung unter Apache Tomcat") angefügt. Weiterhin wird darauf hingewiesen, dass zur Laufzeit die prozessweit gültige Default- Trustmanager-Instanz des Tomcat gegen einen nicht die Zertifizierungsketten validierenden Trustmanager ausgetauscht wird. Das heißt, dass der Zertifizierungspfad von Server- Zertifikaten beim Aufbau von HTTPS-Verbindungen nicht überprüft wird sondern prinzipiell als gültig angenommen wird. Da die geänderte Trustmanager-Instanz innerhalb des gesamten Tomcat-Prozesses globale Gültigkeit besitzt, sollten Sie andere Web-Applikationen nicht im gleichen Tomcat-Prozess betreiben, wenn diese die Sicherheitsfunktionalität des Default-Trustmanagers benötigen bzw. wenn diese einen eigenen Trustmanager verwenden. Lediglich Web-Applikationen, die keinen Trustmanager verwenden bzw. die die eingeschränkte Sicherheitsfunktionalität nicht benötigen, können im gleichen Tomcat-Prozess betrieben werden. Dieser Trustmanager wird installiert um den Administrationsaufwand für das Einbinden neuer abzusichernder Dienste zu minimieren. Sollte dies den Sicherheitskriterien ihrer Umgebung nicht genügen, so kann die Installation des Trustmanagers durch einfache Konfiguration unterbunden werden. Wenden Sie sich dazu bitte gerne an uns. 2.2 UTF-8 Unterstützung Die verwendete Servlet Engine (bzw. der Web Server) muss UTF-8 als Encoding für URIs unterstützen. 2.3 Speichereinstellungen Abhängig von der verwendeten Servlet-Engine muss der zugewiesene Speicher erhöht werden. Folgende Werte werden für 64-bit Systeme empfohlen: -Xms256m Minimaler von der JVM alloziierter Speicher: 256 MByte -Xmx1024m Maximaler von der JVM alloziierter Speicher: 1024 MByte dies ist ein Richtwert, bei erwarteter hoher Last und vielen geschützten Diensten sollte der Wert entsprechend der verfügbaren Hardware erhöht werden Nur für Java Version 7 und älter :-XX:MaxPermSize=512m maximaler von der JVM alloziierter Speicher für statische Variablen und Klassen: 512 MByte Die Parameter sind ggf. zusätzlich analog zu den Proxy-Einstellungen zu setzen. 7
2.4 Datenbankberechtigungen Zur Ablage der Benutzer und Berechtigungen muss eine Datenbank in einem der unterstützten DBMS eingerichtet und zur Installation verfügbar sein. Zur Laufzeit müssen diese Datenbanken via JDBC vom Web Server erreichbar sein (INSERT, UPDATE, DELETE, SELECT). 8