Der CORBA Security Service

Auf das sehr umfangreiche Sicherheitsmodell des CORBA-Standards kann nur kurz eingegangen werden. Die genaue Spezifikation findet sich in [Os96], ein Kurzüberblick wird in [Or97] gegeben.
Der CORBA Security Service definiert einen kompletten Rahmen, in dem die Sicherheit verteilter Systeme realisiert werden soll. Konkret handelt es sich dabei um eine Sammlung von CORBA-Schnittstellen, die entweder von ORB-Herstellern oder den Anwendungen selbst implementiert werden müssen. Die Ziele, die durch die Verwendung des Security Services erreicht werden sollen, sind die unter 2.1 genannten. Dies kann dabei auf zwei verschiedenen Ebenen erreicht werden: Die System-Ebene, wo der ORB die Verwaltung der Sicherheit übernimmt, und die Anwendungsebene, in der die Anwendung selbst die notwendigen Schritte zur Sicherheit unternimmt. Der Hintergrund dieser Aufteilung ist, daß einerseits ORBs auch Anwendungen sicher machen sollen, die selbst über keinerlei Sicherheitsmechanismen verfügen (sog. sicherheitsunbewußte Anwendungen - security unaware applications); andererseits sollen Anwendungen die Möglichkeit haben, die Sicherheitsmöglichkeiten mit ihrer Semantik zu verknüpfen (etwa ein Bank-Server, der Transaktionen ab einem bestimmten Geldbetrag besonderen Sicherheitsbestimmungen unterstellt).

Die Integration des Security Service in den ORB findet wie bei allen anderen CORBA-Services durch zusätzliche Objekte statt, die sich aufgrund ihrer Darstellung in (Pseudo-)IDL als normale CORBA-Objekte ansteuern lassen. Als Beispiel und im Hinblick auf die bisher vorrangig betrachtete Frage ``Wer darf was?'', wollen wir schrittweise ein Szenario betrachten, in dem ein Client eine Methode in einem entfernten Server aufruft. Beide Objekte sollen dabei sicherheitsunbewußt sein, d. h. es soll lediglich die Sicherheit auf System-Ebene betrachtet werden (Abb.7):

 

Abbildung 7: Objektsicherheit beim entfernten Methodenaufruf

Anmeldung und Authentisierung des Benutzers: Durch ein System-Programm wird der Benutzer (Principal) aufgefordert, sich - z.B. durch Eingabe eines Paßworts - beim ORB zu authentisieren.

Erzeugung eines Sicherheitstickets: Der PrincipalAuthenticator gibt ein oder mehrere beglaubigte Sicherheitstickets in Form eines Credentials-Objekt aus, das die Identität und die Rechte (Privileges) als Attribute enthält. Dies ist der ``Ausweis'' des Principals.

Erzeugung und Konfiguration eines Ausführungskontextes: Durch den Aufruf von ORB::get_current() enthält das System eine Referenz auf den aktuellen Ausführungskontext Current. Diesem werden dann mittels set_credentials() die Sicherheitstickets übergeben.

Aufruf der Methode im entfernten Objekt: Der Methodenaufruf erfolgt normal. Neben der üblichen Information über Parameter etc. wird dem Request vom Security Service ein service_context (s. 1.3.2) beigefügt, der auf zusätzliche Informationen verweist. Anhand dieser Informationen extrahiert der Security Service auf Serverseite das Current-Objekt mit den zugehörigen Credentials.

Ausführung der Methode durch das entfernte Objekt: Es werden zunächst die Attribute aus den Credentials ausgelesen. Daraufhin wird durch das AccessDecision-Objekt überprüft, ob der Client auf die entsprechende Servermethode zugreifen darf. Die Überprüfung wird anhand von ORB-internen Access Control Listen vorgenommen, für deren Einrichtung ebenfalls ein Interface existiert.

Die Spezifikation des Security Service wurde im Hinblick auf die Wichtigkeit der Sicherheit verteilter Objekte weitreichend gefaßt, was jedoch zur Folge hat, daß Implementationen seitens der ORB-Hersteller zur Zeit noch auf sich warten lassen. Der nun folgende Ansatz beschreibt eine bereits bestehende, vergleichsweise einfache Alternative der Firma Iona Technologies.