Version: GSB 7Site-Administration

In diesem Kapitel wird der site-administrative Teil von Zugriffsbereichen vorgestellt. Dabei wird zunächst die Tomcat-Konfiguration erläutert. Daran schließen sich Erläuterungen zu Rollenverwaltung, Verwaltung von Zugriffsbereichen sowie Ausführungen zur Benutzerwaltung an.

Konfiguration des Spring-Security-Frameworks

Für die Integration des Spring-Security-Frameworks wird ein Servlet-Filter in der web.xml wie folgt konfiguriert:

<syntaxhighlight lang="xml" enclose="div">

 <filter>   <filter-name>springSecurityFilterChain</filter-name>   <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter>

</syntaxhighlight> Die Klasse FilterChainProxy führt eine Kette von Servlet-Filtern als Liste von Spring-managed Beans aus. Dies ist der einzige Filter, der in der web.xml mit Hilfe eines FilterToBeanProxy definiert werden muss.

Die Filter-Mapping wird in der web.xml wie folgt definiert:

<syntaxhighlight lang="xml" enclose="div">

 <filter-mapping>   <filter-name>springSecurityFilterChain</filter-name>   <url-pattern>/*</url-pattern>  </filter-mapping>

</syntaxhighlight> Das skizzierte Beispiel definierte einen Filter der für alle URLs (/*) verwendet wird.

Die genaue Definition des Mappings und eigentliche Konfiguration des Acegi Frameworks erfolgt in der Datei acegi-security.xml.

Konfigurationsdatei acegi-security.xml

In der Konfigurationsdatei acegi-security.xml wird die Filter-Kette wie folgt konfiguriert:

<syntaxhighlight lang="xml" enclose="div"> <bean id="springSecurityFilterChain" class="org.springframework.security.util.FilterChainProxy">

   <property name="filterInvocationDefinitionSource">     <value>       PATTERN_TYPE_APACHE_ANT       /admin/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,       securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor

       /servlet/path/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,       securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor              /servlet/contentblob/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,       securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor

       /servlet/contentpathblob/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,       securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor

       /servlet/action/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,       securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor

       /j_acegi_security_check=httpSessionContextIntegrationFilter,authenticationProcessingFilter,rememberMeProcessingFilter,       securityContextHolderAwareRequestFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor       /**=#NONE#     </value>   </property> </bean>

</syntaxhighlight> Die filterInvocationDefinitionSource bestimmt anhand der URL, ob und, falls ein passender Mapping-Eintrag gefunden wurde, welche Filter-Kette ausgeführt werden soll. Die Ausführung stoppt, sobald ein passender Eintrag gefunden wurde. Mit Hilfe des TOKEN_NONE (#NONE#) kann eine Ausführung für ein URL-Pattern verhindert werden.

Folgende Filter werden eingesetzt:

• httpSessionContextIntegrationFilter - liest Informationen zum SecurityContext aus der HttpSession oder erzeugt einen neuen, falls keine gefunden wurde.
• authenticationProcessingFilter - wertet die durch ein Login-Formular übermittelten Daten (j_username und j_password) mit Hilfe des eingestellten authenticationManager aus.
• rememberMeProcessingFilter – behandelt die automatische Anmeldung mit Hilfe von persistenten Cookies.
• securityContextHolderAwareRequestFilter - dieser Filter sorgt durch Wrapping des ServletRequest dafür, dass die Methoden isUserInRole(), getUserPrincipal() und getRemoteUser() des HttpServletRequests mit Spring-Security kompatibel sind.
• anonymousProcessingFilter - falls im SecurityContextHolder keine Authentication-Objekt vorhanden ist, wird ein neues erzeugt. Mit userAttribute wird der Principal (anonymousUser) und seine GrantedAuthorities (ROLE_ANONYMOUS) festgelegt.
• exceptionTranslationFilter - falls bei der Auswertung des filterInvocationInterceptor eine AuthenticationException geworfen wird, die anzeigt, dass eine Authentifikation/Authorisation erforderlich ist, wird mit Hilfe des authenticationEntryPoint eine Authentifikation durchgeführt. Der eingestellte AuthenticationProcessingFilterEntryPoint leitet den Benutzer an die mit loginFormUrl angegebene URL weiter. In der Regel ist dies die JSP mit dem Login-Formular. Mittels accessDeniedHandler wird beim Werfen einer AccessDeniedException an eine Fehler-Seite weitergeleitet.
• FilterInvocationInterceptor – ersetzt die security-constraints der web.xml mit der im objectDefinitionSource eingestellten Implementierung, die einer URL eine oder mehrere benötigte Rollen zuordnet.

Das objectDefinitionSource liest mit Hilfe des eingestellten actionDao die Zuordnung von URL zu benötigten Rollen aus einer Datenbank.

Authentifizierung und Mandanten

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

Der WebSite-Benutzer sollte jedoch von seinem vollqualifizierten Benutzernamen eigentlich nichts wissen und immer nur mit der kurzen Form arbeiten. Der Name des Mandanten ist durch die mandantenspezifische Konfiguration des Apache immer eindeutig definiert.

Beispiel:

Der Benutzer authentifiziert sich mit dem Namen user. Der Apache-Webserver transportiert den Namen des Mandanten transparent über eine Rewrite-Regel zum GSB. Hierdurch ist die Überprüfung des vollqualifizierten Benutzernamens user@mandant möglich:

<syntaxhighlight lang="xml" enclose="div"> j_username=user j_password=secret </syntaxhighlight>

Um Konflikte zu vermeiden sollte als Suffix die Domäne (z.B. die LDAP-Domäne) des Mandanten gewählt.

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 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.

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.