Version: GSB 7Tomcat

Die Konfiguration des Tomcats unterstützt folgende Features:

1. Es werden standardisierte Fehlerseiten ausgeliefert, wenn der Tomcat bei der Verarbeitung auf einen Fehler trifft.
2. Es wird eine GSB Features unterstützende Tomcat Authentifizierung bereitgestellt.

Die Erweiterungen werden in den nachfolgenden Abschnitten beschrieben.

Fehlerseiten

Allgemeines

Um im Tomcat oder anderen Servlet-Containern angepasste Fehlerseiten z.B. für die Fehlercodes 403 (Access Denied), 404 (Resource not found) oder 500 (Internal Server Error) etc. anzulegen, sind in der Datei

bund/WEB-INF/web.xml

für jeden Fehlercode YYY Blöcke der Form

<error-page>
<error-code>YYY</error-code>
<location>/generator/common/ErrorPageYYY,templateId=renderError</location>
</error-page>

anzulegen.

Diese Blöcke müssen nach der Session-Configuration und vor den Taglib-Einbindungen erscheinen. (Dies ist eine Standard-J2EE-Konfiguration).

Mandantenspezifische Fehlermeldungen

Unter dem Pfad

/common/ErrorPageYYY

werden innerhalb des GSB Repositories ConfigCl2LinkList-Dokumente (d.h. eines für jeden YYY Fehlercode) abgelegt, in denen mandantenspezifische Fehler-Seiten registriert werden können. Pro Mandant darf in jeder ConfigCl2LinkList höchstens jeweils ein Eintrag existieren.

Für jede Cl2LinkListe gilt:

• In der TextClassifier-Property wird der Name des Mandanten eingegeben.
• In der LinkList-Property wird die tatsächlich zu rendernde Seite verlinkt.
• In der LinkClassifier-Property wird optional eine LOViewVariant verlinkt, mit der die Zielseite zu rendern ist. Wird kein solches Dokument angegeben, wird abhängig vom FehlerCode YYY das Template "renderErrorYYY.jsp" (also renderError404.jsp für den Fehlercode 404 etc.) gewählt.

Anmerkung:

Werden keine mandantenspezifischen Dokumente registriert, wird eine Standard-Fehlermeldung ausgegeben.

Sprach-, Bereichs- und Subsite-spezifische Konfiguration von Fehlermeldungen

Die Konfiguration der Fehlerseiten wird vorrangig im Mandanten selbst über den ConfigReader gesucht. Dadurch sind unterschiedliche Sprach-, Bereichs- und Subsite-spezifische Konfigurationen innerhalb desselben Mandanten möglich.

Auf dem Pfad, ab dem für untergeordnete Verzeichnisse die spezifischen Fehlermeldungen angewendet werden sollen, sind die Link-Dokumente in folgendem Verzeichnis abzulegen:

_config

Existiert das Verzeichnis noch nicht, ist es zuvor anzulegen. Verwendet werden ConfigCl2LinkList-Dokumente mit den Namen

• ErrorPage403
• ErrorPage404
• ErrorPage500

Die Zielseiten- und View-Konfiguration erfolgt in der Dokumentenliste und dem Linkclassifier.

Über das zweibuchstabige Sprachkürzel nach ISO 639 im Text-Klassifizierer wird die Sprache unterschieden. Die Login-Seiten werden exemplarisch in der deutsch- und englisch-sprachigen Version der GSB SL integriert.

Zur Ermittlung des anzuwendenden Config-Dokuments werden der Text Klassifizierer oder anhand der aufgerufenen URL das passende Verzeichnis ermittelt (durch den rekursiv arbeitenden ConfigReader).

Die bisherige Konfiguration über den Common-Pseudomandanten wird nur noch verwendet, wenn über den ConfigReader nichts gefunden wird.

Das Fehlerdokument ist bereitzustellen und im Feld „Link Liste“ zu verknüpfen.

