Security ist ein allgegenwärtiger Begriff bei der Entwicklung von Software. Dies gilt sowohl für Anwendungen für den privaten Gebrauch als auch für Unternehmensanwendungen. Dabei lässt sich der Begriff Security in unterschiedliche Bereiche unterteilen:

• Authentifizierung
• Sichere Kommunikation
• Datensicherheit
• Autorisation

Jeder dieser Aspekte muss im Rahmen einer Implementierung entsprechend den Anforderungen berücksichtigt werden. Für Authentifizierung und Autorisation bietet Eclipse RCP bereits Mechanismen, deren Verwendbarkeit in einer verteilten Umgebung jedoch überprüft werden muss.

Authentifizierung

Im Rahmen des Equinox-Security-Projekts bietet Eclipse RCP die Möglichkeit, für die Authentifizierung JAAS zu verwenden [2]. Somit kann hier die Standard-Java-Login-Infrastruktur zum Einsatz kommen, typischerweise erfolgt die Authentifizierung dann gegen ein LDAP-System. Im Kontext einer verteilten Anwendung ist allerdings zu bedenken, dass eine durch den Client gesteuerte Authentifizierung gegen ein Fremdsystem zwar grundsätzlich möglich ist, architekturbedingt jedoch die Kommunikation mit anderen Systemen immer zentral durch die Serverseite erfolgen sollte. Diese stellt dafür üblicherweise einen Dienst bereit, den der Client verwenden kann. Entsprechend des im vorherigen Teil vorgestellten Spring Remotings würde die Serverseite einen Service anbieten, der vom Client zur Authentifizierung genutzt wird.

1. public interface ISecurityService {
2. String login(String userId, String password);
3. }

Der Service liefert als Rückgabewert einen Token, der bei zukünftigen Requests mittels Piggybacking, also transparent im HTTP Request Header, vom Client mit übermittelt werden muss. Der Token kann auf beiden Seiten, Client- und Serverseite, aspektorientiert behandelt werden. Mit einem Aspekt um die vom Client verwendeten Remote-Services kann der Token auf der Serverseite überprüft werden. Der serverseitige Aspekt kann leicht über die Spring-Konfiguration deklariert werden.

1. <bean class="org.springframework.aop.framework.ProxyFactoryBean" id="fooRemoteService">
2. <property name="proxyInterfaces" value="com.demo.IFooRemoteService"/>
3. <property name="target" ref="fooRemoteServiceTarget"/>
4. <property name="interceptorNames">
5. <list>
6. <value>securityAdvice</value>
7. </list>
8. </property>
9. </bean>
10. <bean class="com.foo.SecurityAdvice" id="securityAdvice">
11. <property name="contextProvider" ref="contextProvider"/>
12. </bean>

Der SecurityAdvice überprüft dabei den vom Client bereitgestellten Token, den er über die ContextProvider-Bean zur Verfügung gestellt bekommt.

1. public class SecurityAdvice implements MethodBeforeAdvice {
2. private IContextProvider contextProvider;
3. public void before(Method method, Object[] arguments, Object returnType) throws Throwable {
4. ISessionService sessionService = (ISessionService) applicationContext.getBean("sessionService");
5. if (!sessionService.isValid(contextProvider.getContextSessionId())) {
6. throw new SessionInvalidException("Session <"contextProvider.getContextSessionId() + "> is invalid.");
7. }
8. }
9. }

Ein HTTP-Filter hat die Informationen zuvor aus dem http-Request ausgelesen und dem ContextProvider über einen ThreadLocal zugänglich gemacht.

Sichere Kommunikation

Bei der beschriebenen Methode wird der Token bei jedem Request mit übertragen und genügt, um auf die Dienste des Servers zurückzugreifen. Um diesen Mechanismus zu schützen, kann bei einer Kommunikation durch unsichere Netzwerke auch HTTPS als Protokoll verwendet werden. Spring bietet zu diesem Zweck den CommonsHttpInvokerRequestExecutor.