next up previous contents
Next: Fazit Up: Orbix Wonderwall Previous: Zugriffssicherung

Konfiguration

Da die Wonderwall einige der in den vorherigen Kapiteln vorgestellten Konzepte implementiert, wollen wir sie auch auf technischer Ebene betrachten, um einen Überblick über die konkreten Möglichkeiten bei der Konfiguration zu gewinnen. Dazu betrachten wir die im Insekten-Simulator-Projekt benutzte Konfigurationsdatei als Beispiel:

########################################################################
# file iiopproxy.cf - a sample WonderWall configuration file
 
# general options
domain          uni-muenster.de
log requests replies
 
# iiop-port listening for incoming calls:
port            1670
 
# used by the built-in http-server:
http-port       8080
http-files      /u/paehler/public/InsectSim.2.0
 
# Object Database
#
# {Kernel,Sim}_Context is declared as server, so objects produced by it apply 
# to the same rules as {Kernel,Sim}_Context itself:
 
server Kernel_Context \
        /u/paehler/public/InsectSim.2.0/tmp/Kernel_server.ior 
server Sim_Context \
        /u/paehler/public/InsectSim.2.0/tmp/Sim_server.ior 
 
# ... other objects might follow
 
# Acess Control List
# anything not stated below is access denied by default
 
# we do not need any IIOP Service Contexts:
deny servicecontexts *
 
# control-object should only be available to a secure host:
allow object Sim_Context op getControl \
      ipaddr 128.176.182.64/255.255.255.192 \
      principal paehler
deny object Sim_Context op getControl
 
# all other operations for {Sim,Kernel}_Context (createInsect(), 
# getStatistic() etc.) are available to the outside world:
allow object Sim_Context  
allow object Kernel_Context  
 
# if the message has not matched a rule until now, it will be 
# denied automatically
Der sicherheitsrelevante Teil der Konfigurationsdatei ist in zwei Teile aufgespalten: Die Objekt-Datenbank, in der verschiedene IORs mit einem Namen und Eigenschaften versehen werden, und der ACL, in der den benannten Objekten die entsprechenden Zugriffsrechte zugeordnet werden. Die Einträge in der Objektdatenbank bestehen lediglich aus einem Schlüsselwort (object, server), einem Namen (Sim_Context, Kernel_Context) und einem Dateipfad, unter dem die IOR des Objektes gespeichert ist. Das mit Kernel_Context benannte Objekt verweist in unserem Beispiel auf ein Programm, das das Interface Kernel::Context implementiert und beim Aufruf von createInsect() eine Referenz auf ein Insect-Objekt zurückgibt. Damit eine solche Referenz ebenfalls von der Wonderwall entsprechenden Zugriffs- und Weiterleitungsbestimmungen zugeordnet werden kann, wird Kernel_Context als server deklariert, was bedeutet, daß alle Objekte, die von ihm erzeugt werden den gleichen Bestimmungen unterliegen wie das Server-Objekt selbst. Für die Schnittstelle Sim::Context, der der symbolische Name Sim_Context zugeordnet wird, gilt dies ebenfalls, da sie z.B. die Referenz auf das Control-Objekt zurückgeben soll. Einfache CORBA-Objekte würden dagegen als object deklariert.
Die ACL ist im Prinzip selbsterklärend: einem allow oder deny folgt der in der Objektdatenbank festgelegte Bezeichner sowie eine Anzahl an Auswahlkriterien, die zur Anwendung der Regel erfüllt sein müssen. Bei mehreren Regeln gelten diese als mit einem logischen UND verknüpft, so kann z.B. Sim::Context::getControl() nur von dem Benutzer paehler auf einem Rechner mit der Adresse 128.176.182.(65 - 127) aufgerufen werden.
Wird nun wie im obigen Beispiel eine Anfrage an die Wonderwall gestellt, so werden zusätzlich zu dem bereits beschriebenen Proxifizierungsprozeß die Zugriffsrechte auf das spezifizierte Objekt überprüft. Dabei wird - wie im allgemeinen üblich - die ACL von oben nach unten durchgearbeitet, bis sich eine Regel findet, die den Zugriff auf das in Frage kommende Objekt explizit erlaubt oder verbietet. Findet sich eine solche Regel, wird der Abarbeitungsvorgang abgebrochen. Das bedeutet, daß bei sich widersprechenden Regeln diejenige in Kraft tritt, die in der Datei weiter oben steht. Im konkreten Beispiel heißt das, daß die Regel deny object Sim_Context op getControl nur dann zum Verbot des Zugriffs führt, wenn die vorangehende Regel nicht zur Anwendung gekommen ist.


next up previous contents
Next: Fazit Up: Orbix Wonderwall Previous: Zugriffssicherung
Tim Paehler
1998-05-12