Sprach-, Bereichs- und Subsite-spezifische Konfiguration von Login-Seiten

Ebenso wie die Konfiguration der Fehlerseiten (siehe Kapitel 7.1.3) werden jetzt auch Login-Seiten vorrangig im Mandanten selbst über den ConfigReader gesucht.

Verwendet werden ConfigCl2LinkList-Dokumente mit den Namen „LoginErrorPage“ und „LoginPage“.

Über das zweibuchstabige Sprachkürzel nach ISO 639 im Text-Klassifizierer wird die Sprache unterschieden. Die Login-Seiten werden exemplarisch in der deutsch- und englisch-sprachigen Version der GSB SL integriert.

Die Zielseiten- und View-Konfiguration erfolgt in der Dokumentenliste und dem Linkclassifier. Die Textclassifier „de“ und „en“ sind vorbereitet und werden für die Konfiguration der Sprache sprachabhängiger Zielseiten genutzt.

Zur Ermittlung des anzuwendenden Config-Dokuments werden der Text Klassifizierer oder anhand der aufgerufenen URL das passende Verzeichnis ermittelt (durch den rekursiv arbeitenden ConfigReader).

Die bisherige Konfiguration über den Common-Pseudomandanten wird nur noch verwendet, wenn über den ConfigReader nichts gefunden wird.

Einbinden weiterer Fehler Codes

Die Fehlercodes 403, 404 und 500 werden durch Fehlerseiten abgefangen.

Um zusätzliche Fehlercodes abzufangen sind die folgenden vier Schritte notwendig (sei YYY der Error-Fehlercode)

• In der Datei web.xml muss ein Eintrag der Form

<error-page>
<error-code>YYY</error-code>
<location>/generator/common/ErrorPageYYY,templateId=renderError</location>
</error-page>

vorgenommen werden.

Als Template wird also hier in der web.xml für alle Fehlercodes nur renderError verwendet. Verschiedene renderErrorYYY-Templates kommen erst für die verschiedenen Mandanten zum tragen.

• Im unteren Teil der JSP

bund/templates/ConfigCl2LinkList/renderError

muss der neue Fehler-Code YYY durch ein entsprechendes if-Statement abgefangen werden, um eine Standard-Fehlermeldung zu erzeugen.

• Für jeden Mandanten müssen für die verlinkten Mandanten-spezifischen Fehler-Dokumente Templates mit Namen "renderErrorYYY.jsp" angelegt werden.

Alternativ kann der TextClassifier des ConfigCl2LinkList-Eintrages des Mandanten als Namen den Namen des zu verwendenden Templates erhalten.

• Es muss unter

/common/ErrorPageYYY

eine ConfigCl2LinkList angelegt werden, innerhalb derer die Mandanten-spezifischen Seiten registriert werden (können).

ModSecurity-Fehlerseiten

Neben der Einbindung und Konfiguration von Standard-Fehlerseiten können auch Mandanten spezifische ModSecurity-Fehlerseiten definiert werden. Das Apache Modul ModSecurity wird verwendet, um potentiell bösartige HTTP-Anfragen zu erkennen und zu blockieren.

Die zu blockierenden Anfragen werden entweder mit einem HTTP-Fehlercode (bspw. 403) beantwortet, alternativ können die Anfragen auch zu einer Ziel-URL weitergeleitet werden, die dann für die Darstellung der Fehlerseite zuständig ist. Diese Konfiguration wird im GSB-Kontext genutzt, um die allgemeinen ModSecurity-Fehlerseiten im Context eines GSB-Mandanten darzustellen.

Vorbereitende Konfiguration

Der ModSecurity-Regelsatz wird global für eine Hostingplattform definiert und muss für die Anzeige von Mandanten spezifischen Fehlerseiten vorbereitet werden. Hier gilt es die Regeln zu identifizieren, die bspw. durch Fehleingaben von Nutzern eine Anfrage blockieren. Für diese Regeln können dann Mandanten spezifische Fehlerseiten konfiguriert werden. Die folgende Definition ist als DefaultRegel in der Datei modsecurity_mat.conf so konfiguriert.

