Die Notwendigkeit von Policies im Allgemeinen ist bereits bekannt. Derzeit arbeiten einige Gruppen an konkreten Vorschlägen für ein allgemeines Policy-Modell. Einer dieser Vorschläge kommt von Elleson, Ed, Strassner, Weiss und Westerinen . Die Arbeit lag zum Zeitpunkt der Erstellung dieses Kapitels als Internet Draft vor.
Die hier beschriebene Version dieses Vorschlages beruht auf dem Draft vom März 1999 (strassner-policy-terms-01) inzwischen ist diese Version nicht mehr verfügbar.
Das allgemeine Policy-Modell ist in Abb. 2.3 dargestellt. Es ist nach dem Draft [ESM99c] erstellt.
Demnach gibt es ein Management-Tool , welches einen Repository Client besitzt. Dieser greift mittels eines Repository Access Protocols (dabei kann es sich um ein proprietäres Protokoll handeln) auf einen Datenbestand zu, der auf diesem Wege verwaltet wird.
Auf der Abbildung 2.3 unten rechts befinden sich PIN (Policy Ignorant Nodes) . Dabei handelt es sich um Programme und Services, die nicht mit Policies zu beeinflussen sind, da sie Policies generell nicht unterstützen oder ein inkompatibles Policy-System unterstützen.
PEP (Policy Enforcement Points) , sind Programme, die mit Policies beeinflußt werden können und Policies umsetzen können. Sie kommunizieren mit einem PDP (Policy Decision Point) , der seinerseits einen Repository Client hat, mit dem er auf den vom Managementsystem gepflegten Datenbestand zugreifen kann. Dabei ist vorgesehen, daß das Repository Access Protocol, welches zwischen Repository Client und Policy Repository sowie zwischen Policy Repository und Management Tool verwendet wird, jeweils identisch sind. Es muß aber nicht mit dem Policy Protocol, welches zwischen PEP und PDP verwendet wird, identisch sein.
Im Policy Decision Point werden ausschließlich Entscheidungen getroffen. Das Ergebnis wird dann dem Policy Enforcement Point mitgeteilt. Nur dieser besitzt die Implementierung zur Durchsetzung der Policy-Entscheidung.
Das allgemeine Vorgehen bei einer Policy-Entscheidung zeigt Abb 2.4. Ein PEP erhält ein Ereignis, welches eine policy-basierte Handlung erfordert. Der PEP stellt an den PDP eine konkrete Anfrage, was er tun soll, bzw. wie die dazugehörige Policy-Entscheidung aussieht. Der PDP wertet die ihm vorliegenden Policies aus und trifft danach eine Entscheidung. Diese übermittelt er an den PEP, der sie umsetzen kann.
Das Policy-Objekt-Modell ist in Abb 2.5 dargestellt. Es handelt sich um ein komplettes Objektmodell einer Policy. Dieses Modell beinhaltet sechs Hauptklassen.
Die Klasse Policy enthält vier Attribute: commonName (cn), caption, description und policyKeywords. (siehe Abb 2.6)
Klasse policy]Klasse policy
Die Klasse Policy hat im Original-Modell zwei direkte Unterklassen: PolicyRule und PolicyGroup . Im oben beschriebenen Management-Modell wäre es allerdings denkbar die Klasse PolicyGroup anstatt der Klasse Group zu verwenden, bzw. umgekehrt. Group ist eine Unterklasse der Klasse Verwaltung .
Die Klasse PolicyGroup enthält im Modell Instanzen der Klasse PolicyGroup oder PolicyRules . Sie ist als reine Container-Klasse gedacht (siehe Abb. 2.7. Dabei ist zu beachten, daß die Klasse PolicyGroup entweder PolicyRules oder PolicyGroups enthalten darf, aber nicht beide.
Klasse policyGroup]Klasse policyGroup
Diese Klasse hat als Attribut einen Namen, der wie cn der Klasse
policy
lediglich zur leichteren Benennung durch Menschen zu verwenden ist.
Die Klasse policyRule enthält drei Unterklassen: policyCondition , PolicyTimePeriod und PolicyAction.
Eine policRuleCondition ist in der Regel entweder ein Set, welches mit 'OR' verbunden ist und jede Einzelregel innerhalb dieses Sets mit 'AND' verbunden ist (Disjunktiv Nornmalform (DNF)) oder ein Set, welches mit 'AND' verbunden ist und jede Einzelregel innerhalb dieses Sets mit 'OR' verbunden ist (Konjunktiv Normalform (KNF)) dargestellt.
Einzelne Regeln können zusätzlich negiert sein. Eine policyRule darf dann und nur dann ausgeführt werden, wenn ihre Auswertung TRUE ergibt - egal ob es sich um KNF oder DNF handelt.
Die genaue Regel, wann etwas auszuführen ist, wird in der Unterklasse policyCondition abgelegt. In der Unterklasse policyRule ist festgelegt, was im Falle einer erfüllten policyCondition zu tun ist.
Die Unterklasse policyTimePeriodCondition beinhaltet eine Angabe über den Zeitraum, an dem diese spezielle policyRule gültig ist.
Klasse policyRule]Klasse policyRule
Die Klasse policyRule hat folgende Attribute:
Der Sinn der Klasse policyCondition ist es, festzulegen wann das Set policyActions auszuführen oder nicht auszuführen ist.
Klasse policyCondition]Klasse policyCondition
Die Klasse hat ein einzelnes Attribut policyConditionName, welches
lediglich einen benutzerfreundlichen Namen enthält.
Die Klasse policyTimePeriodCondition liefert eine Möglichkeit anzugeben, in welchen Zeitabschnitten diese spezielle policyRule aktiv ist und somit auf das System wirken kann. Ist in einem policyRule keine policyTimePeriodCondition angegeben, wird davon ausgegangen, daß diese policyRule immer aktiv sein soll.
policyTimePeriodCondition ist als direkte Unterklasse der Klasse policyCondition definiert. Sie enthält bis zu fünf Attribute, die Zeitperioden definieren. Ist ein Attribut nicht explizit angegeben, wird auch hier wieder davon ausgegangen, dass es die Wirkungszeit nicht einschränkt, also immer gültig ist.
Klasse policyTimePeriodCondition]Klasse policyTimePeriodCondition
Die Spezifikation [ESM99c] beinhaltet noch einige zusätzliche Klassen, welche hier nicht erwähnt sind. Diese dienen der zusätzlichen Gruppierung einzelner policyAction und policyCondition-Klassen. Die daraus entstehende Komplexität ist für den hier vorgesehenen Verwendungszweck allerdings nicht nötig.