Projektstudium
SS98 - distributed computingProjektstudium
SS98 - distributed computing
Nach dem wir uns in den Vorrangegangenen Abschnitten recht eindringlich mit der Implementation der Sicherheitsarchitektur in CORBA beschäftigt haben, betrachten wir nun wie auch schon bei RMI und Java zwei Ausgewählte bereiche. Dies wird zum einenen die Zugriffskontrollen von Seiten der Anwendungsentwickler und zum anderen Zugriffsrechte oder Permissions von Seiten des Administrators sein.
Beschreibung der Einrichtungen
Zugriffspolitik für Anwendungen könnte auf den folgenden Arten und Weisen durchgeführt werden:
Wir betrachten nun im folgenden wie Anwendungen ihre eigenen Zugriffskontrollen durchführen , oder die automatischen Kontrollen erweitern können.
Wie wir schon gesehen haben wird für die Entscheidung ob ein Zugriff erlaubt wird oder nicht das folgenden benutzt:
Die prinzipellen Referenzen (welche entweder ihre Privilegien enthalten oder die Prinzipale identifizieren so das sie herangezogen werden können). Um nur die generelle Identität zu nutzen, setzt voraus, daß sie bei allen Zielen bekannt sein muß.Das führt zu Skalierbarkeitsproblemen, daher wird es nicht so oft benutzt. Die Benutzung der prinzipellen Rollen oder Gruppen ist eher wahrscheinlich einfachere Administration in großen Systemen zu gewährleisten. Firmeneigene definirte Attribute können ebenfalls benutzt werden, so weit sie unterstützt werden
Die Anwendungen benutzen Rechte mit Schnittstellen verknüpft eher, als das sie für individuale Operationene Kontrollen definieren. Regeln der Sicherheitspolitik benutzen diese Informationen um die Zugriffskontrollentscheidungen durchzuführen.
Die Zugriffspolitik wird automatisch vom ORB währen der Objektanfrage durchgeführt. Dies könnte zu Zugriffen auf den Prinzipellen Referenzen, den Zielkontrollattributen, den Operationnen und der Zeit führen, (obwohl die Zeit nicht im standard Zugriffsploitiken benutzt wird.). Wie auch immer, der ORB nutzt nicht diese Parameter für die Operationen von Zugangskontrollen. Als Beispiel, wenn es eine Regel gibt, das nur Senior Manager berechtigt sind Ausgaben über 5000 DM vorzunehmen, so ist es für die Anwendung nötig seine eigenen Test durchzuführen. Wo eine Anwendung seine eigenen Zugangskontrollen durchführt, wird sie zuständig für die Verwaltung der eigenen Kontrollinformationnen über Operationen, Funtionen und Daten, die sie beschützen will. Sie kann dieses tun, indem sie ihre eigenen speziellen Funktionnen und Daten definiert, aber in einigen Fällen, ist es möglich dieses durch eine mehr typische Art von Zugriffsentscheidungen durchzuführen, und in diesen Fällen, kann es möglich sein ein gemeinsames Zugrifsentscheidungungsobjekt zu benutzen, mit gemeinsamer Administration der Kontrollattribute.
Schnittstellen
Anwendungszugriffsentscheidungsfunktionen sollten von Zugriffsentscheidungsobjekten übernommen werden. Dies mag dazu führen, das verschiedene Informationen benötigt werden, abhängig von , zum Beispiel, den Aktionen oder Daten, welche Kontrolliert werden sollen , und den Regeln der Sicherhietspolitik als vorangehende Beschreibung. Die Zugriffsentscheidungsobjekte sollten eine
access_allowed Operation unterstützen, welche verwendet wird die Zugriffspolitik in ORB’s durchzuführen. Die Eingabe Parameter von diesem sollten normalerweise folgendes definieren:
Der Rückgabewert von diesen
access_allowed Operationen sollte TRUE sein, wenn der Zugriff erlaubt wird und sonst FALSE.
Es ist empfehlenswert, daß wo möglich, Zugriffsentscheidungen von Zugriffsentscheidungsobjekten gemacht werden (oder zumindest speziellen internen Funktionen), die die Details von der aktuellen Sicherhietspolitik verbergen, so daß Anwendungen diese nicht zuwissen brauchen.
Portable Implikationen
Portabilität von Anwendungen, die ihre eigenenen Zugriffskontrollen durchführen wird verbessert durch die Benutzung von Zugriffsentscheidungsobjekten wie zuvor schon beschrieben. Die Anwendung brauch dann nicht die genauen Regeln kennen und auch nicht die Prinzipals und Objektattributtypen, die zur Entscheidung ob ein Zugriff erlaubt wird oder nicht benutzt werden. (Es kann ebenfalls verbergen, ob eine Referenz eines Prinzipals alle benötigten Privileginattribute beinhaltet, oder ob sie dynamisch erhalten werden.)
Bei verschiedenen Systemen könnte es nötig sein verschiedene Zugriffskontrollpolitiken zu unterstützen. Beim Verstecken von Details der Zugriffskontrollregeln wird ein standard Interface verwendet um dieses durchzuführen. Die Anwendung wird dadurch portabel zu Umgebungen mit verschiedenen Sicherheitspolitiken. Anwendungen, die ihren eigenen speziellen Code benutzen um Zugriffsentscheidungen zu machen, sind nur portabel zu Systemen, die die Identitäten und Priviligenattributtypen, die verwendet wurden, in der selben Syntax benutzen.
Wie wir sehen scheint es generell zu Problemen zu führen, wenn Anwendugen eigenen Zugriffskontrollen benötigen. Dieses Problematik wurde in CORBA schon durch die einführung eines Zugriffsentscheidungsobjekt versucht zu abstrahieren, ist ihnen aber wohl nur teilweise gelungen.
Zugriffspolitiken
Es gibt zwei Aufruf-Zugriffs-Politiken: die ClientInvocationAccess Politik, welche auf der Client-Seite für einen Aufruf benutzt wird, und die TargetInvocationAccess Politik, welche auf der Zielseite benutzt wird.
Es gibt einen Poliktyp für Anwendungszugriffe. Wie auch immer, es ist keine standard Administrationsschnittstelle definiert, weil verschiedene Anwendugen Verschiedenen Bedürfnisse haben.
Zugriffs Politik Kontrollen gereifen mit S
ubjekten (die Privileginattribute besitzen), auf Objekte zu,unter der Benutzung von
Rechten.
Rechte
Die standard Zugriffspolitik Objekte in einen sicheren CORBA System benutzen Rechte, um die Zugriffspolitik zu implementieren. In Recht-basierten Systemen, geben AccessPolicy Objekte Rechte an PrivilegeAttributes weiter. In einen sicheren Objekt witd für jede Operation in der Schnittstelle eine Menge von Rechten benötigt. Aufrufer müssen diese verlangten Rechte besitzen, um erlaubt zu sein eine Operation aufzurufen. Sichere CORBA Systems unterstützen eine RequiredRights Schnittstelle, welche folgendes erlaubt:
Ein RequiredRights Objekt ist erreichbar als ein Atrribut vom Current Objekt in jeden Ausführungszusammenhang. Jedes RequiredRights Objekt wird die selben Informationen erhalten und setzen, so daß es keine Rolle spielt welche Instanz von den
RequiredRights Schnittstellen benutzt wird. Die benötigten Rechte für die Operationen aller sicheren Schnittstellen werden angenommen, um erreichbar für jede RequiredRights Instanz zu sein. Beachte, daß Required Rights Charakteristika von Schnittstellen und nicht von Instanzen sind. Alle Instanzen von einer Schnittstelle, haben daher immer die gleichen Required Rights (benötigten Rechte).
Weil alle Required Rights durch die RequiredRights Schnittstelle definiert und erlangt werden, sind keine Ändereung von existierenden Objektschnittstellen nötigt, um die verlangten Rechte den entsprechenden Operationen zuzuordnen.
Rights Families
Um Erweiterbarkeit zu erlauben,werden Rechte in Rights Families eingeteilt. Diese RechteFamilien enthalten die standard Rechte ("corba" genannt). Diese bestehen aus:
Implementationen können verschiedene Rights Families ergänzen. Rechte werden immer gebildet von den RightsFamilies zu denen sie gehören.
Die RequiredRights Schnittstelle
RequiredRights Objekte können als Tabelle verstanden werden. Beachte, das Implementationen "RequiredRights" nicht auf der Basis von Schnittstelle-zu-Schnittstelle behandeln müssen. Das heißt, daß in vielen Implementationen alle Aufrufe von den RequiredRights Schnittstellen von einer einzigen Instanz des RequiredRights Objekts, oder von einer Anzahl von replizierten Instanzen von einer Objektinstanz verwaltet werden (wo das letztere dem Muster von Prototypen gleichkommt). Ein Eintrag einer Operation ist eine Liste von Rechten in der RequiredRights Tabelle. Es definiert ebenso einen Rechte Kombinierer (
Rights Combinator). Dieser "rights combinator" definiert, wie Einträge mit mehr als einen benötigten Recht interpretiert werden sollen. Es gibt zwei wesentliche "Rights Combinators":
Beachte, daß die folgenden Verhaltensweisen vom System von CORBA nicht spezifiziet sind, und daher von der Implementation abhängen:
get_required_rights
Diese Operation gibt die Rechte an, die zum Ausführen der Operation
operationName der Schnittstelle obj benötigt werden.. Die Obj’s Schnittstelle wird bestimmt und dann benutzt, um Auskunft über die benötigten Rechte zu erhalten. Der Ergebniswert ist eine Liste von Rechten und eine Kombinationsbeschreibung, wie die Rechte interpretiert werden sollen, wenn die Liste mehr als einen Eintrag enthält.
void get_required_rights(
in Object obj,
in Identifier operation_name,
in RepositoryId interface_name,
out RightsList rights,
out RightsCombinator rights_combinator
);
Parameter
obj Das Objekt von dem eine Liste der benötigten Rechte zurückgegeben wird.
operation_name Der Name der Operation, von der eine Liste der benötigten Rechte zurückgegeben wird.
interface_name Der Name der Schnittstelle, von der eine Liste der benötigten Rechte zurückgegeben wird.
operation_name wird definiert, wenn es verschieden von der Schnittstelle ist, von der obj instanziert wurde.
Nicht alle Implementationen benötigen diesen Parameter. Es sind im Zweifel die entsprechenden Dokumentationen zu überprüfen.
rights Die zurückgegebene Liste der benötigten Rechte
rights_combinator Der zurückgegebene "right combinator".
set_required_rights
Diese Operation ändert die benötigten Rechte zum ausführen der Operation operationName von der Schnittstelle interface. Der Aufrufer muß eine Liste von Rechten und eine Kombinatorbeschreibung übergeben. Beachte, daß korrekte Ausgaben von replizierten RequiredRights Objekten erscheinen müssen. Die Verteilung der RequiredRights Schnittstellen muß von der Implementation richtig verwaltet werden. Nach einen Aufruf von
set_required_rights müssen alle nachfolgenden Aufrufe von get_required_rights, von einen Client, die richtige Rechtliste zurückliefern.
void set_required_rights(
in string operation_name,
in RepositoryId interface_name,
in RightsList rights,
in RightsCombinator rights_combinator
);
Parameters
operation_name Der Name der Operation, deren benötigten Rechte verändert werden sollen.
interface_name Der Name der Schnittstelle, deren benötigten Rechte verändert werden sollen.
rights The desired Die neue Liste der benötigten Rechte.
rights_combinator Der gewünschte neue rights_combinator.
Die AccessPolicy Schnittstelle
Dies ist die Grundschnittstelle für alle verschiedenen Arten von Zugangskontrollpolitiken. Diese Schnittstelle unterstützt Anfrage der effektiven Zugriffsgewährung über eine Referenz durch einen Zugriffspolitikaufruf. Es enthält die Politikschnittstelle und hat eine Operation,
get_effective_rights.
get_effective_rights
Diese Operation gibt die aktuellen effektiven Rechte (von Familien /
RightsFamilies) gewährt vom AccessPolicy Objekt zu dem Subjekt, indem alle Privilegienattribute in der Referenz cred gespeichert werden.
RightsList get_effective_rights (
in CredentialsList creds_list,
in ExtensibleFamily rights_family
);
Dieser Aufruf wird das Access Policy Objekt veranlassen die erteilten Rechte mit allen Privilegienattributes der Eingangsreferenz zu kombinieren, und das Ergebnis der Kombination zurückzuliefern. Access Decision Objekte und Anwendungen, die ohne AccessDecision Objekt prüfen ob Zugriffe erlaubt sind, sollten diese Operation benutzen um die Rechte von Subjekten zuerhalten.