SecDefaultAction "phase:2,log,redirect:/cae/servlet/path/common/SecurityError?msc=%{rule.id}&msvn=%{matched_var_name},t:lowercase,t:replaceNulls,t:compressWhitespace"

ModSecurity-Regeln bei denen die Default-Action ausgeführt wird rufen die URL /cae/servlet/path/common/SecurityError. Weiterhin werden noch die Request-Parameter msc und msvn gesetzt. Der Parameter msc enthält die ID der blockierten ModSecurity-Regel, der Parameter msvn enthält den Variablenname auf den die ModSecurity-Regel gematched hat.

Konfiguration im Mandanten

Die bisherigen Konfigurationen waren globaler Natur und sind auf Ebene der Infrastruktur durchzuführen. Für die Anzeige einer Mandanten spezifischen Fehlerseite müssen im GSB-Mandanten darüber hinaus noch einige Konfigurationen vorgenommen werden. So muss im GSB-Mandanten das Dokument _config/ErrorPageModSecurity (Dokumenttyp ConfigCl2Linklist) angelegt werden. Die klassifizierte LInkliste verlinkt analog zu den anderen Fehlerseiten auf die zu verwendende View (Link-Klassifizierer) und die Fehlerseite (Link Liste).

Hinweis

Da die Fehlerseite global durch ModSecurity aufgerufen wird, können keine Bereichs- und sprachspezifischen Fehlerseiten konfiguriert werden. Innerhalb eines Mandanten bzw. Subsite kann nur eine ModSecurity-Fehlerseite konfiguriert werden.

Der folgende Screenshot zeigt die Konfiguration exemplarisch am Beispiel der Standardlösung

ModSecurity Fehlerseite

Die eigentliche Fehlerseite wird wie skizziert im Dokument ErrorPageModSecurity verlinkt und referenziert eine GenericJsp. st ein Dokument vom Typ GenericJsp. Die GenericJsp enthält in der klassifizierten LInkliste Konfigurationsdokumente (cl2RelatedEnts)

• die Layout-Variante ErrorPageModSecurity sowie
• den allgemeinen Fehlertext (GeneralErrorText)

Die klassifizierte LInkliste Parameter (cl2Parameters) enthält dann weitere Fehlertexte. Im Textklassifizierer wird hierbei die ID der jeweiligen ModSecurity-Regel oder der Variablenname auf den die Regel gematched hat. die LInkliste verlinkt dann auf ein Label welches einen ID bzw. Variablennamen spezifischen Fehlertext enthält. Der folgende Screenshot skizziert die Konfiguraiton der GenericJsp exemplarisch und definiert spezielle Fehlertexte für die Regel mit der ID=1000002 und dem Variablennamen ARGS und Wert templateQueryString.

Die so konfigurierten Fehlercodes werden ausgegeben, wenn ein Nutzer in ein Suchfeld mit Namen templateQueryString einen Suchbegriff mit spitzen Klammern eingibt (bspw. '<script type="text/javascript">// <![CDATA[alert(1)// ]]></script>').

Tomcat Authentifizierung (FormAuthenticator)

Hintergrundinformationen

Über die Property

tomcat_should_apply_form_authentication_patch=true

in der Datei build_tomcat.properties kann die bis GSB-Version 3.x beiliegende angepasste Version der Klasse

org.apache.catalina.authenticator.FormAuthenticator

in den Tomcat eingebunden werden.

Diese angepasste Klasse implementiert die folgenden Erweiterungen:

• Die Klasse führt Redirects auf Login-Seiten etc. nicht auf den Tomcat-Port 8001, sondern auf den Port 80 und auf den im Request enthaltenen Hostnamen durch.
• Die Klasse ist durch die Datei

