8. Richtlinien zur Agentenimplementierung

In diesem Kapitel sollen einige Hinweise gegeben werden, die für die Implementierung einer Agentengattung beachtet werden sollten.

Ein guter Ausgangspunkt für jede Implementierung ist dabei die FOO-Agentengattung. Diese Gattung wurde speziell zu Demonstrationszwecken erstellt und bietet eine gute Basis, da hilfreiche Details zur Programmierung und dem Umgang mit der Produktionsumgebung in der Distribution enthalten sind.

Den Applets muß bei der Implementierung besondere Aufmerksamkeit geschenkt werden. Nach Kap. 5.5.1 können Applets durch die Agenteninstanz nicht authentisiert werden. Wird nun durch ein Applet eine Aktion angefordert, so kann nicht überprüft werden, ob die Anforderung tatsächlich vom ``eigenen'' Applet kommt oder von einem anderen, feindliche Absichten hegenden Applet versendet wurde. Für den naheliegenden Gedanken, Autorisierungsentscheidungen auf einem Applet zu treffen, heißt das, daß nicht gewährleistet werden kann, daß die Autorisierung tatsächlich durchgeführt wurde.

Einem Beispiel: Eine Agenteninstanz biete zwei Methoden M und X an, die beide durch das Applet dargestellt werden. Dabei solle X nur von bestimmten Anwendern genutzt werden dürfen. Wird die Überprüfung, ob X vom aktuellen Anwender ausgeführt werden darf, nur auf dem Applet durchgeführt, so entsteht ein Sicherheitslücke. Ein Angreifer kann nämlich ein anderes Applet benutzen, das die Überprüfung nicht durchführt, ohne daß dies von der Agenteninstanz bemerkt werden könnte.

Deshalb: Jegliche Autorisierungen immer durch die Agenteninstanz durchführen, niemals (alleinig) durch das Applet.

Nachfolgend einige weitere Richtlinien, die bei der Implementierung zu beachten sind:

• Kritische Berechnungen möglichst nur auf ``sicheren'' Agentensystemen durchführen.

• Kritische Daten nach Möglichkeit nur verschlüsselt, zumindest aber signiert ablegen.

• Eine genau Spezifikation anfertigen, welche Aktionen auf dem Endsystem ausgeführt werden, welche Klassen hierfür benötigt werden und mit welchen anderen Agenten wie kooperiert wird.

• Benutzung der eigenen CORBA-Schnittstelle immer autorisieren.

• Keine öffentlich zugreifbaren Java-Schnittstellen schaffen, besonders nicht in Klassen, die public deklariert sein müssen, da sie CORBA-Funktionen implementieren.

• Agentengattungen sollten nach Möglichkeit in genau einem Java-Package implementiert werden, das ermöglicht die optimale Nutzung von Visibilitätsmodifikatoren:

• Klassen, die nicht abgeleitet werden sollen, final deklarieren.

• Klassen, die nur von der eigenen Agentengattung benötigt werden, package deklarieren.

• Methoden, die nicht überladen werden sollen, final deklarieren.

• Methoden, außer jene, die CORBA-Funktionen implementieren, möglichst nie public deklarieren.

• Methoden, die nur von der eigenen Agentengattung benötigt werden, package deklarieren.

• Methoden, die nur in der deklarierenden Klasse benötigt werden, private deklarieren.

• Attribute, deren Werte nur einmalig im Constructor der Klasse gesetzt werden sollen, final deklarieren.

• Attribute immer private deklarieren.

• Wenn auf Attribute außerhalb einer Klasse zugegriffen werden muß, Zugriffsmethoden (get()/set()-Methoden) bereitstellen, dabei auf Visibilitätsmodifikatoren achten. Überprüfungen auf semantische Korrektheit in der set()-Methode durchführen.