next up previous contents
Nächste Seite: 5.10 Domänenbildung Aufwärts: 5. Ein Sicherheitsmodell für Vorherige Seite: 5.8 Autorisierung   Inhalt

Unterabschnitte


5.9 Delegation

Mit Hilfe einer Policy ist nun die fallweise Erteilung eines Rechts für die Ausführung einer Aktion möglich. Für die in 2.5 geforderte Möglichkeit der Delegation, der Weitergabe von Rechten, ist es notwendig, diese persistent formulieren zu können. Dabei genügt es nicht, einfach nur das Recht zu betrachten, da dieses keine Beziehung zur berechtigten Entität besitzt.


Beispiel: Habe eine Agentengattung A gemäß der Permission Policy eines Agentensystems S das Recht Lesen der Datei F. Eine Agentengattung B solle dieses Recht gemäß der Permission Policy nicht haben.

Um einer Instanz von B dieses Recht für die Durchführung einer Teilaufgabe im Auftrag von einer Instanz A erteilen zu können, wäre ein naiver Ansatz jener, daß jede Agenteninstanz eine Liste von Rechten mit sich führt.

Trage eine Instanz von B also das Recht zum Lesen von F mit sich. Nur wie kann dann entschieden werden, ob B durch A ermächtigt wurde F zu lesen, oder B sich dieses Recht illegalerweise selbst eingeräumt hat?


5.9.1 Persistenz von Rechten: Capabilities

Anhand des Beispiels läßt sich erkennen, daß an ein Recht unmittelbar zwei weitere Attribute geknüpft sind:

Dieses 3-Tupel aus Recht, Eigentümer und Aussteller soll fortwährend als Capability bezeichnet werden.

Um nun die Authentizität einer Capability sicherstellen zu können bietet sich wiederum das Verfahren der digitalen Signatur an: Das 2-Tupel bestehend aus Recht und Eigentümer wird vom Aussteller signiert. Damit kann eine beliebige Instanz die Authentizität der Capability überprüfen, indem es die Signatur über Recht und Eigentümer überprüft. Weiterhin tritt mit der Signatur der Aussteller als Bürge für die ``Rechtmäßigkeit'' des Besitzes des genannten Rechts auf.

Mit den Capabilities wurde somit eine Möglichkeit geschaffen, daß eine Agenteninstanz eine Liste von Rechten mit sich trägt und überprüft werden kann, ob die Agenteninstanz tatsächlich über die in der Liste verzeichneten Rechte verfügt.

Die Rechte, die durch eine Permission Policy erteilt werden lassen sich nun ebenfalls als Capability formulieren: Wird für eine konkrete Entität gemäß einer Permission Policy ein Recht eingeräumt, so stellt dies eine implizite Capability dar, mit der konkreten Entität als Eigentümer und der autorisierenden Entität, die die Permission Policy auswertet, als Aussteller. Damit lassen sich also Permission Policies benutzen, um konkrete Capabilities zu erstellen.

5.9.2 Autorisierung mittels Capabilities

Für die Autorisierung einer Aktion können nun neben den sich aus der Permission Policy ergebenden Rechten auch die von der Agenteninstanz mit sich getragenen, expliziten Capabilities herangezogen werden.

Wird nämlich ein benötigtes Recht nicht durch die Permission Policy erteilt, so könnte eine Agenteninstanz immer noch eine Capability des entsprechenden Rechts vorweisen.

Um nun die Autorisierung vornehmen zu können, müssen die folgenden Fragen geklärt werden:

  1. Ist die Capability authentisch?

  2. Ist die Agenteninstanz der Eigentümer der Capability?

  3. Ist der Aussteller der Capability vertrauenswürdig?

Die Fragen 1 und 2 lassen sich nach dem vorangegangenen Abschnitt eindeutig klären.

Frage 3 ist nun wiederum eine individuelle Entscheidung, die eine autorisierende Instanz über die eigene Permission Policy klären kann, beispielsweise indem diese Regeln enthält, die bestimmte Entitäten als vertrauenswürdige Bürgen für Rechte bzw. Aussteller von Capabilities markiert.

Somit wird es möglich, daß eine autorisierende Entität Aktionen genehmigt, ohne daß sie selbst vorher explizit Kenntnis der hierfür benötigten Rechte hat, indem sie sich bei der Autorisierung auf einen vertrauenswürdigen Stellvertreter verläßt.

5.9.3 Ketten von Capabilities: delegierte Rechte

Abbildung 5.10: Principals mit Zertifikaten und Capabilities
\begin{figure}
\centering\includegraphics [width=1.0\textwidth]{principals3_illu_argo}\end{figure}

Mit den vorgestellten Konzepten läßt sich nun auch die ``Weitergabe'' von Rechten vergleichsweise einfach realisieren. Die entsprechende Erweiterung des UML-Diagramms um Capabilities ist in Abbildung 5.10 dargestellt.

Eine Agenteninstanz, die über eine Capability verfügt, kann diese an eine andere Agenteninstanz weitergeben, indem sie selbst eine neue Capability des gleichen Rechts mit der anderen Agenteninstanz als Eigentümer ausstellt. Damit entsteht eine Kette von Capabilities gleichen Rechts, die über die Aussteller und Eigentümer der einzelnen Capabilities verknüpft ist.

Betrachtet man das eingangs vorgestellte Beispiel der beiden Agenteninstanzen A und B, so kann A das Recht F an B folgendermaßen weitergeben: A erzeugt eine neue Capability über F_lesen, in der B als Eigentümer eingetragen ist und A selbst als Aussteller fungiert. A übergibt die Capability an B. Will B nun tatsächlich die Datei F_lesen, führt S folgende Überprüfungen durch:

  1. Hat B gemäß der Permission Policy das Recht F zu lesen: Nein (nach den Annahmen zum Beispiel).

  2. Hat B eine Capability die Datei F zu lesen: Ja, explizit.

  3. Ist A, der Aussteller der Capability, vertrauenswürdig: Nein

  4. Besitzt A eine Capability die Datei F zu lesen: Ja, nämlich implizit über die Permission Policy.

  5. Ist S, der Aussteller der impliziten Capability, vertrauenswürdig: Ja

Damit konnte die Aktion F_lesen für die Agenteninstanz B autorisiert werden, obwohl S diese Aktion selbst nicht direkt durch seine Permission Policy gestattet, indem über die Kette der Capabilities ein vertrauenswürdiger Aussteller (in diesem Beispiel S selbst) gefunden wurde.

Optional kann, ebenfalls über eine Policy gesteuert, auch noch die zusätzlich Abfrage gestellt werden, ob eine Instanz als berechtigt angesehen wird, überhaupt Capabilities weiterzugeben.


next up previous contents
Nächste Seite: 5.10 Domänenbildung Aufwärts: 5. Ein Sicherheitsmodell für Vorherige Seite: 5.8 Autorisierung   Inhalt
harald@roelle.com