basis/config/ServeltContainer/TomcatPatches/org/apache/catalina/authenticator/FormAuthenticator.properties

konfigurierbar.

• Die Klasse setzt bei erfolgreichem Login in Datenbanktabelle BKCMS_TOMCAT_USERS in Spalte FAILED_LOGIN_COUNT für den aktuellen User auf 0 zurück.
• Zur Unterstützung der Mandantenfähigkeit akzeptiert die Klasse den zusätzlichen Parameter j_bkcms_username_suffix. Dieser wird mit einem @ als Trennzeichen an den Benutzernamen gehängt.

Authentifizierung und Mandanten

Da der GSB mandantenfähig ist, sind bzgl. der Authentifizierung besondere Vorkehrungen zu treffen. Hierzu ist, an dem für den WebSite Benutzer ersichtlichen Benutzernamen, ein den Mandanten identifizierender Suffix anzuhängen. Nur hierdurch ist es möglich die gleichen Benutzernamen für verschieden Mandanten zu vergeben.

Der WebSite-Benutzer sollte jedoch von seinem vollqualifizierten Benutzernamen eigentlich nichts wissen und immer nur mit dem mit der kurzen Form arbeiten. Die WebSite trägt daher die Verantwortung, im Hintergrund das korrekte Suffix zu setzen. In jedem Login-Formular sollte daher immer ein Hidden-Feld mit dem entsprechend gesetzten Parameter j_bkcms_username_suffix existieren, welches den Namen des Mandanten transportiert.

Beispiel:

Der Benutzer authentifiziert sich mit dem Namen user. Die WebSite transportiert den Namen des Mandanten (mandant.bva.bund.de) transparent über das Hidden-Feld zum GSB. Hierdurch ist die Überprüfung des vollqualifizierten Benutzernamens user@mandant.bva.bund.de möglich:

j_username=user

j_password=secret

j_bkcms_username_suffix=mandant.bva.bund.de

Um Konflikte zu vermeiden ist als Suffix ausschließlich die LDAP-Domäne des Mandanten zu wählen.

Erweiterungen der Datenbankschemata des Tomcats

In der DB-Tabelle BKCMS_CUSTOMERS wird neben dem Namen des Mandanten auch dessen Domain registriert. Die Tabellen BKCMS_TOMCAT_USERS wurde um die Spalte FULL_USER_NAME erweitert. Diese Spalte ist im Tomcat in der Datei

conf/server.xml

im Realm "UserDatabase" registriert und wird für die Authentifizierung verwendet. Sie enthält den vollen, eindeutigen Benutzernamen inkl. Suffix. Die bisher verwendete Spalte USER_NAME enthält den Benutzernamen ohne Suffix und dient als Display-Name.

In der Tabelle BKCMS_TOMCAT_USER_ROLES wurden die Spalten USER_NAME und ROLE_NAME durch die Spalten FULL_USER_NAME und FULL_ROLE_NAME ersetzt. Diese Tabelle dient der Abbildung der "many-to-many"-Beziehung der Registrierung von Benutzern in Gruppen. Sie ist im Tomcat in der Datei

conf/server.xml

im Realm "UserDatabase" registriert.

Abschließend wurde eine weitere Tabelle BKCMS_TOMCAT_ROLES angelegt, welche analog zu der USER-Tabelle, den ROLE_NAME, FULL_ROLE_NAME und eine ID_CUSTOMER besitzt. Hierdurch sind Rollen immer explizit einem Mandanten/Customer zugeordnet.

Die Zuordnung eines Benutzers zu einem Mandanten geschieht nicht über dessen Suffix, sondern über die Registrierung in der/den entsprechenden Gruppen des Mandanten. Es ist also an dieser Stelle möglich, einen Benutzer in mehreren Mandanten zu registrieren. Seine Domain würde dann keinen Aufschluss mehr über die Zugehörigkeit zu einem Mandanten geben.