next up previous contents
Nächste Seite: 6.8 Klassen für gesicherte Aufwärts: 6. Implementierungskonzept Vorherige Seite: 6.6 Authentisierung   Inhalt

Unterabschnitte


6.7 Autorisierung und Überwachung der Schnittstellen

Für das Fällen der Entscheidung, ob eine Aktion ausgeführt werden darf oder nicht, muß in MASA eine neue Komponente eingeführt werden, der Permission Manager.

Der Permission Manager implementiert dann die in Kap. 5.8.3 informell beschriebene Syntax für Policies in MASA. Weiterhin muß er die Möglichkeit bieten, dynamisch die Permission Policies von Agenteninstanzen zu integrieren, sowie die Capabilities einer Agenteninstanz miteinbeziehen. Des weiteren besitzt er eine Schnittstelle, mit der abgefragt werden kann, ob eine Aktion für eine konkrete Entität erlaubt ist.


6.7.1 Integration in die Java Platform 2 Security Architecture

Um die mit der Java Platform 2 Security bereits vorhandenen Mechanismen zur Autorisierung von Aufrufen des Java-API nutzen zu können muß der Permission Manager in die JDK 1.2 Sicherheitsarchitektur integriert werden. Dies geschieht, indem die Implementierung des Permission Managers von java.security.Policy abgeleitet wird und dann als globale Java-Policy nach [JDK1.2-SDK] in der JVM installiert wird.

Um im Sicherheitsmodell von JDK 1.2 die lokalen Agenteninstanzen repräsentieren zu können, ist mit den Protection Domains bereits ein genau passender Mechanismus vorhanden. Errichtet man für jede lokale Agenteninstanz eine eigene Protection Domain, so können durch die in JDK 1.2 bereits vorhandenen Sicherheitsmechanismen die einzelnen Agenteninstanzen unterschieden werden.

Wird nun durch einen Java-API Aufruf der Java Access Controller befragt, bezieht dieser indirekt den Permission Manager in die Entscheidung mit ein, da der Access Controller die Java System Policy benutzt, um zu entscheiden, ob die zum Aufrufer gehörige Protection Domain über ein entsprechendes Recht verfügt. Über die Protection Domain kann dann der als System Policy Objekt installierte Permission Manager herausfinden, um welche Agenteninstanz es sich bei dem Aufrufer handelt und entsprechend die Regeln der Permission Policy anwenden.


6.7.2 Überwachung der Schnittstellen

Für die Überwachung der Schnittstellen muß zwischen zwei Arten unterschieden werden:

6.7.2.1 ``Eigene'' CORBA-Schnittstellen

Die Überwachung eigener CORBA-Schnittstellen wird einfach dadurch realisiert, daß die Methoden, die die einzelnen Funktionen der Schnittstelle implementieren, überwacht werden.

Konkret führt man in der Implementierung einer solchen Methode als erste Aktion die Entscheidung durch, ob der Funktionsaufruf autorisiert werden kann oder nicht. Dies geschieht dadurch, daß man über den Permission Manager eine Abfrage der Permission Policy durchführt.

6.7.2.2 ``Fremde'' CORBA-Schnittstellen


Für den Fall, daß eine fremde CORBA-Schnittstelle überwacht werden soll, ist die im vorangegangenen Abschnitt beschriebene Technik nicht einsetzbar, da kein Zugriff auf den Quelltext der zu überwachenden Methoden besteht.

Wird an einer CORBA-Schnittstelle einer Agenteninstanz eine Funktion aufgerufen, so geschieht dies konkret dadurch, daß die ORB-Instanz die entsprechende Methode in der Agenteninstanz ausführt. Damit nun das Agentensystem diese Schnittstelle überwachen kann, müßte das Agentensystem durch den ORB zur Autorisierung befragt werden, bevor dieser die Methode der Agenteninstanz aufruft. Das Agentensystem ist also für diesen Fall auf die Zusammenarbeit mit dem ORB angewiesen und kann von sich aus keine Maßnahmen ergreifen.

Nur wenn der verwendete ORB die sog. Access Decision Objekte (Teil der Security Functionality Level 2; [OMG 98-12-17]) unterstützt, ist eine standardisierte Schnittstelle für die Kooperation mit dem ORB gegeben. Da aber kein z. Zt. erhältlicher ORB die Security Funcionality Level 2 implementiert, besteht im Rahmen dieses Implementierungskonzepts keine direkte Möglichkeit, daß ein Agentensystem die Schnittstellen einer Agenteninstanz überwacht.

6.7.2.3 Schnittstellen des Endsystems

Für die Schnittstellen des Endsystems, die durch das Java-API repräsentiert werden, bietet die Java 2 Security Architecture bereits die entsprechenden Möglichkeiten. Da der Permission Manager mit Abschnitt 6.7.1 in die Sicherheitsarchitektur eingebunden ist, werden diese Mechanismen automatisch benutzt.

Da bei Verwendung einer Methode aus dem Java-API, die kritische Aktionen durchführt, und somit bestimmte Rechte benötigt, automatisch der Access Controller befragt wird, wird mit der in Abschnitt 6.7.1 angegebenen Technik über den Permission Manager auch die Permission Policy ausgewertet.

Durch den Access Controller wird dann überprüft, ob die Agenteninstanz, aus der der Aufruf durchgeführt wurde, über ein entsprechendes Recht verfügt, das den Aufruf der Methode gestattet.


Die Verwendung von zusätzlichen Bibliotheken, die keine Überwachung durch den Access Controller implementieren, kann nicht bis auf die Ebene der einzelnen Methoden kontrolliert werden. Allerdings kann durch die Trennung der Namensräume eine Kontrolle bis auf die Ebene der Klassen durchgeführt werden.

Soll beispielsweise die Benutzung einer SNMP-Bibliothek, die im Package com.one_company.snmp implementiert ist, exklusiv der Gattung com.other_company.SNMP_Agent erlaubt werden. Dann kann der Zugriff auf die Bibliothek eingeschränkt werden, indem nur die Classloader von Agenteninstanzen der Gattung com.other_company.SNMP_Agent das Laden von Code aus dem Package com.one_company.snmp gestatten. Die Classloader anderer Agenten dagegen verweigern das Laden von Klassen aus diesem Package. Zur Entscheidung, ob eine Klasse geladen werden darf, befragt der Classloader den Permission Manager.


next up previous contents
Nächste Seite: 6.8 Klassen für gesicherte Aufwärts: 6. Implementierungskonzept Vorherige Seite: 6.6 Authentisierung   Inhalt
harald@roelle.com